On 6/8/23 20:32, Bagas Sanjaya wrote:
> Hi,
>
(also changing reporter's email to the proper one).
> I notice a bug report on Bugzilla [1]. Quoting from it:
>
>> With Debian Sid, trying to use two different Realtek USB Wifi Adapters (with
>> Antenna).
>>
>> Using kernels including various Liquorix 6.2.x, 6.3.x , and the most recent
>>
>> linux-image-6.3.4-1-liquorix-amd64
>>
>> also, Debian experimental
>>
>> Debian (experimental) linux-image-6.3.0-0-amd64-unsigned
>> 6.3.5-1~exp1
>>
>> Debian's linux-image-6.3.0-0-amd64 (Linux 6.3.0-0-amd64 #1 SMP
>> PREEMPT_DYNAMIC Debian 6.3.2-1~exp1 (2023-05-15) x86_64 GNU/Linux)
>>
>> same problem.
>>
>> At local library's public open wifi, no password required. Using either
>>
>> 0bda:0179 (rtl8188eu) USB Wifi adapter,
>>
>> or
>>
>> 0bda:f179 (rtl8188fu) USB Wifi adapter
>>
>> Both adapters are loading
>>
>> rtl8xxxu kernel module
>>
>> Using ( manual Wifi connection ) script , the system was able to obtain DHCP IP
>> address. Normally, all HTTP(S) requests get redirected to a public usage
>> policy web page, where users have to click on "I agree" to continue. Which
>> works fine with another USB adapter (mt7601 kernel module).
>>
>> However, with both Realtek adapters above, web browser will just time out, will
>> NOT even get redirect to a "Public Use Notice" web page.
>>
>> The relevant error message from system log shows
>>
>> 2023-05-15T16:57:48.491567-04:00 usrhostname kernel: wlan1: deauthenticated
>> from 7a:83:c2:8a:f1:13 (Reason: 6=CLASS2_FRAME_FROM_NONAUTH_STA)
>>
>> Apparently, the rtl8xxxu driver assumes an error condition, and immediately
>> deauthenticates and drops the Wifi connection, will not complete the
>> redirection to the "Public Use Notice" web page.
>>
>> Try to connect again, same problem, repeating itself, not allowing any
>> additional wifi traffic at all.
>
> See Bugzilla for the full thread.
>
> The reporter said that this is known rtl8xxxu issue (unusable on public,
> open WiFi access points [no WPA authentication?]). From his analysis:
>
>> Let me know if I need to do anything else. I looek at the code briefly, I belive the rtl8xxxu called a function from 802.11 layer to handle the return code (Reason code 6), which promptly call a function to deauthenticate the session, thus disconnected the device from further wifi traffic.
>>
>> I believe the 802.11 level handling is too harsh for public open AP. However, i think the Realtek level code is too lazy. Realtek driver code should check for reasonable return codes for situations like this and allow paasing at least a few of these before considering these as hacking attempts, which require deauthenticating, or disconnecting. But then again, this would also be too strict for monitor mode handling of traffic.
>>
>> Don't know if 802.11 level specs even have considerations for situations like these at all, or they simply handle lower level logic and leave these things for the device drivers to cooperate with application layers to handle these.
>
> Jes and Kalle, would you like to take a look on checking return codes
> (as reporter demands)?
>
Hi,
FYI, from Bugzilla [1], the reporter posted (untested) fix. Would you
like to review it?
Thanks.
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=217531#c8
--
An old man doll... just what I always wanted! - Clara
Bagas Sanjaya <[email protected]> writes:
> On 6/8/23 20:32, Bagas Sanjaya wrote:
>> Hi,
>>
>
> (also changing reporter's email to the proper one).
>
>> I notice a bug report on Bugzilla [1]. Quoting from it:
>>
>>> With Debian Sid, trying to use two different Realtek USB Wifi Adapters (with
>>> Antenna).
>>>
>>> Using kernels including various Liquorix 6.2.x, 6.3.x , and the most recent
>>>
>>> linux-image-6.3.4-1-liquorix-amd64
>>>
>>> also, Debian experimental
>>>
>>> Debian (experimental) linux-image-6.3.0-0-amd64-unsigned
>>> 6.3.5-1~exp1
>>>
>>> Debian's linux-image-6.3.0-0-amd64 (Linux 6.3.0-0-amd64 #1 SMP
>>> PREEMPT_DYNAMIC Debian 6.3.2-1~exp1 (2023-05-15) x86_64 GNU/Linux)
>>>
>>> same problem.
>>>
>>> At local library's public open wifi, no password required. Using either
>>>
>>> 0bda:0179 (rtl8188eu) USB Wifi adapter,
>>>
>>> or
>>>
>>> 0bda:f179 (rtl8188fu) USB Wifi adapter
>>>
>>> Both adapters are loading
>>>
>>> rtl8xxxu kernel module
>>>
>>> Using ( manual Wifi connection ) script , the system was able to obtain DHCP IP
>>> address. Normally, all HTTP(S) requests get redirected to a public usage
>>> policy web page, where users have to click on "I agree" to continue. Which
>>> works fine with another USB adapter (mt7601 kernel module).
>>>
>>> However, with both Realtek adapters above, web browser will just time out, will
>>> NOT even get redirect to a "Public Use Notice" web page.
>>>
>>> The relevant error message from system log shows
>>>
>>> 2023-05-15T16:57:48.491567-04:00 usrhostname kernel: wlan1: deauthenticated
>>> from 7a:83:c2:8a:f1:13 (Reason: 6=CLASS2_FRAME_FROM_NONAUTH_STA)
>>>
>>> Apparently, the rtl8xxxu driver assumes an error condition, and immediately
>>> deauthenticates and drops the Wifi connection, will not complete the
>>> redirection to the "Public Use Notice" web page.
>>>
>>> Try to connect again, same problem, repeating itself, not allowing any
>>> additional wifi traffic at all.
>>
>> See Bugzilla for the full thread.
>>
>> The reporter said that this is known rtl8xxxu issue (unusable on public,
>> open WiFi access points [no WPA authentication?]). From his analysis:
>>
>>> Let me know if I need to do anything else. I looek at the code
>>> briefly, I belive the rtl8xxxu called a function from 802.11 layer
>>> to handle the return code (Reason code 6), which promptly call a
>>> function to deauthenticate the session, thus disconnected the
>>> device from further wifi traffic.
>>>
>>> I believe the 802.11 level handling is too harsh for public open
>>> AP. However, i think the Realtek level code is too lazy. Realtek
>>> driver code should check for reasonable return codes for situations
>>> like this and allow paasing at least a few of these before
>>> considering these as hacking attempts, which require
>>> deauthenticating, or disconnecting. But then again, this would also
>>> be too strict for monitor mode handling of traffic.
>>>
>>> Don't know if 802.11 level specs even have considerations for
>>> situations like these at all, or they simply handle lower level
>>> logic and leave these things for the device drivers to cooperate
>>> with application layers to handle these.
>>
>> Jes and Kalle, would you like to take a look on checking return codes
>> (as reporter demands)?
>>
>
> FYI, from Bugzilla [1], the reporter posted (untested) fix. Would you
> like to review it?
>
> Thanks.
>
> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=217531#c8
I'm not seeing any fix from the reporter, where is it?
Also more information would be good to have to pinpoint where the actual
problem is. For example, it would be good to test different APs with
different encryption methods and make a list what works and what doesn't
on his device. There can be numerous reasons for the problem.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches