Unstable wireless link state

my dmesg output has a lot of
Code:
wlan0: link state changed to UP
wlan0: link state changed to DOWN
wlan0: link state changed to UP
wlan0: link state changed to DOWN
wlan0: link state changed to UP
However, the network appears to be working ok.

I once ditched Solaris 11, believing it was incompatible with my hardware. My NIC is HP integrated Intel 3945g.
 
I have also an issue with an old Intel N Wireless adaptator 5200 serie
It was working perfectly with FreeBSD 10, and upgrading to FreeBSD 11, it became unstable.

Before connecting during 30-60 minutes link state status changes, further it tries to authenticate and doesn't seem to succeed, starts again with his status link changing, and suddenly with no reason the system accepts to connect.
Generally, when the system authenticates with the AP, there is no more link issue, but I must take care not to disconnect.

This is not a wave transmission problem as I am not more than 4 meters from the AP, with no obstacle between the two devices , and it was working perfectly with FreeBSD 10

So this is an issue with the revised driver. Hoping eventually that coming upgrade 11.1 will fix the problem.

FreeBSD as a "server" flavor doesn't put as a priority the Ethernet Wireless in their development. We will say, not minor... but medium priority.

WiFi N double channel (2,4GHZ and 5 GHZ) support is only handled since FreeBSD 11 (this is probably the revised code linked to N support that causes some regression), there are some signs of development around Wifi AC in FreeBSD Current (for next FreeBSD 12), and so for the new WiFi ad... we can probably wait for 5 to 8 years.

There is also an unsolvable compatibility issue with most of Broadcom wireless chipsets, in particular the hybrid series WiFi/Bluetooth. As explained in the support page, for these devices it is impossible to develop drivers because Broadcom refuses to open the code, and Broadcom really doesn't care of BSD world (except Apple), so users should void devices integrating such chipsets, and as now Intel was generally still the best choice for FreeBSD as Intel keeps his drivers "open source".
 
Last edited:
I have also an issue with an old Intel N Wireless adaptator 5200 serie
It was working perfectly with FreeBSD 10, and upgrading to FreeBSD 11, it became unstable.

Before connecting during 30-60 minutes link state status changes, further it tries to authenticate and doesn't seem to succeed, starts again with his status link changing, and suddenly with no reason the system accepts to connect.
Generally, when the system authenticates with the AP, there is no more link issue, but I must take care not to disconnect.

This is not a wave transmission problem as I am not more than 4 meters from the AP, with no obstacle between the two devices , and it was working perfectly with FreeBSD 10

So this is an issue with the revised driver. Hoping eventually that coming upgrade 11.1 will fix the problem.

FreeBSD as a "server" flavor doesn't put as a priority the Ethernet Wireless in their development. We will say, not minor... but medium priority.

WiFi N double channel (2,4GHZ and 5 GHZ) support is only handled since FreeBSD 11 (this is probably the revised code linked to N support that causes some regression), there are some signs of development around Wifi AC in FreeBSD Current (for next FreeBSD 12), and so for the new WiFi ad... we can probably wait for 5 to 8 years.

There is also an unsolvable compatibility issue with most of Broadcom wireless chipsets, in particular the hybrid series WiFi/Bluetooth. As explained in the support page, for these devices it is impossible to develop drivers because Broadcom refuses to open the code, and Broadcom really doesn't care of BSD world (except Apple), so users should void devices integrating such chipsets, and as now Intel was generally still the best choice for FreeBSD as Intel keeps his drivers "open source".

You know, this thing started acting up on my Windows 2008 R2 as well. Random link disconnects, and needs manual action, the best of which is the default "troubleshooting" context menu item that brings it up again.
 
Back
Top