After 8h from first setup, all Wi-Fi interfaces (Marvell 88W8964) deactivated

Hi,

I've just setup OpenWRT (latest version) on my WRT3200ACM V1, and perfectly worked all day... but after about 8h, all the wi-fi interfaces went down, and cannot revive them no matter what I do (LAN and internet connectivity through WAN still work):

Wireless config:

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'soc/soc:pcie/pci0000:00/0000:00:01.0/0000:01:00.0'
        option band '5g'
        option cell_density '0'
        option channel 'auto'
        option htmode 'VHT80'
        option country 'US'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option macaddr '**redacted**'
        option encryption 'psk2'
        option key '**redacted**'
        option ssid 'gta_5GHz'

config wifi-device 'radio1'
        option type 'mac80211'
        option path 'soc/soc:pcie/pci0000:00/0000:00:02.0/0000:02:00.0'
        option band '2g'
        option htmode 'HT40'
        option channel 'auto'
        option cell_density '0'
        option txpower '30'
        option country 'US'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option macaddr '**redacted**'
        option encryption 'psk2'
        option key '**redacted**'
        option ssid 'gta_24GHz'

config wifi-device 'radio2'
        option type 'mac80211'
        option path 'platform/soc/soc:internal-regs/f10d8000.sdhci/mmc_host/mmc0
        option channel '34'
        option band '5g'
        option htmode 'VHT80'
        option disabled '1'

config wifi-iface 'default_radio2'
        option device 'radio2'
        option network 'lan'
        option mode 'ap'
        option ssid 'OpenWrt'
        option encryption 'none'

I've seen in another post that setting the country to "00-world" has fixed, but not in my case (Radio0 "Device is not active" (Qualcomm Atheros QCA9886 802.11acn) - Installing and Using OpenWrt - OpenWrt Forum).
I also tried this, but with no luck: WRT3200ACM + 21.02.0-rc4: multiple Wifis on a single radio? - Installing and Using OpenWrt / Network and Wireless Configuration - OpenWrt Forum

Any ideas on what could have suddenly happened? I haven't tweaked with any network settings once all got running 8h ago!

Thanks for any help.

PS: reverting back to the original Lynksys FW partition (thinking it could have been a HW failure), got all working, so it's definitively must be an OpenWRT configuration issue.

Search the forum for wrt3200 wifi, plenty of threads about it, unfortunately.

The "solution" appears to be to run 19.07, for the time being.

1 Like

To complement with a real access point is also a viable long term solution for that router.
The router it self is not bad, but the wifi chip is not so good.

Thanks, that's not good news :frowning:

Building a "train" of three components (modem, router, AP) is going to be a bit overkill. Also because the Wi-Fi of this router is very powerful and fast.

The stock firmware is instead flawless, and has great performance... It's just old and probably insecure.
Therefore, I wouldn't say that the Wi-Fi chip itself is bad, because otherwise stock firmware would have problems as well... I'd believe the problem is the driver implementation that is embedded in OpenWRT.

Because the stock firmware is open source, wonder if those drivers from that codebase were transplanted into the WRT3200ACM port of OpenWRT...

Not BCM, thnx @anomeome, statement redacted.

@gtrevi try 19.07.x before you decide to revert back to the original fw.

1 Like

What version of OpenWrt. This is not an issue I have seen reported before for this device. Both TX power and CC (country) are ignored and pulled from the EEPROM as per the device locale. If you want to use auto, maybe try some variation on:

	option channel 'auto'
	option channels '1 11 6'

and 5G; this is not a broadcom device.

I'm using the latest, OpenWrt 21.02.2 r16495-bf0c965af0 / LuCI openwrt-21.02 branch git-22.046.85957-59c3392

I added the channels option, but still the radios are still not active. Same thing if I just stick to a fixed channel.

So any message in logread when you start wifi.

Apologies, which logs should look?
kernel & System logs are completely crumbled with these repeating continuously:

