Simple Networking in Linux | Hacker News Reader

Simple Networking in Linux

insanity.industries

101 pointsgravitate16 comments

I'm sorry but i fail to see how this is _simple_ networking. It shows the state of Linux these days. Compare that with OpenBSD's interface to do the same thing.

wired: ifconfig [if] autoconf up

wireless: ifconfig [if] join [ssid] wpakey [pass] autoconf up

Consistent documentation existing in man ifconfig. The sad thing is that Linux used to be designed not evolved.

I agree that it's not simple, but systemd networkd is far simpler than network configuration has been on Linux for a long time.

Its not simpler, its more complex than ever. Its only easier to use.

"Simple Made Easy" - Rich Hickey (2011) [0] explains the difference.

[0] https://www.youtube.com/watch?v=SxdOUGdseq4

You can use `ifconfig` / `ip link` if you want. The submitted article is about having systemd-networkd manage it.

i would also need wpa_supplicant for the wifi though. i would also need to install ifconfig or iptools and making sure that systemd/network-network manager respects my config. I would also need to figure out the interface's name-du-jour or add udev rules to force a name of my preference. I hope you see my point.

I wanna see this person debug their networking when it goes wrong. Stepping through udev and dbus must be fun.

It's probably par for the course. Networking is an area that's always felt like shifting ground. Anytime I need to spin up a machine with WoL or (rarely) need to edit something at the conf level, it's always a software archeology project, trying to figure out what the new hotness is, where the system vs user config is under the new networking package, grokking the new config syntax/options, and what supercedes if/when multiple networking packages exist on the same host.

Knowing the reality, looking at the domain name, given the title, and that it starts off:

> It is time to revisit of the simple wifi setup as much has changed [in a year]

I am led to believe this is satire.

> I am led to believe this is satire.

Looking at their other posts, some very serious not funny at all kind of satire.

This actually reminds me of sound on Linux too. I'm running a bleeding edge Tumbleweed on my laptop and Home Cinema. I now have to occasionally tweak ALSA, PulseAudio and PipeWire stuff. I know that by installing pipewire-pulse, I'm actually using PipeWire, but since it still relies on a heap of PulseAudio conf files and command line utilities, it feels like they've added one more thing to be confused about rather than simplifying the setup. Just try to figure out how to upmix stereo to 5.1 with an LFE channel to your subwoofer. Do you use the (now renamed) lfe options in pulse daemon.conf, some pipewire conf, or the extremely arcane ALSA ttable mappings? There has never been a decent GUI for handling audio in Linux. Sometimes I wonder if I should also install Jack to see if that complicates it more or simplifies it.

Oh, does networking ever get fun. Debugging udev sounds like easy mode. At least it's userspace and has logs. I've been beating my head against this one problem for days with no progress whatsoever.

Scenario:

Host: Laptop (192.168.0.2) Outer VM: Ubuntu (192.168.122.254, assigned by libvirt) Inner VM: Ubuntu (10.0.0.2)

Inner VM is a normal Ubuntu install, nothing odd about it.

Outer VM is setup to MASQUERADE Inner's IP address. It's all straightforward. There's only one exit network interface, and iptables is set up perfectly normally. Copy/pasted from the docs even just to be sure.

Checking stats shows that the NAT table is not actually being hit. Inner's packets get forwarded to Host with the IP address un-NATed. Stuff obviously doesn't work.

And how exactly do you debug this? How do you ask the kernel, "hey, why do you think this particular packet has no need to go through the NAT table?"

In general for networking kernel-side what you get is that if you're lucky you get an error number which doesn't even come close to explaining what the actual problem is. If you're not, stuff just fails to work with no explanation whatsoever. Yeah, you can add log rules, but it's kind of a problem when the table you think should be consulted just isn't, at all.

Well, I guess at least there's source code. Hope it doesn't come to that.

I mean its one way of setting up your networking. But I'm not sure I would call it simple.

I have been burned by systemd-resolved. It seems like a black box that does silent automagical stuff in a non transparent way. I am keen to hear what the advantages are though. (barring stats and DNSSEC.)

_personally_ I am still a fan of /etc/network/interfaces and or whatever redhat style machines do.

I have also used network manager, which is sorta ok, but when stuff starts failing it seems to suck donkeyballs. (it also crashes when you start doing auth)

On the wired I'm a fan of doing the extra work to [Match] against MACAddress= then rename it to something friendly. Makes things clearer in logs and shows. It's worth noting you probably want to stick to [a-zA-z]{2,8} even though other things and longer/shorter names are allowed.

That second Z was supposed to be capitalized. I guess my edit didn't actually go through when I made it and now it's too late.

s/Linux/systemd (not how to avoid the Socket BSD API as I was hoping for)

> For modern domain name resolution, you can use systemd-resolved, which provides statistics, automated caching of DNS requests, DNSSEC validation and much more.

I was gonna ask how to check this stuff out, but then I found it: `resolvectl`. I think it may have previously been the command `systemd-resolve`.

`resolvectl statistics` will spit out those statistics and `resolvectl flush-caches` could help with some DNS issues by making resolved forget everything. There's plenty of other commands in there too.

Reply on news.ycombinator.com