Project

General

Profile

Actions

Bug #2440

closed

Wireless client nic set for DHCP does not start dhclient

Added by Seth Mos almost 12 years ago. Updated over 10 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Interfaces
Target version:
Start date:
05/19/2012
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.1
Affected Architecture:

Description

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)

Actions #1

Updated by Seth Mos almost 12 years 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

Actions #2

Updated by Seth Mos almost 12 years 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

Actions #3

Updated by Seth Mos almost 12 years 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.

Actions #4

Updated by Seth Mos almost 12 years ago

  • Status changed from New to Resolved
Actions #5

Updated by Seth Mos almost 12 years 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.

Actions #6

Updated by Seth Mos almost 12 years ago

Hoping the devd changes resolve this, hoping for the best. Wireless is 802.11, not ethernet

Actions #7

Updated by Seth Mos almost 12 years ago

  • Status changed from New to Feedback
Actions #8

Updated by Seth Mos almost 12 years 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.

Actions #9

Updated by Seth Mos almost 12 years ago

  • Status changed from Feedback to New

Ok, this is definitely not fixed, I can't make sense of it. Deferring.

Actions #10

Updated by Seth Mos almost 12 years ago

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.

Actions #11

Updated by Seth Mos almost 12 years ago

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.

Actions #12

Updated by Ermal Luçi about 11 years 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.

Actions #13

Updated by Ermal Luçi about 11 years ago

  • Status changed from New to Feedback
Actions #14

Updated by Chris Buechler over 10 years ago

  • Status changed from Feedback to Resolved

works

Actions

Also available in: Atom PDF