Thanks , I will try and apply it in the next change window ( when my wife is asleep and not using wifi ) 
This is why you need a dual AP setup You do a rolling upgrade and nobody notices the downtime.
1 Like
Everything appears to work ok for me
I have disabled the 5ghz wifi, and the latest build seems to work now without any issues.
My previous configuration:
5ghz wifi:
- Home
2 ghz wifi: - Home
- Guests
- IOT
Was/is there an issue using 5ghz wifi?
jow committed today a fix to uhttpd (the default web server in LuCI), which should hopefully remove the XHR request timed out errors that have plagued LuCI the past few weeks. (LuCI has often typically required a forcible browser refresh after a flash (or some times also after a login))
so, hopefully master-r14639-2a90d308c7-20201005 does not cause that symptom any more.
LuCI works far better however upgrade from web interface still doesn't.
What doesn't work with the upgrade?
I have been sysupgrading from LuCI the whole time.
For me (tested with both r14639 and r14640) upload is accepted but then nothing happens. Also I have noticed degraded 5G performance of r14640 compared with r14639.
Sysupgrading from r14639 and r14640 (to same or next build), or
sysupgrading to them (using sysupgrade & LuCI from the previous firmware)?
Might be browser-specific. Firefox has worked for me (but I haven't yet tested sysupgrading forward from r14639).
Chrome beta. From r14639 to r14640 and back.
I just sysupgraded normally from r14639 to r14640. No problems.
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0
If you continue to have problems, you might check your browser extensions/add-ons etc. (plus clear the cache).
I am usually upgrading through CLI anyway. More concerned about 5G perfirmance
Heads up for those using references to LEDs in scripts/config:
somewhere around build 14693 paths for LEDs got changed.
Now it is like /sys/class/leds/amber:power/ instead of /sys/class/leds/r7800:amber:power/
1 Like
Sure. (merged on Oct 7)
I haven't yet figured if I will implement a reverse transition script in 19.07 (for going back from master to 19.07)
BTW 5G WiFi performance issue I was mentioning previously seems to be gone:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 813 MBytes 682 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 811 MBytes 680 Mbits/sec receiver
Is this now part of 19.07.4? I just did a clean install on an r7800 which had no problems with 18.x.x builds, and get this error after a very long wait. Then it all continues on fine.
Are you testing with a 3x3 WiFi client? What is the CPU utilization like?
2x2 if I am not mistaken (Intel AX200).
freq: 5320
RX: 1518098446 bytes (2133757 packets)
TX: 2072277066 bytes (544514 packets)
signal: -56 dBm
rx bitrate: 1053.0 MBit/s VHT-MCS 6 160MHz VHT-NSS 2
tx bitrate: 866.7 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 2
bss flags: short-slot-time
dtim period: 5
beacon int: 101
Ah ... 160MHz. That explains it.
I wonder if you would hit near Gbps speed if using the master NSS build, as least for the client(tx) -> AP(rx) direction.
Thanks for providing the details.
I am running version OpenWrt 19.07-SNAPSHOT r11210-29b4104d69 / LuCI openwrt-19.07 branch git-20.247.75781-0d0ab01
I have observed twice in the last 2 weeks a shutdown of the wireless drivers. Happened again tonight. All Wi-Fi networks simply disappear.
Network -> Wireless -> Restart buttons are not helping to make the Wi-Fi start up again. Pressing Restart button results in no change. Pressing "Enable" finally made them start again.
I cannot find any error messages in system or kernel log helping me identify what have gone wrong. This is annoying.
ifconfig wlan0 gives me "ifconfig: wlan0: error fetching interface information: Device not found"
Anybody got a hint what might be the issue? How can I debug this?
Could it be a thermal problem?
