Roy Marples

Not relevant to a fix, but 6299f1f1cabecdee1f82e06fc6cce234f933eea9 is related just by the actions happening here.

udev is also in play here, so whilst `ip monitor` might not show anything, it could be a bug in udev announcements looping. I have no idea how to work...

from dhcpd.conf.5 > ssid ssid Subsequent options are only parsed for this wireless ssid. It's documented in the same way as interface and arp profile options. Is this not good...

There is no relationship between the ssid dhcpcd option and the wpa supplicant hook script. Since I added the -M option to upstream wpa supplicant, my personal need and infact...

https://w1.fi/cgit/hostap/commit/wpa_supplicant/wpa_supplicant.c?id=2e997eece5776eca0a99d53893e343539f9f8eb2 I’m pretty sure there has been a release in the past 10 years.

So the ssid option in dhcpcd is an instruction of what dhcpcd should do when it connects to that ssid. There is no support for setting any wireless options in...

So that sounds like a Debian issue? Gentoo for example has had it enabled for a long time: https://gitweb.gentoo.org/repo/gentoo.git/tree/net-wireless/wpa_supplicant/wpa_supplicant-2.10-r6.ebuild#n142

To be clear, the wpa_supplicant -M option with the parameter of "*" to match all interfaces is the equivalent of the wpa_supplicant hook script here.

No it doesn’t. dhcpcd doesn’t care about wpa supplicant or any other userland mechanism of link management. Debian for example encourages ifupdown which favours explicit interface enablement and could start/stop...

Is there anything to do here or can we close this bug?