Third radio in wrt3200acm?

When I flashed my WRT3200ACM with a new firmware compiled to up-to-date master, I noticed that there is now a third radio in wifi config. Originally named as "mlan0".

That is due to these commits that created a new kernel module kmod-mwifiex-sdio and enabled it by default in WRT3200ACM:
https://github.com/lede-project/source/commit/6674aa97981001c7a96e629146b28be518165211
https://github.com/lede-project/source/commit/fb436f49ad5cff8836109159b2b6a2b4212d4700

Based on links found in the net, it sounds like a third radio interface, possibly with an internal antenna? Possibly also supporting Bluetooth?

https://eko.one.pl/forum/viewtopic.php?id=15254
https://github.com/Chadster766/McDebian

@Heinz
As you added those commits, could you please enlighten me about the practical usage of the new radio. Is it usable? Did you get bluetooth working?

radio, I have not noticed a log message regarding successfully loading the firmware.

This is "normal" wireless interface and You can use it as AP.

Bluetooth not started - problem with firmware. You can see part of bootlog https://eko.one.pl/forum/viewtopic.php?pid=183594#p183594
and my changes ( before accepted my previous commits):
https://github.com/heinzek/source/commit/8ee04e680cd6829300937dc417a7bb33c32f97af

On DD-WRT forum @BrainSlayer wrote that the chip is used to DFS radar detection:
http://www.dd-wrt.com/phpBB2/viewtopic.php?p=1050614#1050614

This chip offer FM and NFC but I have no idea how to run it.

I tested speed of this third radio and get 180Mbps on connected laptop with Intel Wireless-AC 7260.
On main wireless interface i have only 230Mbps. Wifi speed on archer c2600 with LEDE - 420Mbps

afaik they want it to use for radar detection in their official firmware, but don't do it yet

most likely not wired to anything

I tried your Bluetooth changes and pretty much the same result and same log lines. Not working, and not even visible for hciconfig.

But interesting radio in any case. In "AC" wifi mode it only supports 5 GHz network, but in "N" mode you can select either 2.4 or 5 GHz band.

The third radio works. I was thinking it would work well as a wireless backhaul for a Wireless Repeater config.

I'm trying to edit the third radio/third wifi-iface settings in level 55 uci-defaults script and while similar commands work for radio0/radio1 I'm getting errors with radio2:

+ uci del wireless.@wifi-device[2].disabled
uci: Entry not found
+ uci set wireless.@wifi-device[2].channel=38
uci: Invalid argument
+ uci set wireless.@wifi-device[2].htmode=VHT80
uci: Invalid argument
+ uci set wireless.@wifi-device[2].txpower=23
uci: Invalid argument
+ uci set wireless.@wifi-device[2].country=US
uci: Invalid argument
+ uci set wireless.@wifi-iface[2].ssid=****
uci: Invalid argument
+ uci set wireless.@wifi-iface[2].key=****
uci: Invalid argument
+ uci set wireless.@wifi-iface[2].encryption=psk2+ccmp
uci: Invalid argument
+ uci set wireless.@wifi-iface[2].wps_pushbutton=0
uci: Invalid argument
+ uci set wireless.@wifi-iface[2].wpa_group_rekey=3600
uci: Invalid argument

Any ideas why or what am I doing wrong or how can I setup radio2 in uci-defaults script?

Works for me (from console, I have not tested from uci-defaults).
My guess is that you have not yet created that uci config item section in the wireless config.

root@LEDE:~# uci show wireless.@wifi-device[2]
wireless.radio2=wifi-device
wireless.radio2.type='mac80211'
wireless.radio2.channel='36'
wireless.radio2.hwmode='11a'
wireless.radio2.path='platform/soc/soc:internal-regs/f10d8000.sdhci/mmc_host/mmc0/mmc0:0001/mmc0:0001:1'
wireless.radio2.htmode='VHT80'
wireless.radio2.disabled='1'

root@LEDE:~# uci set wireless.@wifi-device[2].channel=38

root@LEDE:~# uci show wireless.@wifi-device[2]
wireless.radio2=wifi-device
wireless.radio2.type='mac80211'
wireless.radio2.hwmode='11a'
wireless.radio2.path='platform/soc/soc:internal-regs/f10d8000.sdhci/mmc_host/mmc0/mmc0:0001/mmc0:0001:1'
wireless.radio2.htmode='VHT80'
wireless.radio2.disabled='1'
wireless.radio2.channel='38'

Creating a new one:

root@LEDE:~# uci add wireless wifi-device
cfg089e91

root@LEDE:~# uci show wireless.@wifi-device[3]
wireless.cfg089e91=wifi-device

root@LEDE:~# uci set wireless.@wifi-device[3].channel=38

root@LEDE:~# uci show wireless.@wifi-device[3]
wireless.cfg089e91=wifi-device
wireless.cfg089e91.channel='38'

And naming it:

uci rename wireless.@wifi-device[3]='radionew'
uci set wireless.@wifi-device[3].channel=44

root@LEDE:~# uci show wireless.@wifi-device[3]
wireless.radionew=wifi-device
wireless.radionew.channel='44'

