pfSense

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

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

Jan 1 01:35:22     kernel: ural0_wlan0: link state changed to UP

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.

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

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.

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.

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.