I get a pretty rare crash about once every two weeks running the latest master build. Been experiencing this for about six months now.
Are kernel panics logged anywhere before the system resets so I can hopefully report this to the openwrt devs?
Also, still absolutely in love with this build/router. I'll be sticking to this until Ubiquiti adds CAKE support officially, which might be a long time. It's that good.
I've had no crashes since I bumped the lowest freq it can go to 800 MHz there were previous posts here discussing it (and I seen in the luci monitoring logs the freq constantly jumping from 300ish to 800), atm I'm using various settings gathered from the thread and had no restart in last 2 weeks or so, for the record I only use 2,4 GHz wifi on the router (for my IoT devices) and the router is only connected to modem and a managed switch.
I got this in my Local Startup in luci:
echo ondemand > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
echo ondemand > /sys/devices/system/cpu/cpufreq/policy1/scaling_governor
echo 1725000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq
echo 1725000 > /sys/devices/system/cpu/cpufreq/policy1/scaling_max_freq
echo 800000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
echo 800000 > /sys/devices/system/cpu/cpufreq/policy1/scaling_min_freq
echo 75 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
/usr/sbin/irqbalance
exit 0
This morning, again, the PiZero is no longer connectable. This is in the kernel log
[286759.252859] ath10k_pci 0000:01:00.0: Invalid peer id 41 peer stats buffer
[286759.259184] ath10k_pci 0000:01:00.0: failed to lookup txq for peer_id 41 tid 1
The 'Failed Lookup' error was repeated many times.
There's a new firmware file for "old"
https://github.com/kvalo/ath10k-firmware/blob/master/QCA9984/hw1.0/3.9.0.2/firmware-5.bin_10.4-3.9.0.2-00099
And also the 3.10 version that has been around for a while:
https://github.com/kvalo/ath10k-firmware/blob/master/QCA9984/hw1.0/3.10/firmware-5.bin_10.4-3.10-00047
The default in the "old" builds is 10.4-3.9.0.2-00070
Not sure what the policy is to bump it to a more recent one.
And also a new "ct" version .019
https://www.candelatech.com/downloads/ath10k-9984-10-4b/?C=M;O=D
Edit: Unfortunately for me .019 is worse than .018 very laggy and packet loss between 2 Macs.
Still having this issue. The 5Ghz seems more stable. It is now the 2.5Ghz that seems to have disconnects w/o reconnect.
@hugalafutro Have put your settings in the router Starte=up and rebooted. Will see if there is any difference.
After installing master-r13684-3b0f698760-20200704 and importing the SSL certificate into the Trusted Root Certification Authorities (Chrome), I still cannot https into luci without the "privacy" error.
Any ideas?
edit: sorry, the problem is that I cannot get rid of the annoying 'not secure' message regarding the certificate.
For Chrome you'll need a certificate with a matching "Subject Alternative Name". You can use the OpenVPN software package where you'll find the "easy-rsa" utility to generate self signed certificates containing those fields.
Or you can install and maintain updates for free Let's Encrypt certificates, respected by most current browsers out of the box.
Any thoughts/inputs on this? Thanks
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=3e992ea790f470d754eaba3e76608630f38055db
Still having issues. I was able to have a mostly complete 2 days without issues. Now, I get his when I rebooted the Pi:
[168235.296541] ath10k_pci 0000:01:00.0: Invalid peer id 16 peer stats buffer
It has an address. The Router shows it getting an address. It can connect the internet. I cannot route to it. I cannot ping it.
Thu Jul 9 17:49:39 2020 daemon.info hostapd: wlan0: STA b8:27:eb:52:cc:d0 IEEE 802.11: disassociated
Thu Jul 9 17:49:40 2020 daemon.info hostapd: wlan0: STA b8:27:eb:52:cc:d0 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Thu Jul 9 17:49:59 2020 daemon.info hostapd: wlan0: STA b8:27:eb:52:cc:d0 IEEE 802.11: authenticated
Thu Jul 9 17:49:59 2020 daemon.info hostapd: wlan0: STA b8:27:eb:52:cc:d0 IEEE 802.11: associated (aid 3)
Thu Jul 9 17:50:00 2020 daemon.info hostapd: wlan0: STA b8:27:eb:52:cc:d0 RADIUS: starting accounting session C8BBB0D049DE475C
Thu Jul 9 17:50:00 2020 daemon.info hostapd: wlan0: STA b8:27:eb:52:cc:d0 WPA: pairwise key handshake completed (RSN)
Thu Jul 9 17:50:05 2020 daemon.info dnsmasq-dhcp[3412]: DHCPDISCOVER(br-lan) b8:27:eb:52:cc:d0
Thu Jul 9 17:50:05 2020 daemon.info dnsmasq-dhcp[3412]: DHCPOFFER(br-lan) 192.168.2.41 b8:27:eb:52:cc:d0
Thu Jul 9 17:50:10 2020 daemon.info dnsmasq-dhcp[3412]: DHCPDISCOVER(br-lan) b8:27:eb:52:cc:d0
Thu Jul 9 17:50:10 2020 daemon.info dnsmasq-dhcp[3412]: DHCPOFFER(br-lan) 192.168.2.41 b8:27:eb:52:cc:d0
Thu Jul 9 17:50:10 2020 daemon.info dnsmasq-dhcp[3412]: DHCPREQUEST(br-lan) 192.168.2.41 b8:27:eb:52:cc:d0
Thu Jul 9 17:50:10 2020 daemon.info dnsmasq-dhcp[3412]: DHCPACK(br-lan) 192.168.2.41 b8:27:eb:52:cc:d0 rune64
I deauthorized it and rebooted the Pi
Thu Jul 9 17:52:53 2020 daemon.info hostapd: wlan0: STA b8:27:eb:52:cc:d0 IEEE 802.11: deauthenticated due to local deauth request
Now I can ping it from another Pi on the LAN but not from my Windows machine nor can I ssh onto it. This will require a router reboot which I cannot do right now.
Actually, I did not reboot, but I was able to reach it via ping and ssh, it just took some time. Do not know how long, but after about 30 min I was able to get back in.
Is hardware NAT now working with the current build and kernel 5.4?
It seems to slow down speed a bit now. The soft flow offload gave an extra 60Mbps.
Or do I need to add an extra software package for this?
Speed is just below 600Mbps now while 941Mbps should be possible (measured on provider's modem/router which is in bridged mode now).
To get FTPS working, forum posts suggested that I need to add kmod-nf-nathelper. But it said "The installed version of package kernel is not compatible, require 5.4.50-1-fb9254c9… while 5.4.48-1-124388c2… is installed."
Does (some of) the software repository only work with the latest build? I'm on OpenWrt SNAPSHOT r13628-870588b6eb build from 25-6.
now that schedutil is supported. works better than ondemand for me, no more need for up_threshold and sampling_down_factor
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_governors
echo schedutil > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo schedutil > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
Still getting this with one RPi. Once it looses its connection, it requires a reboot of the Router and the RPi to reconnect.
[ 7997.416717] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind event: in push mode
[ 7997.416758] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind event: in push mode
[ 7997.423994] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind event: in push mode
[ 7997.432141] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind event: in push mode
[33501.126243] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind event: in push mode
[33501.126303] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind event: in push mode
[33501.133437] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind event: in push mode
[33501.141660] ath10k_pci 0000:01:00.0: received unexpected tx_fetch_ind event: in push mode
What is this? Is it a flawed driver on my RPi or something with ath10k_pci? Both seem possible. On Friday, I had a ro filesystem that had to be remedied and today, I have an ovpn issue where I get this:
Insufficient permissions to read UCI configuration.
at the top of the ovpn configuration page. I looked through the log and did see this:
Sat Jul 11 16:30:36 2020 daemon.err openvpn(xxxx)[2102]: tls-crypt unwrap error: packet too short
Sat Jul 11 16:30:36 2020 daemon.err openvpn(xxxx)[2102]: TLS Error: tls-crypt unwrapping failed from [AF_INET]185.200.118.58:51947
Was this an attempt to connect to my vpn?
Now I am confused. I just tried to download and install the latest hnyman build and when I went to the dropbox, there were no longer images, but folders. Looking for the latest 'master- r13768' which I do not have and all I see are folders and no images. Did something change?
Just click on the folder and from inside the folder download the sysupgrade file, e.g. R7800-master-r13768-f632747704-20200709-1416-sysupgrade.bin
It's always been folders for as long as I've owned a R7800.
Each folder is a release, with it's factory image, upgrade image, manifest and the relevant config files to rebuild the firmware on your own build system.
Some folders are snapshots, some are stable builds.... There's even a choice of wifi drivers at some stages.
My bad. It must've been displayed a bit differently than before. I found the sysupgrade file and will flash it later today. Thanks!
I am currently running my own build of 19.07.3, which should be similar to the build generated by openwrt buildmaster. With software offloading and ondemand governor tweaks, I am able to push 930mbps wan-to-lan and lan-to-wan.
My WiFi speeds on the my Oneplus 6 on the 802.11ac (5G) network is always around 500-540mbps down and around 300-380mbps up.
Can someone here clarify something for me? I assumed that as long as I had an openWRT firmware installed that I could use the '*.sysupgrade.bin' file to upgrade it. Is that correct, or do I have to use hnyman's factory.img then flash his sysupgrade?
I ask this as I had a 'bad day' with connectivity today and had to wipe the router and put ddwrt back on it. Been running it for years and am just more comfortable with it. I want to put openWRT back on it as it is faster and has more features I like, but I'll need to wait for another window of opportunity. We have 4 people using this connection and I need it for work as does my wife and the network was going down about every hour or 2 requiring a network restart to recollect an ip address from Comcast.