yeah i know, but i thought it will earse the data and then reboot the router or do a clean start up after a reset . coz in the faq, it says try to connect to the router after reset by plugin the cable , so....
i want to see if there are any bad blocks etc in the log file
no, it shouldnt be a power issue
Hi @hnyman
Are you able to test your kernel 5.10 DSA build with VLANs? I had the following setup:
R7800 R7800
DHCP ----802.1q trunk----dumb
router AP
The result is like Ethernet switch on VLAN enabled router is misbehaving. At the same time VLANs aware dumb AP is working fine. After swapping R7800 router with AX3600 with the same (in general) config everything works as it should.
DDNS worked 8+ days ago - only had a short time to setup for another location so it's been powered off during this time. Turned the R7800 back on today to finish setup for the network and noticed DDNS showed never/stopped for enabled ipv4. 8 days ago, it showed timestamps for last/next update (duckdns.org). Now it shows never/disabled. Error in the log is below. Any suggestions on how to get DDNS working again?
user.warn ddns-scripts[7338]: myddns_ipv6: PID '7338' exit WITH ERROR '1' at 2021-07-31 21:41
user.err ddns-scripts[7337]: myddns_ipv4: IP update not accepted by DDNS Provider
Hey guys. Brand new user here. Got the build up and running. Enabled SQM using cake/poc on eth0.2 and download speeds have gone from 400mbs to around 20mbps. I know to expect some reduction but is that much normal?
No, it is not normal.
Some config error in your settings, probably.
Mmh, please post your /etc/config/sqm in a new thread and we can take it from there...
Unless it requires lots of effort, is there any chance @hnyman that the 19.07 branch of your build is updated at least to the latest available version r11364 ? : https://openwrt.org/releases/19.07/notes-19.07.8
I softened and did one more 19.07 build with r11366-cfc1602a1e
But as the network config has already changed between 19.07 and 21.02, downgrading is not that easy, and I have to modify my own config, which makes downgrading cumbersome. I have also noticed that I have got some "ubi bad superblock" errors with the last few 19.07 downgrades, so I have lost my config several times, also today. So, this is definitely the final time with 19.07...
The 21.02 final release will get released soon, so there is no real need to stay with the ancient 19.07.
Thanks @hnyman , I was looking for this 
Will the minimal difference between standard r11364 and this r11366 be causing issues when using the package repository?
Is the v21 already that matured out yet?
Just look at the source changes by yourself...
https://git.openwrt.org/?p=openwrt/openwrt.git;a=shortlog;h=refs/heads/openwrt-19.07
There is only the labeling to 19.07.8 and then reverting back to 19.07 snapshot.
No trouble for normal use-space packages, but naturally kernel packages are prevented to be installed, like always.
Thanks, for me as non-dev an adjust and reverse is really weird. I just assume all updates and fixes below it are incorporated.
I just installed the fresh R7800-master-r17319-1c9a9f7c7a-20210810-2141-sysupgrade and it runs fine!
It just makes the 19.07 branch history to continue after the fixed 19.07.8 point. Five years ago releases were one-commit dead-end deviations, but then you could not easily later see where the release 19.07.7 was and what has happened then before 19.07.8.
Now you can more easily see that. 19.07.8 and 19.07.7 linearly in the same history.
I'd like to report a bug regarding the build:
hostapd_cli does not properly function with "/usr/sbin/hostapd_cli -a -B -i " parameters
I know that I've posted before with questions regarding this but this time I've compared the standard openwrt 21rc4 and owrt2102-r16263-4003eeab35-20210803.
In case of this build the user defined script is not run at all.
Test case:
Reinstalling hostapd-utils does not make any difference.
I suspect that is somehow related to hostapd_cli being shipped with the build in relation to WPS but my knowledge is very limited.
I can assist in further investigations if required.
Can you share the script and the exact cmd to launch hostapd_cli?
Of course
The script is launched via entry in /etc/rc.local.:
/root/device-detection/onBoot.sh
onBoot.sh:
#!/bin/sh
# Script that should be run when router boots up
# Should be called from /etc/rc.local
MOSQUITTO_HOST="SNIP"
MSG_TOPIC="openwrt/boot"
MSG=$(date +"%s")
# wait for the router to boot up
sleep 20
# send boot message
mosquitto_pub -h "$MOSQUITTO_HOST" -t "$MSG_TOPIC" -m "$MSG"
sleep 1
# setup device detection scripts
/usr/sbin/hostapd_cli -a /root/device-detection/eventHandler.sh -B -i wlan0 # 2.5GHz
/usr/sbin/hostapd_cli -a /root/device-detection/eventHandler.sh -B -i wlan1-1 # 5GHz
eventHandler.sh:
#!/bin/sh
# Script handles hostapd events
# hotapd_cli event vars
# $1 = interface
# $2 = action
# $3 = MAC Addr
MOSQUITTO_HOST="SNIP"
MSG_TOPIC="openwrt/device_change"
MSG="{\"event\":\"$2\",\"device\":\"$3\",\"interface\":\"$1\"}"
mosquitto_pub -h "$MOSQUITTO_HOST" -t "$MSG_TOPIC" -m "$MSG"
It's worth noting that the "boot message" sent to mqtt broker is received on each test case scenario.
Interesting, I tested with the master build with a simpler script (without mosquitto) and manually launched hostapd_cli, and the triggered script does not seem to run.
Hard to understand why that wps pin code would hurt, and there aren't any other wifi changes.
One major difference is naturally that I use the openssl based hostapd/wpad instead of the default wolfssl-based wpad. But again, hostapd_cli in my build has been compiled along the main wpad, so no reason to believe in version incompatibility.
Dear hnyman and all,
I hope that all are doing well and fine. The purpose of my writing is to ask a pretty straightforward question. Before I do - please no one scold for asking afterwards. I run Divestedwrt on wrt32x and with wireguard - I get 350 MBPS download. Nowhere near this when running these builds or ACwifiDude's NSS. I wonder if this is due to Divestedwrt 5.10 kernel or devcrypto engine being active - or both the cause of the high throughput. With all of that being said - any new 5.10 kernel test builds on the horizon ? Just asking - no pressure intended - Peace
wrt32x has a more powerful CPU for gigabit speeds. Having gigabit connection with wireguard (=additional computation) (and possibly SQM?) may require more CPU power than the R7800 has.
I do not think that the kernel 5.10 would help by itself, but the NSS might help, and naturally a hardware crypto module helps.
I have been waiting with the next 5.10 test builds, as the whole IPQ806x target should likely switch to 5.10 once the 21.02 has been released.
I am using my nbg6817 (same SOC, same performance wise) on a 420/220 MBit/s internet connection, while there's not a huge headroom remaining (probably ~550-650 MBit/s tops), this device can do that without resorting to NSS offloading or software offloading, but also without sqm or VPN (I do have an incoming wireguard connection configured, but that's not really stressing the limits). By enabling sqm, you drop down to around/ just under 200 MBit/s - I have no benchmarks for tunneling all internet traffic through wireguard.
In terms of routing performance, the mvebu SOCs win by a fair margin (at least without dragging NSS offloading into the picture) - in terms of computing power (VPN), ipq8065 should be slightly ahead (but they're pretty much the same). In high speed scenarios, that also implies the mvebu devices being ahead, as they don't need to spend as much performance on dealing with the pure networking, but can dedicate more performance at the VPN encryption/ decryption.
Dear hnyman and slh,
Thanks for the information and education regarding the differences between the devices I referred to in my earlier post. So, I will just " lay in the cut " - be and stay cool until 5.10 kernel drops for R7800 - Peace To All