OpenWrt 19.07.0 second release candidate

Using this on a Linksys EA6350v3, the second wireless interface fails to be initialised. The only error I see in the log is:

radio1 (2249): command failed: Not supported (-95)
mac80211: Failed command: iw phy phy1 set distance 0

but after the message "ACS-STARTED" it can't be seen and/or connected to.

Well, I thought 19.07 rc2 was stable on my EA8500's, but when I configured one the same as the EA6350v3 that 19.07 rc2 was crashing (i.e., replaced EA6350v3 with EA8500) for my first floor AP, I'm seeing the same problems - only difference is the EA8500 has 512MB of memory to hide the problem better.

A spike in CPU usage (core 1 jumps to 1.4 GHZ and 100% usage) occurs just before the memory use starts slowly climbing up from a too high (for the light load) ~150MB to ~210 MB, then drops to ~180 MB. This unit is only being used as an AP for two SSID's each on 2.4 and 5G (a main and a guest each) with a couple wired clients plugged into the ports. I'm using the ath10k-ct, but as noted previously, swapping to the non ct didn't help on the EA6350v3.

And as I type, wifi on the second floor EA8500 running 19.07 rc2 just crapped out too. Which is odd, because it had been fine for days. I changed one thing - I added the cpu frequency plugin for collectd. Guess I'll not be installing that again anytime soon.

Something's broke.

No issues so far with 19.07.0-rc2 on a R7800 (updated from 18.06.5/saving settings).

EDIT: over 7 days of uptime/no issues.

Ran snapshot r11626 overnight (CPU frequency not installed) to see if that would fix. Nope.

It has behaved so far on upstairs EA8500 AP, but not first floor EA8500 AP. Same problems on first floor AP as with 19.07 rc2.

The first floor unit is configured the same with one difference: it has a DHCP client "IOT" interface mapped to a VLAN and port reserved for same that an Ooma VOIP box is plugged into. Otherwise both radios with a primary and guest (the latter mapped to guest VLAN) are in use on both EA8500 AP's. Both AP's are wired to same EdgeRouter X providing DHCP and DNS to all VLAN interfaces (including the IOT and guest VLAN).

So I guess next obvious debug is to remove the IOT VLAN from the first floor unit, map the Ooma port to the main lan, and see if that makes the problems go away.

Installed sysupgrade fine on Archer A7 v5, everything seems fine but can't login to Luci. I get to the login page but get 2 ERR_ABORTED 403 messages (I'll reproduce below). If I attempt to login with the correct password, it just reloads the login page with the same 2 errors. If I use the wrong password it tells me the password is wrong. I attempted to upgrade uhttpd and luci but it didn't change anything. Any ideas?

Here are the errors:

/luci-static/resources/cbi/up.gif?0.7759592691925761:1 GET https://192.168.1.1/luci-static/resources/cbi/up.gif?0.7759592691925761 net::ERR_CONNECTION_REFUSED

/cgi-bin/luci/:10 GET http://192.168.1.1/cgi-bin/luci/admin/translations/en?v=git-19.334.63023-039ef1f net::ERR_ABORTED 403 (Forbidden)

Please start with clearing your browser cache.
In case you had installed luci-ssl before, you'll need to reinstall it before (via ssh) being able to access luci again - sysupgrading removes the necessary ssl/ tls library, but the config redirection http to https remains, leading to luci becoming inaccessible until you reinstall a tls library.

3 Likes

archer A7 v5 (AC1750), all good so far with -htt firmware. Using -htt as a test, since i had wifi issues with a snapshot a while back:

opkg remove ath10k-firmware-qca988x-ct && opkg install ath10k-firmware-qca988x-ct-htt

# opkg list-installed|grep ath|grep -v ath9
ath10k-firmware-qca988x-ct-htt - 2019-10-03-d622d160-1
kmod-ath - 4.14.156+4.19.85-1-1
kmod-ath10k-ct - 4.14.156+2019-09-09-5e8cd86f-1
kmod-phy-ath79-usb - 4.14.156-1

Upgraded the TP-LINK WDR4300 directly from 18.06.5 using the ath79 factory.bin. Even could keep configuration. Works great out of the box.

I think I've got the low memory crash solved. Has to do with the crashing AP having a VOIP phone plugged into a port mapped by the switch to a designated IOT VLAN interface. Checking "Bridge interfaces" in the physical settings for this IOT interface seems to have solved the problem. Doesn't make sense to me - it's not bridged to anything (other than itself) - but memory use is holding steady now just below 60MB. So the problem was not specific to the EA6350v3 at all. Since I swapped it for an EA8500 for debug purposes, I'll probably leave the EA8500 in place unless I get too much "too big for great room" interior decorating feedback.

Thanks! That was it. I've been using snapshots so used to installing a bunch of modules right away and didn't occur to me that ssl was one of them.

This version does not work with hg556a ver A the same problem does not boot

Thanks for sharing. Been running rc2 since it out, now the WiFi 2.4 G is not working anymore, 5G still working.

My router is TP-Link Archer C7 v2.

I installed 19.07 RC 2 on my Turris Omnia via Turris OS which is based entirely on OpenWRT. I am experiencing a problem with access to ssh and LuCI. Although I enter the correct password I continue to be denied access due to incorrect password. The second time I tried updating from scratch, I activated ssh via public key. So I can log in via ssh, but the problem remains with LuCI. I also tried to clean the browser data, but without result. Everything else works perfectly (wifi, LAN, switch, routing, etc). Does anyone know what it could be?

WRT1900ACS: Upgraded from 18.6.5. No issues noted.

@xback Any suggestions how to approach this?

Do you have kept your config?

Did you make any progress identifying the cause of this or open a bug report for it?

Although not a stadia controller, I'm also seeing unpredictable ping's and low speeds on 5G wireless after upgrading to 19.07.0-rc2 on a Linksys WRT3200ACM.

I can trigger the same behavior on 19.07.0-rc1 if I upgrade wpad-basic which suggests there may be some change between hostapd 2.7 (2018-12-02-c2c6c01b) and 2.9 (2019-08-08-ca8c2bd2) which is negatively affecting it.

Using davidc502's community builds for this platform I also see the same behavior starting in his r11159-27bf8abe69 build which was the first to include hostapd 2.9.

I experience the exact same behavior with my C2600.

And by the way, my WDR4300 used as Access Point migrated from ar71xx to ath79 works like a charm.

No not really but seems you already made good progress identifying a possible root cause. Will try and compile rc2 but keeping hostapd to version 2.7 so we can confirm if this is the culprit and open a bug report.

edit: also explains why pre-compiled rc1 image does not have the issue but imagebuilder rc1 does

I was hoping to test out the ath79 build for my TL-WDR3500, but it's not available. Is there a reason for this?

It has 128mb RAM, so it's not one of the low memory devices.