Re: iwm: loosing connection to AP very often

On Fri, 24 Sep 2021 10:59:02 +0000 (UTC)
"Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> wrote:

> On Sun, 12 Sep 2021, freebsd@walstatt-de.de wrote:
> 
> Hallo,

Hello,

thanks for responding.

> 
> > I observe a very negative and unpleasant development and behaviour with Intel iwm
> > driver in FreeBSD recently. Using this WiFi adapter in a Lenovo E540 (technical specs
> > see below, output of pciconf -lvbc), this adapter ran stable with FreeBSD 12-CURRENT
> > some time ago, until I moved to 13-STABLE on that notebook.
> >
> > I use a "typical" wlan0/re0/lagg0 configuration on that notebook, since I have to
> > switch very often between WiFi and wired LAN. The FreeBSD 13-STABLE (most recent
> > incarnation) is configured dual stack IPv4 and IPv6.
> >
> > The overall observation is that the WiFi connection is, no matter what kind of AP I
> > used to be connected to, that the connection is highly unstable! While ifconfig still
> > reports attached IPs (both IPv4 and IPv6) on lagg0 and allegedly beeing associated
> > via wlan0 to the AP, there is no connection any more and the only salvation is
> > service netif restart or bringin down and up IF and all associated services. This
> > problem gets worse, the more the WiFi is crowded with other stations, but even in
> > sparsely populated WiFi areas the loose of connection/association is only a matter of
> > time, sometimes the death of the connection comes rather quickly.
> >
> > I can only report my observations. I used to use the very same notebook with FreeBSD
> > CURRENT and lately with 13-STABLE with FreeBSD since I purchased it in 2014 and used
> > the same wlan0/re0/lagg0 configuration I use these days, but with I never faced an
> > instability like the reported with 12-STABLE I face with 13-STABLE. The problem is
> > present almost 1 1/2 years for now and even with newer commits to WiFi in FreeBSD I
> > did not see a mitigation.  
> 
> Without much more data this is hard to diagnose remotely.  I'd suggest
> (if you are okay with the extra logging) to enable wlandebug such as:
>  	wlandebug_wlan0="+state +crypto +node +auth +assoc +dot1xsm +wpa"
> in rc.conf.  See wlandebug(8) for more information.  That might give
> you a hint maybe of what is going wrong.

You're right, I'll provide more insights (hopefully). Attached is the dmesg extract from
the latest reboot until the system got up with the consequence of being not linked into
my WiFi network. I have trouble sending the debug output to an appropriate file,
hopefully dmesg will suffice as first approach.

Settings for wlandebug:

wlandebug_wlan0="+state +crypto +node +auth +assoc +dot1xsm +wpa +power"

The portion of /etc/wpa_supplicant.conf important for the connection to my local AP; the
AP is in this case an OpenWRT 21.xxx-rc4 (latest stable) driven AVM7412 AP, but the same
phenomenology occurs with another private AP AVM7530 and the APs at some university
departments I have access to and which are supposedly Cisco APs:
 

[...]
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
#eapol_version=2
#ap_scan=1
#fast_reauth=1


# WPA3 (experimentell)
network={
  ssid="Koenigsberg"
  #auth_alg=OPEN
  #key_mgmt=WPA-EAP-SHA256 WPA-PSK-SHA256
  pairwise=GCMP-256
  group=CCMP
  priority=5
  psk=PW
}

# WPA2
network={
  ssid="Koenigsberg-2"
  #auth_alg=OPEN
  #key_mgmt=WPA-EAP WPA-PSK
  pairwise=CCMP
  group=CCMP
  priority=1
  psk=PW
}


Attached you'll find some dmesg from an earlier attempt this morning, the message log
quite recently alongside a syslog derived wpa_supplicant.log, generated after reboot as
long as the ifconfig of the end state of the reboot.

The end state is in almost every case non-connectivity of the WiFi.

As some of the logs show, we use dual stack configurations and therefore, I have to use
net/dual-dhclient, which also gives lots of trouble not ending up in the correct v6
router and without working name resolution (local_unbound: it seems that IPv4 setting get
overridden by the IPv6 ULA DNS and that is in some config scenarios a non-working
solution).
> 
> 
> > I also realized that iwm() is limited by its FreeBSD driver to 802.11b and 802.11g,  
> 
> and 11a.
> 
> > although it claims to be an 802.11ac driver. Is this about to change in a measurable
> > timeframe for a human lifetime?  
> 
> That is underway with the iwlwifi efforts.  See the posting with the
> reference to the wiki earlier this month on this list:
> https://lists.freebsd.org/archives/freebsd-wireless/2021-September/000068.html

Well, this is on 14-CURRENT, I run a bunch of 14-CURRENT servers so far, but for some
reasons concerning stability I run 13-STABLE on the notebook. If 13-STABLE will be target
for that experiment, sure, I'll do my best to support.

> 
> Fair warnings:
> It's probably not quite fully ready/stable enough for your roaming
> usage but if you are willing to test you are more than welcome.
> I am also not aware anyone having tested iwlwifi with a 7000 series card
> yet and I don't happen to have one either to do so.  Could be an extra
> bumpy ride.
> 
> 
> > [...]
> > iwm0@pci0:5:0:0:        class=0x028000 rev=0x73 hdr=0x00 vendor=0x8086 device=0x08b2
> > subvendor=0x8086 subdevice=0x4262 vendor     = 'Intel Corporation'
> >    device     = 'Wireless 7260'  
> 
> From what I can see this is a very early 11n-only device so 11ac won't
> help with it; but 11n would hopefully help you a bit.

The device is in a Lenovo E540, purchased 2014. I tried to replace is with something
FreeBSD could support those days, but the Lenovo firmware rejected the device. Well, 11n
would be a benefit ... but never worked with FreeBSD from the beginning until 13-STABLE
(never used 14-CURRENT on that particular system).
> 


Kind regards,

O. Hartmann