/etc/config/wireless

config wifi-device 'radionew'
        option channel '44'

After the router is booted up, exactly same commands which fail in uci-defaults script work just fine in console.

I'm confused why they don't work for radio2 (while working for radio0/1 just fine in uci-defaults).

So when exactly does the third radio get added during the initial boot/setup? I've just done uci show in the uci-defaults script and it only lists radio0 and radio1.

That may depend a bit on the timeline when that driver gets initialised.
The wifi detection logic was changed recently, and this commit gives you the basics and gives pointers to the relevant files: https://github.com/lede-project/source/commit/5f8f8a366136a07df661e31decce2458357c167a

In nutshell, there is a wifi detection script that writes a default config for each found radio.

• it used to be launched from etc/init.d/boot that did run "wifi detect" before running the uci-defaults scripts.
• but now it is more asynchronous, as a hotplug script is run when a new ieee80211 device registers itself. That hotplug runs "wifi config" that is the new detection function name. In practice this can lead to some delay in case where the third radio registers itself later than the 1 second delay that was added to the script due to brcm47xx and mvebu.

You might test with lengthening that sleep delay to e.g. 5 seconds, and maybe also the third radio gets registered in time so that the uci-defaults scripts can then manipulate the config.

EDIT:
looking at the bootlog at a new device, it is pretty clear that the mwifiex driver starts slowly. The last log item from it is about 1 sec later than the kernel driver loading has been announced completed with "kmodloader: done loading kernel modules from /etc/modules.d/*"

