Re: isc-dhcp-client sends DHCPDISCOVER *before* wpa_supplicant authenticates/associates/connects.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jaime T wrote:
> It works (almost) perfectly! For ages I've been baffled by why my dhcp
> server never responds to clients' first DHCPDISCOVER messages, but a
> quick look at the log shows why:
> [...]
>
> 22:58:05 dhclient[2830]: DHCPDISCOVER on wlo1 to 255.255.255.255 port
> 67 interval 4
>[...]
> 22:58:08 kernel: wlo1: associated
> [...]
> 22:58:09 dhclient[2830]: DHCPDISCOVER on wlo1 to 255.255.255.255 port
> 67 interval 7
> 22:58:09 dhclient[2830]: DHCPREQUEST of 192.168.0.15 on wlo1 to
> 255.255.255.255 port 67
> 22:58:09 dhclient[2830]: DHCPOFFER of 192.168.0.15 from 192.168.0.1
> 22:58:09 dhclient[2830]: DHCPACK of 192.168.0.15 from 192.168.0.1
>
> As you can see, *after* wpa_supplicant has successfully authenticated,
> associated and connected (all of which it does perfectly on the first
> attempt), the following DHCPDISCOVER is "processed" correctly. Which
> then begs the question: why send a DHCPDISCOVER at 22:58:05 given that
> it's guaranteed to fail?
Because presumably it triggered on the interface coming up (even though
it wasn't link-ready). The log snippet didn't show what happens before.
It's only "processed" correctly because the upstream DHCP server got the
DISCOVER packet. Prior being authenticated to the WiFi, the AP will
have dropped the traffic.
>
> Questions:
> 1) Is this a bug?
Not necessarily. You'll likely have to look slightly farther back in
the logs to confirm what's happening. Looks to me like it's operating
on the premise "link's gone active, I can send a DISCOVER". This would
generally work fine for any connection not requiring further
authentication (e.g. wired ethernet or open wifi).
> 2) If it's a bug, in which package?
user. :)
> 3) Are there any quick-and-dirty workarounds until it's fixed? Is
> there a hack to serialize dhclient so that it waits until after the
> CTRL-EVENT-CONNECTED (perhaps based on systemd)?
If it were a bug, then there might be a workaround. As it currently
isn't (at least as far as a quick google can tell me), there's no
"workaround" for the "bug(tm)".
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAlxiqMEACgkQjhHd8xJ5
ooHoNggAj/SCFR4Z9Y+vm7bXNXUzhJHS6OxZztGqxOjl9GDbZkF2u81lYRjx+MQU
fWWSL0H4EW/4n/w1QIf7jy6rdLOw5LR6+d4ozmzCwhabScxXSJB2LsKW7Fcl6LWD
XXbNiu+8zg22+yQTdohJ+9+0mMWyfA03qeKV0qxwMCDRXytHXI/UIsaT+9MKzqKQ
KLKIBqW0wvUWf5USYeEedpE9hyj+SXoGRW8S2WJPX2tR5owmEE4kGwnwTgUZBVRM
t3LzqyUhStnBKKo1H5KYlo6TWAl/sB/LRfStqUmU2S1piJvqHM4ZIUm9pgRm7Agw
55Y0lqb/9a6Ykij/4fMYP7fylzeSJA==
=9qgs
-----END PGP SIGNATURE-----
--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281
Reply to: