Optimized build for IPQ40xx devices

As promised and after some testing and tweaking, a new version is available. This version may break your configuration so be careful.

An issue was found:
When performing the update using LuCI and keeping the "Keep Settings" mark, the firmware won't flash. In the sense that the device will reboot and look like it's upgrading while it's not. You can confirm that the firmware was not correctly written to the alternative partition by looking at the "Advanced Reboot" page and observing that the alternative partition does not show the new kernel version installed. Rebooting to the alternative partition will result in a bootloop that will revert to the latest working firmware.

This problem is mitigated by performing an upgrade without keeping your settings from the LuCI webpage. I'm to confirm if the sysupgrade command works, but what is for sure is that flashing and keeping your settings using LuCI does not.


I can confirm that this error happens only when using LuCI.

1 Like

In this "release" (157e17-v0.22), the last set of bugs were fixed. However, LuCI does not perform the upgrade correctly. I've attached a serial console to the device while upgrading from LuCI, but I was not able to find anything relevant in the output. This bug stills unresolved at the moment.

Anyway, this "release" includes the first "release candidate" (that means, this software has just upgraded from beta to "stable") of the Compressed Memory. This includes a new LuCI app, which you can test and provide the feedback in the linked thread.

Also, this version will include NTFS support out of the box and will disable some unused (never requested by users) features, nothing "visible" to the average user of this build (several kernel packages removed, for advanced users).

Some "verbose" output where reduced and some minor fixes where made for the run-once script (bootz) and the early boot script (prebootz). The 30_ubi_attach.sh preinit script is less verbose now (useful when debugging via the serial console).

1 Like

This is a manteinance "release". It's designed to update to the latest snapshot. Download link and information, as always, at the very first post.

In this "release": the Compressed Memory now have a special parameter checking in LuCI.

No further changes were done, only the update to the latest packages from the snapshot.

Hello! After reading a little I bought an ea6350v3 to run your firmware!

I have set it up to connect as a wifi client to relay to ethernet (installed relayd and luci-proto-relay from https://downloads.openwrt.org/releases/19.07.0/packages/arm_cortex-a7_neon-vfpv4/ as they were not available by default).

I had to completely disable odhcpd as the uci settings did not seem to work and clients kept getting wrong IP addresses!

I also installed iperf3 and get about 200 mbps to the router over AC wifi. Is this about right?

I wondered if all of the patches from here have made it into this build yet, and if not, whether they might make some difference?

Thanks @NoTengoBattery for supporting this, it's a really great firmware :slight_smile:

Hi. Normally, disabling odhcpd should do the trick. If you want, you can disable the boot script that runs odhcpd. Just don't disable the DHCP client (which is udhcp or something like that).

Wireless performance, as reported by other users, is near to ideal (the full 700+ Mbps with fast NAT enabled in the firewall), so it's actually unexpected, more known that the device is not natting or shaping the traffic.

The patches you attached are already in the build and I tried to use hardware acceleration, but the crypto module is actually way slower than the software solution (except for 512+ key length and block size, which I've never seen in the wild). So it's disabled by default because if the device is not thrashing the CPU, it's faster. Also, the encryption of the wireless is (normally) done inside the wireless chip, without CPU intervention.

But, you can probably see in the LuCI statistics page if the device is getting overloaded. If that's the case, maybe using the hardware crypto may help.

You can see some raw testing (the only ones made public) here:

Wow these results are indeed much faster than I am seeing. My laptop is AC1200 as well I think, and I am testing very close to the router, so it should not be limiting performance.

I have the latest overclocked firmware installed (2020_01_03_1de8f-v0.30.oc) but did not install any of the packages. Should I have irqbalance or something to improve performance? Is there anything obvious I could have misconfigured? I basically followed the guide here, but there were a couple of places where it is not completely clear.

The device does not seem to be overloaded, and I am not running any additional services besides relayd.

If I can improve performance I'd like to buy another to put elsewhere in my house, as I have a lot of machines without modern wifi cards (or wifi at all) and running cat6 around the house is not something I want to do at present.

Sorry, I am a complete noob with this. I will test again this evening and double check my settings. Thanks for your help.

EDIT: I've just been looking again at my settings, and everything looks OK, but the wireless status page shows that my laptop is only connected at 300mbps (n mode, I guess). It is ac capable (Intel Corporation Wireless 8260) but I can't figure out how to force it to use ac, or if there is a driver problem (running linux on the laptop, for what it's worth).

EDIT2: Cannot for the life of me figure out how to get my laptop to connect faster than 300mbps... so I decided to take a different approach and connected with an ethernet cable to my main wifi router to run iperf3 from my laptop to the ea6350v3:

Connecting to host 192.168.1.2, port 5201
[  4] local 192.168.1.231 port 60278 connected to 192.168.1.2 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  60.6 MBytes   508 Mbits/sec    0    983 KBytes       
[  4]   1.00-2.00   sec  68.1 MBytes   571 Mbits/sec    0    983 KBytes       
[  4]   2.00-3.00   sec  68.5 MBytes   575 Mbits/sec    0    983 KBytes       
[  4]   3.00-4.00   sec  68.9 MBytes   578 Mbits/sec    0    983 KBytes       
[  4]   4.00-5.00   sec  69.0 MBytes   579 Mbits/sec    0    983 KBytes       
[  4]   5.00-6.00   sec  68.4 MBytes   574 Mbits/sec    0    983 KBytes       
[  4]   6.00-7.00   sec  69.0 MBytes   579 Mbits/sec    0    983 KBytes       
[  4]   7.00-8.00   sec  68.3 MBytes   573 Mbits/sec    0    983 KBytes       
[  4]   8.00-9.00   sec  68.5 MBytes   574 Mbits/sec    0    983 KBytes       
[  4]   9.00-10.00  sec  65.2 MBytes   547 Mbits/sec  103    757 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   674 MBytes   566 Mbits/sec  103             sender
[  4]   0.00-10.00  sec   671 MBytes   563 Mbits/sec                  receiver

Oddly, if I go in the other direction (with my laptop running as iperf3 server) I get less than 10mbps. But I can only assume that is not a problem of the ea6350v3 but something elsewhere.

Anyway, a massive improvement so I think I'll be getting a second ea6350v3 for another room! :smiley:

If you are willing to try something, you can rename your wireless to blabla for 2.45 GHz and blabla5 for 5.8 GHz and then manually connect to the later (you can, for example in macOS, select the priority only if the networks are named different).

Another thing worth trying is the calibration board file. In the discussion I liked you in my previous post, we were doing that: testing the calibrations. My image contains a script and all of the needed files to test one by one. There are reports of slightly different hardware and that's why Linksys added a bunch of different calibrations. I don't know how to automatically select them so the script can help you to do it manually.

Also, there is another thing worth trying: using the open source driver and the OEM firmware for the wireless chip instead of the Candela Technology version. I will be uploading the v0.31 soon with 2 versions of the overclocked firmware: one with the Linux drivers and other with the Candela drivers, so you can test deeply and report back for users with similar problems.

Beside from it, I see no other possible reason of what can be failing given that other users don't report the problem. Please let me know any questions or if you are interested in testing the alternatives I've talked about.

Thanks a lot, I appreciate your help. I already have the networks named differently (actually the 2.4GHz is disabled on the ea6350, but on my main router they are differently named as well). My laptop only gets about 200 Mbps to the ea6350 5GHz AP, but when I look on the luci wireless page I can see that it is only connecting at 300 Mbps and using 40 MHz bandwidth. It should support 867 Mbps (which I think would be 80 MHz bandwidth) but I think this is a problem with my laptop configuration, rather than the router. The ea6350 is connected as a client to my main router at 867 Mbps with 80MHz bandwidth, and I am getting almost 600 Mbps across that link as shown in my last post, so everything is mostly working fine except for my laptop configuration. I am happy with 600 Mbps, as my application here is to bridge my main wifi network to a bunch of ethernet devices connected to the ea6350, so my laptop was only being used for testing the link: Normally I disable the AP on the ea6350 completely and only use its wifi as a client to the main router.

However any improvement in performance above that 600 Mbps would also be great, so I will give the calibration files a try and also try the open source driver when you are ready to release it, and will report back my findings here.

It's worth noting that my main router is a closed box (bt business smart hub) so could be causing delays, though it gets good reviews and is rated at 1700 Mbits for the 5 GHz bands, so should be able to keep up.

fwiw, my Dell Win10 laptop has an Intel AC 7260 2x2 802.11ac wifi card. Windows and LuCI reports it connects at 867 Mbps to as low as around 585 Mbps with laptop being only 3m away from the router.

I've used an old snapshot r10269 as well as 19.07.rc1/2, though the hostapd 2.9 bug has since been fixed in 19.07.1 release.
https://www.dropbox.com/sh/ikepkmlqfqi02vw/AACuSniTpvQgFTJQ2w7bn8gCa?dl=0

I use my EA6350v3 as an Access Point. I eventually returned to using Linksys OEM firmware (AP 'bridge' mode), to fix wifi compatibility issues with an old 2.4GHz device, and also with Intel 6300 windows wireless card driver on other laptops I own.

Your issue with Intel 8260 wifi card sounds like another compatibility issue. Are you using Windows?

Bill, what's exactly your compatibility problem? I want to fix it and make it behave like OEM, if I can.

1 Like

I've already updated the download link, so you can perform your tests if you want. The script is straight forward to use. You just run testcalibration in the terminal.

Windows 10 laptop with Intel Centrino 6300 3x3 802.11n wifi card. Wireless link speed report full rate on 2.4 and 5 GHz. eg. 300 Mbps on 5 GHz by Windows and LuCI. But speed tests are capped at 12-15 Mbps with recent builds on both 2.4 and 5 GHz. Intel haven't updated the windows driver since 2015 as the wifi card is discontinued.

The speed issue does not exist when I use very old 19.07 snapshots such as r10269 (circa July 2019). Identifying the commit which causes this issue would be time consuming. I don't have any snapshots between r10323 and 19.07.0-rc1 to help narrow down the search.

I reported the symptoms within this bug report at the time, but it became evident later it was not the same problem as the Hostapd 2.9 regulatory domain bug.
https://bugs.openwrt.org/index.php?do=details&task_id=2679

However, the biggest problem was I then discovered an old 2.4 GHz device, Roberts Stream 83i internet radio (Frontier Silicon), which uses 802.11g was suffering from severe audio buffering. I discovered it could only maintain a 2.4 Mbps downlink speed reported by LuCI even when the radio was only a foot away from the EA6350v3. My laptops and a newer 802.11bgn capable internet radio don't have speed issues on 2.4 GHz. (I haven't tried using a very old 802.11b/g only wifi card in a laptop to see if same issue exists)

This internet radio has no issues connecting to former Home Hub 5A (Qualcomm AR9287 bgn wifi) access point running LEDE or OpenWrt - at 54 Mbps. As I couldn't fix or replace the Roberts radio, I decided to return to Linksys OEM firmware to resolve this compatibility issue.

Off topic but thanks: My laptop is a thinkpad p50 running ubuntu 18.04. It doesn't want to connect to the AP faster than 300 mbps. I can't find any way to try and force it to go faster, but I think it is the laptop that is at fault here.

I also have a roberts radio, a stream 93i, but haven't noticed any issues with it (it supports 5GHz).

I use a BT business smart hub (with native FW) as my main router, so the EA6350v3 is only for bridging the wifi over to ethernet.

@NoTengoBattery Hi!
Sorry if it's not the appropriate thread to ask this question but since you are the one who ported EA6350v3 to openwrt I think you're the best person to ask.

I want to use the Openwrt official 19.07.1 build, not a custom build for easier maintenance.

I have a Linksys EA6350v3, my ISP uses optical fiber adapter that I plug to WAN port of the router. The ISP use VLAN 100 for WAN. Could you please help me to correct /etc/config/network so it works fine using the official build?

(I copied this one from another user with a wrt32x)


config interface 'wan'
	option proto 'dhcp'
	option ifname 'eth1.100'
	option delegate '0'
	option peerdns '0'
	
 config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '0 1 2 3 5t'
	option vid '1'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '4t 6t'
	option vid '100'

Hi.

There is a problem in the VLAN with this device, which I cannot help since I don't have VLAN to test, and by the fact that this build does contains the correct behavior, therefore I cannot directly help with the official build regarding to VLAN.

One thing is for sure: in the official build, VLAN 1 and 2 are reserved by the hardware and there is no way to use them. Your first step is probably moving your VLAN 1 to 3 and 2 to 4.

Hey I used vlan 100 vid 100 and ports 0t 5t and it worked fine, thanks!

@NoTengoBattery Thanks for the custom build with the VLAN patches! Works great.

Has anyone been able to get 6in4 working on this?

I believe the 6in4 package isn't installed, but it requires a kernel module (kmod-sit) which isn't available for this specific build.

That's right, 6in4 is not included. However, I can trivially include it in the next build if you need it.

That would be great.

Otherwise I can always attempt to make a custom build, although I'll have to some reading into building OpenWRT.