On Sat, Feb 26, 2022 at 11:54 AM Roy Marples <r...@marples.name> wrote:
>
> On 26/02/2022 07:53, Martin-Éric Racine wrote:
> > On Fri, Feb 25, 2022 at 3:52 PM Roy Marples <r...@marples.name> wrote:
> >>
> >> On 25/02/2022 09:25, Martin-Éric Racine wrote:
> >>> Right now, my personal experiements with dhcpcd indicate that
> >>> something as simple as passing options to wpa_supplicant via dhcpcd's
> >>> configuration file is not an easy task.
> >>
> >> Why would you want to? They have separate domains of responsibility. One
> >> configures the addressing and routes and other misc related stuff and the
> >> other
> >> brings up the actual link to do this on.
> >
> > Because having the configuration data for all interfaces is
> > /etc/network/interfaces' whole point.
>
> Then get /etc/network/interfaces to control wpa_supplicant and don't abuse the
> dhcpcd hook.
Something like this?
allow-hotplug enp9s0 wlp12s0
iface enp9s0 inet manual
iface wlp12s0 inet manual
wpa-ssid <SSID>
wpa-psk <password>
That would probably work. The 'manual' method would let dhcpcd do its
job in the background.
> >> dhcpcd's wpa_supplicant hook was written to solely support hotplugging a
> >> USB
> >> wireless stick into a machine without any kind of hotplug support.
> >> Since then I have added then -M flag to wpa_supplicant so it can do it by
> >> itself.
> >
> > Which is a problem. dhcpcd and systemd currently compete for control
> > of the wireless device. systemd tries to rename it to follow
> > Predictable Network Interface Names at the same time as dhcpcd tries
> > to to connect it to a network. It results in configuration failing.
>
> Oh please.
> This issue was 9 solved years ago when I wrote a udev plugin for dhcpcd that
> forces dhcpcd to only "use" the interface when udev says the name has settled.
> https://github.com/NetworkConfiguration/dhcpcd/commit/12bbc8cb5c7507be15a7e0af4140c3d81125c46c
Sure enough, existing Build-Dep inherited from the current packaging
did not pull libudev-dev. Added. Built and tested. Works well. Thanks
for pointing that out.
> > Also, unless I missed something, dhcpcd doesn't currently have the
> > built-in logic to understand whether a device is wireless (needs WPA)
> > or not (doesn't need anythign else than DHCP).
>
> You have missed something.
> dhcpcd can set a profile per SSID so in dhcpcd.conf you could do this
>
> profile AP1
> static ipaddress=192.168.1.100/16
>
> profile AP2
> static ipaddress=10.100.32.1/8
>
> In the hook scripts you also have ${if_wireless} to examine.
Noted.
Martin-Éric
