Wireless client nic set for DHCP does not start dhclient
|Affected version:||2.1||Affected Architecture:|
I've configured a wireless nic as a client (infrastructure) on Opt3. It is set for DHCP but although the link comes up, there is no dhclient process for opt3.
The wireless nic is a Ural device, but that shouldn't matter. It's worked in the past. (2.0)
Set the retry value to 60 seconds, this is not attempts, this is seconds before it needs a reply. So if the DHCP server was any sort of slow it would fail to aquire a lease. This was true for my wireless network at home. Plus, on various other lossy links, even cable modems this could be true.
Redmine ticket #2440
The retry statement determines the time that must pass after the
client has determined that there is no DHCP server present before
it tries again to contact a DHCP server. By default, this is
#1 Updated by Seth Mos about 1 year ago
Error output only lists:
ural0_wlan0: no link .............. giving up
Since launching the dhclient process manually works this is perhaps a timing issue. The link does come up at a normal pace, but it does take a few seconds compared to ethernet. Not sure where the grace period went
#2 Updated by Seth Mos about 1 year ago
check_reload_status is firing off for vr1, but not for ural0_wlan0 eventhough the kernel is marking it as up.
Jan 1 01:37:35 php: : DEVD Ethernet attached event for wan Jan 1 01:37:29 kernel: vr1: link state changed to UP Jan 1 01:37:29 check_reload_status: Linkup starting vr1
but not ural0_wlan0
Jan 1 01:35:22 kernel: ural0_wlan0: link state changed to UP
#3 Updated by Seth Mos about 1 year ago
The wireless interface reconfigure (Even with persist settings toggled) causes the interface to go down which then needs a couple of seconds before it establishes link again.
May 20 13:47:42 kernel: ural0_wlan0: link state changed to UP May 20 13:47:41 php: /interfaces.php: The command '/sbin/dhclient -c /var/etc/dhclient_opt3.conf ural0_wlan0 > /tmp/ural0_wlan0_output > /tmp/ural0_wlan0_error_output' returned exit code '1', the output was '' May 20 13:47:28 kernel: ural0_wlan0: link state changed to DOWN
And because check_reload_status does not trigger on the link UP and launches DEVD for the interface it never goes online.
#5 Updated by Seth Mos about 1 year ago
- Status changed from Resolved to New
Helps in most cases but can still cause it to take too long making the dhcp client fail. Needs proper check_reload_status support.
#6 Updated by Seth Mos about 1 year ago
Hoping the devd changes resolve this, hoping for the best. Wireless is 802.11, not ethernet
#8 Updated by Seth Mos about 1 year ago
I performed more devd.conf changes, the media type is not recognized so I made it act on the _wlan subsystem now.
I also fixed the _vip subsystem match as that didn't trigger before. devd implies ^ at the start of the match, so it must be a full regexep.
Ermal committed changes to check_reload_status so that the _ is allowed.
- Status changed from Feedback to New
Ok, this is definitely not fixed, I can't make sense of it. Deferring.
Cold boot on the alix with 2.0.2 RC1 works. However, the moment the link goes down it enters the up down cycle similar to 2.1
What happens is that the interface is brought down, dhclient is started, and after dhclient times out because there is no link, the kernel states it has become up, so something must be up in the ordering of the commands.
Managed to track it down on a 2.0.2 RC. Turns out that the re-configure of a existing link brings the interface down for a bit. Combined with the killing of wpa-supplicant.
Basically we need to fetch the entire wireless nic state, similar to what is done for the wireless_clone mode to see if it needs to reconfigure. That should be good enough to prevent interface_wireless_configure() from dropping the link causing link cycling.
#12 Updated by Ermal Luçi 4 months ago
For bootup issues i pushed a fix to create the clone early.
For reconfigure it should not be an issue since interface configure will re-start the dhcp client.