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.]_________________Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
GNU/Linux user #369763

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

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.

Quote:

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

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._________________Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
GNU/Linux user #369763

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 _________________Kind regards,
Xavier Miller

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._________________Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
GNU/Linux user #369763

one question. Why?_________________The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king

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..

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)

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.

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._________________Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
GNU/Linux user #369763

@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?

@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.