[   11.422917] procd: - init -
[   11.507259] kmodloader: loading kernel modules from /etc/modules.d/*
[   11.520519] ntfs: driver 2.1.32 [Flags: R/O MODULE].
[   11.527174] tun: Universal TUN/TAP device driver, 1.6
[   11.532298] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[   11.539600] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[   11.546954] gre: GRE over IPv4 demultiplexor driver
[   11.552221] ip_gre: GRE over IPv4 tunneling driver
[   11.558617] ip6_tables: (C) 2000-2006 Netfilter Core Team
[   11.566418] nf_conntrack version 0.5.0 (8192 buckets, 32768 max)
[   11.579333] Netfilter messages via NETLINK v0.30.
[   11.584609] ip_set: protocol 6
[   11.592907] Loading modules backported from Linux version wt-2017-01-31-0-ge882dff19e7f
[   11.600946] Backport generated by backports.git backports-20160324-13-g24da7d3c
[   11.616904] <<Marvell 802.11ac Wireless Network Driver version 10.3.2.0-20170110>>
[   11.624545] pci 0000:00:01.0: enabling device (0140 -> 0142)
[   11.630299] ieee80211 phy0: priv->iobase0 = e1080000
[   11.630309] ieee80211 phy0: priv->iobase1 = e1300000
[   11.630317] ieee80211 phy0: priv->pcmd_buf = ddfac000  priv->pphys_cmd_buf = 1dfac000
[   11.655902] ieee80211 phy0: fw download start
[   11.719308] ieee80211 phy0: FwSize = 207660 downloaded Size = 207660 curr_iteration 65522
[   15.457311] ieee80211 phy0: fw download complete
[   15.457785] ieee80211 phy0: pcmd = ddfac000
[   15.475324] ieee80211 phy0: firmware version: 0x7080004
[   15.783337] ieee80211 phy0: firmware region code: 10
[   15.826913] ieee80211 phy0: 2G disabled, 5G enabled
[   15.831829] ieee80211 phy0: 4 TX antennas, 4 RX antennas
[   15.837208] pci 0000:00:02.0: enabling device (0140 -> 0142)
[   15.842948] ieee80211 phy1: priv->iobase0 = e1480000
[   15.842958] ieee80211 phy1: priv->iobase1 = e1700000
[   15.842967] ieee80211 phy1: priv->pcmd_buf = de3e4000  priv->pphys_cmd_buf = 1e3e4000
[   15.849572] ieee80211 phy1: fw download start
[   15.915307] ieee80211 phy1: FwSize = 207660 downloaded Size = 207660 curr_iteration 65527
[   17.301310] ieee80211 phy1: fw download complete
[   17.301831] ieee80211 phy1: pcmd = de3e4000
[   17.319867] ieee80211 phy1: firmware version: 0x7080004
[   17.638343] ieee80211 phy1: firmware region code: 10
[   17.681022] ieee80211 phy1: 2G enabled, 5G disabled
[   17.685942] ieee80211 phy1: 4 TX antennas, 4 RX antennas
[   17.720832] u32 classifier
[   17.723588]     input device check on
[   17.727267]     Actions configured
[   17.731480] Mirror/redirect action on
[   17.737424] ip_tables: (C) 2000-2006 Netfilter Core Team
[   17.747231] mwifiex: rx work enabled, cpus 2
[   17.752480] nf_conntrack_rtsp v0.7 loading
[   17.773098] nf_nat_rtsp v0.7 loading
[   17.777995] usbcore: registered new interface driver usbserial
[   17.783904] usbcore: registered new interface driver usbserial_generic
[   17.790481] usbserial: USB Serial support registered for generic
[   17.804707] xt_time: kernel timezone is -0000
[   17.810978] PPP generic driver version 2.4.2
[   17.815882] PPP MPPE Compression module registered
[   17.821100] NET: Registered protocol family 24
[   17.826062] PPTP driver version 0.8.5
[   17.830823] kmodloader: done loading kernel modules from /etc/modules.d/*
[   18.352963] mwifiex_sdio mmc0:0001:1: info: FW download over, size 391772 bytes
[   18.711523] mwifiex_sdio mmc0:0001:1: WLAN FW is active
[   18.737809] mwifiex_sdio mmc0:0001:1: CMD_RESP: cmd 0x242 error, result=0x2
[   18.744818] mwifiex_sdio mmc0:0001:1: mwifiex_process_cmdresp: cmd 0x242 failed during       initialization
[   18.801792] mwifiex_sdio mmc0:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (15.68.7.p5)
[   18.809750] mwifiex_sdio mmc0:0001:1: driver_version = mwifiex 1.0 (15.68.7.p5)
[   19.655071] mvneta f1034000.ethernet eth0: configuring for fixed link mode

Hannu, thank you for your elaborate reply. Is the commit you've linked also the same commit which broke wifi detection in ipq806x?

I've tried moving the uci show wireless and modifying settings of radio2 to the level 95 uci-defaults script and it didn't help, the radio2 is still not detected by then.

I then went ahead and instead of modifying radio2/default_radio2 settings I just added them in my uci-defaults script. I don't think this is an optimal solution tho. IMHO the onboard radios should be initialized before the uci-defaults script run and then the hotplugged radios should be added on later.

What's the best way to have this discussed with powers that be? Add a comment to commit?

No. A different commit, but funnily, both are from @chunkeey

This wifi detection trigger logic change is probably permanent.
But you should test adding 1-'2 seconds to the sleep command that exists there just for giving wifi drivers enough time to get themselves initialized before the process continues to uci-defaults. My link gave pretty good reference about the location. About line 43 in init.d/boot

The proper way to get it discussed it either a bug in bug tracker or the developer mailing list. But you should do a bit more debugging first, e.g. find out if 1-2 second more completely is enough waiting etc. And then get also people knowing the mwifiex interested, like @Heinz

My guess about the root reason is the slow start for mwifiex driver.

Thanks, I'll try to experiment with the longer sleep.

I think there's one more way. I didn't test it, because I lack the WRT3200ACM. But if you are interested you could check it out. However, you have to be aware that this is your own "configuration"... and it might break someday. nobody can guarantee it that it works or you can keep it forever the same.

The general idea is to use the ieee80211 hotplug triggers to edit the configuration, instead of using uci-defaults. I've seen scripts for ipq806x updating the wifi MACs. So, it isn't a new hack.

In order to use the hotplug triggers, you only need to put a executable? file into /etc/hotplug.d/ieee80211
and name it like 20-myconfig or something. The important part is the number, it has to be higher than the script which calls "wifi config".

now, in your script, you simply monitor if the default_radio2 network do exist, if it doesn't you can exit.
But if the is there you check for default_radio2, you know that the "wifi config" script has just created the initial configuration. now you your modifications and rename the default_radio2 node in to process to something else.

Here's an example, that might work for you:

#!/bin/sh
[ $(uci -q get "wireless.default_radio2") ] || exit 0
uci -q batch << -EOF
    set wireless.radio2.channel=40
    set wireless.radio2.disabled=0
    rename wireless.default_radio2=configured_radio2
    set wireless.configured_radio2.ssid=myssid
    set wireless.configured_radio2.key=mysecretkey
EOF
uci -q commit wireless

/sbin/wifi

(The /sbin/wifi at the end is a bit questionable, since it will retrigger the scripts and enable the wifi.
But on the second time round, the default_radio2 would be renamed, so it will exit.)

Thanks, I solved my specific problem by just setting up (rather than modifying) both radio2 and default_radio2 wifi-iface from my uci-defaults script. I haven't had a chance to test increased sleep value yet and I understand that exact timing of when that radio gets detected is not dependent on LEDE, I still hope that someone more knowledgable than me investigates this and ensures that all onboard radios get detected before uci-defaults script execute. Maybe add a check that all onboard radios are online before running uci-defaults scripts?

Hey there, I just installed the latest Rango firmware. The third radio appears automatically but there doesn't seem to be any way to configure it to get it to work. Is there something I need to do to make it work. See the screenshot, it's enabled like the other APs but the icon never goes blue.

I am not sure if it's the internal radio people are talking about here. Because it does appear to be capable of 160Mhz. Maybe there was another issue with a different radio.

In this device, radio0 is the 5GHz interface, radio1 is the 2.4GHz interface, and radio2 is an auxiliary interface, that can be configured either as 2.4GHz or 5GHz. Now, in your picture you are already using the third radio, so it is working.

4 posts were split to a new topic: WRT32X third radio limited to 10 devices

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