Where does LUCI get the wireless adapter description from (not the name)?

Goerge255 · February 26, 2021, 2:05am

Where does LUCI get the wireless adapter description from (not the name) ?
By "Description" I mean the text "MediaTek MT76x8 802.11bgn" marked with the red color in the screenshot below (coloring is mine).

I am asking because this DESCRIPTION is totally wrong (although the device name radio2 is correct). The description should be something like: Atheros AR9271 802.11n, because:

root@OpenWrt:~# lsusb -v | grep ID
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 0cf3:9271 Qualcomm Atheros Communications AR9271 802.11n
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

The contents of the:
/etc/config/wireless file are:

root@OpenWrt:/etc/config# cat wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '11'
        option hwmode '11g'
        option path 'platform/10300000.wmac'
        option htmode 'HT20'
        option country 'US'

config wifi-device 'radio1'
        option type 'mac80211'
        option channel '36'
        option hwmode '11a'
        option path 'pci0000:00/0000:00:00.0/0000:01:00.0'
        option htmode 'VHT80'
        option country 'US'

config wifi-iface 'wifinet2'
        option ssid 'myssid'
        option device 'radio0'
        option mode 'sta'
        option key 'shh'
        option encryption 'psk2'

config wifi-device 'radio2'
        option type 'mac80211'
        option channel '11'
        option hwmode '11g'
        option path 'platform/101c0000.ehci/usb1/1-1/1-1:1.0'
        option htmode 'HT20'
        option country 'US'

config wifi-iface 'wifinet1'
        option ssid 'myssid'
        option device 'radio2'
        option mode 'sta'
        option key 'shh'
        option encryption 'psk2'

Also, the wifi device radio2 and the related interface wlan2 functions properly.
The latter is properly displayed by ifconfig and by iwconfig.

hnyman · February 26, 2021, 5:00am

It gets the information directly from iwinfo

(You can try that command at console)

Iwinfo has an internal database of radio chip IDs.
https://git.openwrt.org/?p=project/iwinfo.git;a=blob;f=hardware.txt;hb=HEAD

To my knowledge that has no direct relation to the usb IDs (that you showed), but possibly the id shown for usb matches the IDs recognised by iwinfo.

Example

 -----------------------------------------------------
root@router1:~# iwinfo
wlan0     ESSID: "HN5WLAN"
          Access Point: DC:EF...
          Mode: Master  Channel: 36 (5.180 GHz)
          Center Channel 1: 38 2: unknown
          ...
          Type: nl80211  HW Mode(s): 802.11nac
          Hardware: 168C:0046 168C:CAFE [Qualcomm Atheros QCA9984]
          TX power offset: none
...

wlan1     ESSID: "HNWLAN"
          Access Point: DC:EF:...
          Mode: Master  Channel: 3 (2.422 GHz)
 ...
          Type: nl80211  HW Mode(s): 802.11bgn
          Hardware: 168C:0046 168C:CAFE [Qualcomm Atheros QCA9984]
...

hnyman · February 26, 2021, 5:05am

You seem to have two different radios on channel 9 in screenshot (and later in config they both are on channel 11). That might confuse the detection/parsing logic.

Goerge255 · February 26, 2021, 10:37am

@ Hnyman

Thank you for the hint.

So it is not LUCIs fault. It is the iwinfo that is returning the bad results, see what it displays after I enable all 3 radios:

root@OpenWrt:~# iwinfo

wlan0     ESSID: "myssid0"
          Access Point: BA:AD:F0:0D:BA:AD
          Mode: Client  Channel: 9 (2.452 GHz)
          Tx-Power: 20 dBm  Link Quality: 51/70
          Signal: -59 dBm  Noise: unknown
          Bit Rate: 52.0 MBit/s
          Encryption: WPA2 PSK (TKIP, CCMP)
          Type: nl80211  HW Mode(s): 802.11bgn
          Hardware: 14C3:7628 14C3:0004 [MediaTek MT76x8]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0

wlan1     ESSID: "myssid1"
          Access Point: BA:AD:F0:0D:BA:DD
          Mode: Client  Channel: 44 (5.220 GHz)
          Tx-Power: 20 dBm  Link Quality: 43/70
          Signal: -67 dBm  Noise: unknown
          Bit Rate: 54.0 MBit/s
          Encryption: WPA2 PSK (TKIP, CCMP)
          Type: nl80211  HW Mode(s): 802.11nac
          Hardware: 14C3:7662 14C3:7662 [MediaTek MT76x2E]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy1

wlan2     ESSID: "myssid2"
          Access Point: BA:AA:AD:F0:00:0D
          Mode: Client  Channel: 9 (2.452 GHz)
          Tx-Power: 20 dBm  Link Quality: 56/70
          Signal: -54 dBm  Noise: unknown
          Bit Rate: 150.0 MBit/s
          Encryption: WPA2 PSK (TKIP, CCMP)
          Type: nl80211  HW Mode(s): 802.11bgn
          Hardware: 14C3:7628 14C3:0004 [MediaTek MT76x8]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy2

BTW: Making the channels different on all of these radios in LUCI does not make any difference. They are in the Client mode anyway ...they are not acting as Master/Access Points. In Client Mode the channel numbers entered in LUCI's GUI do not correspond to what iwinfo displays, anyway.

So what is the best place on this forum to address the issue of the bad data returned by iwinfo ?
Namely, the same Hardware line for wlan0 and wlan2 but different MAC addresses and different PHY name.

hnyman · February 26, 2021, 10:54am

Outside forum, as this is not a bug tracker...

https://bugs.openwrt.org/index.php?do=tasklist&project=2&order=id&sort=desc

Goerge255 · February 26, 2021, 12:20pm

OK so I understood your advice as to treat this as a bug.

Thus, I have filed a bug report there:
https://bugs.openwrt.org/index.php?do=details&task_id=3643

Goerge255 · March 6, 2021, 5:27pm

The good people at the Bug Tracker requested the outputs of these 2 commands:

ubus call network.wireless status
strace iwinfo

...which has been quite revealing. This appears to be a bug indeed.

Goerge255 · March 13, 2021, 4:37pm

There has been no attention paid to this bug for a week on the Bug Tracker, despite clear evidence that something is not right.
Is there a way to bump it up ?

anon50098793 · March 14, 2021, 3:45pm

agree... tho' project coders are volunteers and i'd triple your timeframe expectations minimum...

the great thing about obvious bugs (and moreso in core components) is they have a tendancy to self prioritize and resolve...

you've played your part in making it obvious so all you can really do is be patient whilst things sort themselves out...

system · March 24, 2021, 3:45pm

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.