Did you manage to get it working? Tried with a fresh snapshot install but there are no active redirects on the luci page but the system log says that it's creating the rules, not sure why is not working
No, I switched back to firewall3 (not using snapshots, but building my own versions). Maybe the developer doesn't believe there is a problem, because it works for him, you can follow this conversation: https://github.com/openwrt/packages/pull/17094 with Daniel and others saying (like us) that rules don't have effect but Stijn saying it works for him...
So far the problem hasn't come back since flashing a new firmware yesterday. But that's not proof the issue doesn't exist any more, just that it hasn't occurred.
Highly recommend that you stay on fw4 and work with people in the forums to identify and fix bugs therein. Start a new thread under this section with your details.
Upgraded to the latest git revision yesterday, but I'm seeing pretty bad performance. I see a lot of latency and reliably get packet loss. I'm getting 100ms+ ping on 1.1.1.1, whereas usually I get sub 10ms. Curiously the packet loss happens mostly early in communicating over wan. Say, I'm pinging 1.1.1.1, then almost every time the second icmp echo request gets lost, then after that 3 and further usually do arrive (all with bad latency as stated previously). I see no latency or packet loss issues on lan
Try opkg update ; opkg install mtr' followed by
mtr -ezbw -c 100 1.1.1.1and post the result here, that way you can see what happens along the full path. Also try
mtr -ezbw -c 100 8.8.8.8` to see whether Google is also affected (if your router is the cause all paths should show the problem).
It seems - very unfortunate timing - that my ISP is currently having some issues. Apparently they've changed the channel bonding frequencies for my cable modem, and I'm getting interference from 4G radiation now. For now I'm assuming openwrt is blameless, will get back to you all on this in a few days
The issue is gone now, so it must not have been openwrt-related. Very recent version now running perfectly it seems
errors in I/o on this device
kernel log shows
blk_update_request: I/O error, dev mtdblock2, sector 256 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
buffer_io_error: 33922 callbacks suppressed
[99782.929686] Buffer I/O error on dev mtdblock2, logical block 32, async page read
Rebooting, and the issue goes away, so far it's happening every 3 to 5 days. Any suggestions. I'm running SNAPSHOT r18780-73fd9f79ce as the version when it happened most recently.
This error can show when trying to access areas in the flash with broken OOB/ECC data.
Are there any problems apart from the message showing in the log?
Because the error message you are quoting here indicates that something is reading the unused area of the factory
partition -- maybe you were trying to download factory
partition using LuCI backup feature?
Router had been up for about 24 hours, no activity going on by me, this device is configured as a dumb ap with ethernert backhaul to the other rt3200. Oy services running on it are DAWN.
hosts three networks, a local 2.4g backup incase of issues with the other router, and 2.4/5 11ax that is common with the other device.
At the time of problem oy traffic was sky Q via ethernet, and a few iot switches on 2.4,
All other stations were kicked by DAWN to the main box which is normal.
As nothing should be reading anything from flash once the boot has completed and all interfaces are up, I suspect that DAWN (which I haver never used/touched) may be the cause for this read of the bad area of on mtd2
. @PolynomialDivision does DAWN access mtd or block devices directly at runtime?
I'm asking because I'm using RT3200 in exactly this configuration -- just using usteer
instead of DAWN
-- and never saw this error (unless I try to read those dead areas of /dev/mtd2
or /dev/mtdblock2
)
Interesting that you are trying usteer, I also tried that, but say devices remaining stuck on 2.4 and not moving to 5. Can you share your usteer config as I could not get it to work, whereas Dawn is working very well, if very chatty in the logs out of the box.
I've a running config, consist of 3 rt3200 as a 801.11s mesh network. I use 5G 80Mhz, to build the mesh-wifi, both 2,4G and 5G as clients access network run stable, with a throughput not amazingly high, but acceptable. My first goal is stability.
Here's an iperf3-run (3 Mesh AP and my 802.11ac intel based laptop)
Running the iperf3 on the devices themselves will not give you realistic throughput figures but something much lower, as the CPU is then busy running iperf3...
I had the same problem (some devices remaining on 2.4GHz and never roaming into 5 GHz), I've solved it by enabling
option assoc_steering 1
in /etc/config/usteer
. Apart from that I left the defaults unchanged, just set the backhaul interface and SSID to be used.
thats correct, the throughput from devices (laptop at 5G wifi to NAS at 1Gig LAN ) is about 250 Mbit though, not impressive, but acceptable in my opinion
No, as far as I know. Why should DAWN access mtd blocks directly?
hello I have a vdsl2 line and my colleague has a 1 gigabit optical fiber we have both activated irq balance and packet steering, our main goal is video games, he tells me that he really has better sensations without irq balance and packet steering, we both use qosify do you think it works on the router or not? thanks in advance