I'm using Davidc502 baked firmwares with a WRT3200ACM since the LEDE era, and now with OpenWRT. I updated usually every month for over two years, but I was not able to update for 198 days now.
My current firmware is "Lede SNAPSHOT r8614-78ca6a5578 / LuCI Master (git-18.333.34665-4f2b80e)", kernel 4.14.82.
Few years ago when I bought this router I performed the flash procedure with the "factory" image, and then after that I always downloaded the latest "openwrt-mvebu-cortexa9-linksys_wrt3200acm-squashfs-sysupgrade.bin" - sysupgrade. I'd just go into the System > Backup / Flash Firmware in LuCI, and at the bottom you have the "Flash new firmware image", I select the bin file and Flash. The last 198 days I tried at least 6-7 times periodically, but when the router supposed to reboot, it just gets back into the current state and don't upgrade, don't reboot.
What could be wrong?
Here is a pastebin from the syslog: https://pastebin.com/gevkqXnv
Can this be this dropbear message? I cannot find other detailed log which could be telling.
Did anyone have similar issues? Any pointers for the solution welcome.
Did you at one time have a 1900ac V1/V2? Or have you always owned the 3200ACM?
Sounds to me like the 3200acm has a configuration for an older hardware model, and that's why it doesn't automatically go over to the other partition. The work around is to flash, and then when the router comes up, just use the Power On/Off sequence to boot over to the other partition manually.
I can't remember where I put the instructions, but I used to have them to fix the 3200acm if it got another hardware configuration where it would not boot over to the other partition.
Get the current partition /usr/sbin/fw_printenv -n boot_part
Using the value from "1." replace # with the other partition label. Linksys WRT AC routers have two partitions labelled 1 and 2. If the value from "1." is 1, then replace # with 2 in the command below. /usr/sbin/fw_setenv boot_part #
Hi,
perhaps this would have been the right Thread to post my wifi issue with the wrt32x.
Could someone who is familiar with the Davidc502 build for the wrt32x check out this issue please?
Well, I'm thinking about ripping off the band-aid for dnscrypt-proxy 2. Just finished a build and upgraded, and dns is still working fine. The caveat is the configuration file is in a different directory. I did get the configuration change (thanks @solidus1983) to make it use the configuration file in the old directory, but would be non standard.
I'll probably upload the new build in the morning with dnscrypt-proxy 2 baked in.
Let me share my experience about 160MHz channels in this firmware.
First... In general it works well, but with some tricks and limitation. Speed are very nice, i have around 60MBps reading stream from Samba.
But:
Selecting RIGHT channel is a trick - you should experiment yourself to find right one - and forget about manuals, it can be done even at low channels. If station not start - try different channel number. Keep you eye at the system log, sometimes it can't start because of WPA_SUPPLICANT exception, restart router in this case.
Selecting 160MHz channel make wifi incompatible with some 80MHz-only adapters, they can't connect anymore. In my case i got this with Killer 1535 one. Intel and Quallcomm (android phones) works well.
Conclusion: Yes, 160MHz supported, so you can use it if have no heavy interference at 5GHz and all you gear compatible.
David, I'm looking forward to trying the new build out with dnscrypt-proxy v2 baked in. As I understand, the only change from how it is currently handled is that the config file will be in the new location.
Correct, just move the .toml file out of /etc/config/ over to /etc/dnscrypt-proxy2/ then restart dnscrypt-proxy2 like so --- /etc/init.d/dnscryp-proxy restart
I'm going to be in and out all day, and after 3 will be out of town. However, I'm interested in your experience and if moving the .toml file to the new directory fixes the issue. It should, but I can't just go by my set up or figure it works for me so it will work for everyone else.
Column:
1: channel number
2: ?
3 - 16: Possible power levels? Why so many?
17: ?
18: ?
Which row does indicate if a channel is a DFS channel?
I tried to add a new reg domain with lower power levels (6dbm for 2.4Ghz and 12dbm for 5Ghz)
The kernel log shows that the new regdomain and powerlevels were recognized by mwlwifi.
But there was no actual difference.
@T-Troll
160Mhz almost uses the entire available spectrum,
so maybe it is best to always use channel 36 (centered to channel 50 and 114?) for 160Mhz?
Do your 80Mhz devices support all 5Ghz channels?
160Mhz also only seems useful in a place where no other 5Ghz Wifis interference with your wifi.
When you use 160Mhz channel width your AP can create interference almost along the entire spectrum.
So only use 160Mhz when necessary and/or use adequate power levels.
Unfortunately mwlwifi doesn't allow to lower the output power levels
driver name: mwlwifi
chip type: 88W8864
hw version: 7
driver version: 10.3.8.0-20181210
firmware version: 0x0702091a
power table loaded from dts: yes
firmware region code: 0x0
mac address: 00:25:9c:13:ca:bb
2g: disable
5g: enable
antenna: 2 2
irq number: 73
ap macid support: 0000ffff
sta macid support: 00010000
macid used: 00000001
radio: enable
iobase0: c47fdfd2
iobase1: 28d76619
tx limit: 768
rx limit: 64
qe trigger number: 4004846
Kernel Log:
[ 17.215257] ieee80211 phy1: regdomain: DE
[ 17.219332] ieee80211 phy1: Channel: 1: 0x0 0x0 0xf
[ 17.224247] ieee80211 phy1: 6 6 6 6 6 6 6 6 6 6 6 6 0 0 0 0
[ 17.230044] ieee80211 phy1: Channel: 2: 0x0 0x0 0xf
[ 17.234958] ieee80211 phy1: 6 6 6 6 6 6 6 6 6 6 6 6 0 0 0 0
[ 17.240672] ieee80211 phy1: Channel: 3: 0x0 0x0 0xf
[ 17.245584] ieee80211 phy1: 6 6 6 6 6 6 6 6 6 6 6 6 0 0 0 0
[ 17.251301] ieee80211 phy1: Channel: 4: 0x0 0x0 0xf
[ 17.256219] ieee80211 phy1: 6 6 6 6 6 6 6 6 6 6 6 6 0 0 0 0
[ 17.261948] ieee80211 phy1: Channel: 5: 0x0 0x0 0xf
[ 17.266867] ieee80211 phy1: 6 6 6 6 6 6 6 6 6 6 6 6 0 0 0 0
[ 17.272573] ieee80211 phy1: Channel: 6: 0x0 0x0 0xf
[ 17.277508] ieee80211 phy1: 6 6 6 6 6 6 6 6 6 6 6 6 0 0 0 0
[ 17.283206] ieee80211 phy1: Channel: 7: 0x0 0x0 0xf
[ 17.288133] ieee80211 phy1: 6 6 6 6 6 6 6 6 6 6 6 6 0 0 0 0
[ 17.293829] ieee80211 phy1: Channel: 8: 0x0 0x0 0xf
[ 17.298762] ieee80211 phy1: 6 6 6 6 6 6 6 6 6 6 6 6 0 0 0 0
[ 17.304457] ieee80211 phy1: Channel: 9: 0x0 0x0 0xf
[ 17.309397] ieee80211 phy1: 6 6 6 6 6 6 6 6 6 6 6 6 0 0 0 0
[ 17.315103] ieee80211 phy1: Channel: 10: 0x0 0x0 0xf
[ 17.320128] ieee80211 phy1: 6 6 6 6 6 6 6 6 6 6 6 6 0 0 0 0
[ 17.325823] ieee80211 phy1: Channel: 11: 0x0 0x0 0xf
[ 17.330842] ieee80211 phy1: 6 6 6 6 6 6 6 6 6 6 6 6 0 0 0 0
[ 17.336539] ieee80211 phy1: Channel: 12: 0x0 0x0 0xf
[ 17.341560] ieee80211 phy1: 6 6 6 6 6 6 6 6 6 6 6 6 0 0 0 0
[ 17.347268] ieee80211 phy1: Channel: 13: 0x0 0x0 0xf
[ 17.352281] ieee80211 phy1: 6 6 6 6 6 6 6 6 6 6 6 6 0 0 0 0
[ 17.358019] ieee80211 phy0: regdomain: DE
[ 17.362058] ieee80211 phy0: Channel: 36: 0x0 0x0 0xf
[ 17.367058] ieee80211 phy0: c c c c c c c c c c c c c c c c
[ 17.374173] ieee80211 phy0: Channel: 40: 0x0 0x0 0xf
[ 17.379213] ieee80211 phy0: c c c c c c c c c c c c c c c c
[ 17.386307] ieee80211 phy0: Channel: 44: 0x0 0x0 0xf
[ 17.391327] ieee80211 phy0: c c c c c c c c c c c c c c c c
[ 17.398442] ieee80211 phy0: Channel: 48: 0x0 0x0 0xf
[ 17.403445] ieee80211 phy0: c c c c c c c c c c c c c c c c
[ 17.410563] ieee80211 phy0: Channel: 52: 0x0 0x0 0xf
[ 17.415565] ieee80211 phy0: c c c c c c c c c c c c c c c c
[ 17.422677] ieee80211 phy0: Channel: 56: 0x0 0x0 0xf
[ 17.427701] ieee80211 phy0: c c c c c c c c c c c c c c c c
[ 17.434794] ieee80211 phy0: Channel: 60: 0x0 0x0 0xf
[ 17.439811] ieee80211 phy0: c c c c c c c c c c c c c c c c
[ 17.446904] ieee80211 phy0: Channel: 64: 0x0 0x0 0xf
[ 17.451925] ieee80211 phy0: c c c c c c c c c c c c c c c c
[ 17.459036] ieee80211 phy0: Channel: 100: 0x0 0x0 0xf
[ 17.464138] ieee80211 phy0: c c c c c c c c c c c c c c c c
[ 17.471248] ieee80211 phy0: Channel: 104: 0x0 0x0 0xf
[ 17.476339] ieee80211 phy0: c c c c c c c c c c c c c c c c
[ 17.483458] ieee80211 phy0: Channel: 108: 0x0 0x0 0xf
[ 17.488563] ieee80211 phy0: c c c c c c c c c c c c c c c c
[ 17.495658] ieee80211 phy0: Channel: 112: 0x0 0x0 0xf
[ 17.500779] ieee80211 phy0: c c c c c c c c c c c c c c c c
[ 17.507887] ieee80211 phy0: Channel: 116: 0x0 0x0 0xf
[ 17.512987] ieee80211 phy0: c c c c c c c c c c c c c c c c
[ 17.520110] ieee80211 phy0: Channel: 120: 0x0 0x0 0xf
[ 17.525198] ieee80211 phy0: c c c c c c c c c c c c c c c c
[ 17.532310] ieee80211 phy0: Channel: 124: 0x0 0x0 0xf
[ 17.537425] ieee80211 phy0: c c c c c c c c c c c c c c c c
[ 17.544518] ieee80211 phy0: Channel: 128: 0x0 0x0 0xf
[ 17.549626] ieee80211 phy0: c c c c c c c c c c c c c c c c
[ 17.556720] ieee80211 phy0: Channel: 132: 0x0 0x0 0xf
[ 17.561828] ieee80211 phy0: c c c c c c c c c c c c c c c c
[ 17.568954] ieee80211 phy0: Channel: 136: 0x0 0x0 0xf
[ 17.574051] ieee80211 phy0: c c c c c c c c c c c c c c c c
[ 17.581168] ieee80211 phy0: Channel: 140: 0x0 0x0 0xf
[ 17.586257] ieee80211 phy0: c c c c c c c c c c c c c c c c
So the new values got read by the mwlwifi driver.
I also removed all short range channels (140+ ?)
But iw uses values from the wireless-regdb, I guess?
mwlwifi also has no TPC support, right?
Hmm if it is not possible to reduce power levels through software/driver methods, I'm thinking to get some attenuators and physically reduce the signal.
Someone like kaloz might be able to assist with the format of the DTS power table, but I expect it is NDA.
I'd be also interested in the format of the wrt32x ones that are unrestricted (e.g. AU) because they are a slightly different format.
I expect the middle numbers are a series of numbers which go into a register to tune the power.
I think someone asked about the dts layout on the mwlwifi github issue tracker before and kaloz replied that he can't answer this question, so yes you are right and it is under NDA.
Why do some tables have different values in the same row?
I have some other question about the automatic channel selection.
To exclude dfs channels from the automatic channel selection:
acs_exclude_dfs option doesn't me to work with mwlwifi.
acs_chan_bias '36:0.8 44:0.8' sometimes seems to work but is not reliable enough.
channels '36 44' seems to work best but sometimes hostapd gives this message: hostapd: Switch own primary and secondary channel to get secondary channel with no Beacons from other BSSes
In this case ACS has selected channel 44 (+48 as secondary) but then switches those channels.
48 primary and 44 as secondary but then my devices can't connect anymore.
Using the noscan option fixes this but is there are a better solution?
//edit
Nevermind, works fine.
When using channel 48 with a channel width of 40 Mhz,channel 52 will be used as secondary channel?
If yes, this can cause DFS to trigger because channel 52 requires DFS?
This new build with dnscrypt-proxy v2 works well in my configuration (Linksys WRT1900ACS V2, ~50 devices, most wireless, added wireguard and vpn-policy-routing packages, 300 Mbs / 100 Mbs fiber connection).