Menu
What's new
By:
Filters Better Search

Search results

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

  1. C

    [Release 384/NG] Asuswrt-Merlin 384.5 is now available

    RT-AC88U switched from 384.4beta1 to 384.5 today. For those messing with VLANs: BEWARE of the RoboSwitch configuration! The "CPU" port went from 8 (380.x), to 7 (384.4beta1), back to 8 (384.5). @skeal: about you TQoS<->VPN issue (as the developer of the TQoS patch): I don't see how to fix that...
  2. C

    (RT-AC88U) Traditional QoS fully fixed (I believe)

    @cdufour can you give me your Github info so I can give you proper author credits on the commit? Thanks. PR sent: https://github.com/RMerl/asuswrt-merlin.ng/pull/123 Thanks
  3. C

    (RT-AC88U) Traditional QoS fully fixed (I believe)

    Attached the qos.c patch file corresponding to the changes proposed in comment #19. I managed to build AsusWRT (NG) from the latest GutHub pull and verified it passes compilation: Problem now: I dare not test further and risk bricking my (in use) AC88U. PS: Has anyone ever tried running...
  4. C

    (RT-AC88U) Traditional QoS fully fixed (I believe)

    Hurrah. Everything Traditional QoS now works: upload (WAN egress), download (WAN ingress) and transferred limits (I believe). ingress qdisc is NOT used, given it can not make use of (CONN)MARKs. Instead, a standard (egress) qdisc on br0 does the job. Below the files that ought to be created by...
  5. C

    (RT-AC88U) Traditional QoS fully fixed (I believe)

    qos.c is riddled with #ifdef CONFIG_BCMWL5; would those intersect with routers that do have the ifb interfaces ? Or is there another #ifdef I can use ?
  6. C

    (RT-AC88U) Traditional QoS fully fixed (I believe)

    I'm concentrating here on Traditional QoS (TQ). But the underlying mechanisms - tc and iptables - are the same. As far as I understood, download shaping does work when using Adaptive QoS (AQ). From what I've stumbled on here and there, it seems that AQ uses tc rules on the br0 bridge; TQ...
  7. C

    (RT-AC88U) Traditional QoS fully fixed (I believe)

    Traditional QoS implements ingress qdisc filtering using firewall marks - set in the QOSO chain - like for the standard egress qdiscs. BUT, when being processed in the ingress qdisc, a packet has NOT YET gone through netfilter (iptables) processing and thus lacks the necessary (CONN)MARKs...
  8. C

    (RT-AC88U) Traditional QoS fully fixed (I believe)

    GOOD NEWS: WORKS! While downloading, and (WAN ingress) traffic does indeed appear on the ifb0 interface! AND, a very crude shaper built on top of it DOES work: Downloads now peak at 4096kit! This opens up great new horizons for ingress shaping! EDITED: I expected upload (LAN ingress)...
  9. C

    (RT-AC88U) Traditional QoS fully fixed (I believe)

    Just for the sake of clarity, I paste below the original Traditional QoS configuration as performed by AsusWRT magic (but reflecting part of my personal rules). /tmp/qos: /tmp/mangle_rules: I'm working on the qos.c source code that generates those two files.
  10. C

    (RT-AC88U) Traditional QoS fully fixed (I believe)

    Agree. After further thinking, I came to see (and edited my original post) that ingress shaping isn't much different from what our ISP does to have the bandwidth match what we pay for. So it can not be that bad. Agree the Upload/Download terms may be misleading. Yes, with one clarification...
  11. C

    (RT-AC88U) Traditional QoS fully fixed (I believe)

    Just a note on ingress filtering: Linux/TC support for ingress infiltering is quite originally sparse. But it'd be worth looking into the RT-AC88U's ifb0/ifb1 interfaces (unused as far as I can tell, at least by Traditional QoS): tc filter add dev eth0 parent ffff: protocol ip u32 match ...
  12. C

    (RT-AC88U) Traditional QoS fully fixed (I believe)

    Had a look at router/rc/qos.c: the erroneous qdisc filter is fixable but tricky: in order to stay safe, one ought to filter specifically for the LAN VLAN ID; is ID=1 to be considered the "hard-coded" ID for the LAN or should this be extracted from NVRAM ? the "erroneous" CONNMARK mask is...
  13. C

    (RT-AC88U) Traditional QoS fully fixed (I believe)

    Looking at the Broadcom Roboswitch setup: admin@rt-ac88u:/tmp/home/root# robocfg show VLANs: BCM5301x enabled mac_check mac_hash 1: vlan1: 0 1 2 3 5 7t 2: vlan2: 4 7 Might explain the strange eth0/vlan1 setup: unless I'm utterly wrong, the "CPU" port number 7 is the one referred to as...
  14. C

    (RT-AC88U) Traditional QoS fully fixed (I believe)

    EDITED: applies to 384.4.beta1 Looking closely at the output of the various tc -s ... commands when downloading/uploading files, I have discovered that the ingress (ffff:) qdisc on the eth0 interface behaves very strangely: downloaded/ingress traffic DOES appear on the ingress (ffff:) qdisc...
  15. C

    [Beta 384/NG] Asuswrt-merlin 384.4 Beta is now available

    Updated my AC88U today (from 380.69.2): Hard reset before upgrading (red button) Upgrade Hard reset after upgrading (red button) The routeur has been working flawlessly (except for bugs that have been here for ages; see below). Note however that my use case covers only the WiFi and IP stuff...
  16. C

    BUG: Port "Forwarding" does not work when NAT is disabled

    Of course. First thing I did ;-) Ooh my!... Now I understand why we'd rather avoid modifying the source code. That would need a heavy re-factoring :-( As far as I can tell, based on the commit history, it seems Asus itself doesn't see "non-NAT" mode as a real-life scenario :-) I'll try to...
  17. C

    BUG: Port "Forwarding" does not work when NAT is disabled

    Just wanted to contribute to the improvement of this wonderful firmware ;-) If one can point me where in the source code the GUI/nvram configuration is "converted" to actual iptables commands, I might actually contribute the patch itself. By the way, I just verified in AsusWRT-RMerlin - with...
  18. C

    BUG: Port "Forwarding" does not work when NAT is disabled

    PS: Actually port forwarding - allowing LAN resources to be accessible from the WAN - is more about "Chain FORWARD ... ACCEPT" than "Chain PREROUTING ... DNAT". DNAT is required for port forwarding to work when the network topology mandates NAT. But if the network topology does not mandate NAT...
  19. C

    BUG: Port "Forwarding" does not work when NAT is disabled

    https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Security_Guide/s1-firewall-ipt-fwd.html "If you have a default policy of DROP in your FORWARD chain, you must append a rule to allow forwarding of incoming HTTP requests so that destination NAT routing can be possible"
  20. C

    BUG: Port "Forwarding" does not work when NAT is disabled

    PS: unless there is some other firewall configuration page that I missed in the UI when NAT is disabled
Top