you are a magician 
thank you
@robimarko as we fixed this last thing, i think this device is the best ipq807x device currently? good looking device, good feature...
1 Like
Overall its a really good device, when its on sale its not a bad buy
In terms of bang for buck, the Dynalink DL-WRX36 probably wins (going for around 90 EUR at the moment, IPQ8072A, QCN5024+QCN5054, 1* 2.5GBASE-T + 4* 1000BASE-T, 256 MB flash/ 1 GB RAM); obviously lacking the 10GBASE-T feature.
what about support?
I don't have it myself (I sadly missed out on the good deals in spring for around 60 EUR), but it seems to be mostly in order and in Robert's tree:
WOW IT WAS 60 EUR WTH...
main problem is that both can't be found online o.O chip shortage ?
I got mine as used one from eBay for 70 EUR as I couldn't find it anywhere to buy new.
Its constantly 99 USD in US, so its is best buy I would say for the money since its IPQ8072A so full clock, 1GB of RAM and even has 2.5G port
I am having an issue with wifi not starting at boot; I am able to bring up the wifi by issuing "wifi up"
this is the log - the last line show the output of "wifi up"
Wed Oct 26 08:58:00 2022 daemon.notice netifd: radio0 (2621): Phy not found
Wed Oct 26 08:58:00 2022 daemon.notice netifd: radio0 (2621): Could not find PHY for device 'radio0'
Wed Oct 26 08:58:00 2022 daemon.notice netifd: Wireless device 'radio0' set retry=0
Wed Oct 26 08:58:00 2022 daemon.notice netifd: radio1 (2622): Phy not found
Wed Oct 26 08:58:00 2022 daemon.notice netifd: radio1 (2622): Could not find PHY for device 'radio1'
Wed Oct 26 08:58:00 2022 daemon.crit netifd: Wireless device 'radio0' setup failed, retry=0
Wed Oct 26 08:58:00 2022 daemon.notice netifd: Wireless device 'radio1' set retry=0
Wed Oct 26 08:58:00 2022 daemon.crit netifd: Wireless device 'radio1' setup failed, retry=0
Wed Oct 26 08:58:00 2022 daemon.notice netifd: radio0 (2692): WARNING: Variable 'data' does not exist or is not an array/object
Wed Oct 26 08:58:00 2022 daemon.notice netifd: radio0 (2692): Bug: PHY is undefined for device 'radio0'
Wed Oct 26 08:58:00 2022 daemon.notice netifd: Wireless device 'radio0' is now down
Wed Oct 26 08:58:00 2022 daemon.notice netifd: radio1 (2701): WARNING: Variable 'data' does not exist or is not an array/object
Wed Oct 26 08:58:00 2022 daemon.notice netifd: radio1 (2701): Bug: PHY is undefined for device 'radio1'
Wed Oct 26 08:58:00 2022 daemon.notice netifd: Wireless device 'radio1' is now down
Wed Oct 26 09:03:47 2022 daemon.notice netifd: Wireless device 'radio0' is now up
Wed Oct 26 09:03:48 2022 daemon.notice netifd: Wireless device 'radio1' is now up
Wed Oct 26 09:42:49 2022 daemon.notice netifd: Wireless device 'radio1' is now down
Wed Oct 26 09:42:49 2022 daemon.notice netifd: Wireless device 'radio0' is now down
Wed Oct 26 09:42:50 2022 daemon.notice netifd: Wireless device 'radio1' is now up
Wed Oct 26 09:42:50 2022 daemon.notice netifd: Wireless device 'radio0' is now up
has anyone observing this issue? this seems to have been originated by the move from wlan to use instead phy-ap
All other devices I have dynalink + ax3600 don't have this issue.
thank you
After some searching for a proper 10G/2.5G router, and seeing the ongoing support, I've decided to grab a 301W.
Installing OpenWrt was a breeze with the "live" approach detailed above, instead of cracking the unit open.
A few notes:
- if possible, I'd reverse the Eth port assignment order - the current order is a bit confusing (eth3 is Port 1 on the 2.5Gb row, going down all the way to eth0 being Port 4, then port 5 is 10G port 1, and so on). IIRC older OpenWrt porting documentation had a soft requirement of having the ethX interfaces match up as close to the exterior port numbering as possible, to reduce confusion. Maybe even going as far as calling them 10geth0/10geth1, 25geth0...25geth3? I'm not certain about the naming requirements if it would allow the port names to begin with a number, so worst case scenario, I could see eth0..eth3 being matched up with Port1..Port4, and eth4/eth5 staying the same working.
- I ran into a weird scenario on my first setup try, where, when I reassigned the WAN port as eth3 (Port 1 on the 2.5G row), it wouldn't initiate a full link - there was some minimal Rx/Tx, but no DHCP assignment, even though the logs showed no issues, it just seemed to time out? After a reboot the issue was gone and even after multiple resets, I couldn't reproduce it.
- is there any progress on getting mainline U-boot support? I know it's not important for the current level of "making it work", but I would feel safer if all the QNAP shit was completely gotten rid of, given their tendency of not giving a flying frak about security (just see how many cases of cryto lockers have hit QNAP NASes due to the default configuration being about as secure as jamming two wet metal chopsticks into an electric outlet), plus it would open up a few improvement opportunities
- first and foremost improvement would be that we can get rid of the awful partition layout Qnap enforces, to use the whole 4GB flash, allowing a bit more functionality jammed into the router, say, a Unifi controller, or Nginx reverse proxy (with Nginx Proxy Manager) through Docker. This would obviously require an approach similar to what was done on the Belkin RT3200, using a specially made build of OpenWrt that takes care of the flash rearrangement (and backup of the stock partitions) into the UBI layout, and possibly another build that can take the official firmware image (or the previously created backup files), and restore the stock completely.
@robimarko I've been considering a possible solution for both the GHA-multibuild issue of missing extra packages (that was mentioned somewhere around halfway through the thread), as well as a proper update pipeline and platform-specific updates, at least until the ipq807x platform gets official snapshot support in the official repo: by using asu. The GHA workflow could he modified to build the OpenWrt ImageBuilder target instead, with all extra package and kernel module built specific to our arch, added to a tagged release, then in another step, a GitHub Pages subpage could be generated (based on a template mimicking the OpenWrt Downloads portal, allowing the base asu implementation to work when pointed to that GHP URL) and committed.
Once this is done, an ASU server could be hosted that takes care of generating updates for the users. If someone was willing to take care of the logistics/maintenance, I'd gladly donate £2-3 a month to keep things running.
If there's interest, I could start looking into automating the Downloads page generation, and the template for it, maybe even work out a way to replace asu's rq-based worker with GHA workflows running with specific parameters... Then the asu instance could run on something as small as a DigitalOcean droplet.
I agree on the naming, its not intuitive as its just the order that driver registers them.
There is no work on U-boot for this SoC, it's low on the list.
There isn't any 2.5G row, those 4 black ports are 1G only, and only those 2 10G ports can do 2.5 and 5G as well.
Honestly, I dont want to create parallel infrastructure for this.
With some planning (and maybe a migration script) the upgrade should be painless, I believe.
Understandable. Are IPQ targets hard to port over to U-Boot mainline? First time I'm looking at Qualcomm's platform from a non-BSP perspective (i.e. non-Android), so no idea if it's gonna be a struggle, or a breeze.
You're right, I'm a moron - been looking at all the Qhora models, and mashed up the 321 with the 301W.
Me neither, but ipq807x support isn't getting merged anytime soon to mainline OpenWrt, which means no (semi)official builds making it to the main ASU server, which severely limits the update and package-install possibilities.
EDIT:
Just saw that you pushed some changes to your ipq807x-5.15-pr branch, which should deal with the renaming of the ports (unless I'm misreading something). Cheers!
Well, it's quite challenging to port U-boot as there aren't really any existing drivers that can be reused.
I only pushed driver changes to parse the label property and set that as the interface name only half an hour ago, but I did not set them in the DTS so far.
No, there are no changes.
I just pushed support for NSS DP to even read the name from label property if set in DTS like an hour ago:
But, have not changed it on any boards at all.
1 Like
Can't seem to get past 2.3 Gbits/s on the latest build. 100% usage on single core.
iperf3 -c 192.168.1.1
Connecting to host 192.168.1.1, port 5201
[ 4] local 192.168.1.201 port 9752 connected to 192.168.1.1 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 263 MBytes 2.21 Gbits/sec
[ 4] 1.00-2.00 sec 274 MBytes 2.29 Gbits/sec
[ 4] 2.00-3.00 sec 273 MBytes 2.29 Gbits/sec
[ 4] 3.00-4.00 sec 276 MBytes 2.32 Gbits/sec
[ 4] 4.00-5.00 sec 275 MBytes 2.31 Gbits/sec
[ 4] 5.00-6.00 sec 274 MBytes 2.30 Gbits/sec
[ 4] 6.00-7.00 sec 275 MBytes 2.31 Gbits/sec
[ 4] 7.00-8.00 sec 272 MBytes 2.29 Gbits/sec
[ 4] 8.00-9.00 sec 273 MBytes 2.29 Gbits/sec
[ 4] 9.00-10.00 sec 275 MBytes 2.31 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 2.67 GBytes 2.29 Gbits/sec sender
[ 4] 0.00-10.00 sec 2.67 GBytes 2.29 Gbits/sec receiver
1 Like
iperf3 that you run inside the router is single threaded, it can't run in the other cores, that will be always a limitation in the test you are doing.
Enable SW flow offloading and Packet Steering, then reboot the router for Packet Steering to take effect.
Also in your test try, iperf3 -c 192.168.1.1 -R.
The better option is to run iperf outside of the router, so it doesn't interfere with the test. Also looks like you are measuring LAN speed only.
PS: I don't have this router, so I don't know what speed to expect.
Were you able to solve this issue? Tested 8000Mbit/s with stock firmware. 2000Mbit/s direct from router. Plugged into 10G port to a Asus 10G NIC and cannot get full speed. SW Offloading and Packet steering are both on.
Considering there is no offloading you are not gonna get close to stock FW
1 Like