Re: iwlwifi in German ICE4 trains

["Toke Høiland-Jørgensen" <toke@kernel.org>]

"Greenman, Gregory" <gregory.greenman@intel.com> writes:

> On Sun, 2023-04-23 at 10:55 +0200, Uwe Kleine-König wrote:
>> Hello Gregory,
>> 
>> there is a thread on debian-user-german@lists.debian.org[1] about
>> broken wifi on Thinkpads when they are supposed to be connected to the
>> hotspots available in ICE4 trains. The mailing lists language is German
>> and the thread is long, so I sum up the problem:
>> 
>> - It only affects the wifi equipment in ICE4 trains, the older ones work
>>   fine.
>> 
>> - Can be seen at least on
>>   - Jürgen's laptop (Intel Corporation Wireless 8260 [8086:24f3] (rev 3a))
>>   - Marc's Thinkpad X260 (Intel Corporation Wireless 8260 [8086:24f3] (rev 3a))
>>   - Uwe's Thinkpad T460p (Intel Corporation Wireless 8260 [8086:24f3] (rev 3a))
>> 
>> - Other Thinkpads with a Realtek-Chip doesn't show the problem
>> 
>> - Works on puppy-Linux with 4.19.23, however Debian with 4.19.0-18 is
>>   also broken.
>> 
>> - The OP provided a syslog dump at
>>   https://lists.debian.org/msgid-search/75ad7ff2-ef25-90cd-2cb3-1f49f3e4909e@online.de
>> 
>>   I don't reproduce it here, but the gist seems to be:
>> 
>>         Jun 23 15:44:53 lina kernel: [ 1006.011129] wlp1s0: deauthenticated from 3c:51:0e:56:32:80 (Reason: 2=PREV_AUTH_NOT_VALID)
>> 
>> - it seems to help to do:
>>   $ cat /etc/modprobe.d/iwlwifi.conf
>>   options iwlwifi 11n_disable=1 swcrypto=0 bt_coex_active=0 power_save=0
>>   options iwlmvm power_scheme=1
>>   options iwlwifi d0i3_disable=1
>>   options iwlwifi uapsd_disable=1
>>   options iwlwifi lar_disable=1
>> 
>> I added all participants of said thread to Cc, in case I forgot
>> something relevant.
>> 
>> Tomorrow I might have the opportunity to test and reproduce the problem
>> (I don't know if my train will be an ice4 or one of the older ones
>> though.)
>> 
>> I wonder if there is something you want me to test. Without further
>> input I will try with the modprobe options and check for a minimal
>> subset of them that makes the problem disappear.
>> 
>> Is there something I can do to make the problem better understandable
>> for someone who knows about the hardware? Or to find out the critical
>> detail about the wifi hotspot that triggers the problem?
>> 
>> Best regards
>> Uwe
>> 
>> [1] https://lists.debian.org/msgid-search/da8c1552-6bcb-14c3-0e86-abcb835ec350@online.de
>> 
>
> Hi Uwe,
>
> Based on the log, I can understand that it had successfully connected
> to the AP (supplicant management interface state: associating ->
> completed); then there're some DHCP errors and eventually the AP sends
> a deauth.

If it's DHCP failing it could be an issue with multicast traffic? I've
definitely seen multicast failing on busy networks because it is set to
too low a rate and gets overwhelmed, which leads to DHCP (and ARP)
failures while unicast traffic works fine.

It's probably not (only) a network issue if it works fine with other
drivers, but maybe there's some kind of interaction between the driver
and multicast? Just a thought :)

-Toke