Recent content by EnF70

I got close to 1Gb through the router with the CPU maxed out. It is definitively better with just 1 cable between the router and the switch and without LAG. Between the switch and the NAS I get the full 2Gb with at least 2 clients. Sent from my Pixel XL using Tapatalk

Stopped using LAG on the router as I found some performance issues. CPU not fast enough to handle the LAG traffic.

I had LAG (link aggregation) enabled on 2 LAN ports using the bonding driver but I stopped using it. Apart from issues with QoS there are also LAN traffic performance issues associated so it's not worth it. Back to the normal setup now, thanks for your script, playing with it at the moment.

Is there a specific mark to exclude some traffic from QoS? Having issues with LAG traffic on the LAN being restricted by QoS.

Traffic classification seems to be working fine in 384.6 (LAG traffic included) but same issues with QoS as above.

Just wanted to say thanks for the info provided and that I am using LAG / LACP for some time now. One thing to mention is that I had to disable QOS on the router to make it work properly. For some reason the LAG traffic is classified as Internet traffic (it also shows in the "Traffic Analyzer"...

Decided to do a Factory reset as those two processes were still using a lot of CPU even after a couple of reboots. So the issue might not be related to a power cut or to the order in which the modem and router rebooted.

I got this a couple of times already, with older versions and with 380.68.2. After a power cut the router reboots faster than the Virgin Media modem (bridge) and it gets into this state. CPU is 100% on both cores and the router overheats, I think after some time nothing works, a reboot of the...

Update: Just discovered that a MacBook Pro (Retina, 15-inch, Late 2013) using 802.11 ac is also affected on the 5GHz WiFi. Very similar to the Nexus 6P, ping and low-latency video streaming issues. Another MacBook Pro (Retina, 15-inch, Early 2013) which only supports 802.11 a/b/g/n is not...

Yes, that one. But I have two rules, one for each OpenVPN instance (tun21 and tun22). I use one OpenVPN instance for UDP and one for TCP (for networks that don't allow UDP).

I use my original rules (the ones included in Alpha3) but the one mentioned above works just as well. I still believe it's sufficient to mark individual packets in the PREROUTING chain to work-around the CTF issue rather than do it per connection and involve the connection tracking mechanism...

I know, I see the rules in iptables - thanks for adding them :) I'm flushing the chains before testing different rules and I tested Alpha3 with no rules at all. That's why I said that there are still issues with CTF enabled if we don't mark packets.

Nice work, thanks for sharing :)

I am on Alpha3 and I think there are still issues with CTF enabled if we don't mark packets. Can you post again the latest rule, I want to make sure I get the correct one. (I can still see a connmark in the latest one) EDIT: I think I know which one you are referring to now: iptables -t mangle...

Now I understand why it works with "--or-mark 0". It doesn't matter what value we mark the packets with. It seems there is a difference between unmarked and marked packets. I thought a default mark of 0 (zero) is present on all packets but it seems that's not the case. I changed my rule to use...