TIP: Complete network stack without net.* scripts

Message

VinzC · Post by **VinzC** » Sun Aug 11, 2013 7:25 pm

smartass wrote:VinzC, I use rfkill because AFAIK it can save power (may not be true for all cards). I recommend you assign a special key you don't use very often to issue rfkill through your WM or DE.

Not required. IIRC unloading the kernel module (iwlwifi) is enough to stop the wireless adapter (at least on my machine). As far as power is concerned the video adapter (Radeon) consumes far more than the wifi card, alas, which shows a negligible consumption in comparison. [OT: That's why I'm looking forward to 3.11 and DPM for ATI cards. But that's another story.]

UberLord · Post by **UberLord** » Mon Aug 19, 2013 9:53 am

I would just like to say thanks to VincZ for documenting and promoting what I originally set out to do with the OpenRC network (not the net.*) script and dhcpcd.
Basically, configure conf.d/network to brink up the link (bridging, bonding, authentication, etc) and let dhcpcd handle everything else.

Of note re wpa_supplicant, dhcpcd-6 will start (and stop) wpa_supplicant if /etc/wpa_supplicant.conf exists by itself.
This is handy because I can now plug and unplug a USB wifi card and It Just Works

No need for udev, ifplugd, NM or anything else.

smartass · Post by **smartass** » Mon Aug 19, 2013 11:32 am

UberLord wrote: Of note re wpa_supplicant, dhcpcd-6 will start (and stop) wpa_supplicant if /etc/wpa_supplicant.conf exists by itself.
This is handy because I can now plug and unplug a USB wifi card and It Just Works

No need for udev, ifplugd, NM or anything else.

I appreciate that you've added so many features, but isn't it a bit too far against the unixy way of having one tool do its job well and do only that job?

OTOH, it's incredible that you've managed to this on your own in one tool and the people at RH have been failing to make it so simple and automagic for years

But seriously, isn't it a bit close to reinventing the wheel?

UberLord · Post by **UberLord** » Mon Aug 19, 2013 11:49 am

smartass wrote:
UberLord wrote: Of note re wpa_supplicant, dhcpcd-6 will start (and stop) wpa_supplicant if /etc/wpa_supplicant.conf exists by itself.
This is handy because I can now plug and unplug a USB wifi card and It Just Works

No need for udev, ifplugd, NM or anything else.
I appreciate that you've added so many features, but isn't it a bit too far against the unixy way of having one tool do its job well and do only that job?

Not at all, when you view that the job of dhcpcd is just to configure network interfaces - it's not just a DHCP client.
And it does configure network interfaces very very well

OK, interacting so directly with wpa_supplicant is a little out of scope as dhcpcd doesn't really want to manage link configuration BUT it's a great example of how the hook scripts work.
The main reason why I included it is for the benefit of the BSD systems I also use where the user is entirely expected to script hotplugging, unlike say in Gentoo where this is achieved via udev and OpenRC automatically.

OTOH, it's incredible that you've managed to this on your own in one tool and the people at RH have been failing to make it so simple and automagic for years

But seriously, isn't it a bit close to reinventing the wheel?

Thanks

It's not re-inventing the wheel at all. It's about making the wheel better with less maintenance.
Think about how many different parts other systems have, now think about many different parts dhcpcd has.

VinzC · Post by **VinzC** » Mon Aug 19, 2013 6:26 pm

UberLord wrote:I would just like to say thanks to VincZ for documenting and promoting what I originally set out to do with the OpenRC network (not the net.*) script and dhcpcd. [...]

It's my pleasure, Roy, totally.

Even after hacking the network stack and creating my own set of tools I still felt like I had underused dhcpcd all those years. So I dug a little and decided to share my findings. And I have to admit it is a remarkable tool of simplicity.

xaviermiller · Post by **xaviermiller** » Tue Sep 17, 2013 10:13 am

Hello,

I tried the tip, and I would like to migrate preup() and postup() hooks I have in /etc/conf.d/net, especially the SSID variable. But moving preup() and postup() from net to network don't help.

Any idea?

smartass · Post by **smartass** » Tue Sep 17, 2013 11:54 am

XavierMiller, you could use the hooks framework that dhcpcd offers. See the manual page of

Code: Select all

dhcpcd-run-hooks

according to

Code: Select all

dhcpcd --variables

the ssid variable can be set, so you could add a case construct for that.

xaviermiller · Post by **xaviermiller** » Tue Sep 17, 2013 12:19 pm

Thank you, I will take a look tonight

Dr.Willy · Post by **Dr.Willy** » Tue Sep 17, 2013 2:59 pm

wireless specific actions can also be triggered via "wpa_cli -a <script>"

xaviermiller · Post by **xaviermiller** » Tue Sep 17, 2013 6:02 pm

Hello,

I have an other issue : wpa_supplicant is not run on hotplugged wlan interfaces (usb sticks). If I restart the service, the USB stick is activated.

VinzC · Post by **VinzC** » Tue Sep 17, 2013 6:26 pm

XavierMiller wrote:I have an other issue : wpa_supplicant is not run on hotplugged wlan interfaces (usb sticks). If I restart the service, the USB stick is activated.

Have you installed >=dhcpcd-6.0 ?

xaviermiller · Post by **xaviermiller** » Tue Sep 17, 2013 6:30 pm

Yup, I'm running ~arch

Code: Select all

[ebuild   R    ] net-misc/dhcpcd-6.0.5-r1  USE="-ipv6" 0 kB

PS: if I pollute that thread, I could open a new one.

xaviermiller · Post by **xaviermiller** » Thu Sep 19, 2013 10:18 am

I will take a look at this wpa_supplicant hook : http://fossies.org/linux/misc/dhcpcd-6. ... supplicant

EDIT: found! The hook looks /etc/wpa_supplicant.conf which is not correct in Gentoo. If I create a symlink, wpa_supplicant is managed by dhcpcd
I will file a bug

VinzC · Post by **VinzC** » Thu Sep 19, 2013 11:26 am

XavierMiller wrote:I will take a look at this wpa_supplicant hook : http://fossies.org/linux/misc/dhcpcd-6. ... supplicant

EDIT: found! The hook looks /etc/wpa_supplicant.conf which is not correct in Gentoo. If I create a symlink, wpa_supplicant is managed by dhcpcd
I will file a bug

IMHO the bug is not needed as it looks like a configuration parameter. Try setting wpa_supplicant_conf in dhcpcd.conf to the real path and see how it works.

xaviermiller · Post by **xaviermiller** » Thu Sep 19, 2013 11:38 am

it also works

For the moment, I write my hook to set-up some hostpot scripts and other stuff, and it seems to work.

EDIT: it works !

Naib · Post by **Naib** » Fri Sep 20, 2013 12:35 pm

one question. Why?

xaviermiller · Post by **xaviermiller** » Fri Sep 20, 2013 12:44 pm

Because I don't want to need nice GUIs, which are unnecessary to configure 2-3 networks. And so, I avoid unnecessary bullshit that change every 2 years (HAL, Systemd, *kit).

And I need to configure 2 things depending on the discovered network
- set DISTCC features at home, when the distcc server is up and running
- execute a logon script on hotspot used at work

Because KISS.

VinzC · Post by **VinzC** » Fri Sep 20, 2013 1:59 pm

Naib wrote:one question. Why?

XavierMiller wrote:Because I don't want to need nice GUIs, which are unnecessary to configure 2-3 networks. And so, I avoid unnecessary bullshit that change every 2 years (HAL, Systemd, *kit).
[...]
Because KISS.

Ditto.

Incomplet · Post by **Incomplet** » Sat Mar 22, 2014 5:16 pm

dhcpcd is perhaps the most awesome piece of software that I've ever come across. It's awesome even if you don't configure it, and more awesome when you do. It's also the most reliable network manager that I have ever used, free or otherwise. The network manager on OSX would randomly stop working and if the network went screwy there was no chance of bringing it back without a restart (or two). On windows the manager does screwy things sometimes, and you never know what kind of garbage MS has in the pipe at any time. dhcpcd, on the other hand, has always "just worked" for me, no matter what (although the rest of my system is another story..). The wind will knock out all my powerlines and bring my machine down before dhcpcd will give me problems, and I can hardly blame it for not working then.

The mere fact that it's still being improved astounds me. If only gnome had that sort of accountability..

UberLord · Post by **UberLord** » Sat Mar 22, 2014 7:47 pm

Incomplet · Post by **Incomplet** » Sat Mar 22, 2014 9:26 pm

aand, now testing with no net.* scripts, and it looks to be working as advertised. At first I thought it hadn't worked, since with background and quiet I couldn't even see the entry in openrc. But no, fully automagical.

How on earth did you do that, anyway? Test driven development? Magic? (the only options I can come up with)

UberLord · Post by **UberLord** » Sat Mar 22, 2014 11:41 pm

Magic is not depending on the FOTM middleware. dhcpcd communicates only via libc and listens only via the kernel (ok, dhcpcd does have a udev plugin so that udev can do its pointless device naming). These channels of communication are defined by agreed standards, such as POSIX and in the case of Linux, netlink. But this is not magic, this is common sense.

From my Debian amd64 box

Code: Select all

roy@uberpc:~/src/dhcpcd$ size /sbin/dhcpcd /sbin/dhclient /usr/sbin/NetworkManager
   text	   data	    bss	    dec	    hex	filename
 194982	   1544	    432	 196958	  3015e	/sbin/dhcpcd
1620973	  24576	  45264	1690813	 19ccbd	/sbin/dhclient
1012178	  22656	   3016	1037850	  fd61a	/usr/sbin/NetworkManager

And that's not including any GUI components. Magic

VinzC · Post by **VinzC** » Sun Mar 23, 2014 5:53 pm

Since my favourite Troll has been invited (hehe

) I'd just add onto the MS weirdness that I've always been amazed at why on Earth Microsoft decided to make interface precedence but *manual* (interfaces are sorted... alphabetically). We have the issue systematically at work when we receive pre-installed machines or when reinstalling them: wireless interfaces always take precedence over the wired interfaces and you have to manually reorder them, i.e. move the wired interface to the top of the list.

On Linux it is automatic. Besides, traffic automatically switches to the fastest interface when you plug the cable, no need to restart existing connections.

Magic sometimes relates to common sense.

Incomplet · Post by **Incomplet** » Sun Mar 23, 2014 9:22 pm

@RM: Yeah, I've noticed that upstream sucks. It's really sad if the rest of gnu/linux could be that good if only certain people weren't trying to play monopolyOS. It's also amazing in a way, given all the limitations of C.

@Vinz: *sigh* dhcpcd also automatically stops the wireless card/driver in that situation too, doesn't it? What is it people have against sensibility, anyway?

UberLord · Post by **UberLord** » Sun Mar 23, 2014 9:41 pm

Incomplet wrote:@Vinz: *sigh* dhcpcd also automatically stops the wireless card/driver in that situation too, doesn't it? What is it people have against sensibility, anyway?

No, dhcpcd just changes the default route to go via wired.
If both are on the same subnet (which they really shouldn't be) then it will change the subnet route also on BSDs = on Linux there is no need thanks to routing metrics.

The only thing dhcpcd will stop is wpa_supplicant if the interface goes away.