[  943.845165] ieee80211 phy0: buffer is NULL for tx done ring
[  943.845209] ieee80211 phy0: adapter does not exist
[  943.855637] ieee80211 phy0: adapter does not exist
[  943.860475] ieee80211 phy0: adapter does not exist
[  943.865295] ieee80211 phy0: adapter does not exist
[  943.870108] ieee80211 phy0: adapter does not exist
[  943.874917] ieee80211 phy0: adapter does not exist
[  943.955532] ieee80211 phy0: buffer is NULL for tx done ring
[  943.995231] ieee80211 phy1: buffer is NULL for tx done ring
[  944.055258] ieee80211 phy1: buffer is NULL for tx done ring
[  944.095275] ieee80211 phy0: buffer is NULL for tx done ring
[  944.155303] ieee80211 phy0: buffer is NULL for tx done ring
[  944.195322] ieee80211 phy1: buffer is NULL for tx done ring
[  944.255349] ieee80211 phy1: buffer is NULL for tx done ring

The dmesg is filled with this as well as logread? On a reboot check for any anomalies re wifi setup messages in dmesg.

yep, dmesg gets filled with those as well: I can't spot any error, but I may have missed something.

PS: in case this may be a potential bug, happy to collect anything that could be useful before wiping all out.

IIRC, from some time deep in a time long time passing, something like this manifested around LED changes; as bizarre as that sounds. Post link from:

cat /etc/config/system | nc termbin.com 9999

Edit: as per issue on mwlwifi github, don't recall cause / resolution

1 Like

Wow that's interesting, indeed I did tweak some LED configurations... may it be that?
All LED configurations actually do work, but should I try removing them?

config system
	option ttylogin '0'
	option log_size '64'
	option urandom_seed '0'
	option compat_version '1.1'
	option hostname 'gta-router'
	option log_proto 'udp'
	option conloglevel '8'
	option cronloglevel '5'
	option zonename 'America/Vancouver'
	option timezone 'PST8PDT,M3.2.0,M11.1.0'

config timeserver 'ntp'
	list server '0.openwrt.pool.ntp.org'
	list server 'time.google.com'
	list server 'time.windows.com'

config led
	option name 'Power'
	option sysfs 'rango:white:power'
	option trigger 'heartbeat'

config led 'led_wan'
	option name 'WAN'
	option sysfs 'pca963x:rango:white:wan'
	option trigger 'netdev'
	option dev 'wan'
	list mode 'link'

config led
	option sysfs 'rango:white:wlan_2g'
	option trigger 'netdev'
	option dev 'wlan1'
	list mode 'tx'
	list mode 'rx'
	option name 'WLAN 2.4GHz'

config led
	option name 'WLAN 5GHz'
	option sysfs 'rango:white:wlan_5g'
	option trigger 'netdev'
	option dev 'wlan0'
	list mode 'tx'
	list mode 'rx'

config led 'led_usb1'
	option name 'USB 1'
	option sysfs 'pca963x:rango:white:usb2'
	option trigger 'usbport'
	list port 'usb1-port1'

config led 'led_usb2'
	option name 'USB 2'
	option sysfs 'pca963x:rango:white:usb3_1'
	option trigger 'usbport'
	list port 'usb2-port1'
	list port 'usb3-port1'

config led 'led_usb2_ss'
	option name 'USB 2 SS'
	option sysfs 'pca963x:rango:white:usb3_2'
	option trigger 'usbport'
	list port 'usb3-port1'

Maybe try a simple test:

cd /etc/config
mv system systemBAK
reboot

to see if the default OOTB system config manifests the same issue.

I just deleted the two WI-FI LED configurations, rebooted and all started working again! :smiley:
This is indeed bizarre and likely a bug!

1 Like

Just an FYI, if this is a CA unit, and you fire up the third radio, be sure all CC are in agreement.

Thanks for the tip, I'm just missing what you exactly intend with CA unit and CC :slight_smile:

Country Code (CC) as in Canada (CA) , I see Vancouver in your TZ setting, but US in the WIFI setup, whiich should be ignored. mwlwifi will grab CC from your EEPROM, so if a CA unit mwlwifi will be CA, but the third radio will default to US, so be sure to set CC.

1 Like

Ah yes, very good point!

Thanks @anomeome for helping get to this fix!!
I'll file a bug and mention you in it! :wink: