Comment 8 for bug 1833474

Hi all,

I've managed to track down where the problem comes from.

CONTEXT

- I use one of my neighbors' access point/portal to access internet (based on FON principle: https://en.wikipedia.org/wiki/Fon_(company)).

- Since the access point is not that close from my apartment, I baught and use an external Wifi adapter with a (supposed to be) 5DBi antenna. This is the exact following "ALFA" model:
https://www.dx.com/p/alfa-awus036nh-network-ralink-3070l-wifi-network-card-2000mw-alfa-wireless-wifi-usb-adapter-with-5dbi-antenna-white-2053330.html

- In order to be able to put this device outside my window, I plug it to my computer via a 2m USB armored cable, similar to this one (with the characteristic little bump / fuse?)
https://mpshop.tn/3035-thickbox_default/rallonge-usb-male-femelle.jpg
I tried with several cables (non-armored ones or longer cables, armored or not). All lead to kernel not recognizing the device or intermittent disconnection from the AP or disappearing of the device after a few minutes.

The chipset is apparently detected as a RaLink and the kernel tells me it uses the 'rt2870.bin' firmware:
[27393.587771] usb 1-1: new high-speed USB device number 6 using xhci_hcd
[27393.753513] usb 1-1: New USB device found, idVendor=148f, idProduct=3070, bcdDevice= 1.01
[27393.753519] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[27393.753523] usb 1-1: Product: 802.11 n WLAN
[27393.753526] usb 1-1: Manufacturer: Ralink
[27393.753528] usb 1-1: SerialNumber: 1.0
[27393.883944] usb 1-1: reset high-speed USB device number 6 using xhci_hcd
[27394.044554] ieee80211 phy2: rt2x00_set_rt: Info - RT chipset 3070, rev 0201 detected
[27394.055744] ieee80211 phy2: rt2x00_set_rf: Info - RF chipset 0005 detected
[27394.056214] ieee80211 phy2: Selected rate control algorithm 'minstrel_ht'
[27394.098722] rt2800usb 1-1:1.0 wlx000f0032e9c8: renamed from wlan0
[27394.150888] ieee80211 phy2: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin'
[27394.150937] ieee80211 phy2: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.36
[27395.779361] wlx000f0032e9c8: authenticate with e4:9e:12:cf:e8:09
[27395.790695] wlx000f0032e9c8: send auth to e4:9e:12:cf:e8:09 (try 1/3)
[27395.792593] wlx000f0032e9c8: authenticated
[27395.798527] wlx000f0032e9c8: associate with e4:9e:12:cf:e8:09 (try 1/3)
[27395.801965] wlx000f0032e9c8: RX AssocResp from e4:9e:12:cf:e8:09 (capab=0x401 status=0 aid=1)
[27395.804884] wlx000f0032e9c8: associated
[27395.805216] IPv6: ADDRCONF(NETDEV_CHANGE): wlx000f0032e9c8: link becomes ready

Under Linux (XUbuntu 19.04), everything works fine (detection of networks/connection to networks/upload&download), apart the fact that the computer totally freezes/crashes in less than 2 hours as soon as the ALFA device is plugin. When I use the computer without the ALFA device plugged, everything works fine (tested reaching a 12 days uptime!)

Under windows (10 1903) everything works fine whatever the conditions (there's no crashes, even with the ALFA device plugged, tested reaching 24hrs uptime - sorry, I'm not able to use Windows more than that ;)...).

So my (informed) guess is that there's a bug either in Linux's RaLink module or 'rt2870.bin' firmware.

How can I provide more details, so that the bug is corrected ?

PS: I don't see how this is not a security issue: a computer that freezes brutally and in a non recoverable manner (CTRL-ALT-DEL & SysReq are useless)
1) reflects a very big problem in some module/firmware code, that probably can be related to a buffer overflow of some kind which could be exploited locally/remotely to take control of the machine
2) has a very strong probability to lead to data corruption (as it is clear that apps/fs/disks are not shutdown correctly)
3) even if it is not the case, being potentially able to voluntarily (locally or remotely) execute the part of the code that crashes the machine, i.e. perform a Denial of Service, is very serious problem...

PS2: I'm aware that I use potentially chinese non-guenuine devices/chipsets/cables and that can be the source of many problems. However, the Linux kernel should, at worse, refuse to recognize/use the device, but crashing after woking correctly a few hours is not an acceptable option.