SQM QoS option in Luci refer of speed download (ingress) and upload (egress) is reverse..., at least that would be the result of my tests.
If have link e.g. 50Mbps download and 10Mbps upload that in "ingress" to 10 write and in "egress" to 50 write.
My speed is 320 when I set download to 50, it is still about 320.
share output of tc -s qdisc
Tested 3.0.1 on MR9000, looks that it's working as a charm. Thanks!
ENG. And upload speed if type e.g. "5Mbps" to download? In option "Download" type speed of upload, and option "Upload" type speed of download. SQM work (for me mainly as a bandwidth limitation for WLAN), but effectiveness is hard to say on link of LTE.
PL. A jeżeli wpiszesz prędkość wysyłania np. "5Mb" w pole dotyczące pobierania? W opcji „Download” wpisz prędkość pobierania, a w opcji „Upload” wpisz prędkość pobierania. SQM działa (u mnie głównie jako ograniczenie przepustowości dla WLAN), ale trudno stwierdzić skuteczność na łączu LTE.
Version 3.0.1 on EA6350 works very good, but I need of packet usb-modesitch in standard, and... slightly better bandwidth in a noisy 2.4GHz environment (required for range and devices) (joke of course, is fine).
Calibration on 'AU/2G/Y9803_wifi0 for 2.4GHz' is best for me (but it could be better in situation if the neighbor turn on the wifi video of cam a few hundred meters away and drowns out most of the channels).
I did get the sudden crash/reboot twice in a row, each after about 24 hours of uptime (though daily use patterns rather than uptime may be the culprit: I was doing the same things on the network at the same time each time), So I set /proc/sys/kernel/panic_on_oops to 0. The next evening at pretty much the same time it oopsed and did not reboot.
Symptom is that it was mostly dead; unresponsive to pings on the wired network, wireless SSIDs gone, LED dark, but because it didn't reboot the switch continued to operate smoothly as configured, VLANs and all.
With it unresponsive on the network I was unable to connect to it to obtain the pstore files or do anything else; had to power-cycle. After the power cycle there is nothing in /rom/bootfs or /sys/fs/pstore. I am now running a screen session on a wired machine ssh'd into it, we'll see if that remains available if/when it happens again. But given that it wasn't pingable, I'm not hopeful.
ea6350v3 running v3.0.1 r16325-88151b8303, installed from factory image.
Differences from default:
- several VLANs on switch
- wpad-basic-wolfssl replaced with wpad-wolfssl (for 802.11r fast roaming support)
- dnsmasq, unbound, odhcpd, firewall, adblock all disabled and not running (using as a dumb AP + managed switch)
- 1 5GHz channel active on an 80MHz DFS/radar detect frequency
- 3 2.4GHz channels active on a 20MHz frequency
I've set panic_on_oops to 0 again and I'm just letting it run with all wifi channels disabled, to see if that makes a difference. If I get the same problem I'm going try the same use case while booted from the alternate partition, which still has NoTengoBattery v3.0.0-rc4 installed; I had good experience with that for a while last year, though not with this use case.
Is there any information about hardware NAT support in OpenWrt for IPQ40xx devices?
There is no "hardware NAT" on ipq40xx.
Network Subsystem Hardware NAT engine
1 Like
6in4 is working on 3.0.1
there is some css bug in the interface but I assume that is an upstream bug and nothing to do with upgrading or your build.
Has anyone confirmed this works with the TEW-829DRU ? Do the LED / Wifi / Failover work?
I would rather put OpenWRT on this device, the vendor's firmware is buggy and the main menu keeps having half the items disappear, mainly the multiwan / wan pages. It's becoming a nuisance!
Don't you think someone would have to develop the TE-829DRU device support first?
--
At this point, this certain someone would have to be you, there's no way around hands-on development with the particular device on the desk.
Unfortunately my ea6350v3 continued to crash/reboot like clockwork as described here.
After installing the corresponding mainline OpenWRT 21.02.1 r16325-88151b8303, all other things being the same, the problem goes away; it's been up for three days and used as my primary access point and a managed switch without a problem.
Unfortunately, by giving up the NoTengoBattery build I lose more than 100mbps of wireless speed on the 5GHz band; again, all other things configured the same. Edit: correction, NOT the same. Installing irqbalance closes the gap. Reducing cpufreq up_threshold from 95 to 65 to compensate for the reduced sirq thanks to balancing the interrupt affinities gets it much closer to your build's performance. It also means I can't use luci to manage the switch, but that's less of a problem; the config switch_* settings in /etc/config/network get the job done.
One interesting issue (which I don't think is a problem on the NoTengoBattery build, but I'm not sure, I'd have to boot back into it and double-check):
While I can get the "WAN" interface ("port 5") to act as part of the main switch easily enough, and it works in VLAN groups with the other four ports for most ordinary TCP/IP purposes, it doesn't seem to work with Chromecast, which relies on mDNS. On other words, with this setup
VLAN 1: 0t 1 2 3 4
VLAN 20: 0t 1t 5
A chromecast device attached to port 5 cannot be found on VLAN 20 (port 1 is the trunk port in this case). It otherwise has functional access to the network and can be pinged from other devices; it's just not visible to those devices as a chromecast target.
If I move one of the "LAN" ports into VLAN 20, e.g. port 4:
VLAN 1: 0t 1 2 3
VLAN 20: 0t 1t 4 5
And move the Chromecast device to port 4, the device immediately becomes visible as a cast target to everyone on VLAN 20. I can only speculate as to why this is, I suspect it's an L2/L3 issue.
That is what this thread is about... In fact that is what I am asking about. Read the thread, read my reply.
This thread is about IPQ40xx devices , of which the TEW-829DRU is one, and has been part of this thread's conversation.
I simply asked if it is tested and working. Don't be an asshat. Also probably a good idea not to post a reply unless you actually have a reply (with useful information or a question) instead of making snarky responses to people asking simple questions. This thread is already 3 years long.
You don't tell this person "well someone would have to code it first" so why you would me I don't know. You seem to be all over this thread, and the only person you get snarky with is me when I simply ask if a device is working yet.
You guys are right, after more reading and using it I get it. On the file server I saw Mikrotik and got excited. I'm a mikrotik guy, and now realize openWRT is the project you are working on and both devices us the same Qualcomm processor.
I calibrated board file new data 'boardData_1_0_IPQ4019_DK06_2G.bin' and... is better of 'AU/2G/Y9803_wifi0 for 2.4GHz'- is highest stable range (to 10-20% better) and speed internet LTE of wireless 2.4GHz is stable 10-15Mbps in two floor house (unstable 2-15Mbps earlier; on Ethernet LTE internet is 40-45Mbps).
In link are more board file 'boardData_1_0_IPQ4019_DK08_wifi0_2G.bin' and 'boardData_1_0_IPQ4019_FPGA_2G_5G.bin'. Interested me 2.4GHz wireless, but are also files to 5GHz wireless.
Were these files ever considered or tested on EA6350v3?
Seems like their is a way to use HNAT called fastpath or sfe. Is it possible to be used in this firmware?
For example: https://github.com/quarkysg/openwrt/commit/9ba313d46f6e06b712ef67b1300fe8b61c958b61 and https://github.com/gwlim/openwrt-sfe-flowoffload-ath79 and https://github.com/MeIsReallyBa/Openwrt-sfe-flowoffload-linux-5.4
Did you succeed with the nbg6617? I just got two units and would like to try out @NoTengoBattery 's build but it seems there is no nbg6617 build yet
I was low on time and I got enough devices so I put this aside. I'll reach out to him now