[Alpha] 386.2

[RMerlin]

However, asuswrt is an old kernel to add this feature, so I couldn't find a way other than using skbedit.

If skbedit works, then I'll need to make sure that iproute2 4.3.0 has support for it before I can enable it, or that backporting it won't be too painful. And also that it won't mess up with any of the proprietary kernel modules from BCM or TM.

 

[LimJK]

Yes, please do the Tunnelblick connection, this way we'll know if the iPhone ovpn connect is the only factor. Again thanks for your assist.
Oh btw, is your macbook connected to the home internet or cellular data?

bluepoint,
I have run Tunnelblick for over 1.5 days over combination of Guest Wifi Network, Cellular, Other Wifi Network / Hotspot. No problem on the OpenVPN Server.

 

[bluepoint]

bluepoint,
I have run Tunnelblick for over 1.5 days over combination of Guest Wifi Network, Cellular, Other Wifi Network / Hotspot. No problem on the OpenVPN Server.

Okay, so we have the culprit, iPhone's Openvpn connect app connecting to Openvpn 2.5.0 server. I assume you used the iPhone the same way, cellular, other wifi networks, hotspots and not cellular exclusively correct? Again, thanks.

 

[Frankflash]

Also just to keep everyone's expectations at a reasonable level: this is not compatible with hardware acceleration. So, forget about using Cake on your 500 Mbps connection, your CPU won't be able to keep up.

what about people who have high speed fiber pppoe connections thiers never any thing in this firmware for them its just a firmware for low speed conections like Adsl vdsl and cable this is just a joke

 

[Kingp1n]

what about people who have high speed fiber pppoe connections thiers never any thing in this firmware for them its just a firmware for low speed conections like Adsl vdsl and cable this is just a joke

Where is the joke?

 

[Tekneek]

what about people who have high speed fiber pppoe connections thiers never any thing in this firmware for them its just a firmware for low speed conections like Adsl vdsl and cable this is just a joke

There are limitations to what the hardware can do. That's not a firmware issue.

 

[Treadler]

what about people who have high speed fiber pppoe connections thiers never any thing in this firmware for them its just a firmware for low speed conections like Adsl vdsl and cable this is just a joke

FlexQos. Just sayin’

 

[Jeffrey Young]

what about people who have high speed fiber pppoe connections thiers never any thing in this firmware for them its just a firmware for low speed conections like Adsl vdsl and cable this is just a joke

Place your frustration where it belongs. The issue is hardware related - not firmware.

 

[Frankflash]

Okay, so we have the culprit, iPhone's Openvpn connect app connecting to Openvpn 2.5.0 server. I assume you used the iPhone the same way, cellular, other wifi networks, hotspots and not cellular exclusively correct? Again, thanks.

Place your frustration where it belongs. The issue is hardware related - not firmware.

then the hole router is just a joke then

Place your frustration where it belongs. The issue is hardware related - not firmware.

FlexQos. Just sayin’

you cant use Qos on fiber

 

[Jack Yaz]

I use FlexQos on fibre, works fine.

DFTT

 

[Frankflash]

and a DFTT to you to jack yaz

 

[dave14305]

Click me!

https://www.snbforums.com/members/frankflash.62574/ignore

 

[dave14305]

This should already work (the DSCP netfilter target is already available):

iptables -t mangle -A FORWARD -p tcp --dport 8888 -j DSCP --set-dscp 1

As an example, I just setup an outbound iptables rule for Skype traffic to ensure it lands in the diffserv3 Voice tin. I set those packets as EF (Expedited Forwarding).

iptables -t mangle -A POSTROUTING -o eth0 -p udp -m multiport --dports 3478:3481 -j DSCP --set-dscp-class EF

Obviously this doesn't do anything for any incoming traffic, but there's only so much we can control. If we are already washing inbound DSCP marks with Cake, there's no DSCP/TOS bits to put anything in individual tins, so besteffort seems appropriate for download traffic.

# iptables -t mangle -nvL POSTROUTING
Chain POSTROUTING (policy ACCEPT 21559 packets, 12M bytes)
 pkts bytes target     prot opt in     out     source               destination
  392 83518 DSCP       udp  --  *      eth0    0.0.0.0/0            0.0.0.0/0            multiport dports 3478:3481 DSCP set 0x2e
# tc -s qdisc show dev eth0
qdisc cake 8001: root refcnt 2 bandwidth 24576Kbit diffserv3 triple-isolate nat nowash no-ack-filter split-gso rtt 100.0ms noatm overhead 18 mpu 64
 Sent 64896551 bytes 88458 pkt (dropped 329, overlimits 56934 requeues 0)
 backlog 0b 0p requeues 0
 memory used: 198400b of 4Mb
 capacity estimate: 24576Kbit
 min/max network layer size:           28 /    1500
 min/max overhead-adjusted size:       64 /    1518
 average network hdr offset:           14

                   Bulk  Best Effort        Voice
  thresh       1536Kbit    24576Kbit     6144Kbit
  target         11.8ms        5.0ms        5.0ms
  interval      106.8ms      100.0ms      100.0ms
  pk_delay          0us        8.0ms        3.1ms
  av_delay          0us        929us         97us
  sp_delay          0us          1us          1us
  backlog            0b           0b           0b
  pkts                0        88035          752
  bytes               0     65211420       146513
  way_inds            0          168            0
  way_miss            0         4921           12
  way_cols            0            0            0
  drops               0          329            0
  marks               0            0            0
  ack_drop            0            0            0
  sp_flows            0            1            0
  bk_flows            0            1            0
  un_flows            0            0            0
  max_len             0         1514         1342
  quantum           300          750          300

 

[kernol]

Click me!

https://www.snbforums.com/members/frankflash.62574/ignore

Works a treat - awesome solution {ThumbsUp} .

Strips out all the trolling posts and blanks the trolling replies - restoring the pleasure of browsing these friendly & helpful threads .

 

[RMerlin]

Obviously this doesn't do anything for any incoming traffic, but there's only so much we can control. If we are already washing inbound DSCP marks with Cake, there's no DSCP/TOS bits to put anything in individual tins, so besteffort seems appropriate for download traffic.

I wonder however, is there any point in washing ingress if we only use a single tin? Might save a few precious CPU cycles if we didn't wash ingress traffic.

 

[Wade Coxon]

I wonder however, is there any point in washing ingress if we only use a single tin? Might save a few precious CPU cycles if we didn't wash ingress traffic.

Agreed, no sense in washing when using in conjunction with besteffort.

Note though, that if you do manage to allow for DSCP marking on ingress (as-per prior discussion), we will want to be able to override the besteffort on ingress setting, so we can use diffserv 3 or 4 instead.

Then it can be left to someone else (community effort) to implement a nice script to define the dscp marking rules.

 

[dave14305]

I wonder however, is there any point in washing ingress if we only use a single tin? Might save a few precious CPU cycles if we didn't wash ingress traffic.

There are anecdotes out there that some ISPs put improper DSCP markings on traffic (think Comcast) and that can carry forward to your WiFi if not washed, I believe.

 

[brummygit]

There are anecdotes out there that some ISPs put improper DSCP markings on traffic (think Comcast) and that can carry forward to your WiFi if not washed, I believe.

Would it be better to provide a switch so what may be a minority can enable washing, and allow anyone receiving correctly marked traffic to benefit?

I'm not sure how much of an overhead there would be by running Diffserv in both directions when most (or all) traffic ends up in the Besteffort tin

EDIT: I can also see that there is an argument for providing a set and forget solution, but washing the traffic should (in theory) be one-time decision

 

[Odkrys]

# CONFIG_NET_EMATCH is not set

tc-ematch(8) - Linux manual page (man7.org)
ematch will be useful if someone want to classify packets based on ipset. For example,

MAJOR=$(tc qdisc show dev $DEV | head -1 | awk'{print $3}')
tc filter add dev $DEV parent $MAJOR protocol ip prio 30 basic match 'ipset(gdrive src)' action skbedit priority ${MAJOR}1
tc filter add dev $DEV parent $MAJOR protocol ip prio 30 basic match 'ipset(youtube src)' action skbedit priority ${MAJOR}3

 

[RMerlin]

There are anecdotes out there that some ISPs put improper DSCP markings on traffic (think Comcast) and that can carry forward to your WiFi if not washed, I believe.

If true, that would break things for virtually everyone, not just Cake users.

we will want to be able to override the besteffort on ingress setting, so we can use diffserv 3 or 4 instead.

The way will be by replacing the qos script with your own. I'm not gonna provide 10 different parameters that will confuse everyone. The only setting available on the webui will be the same as for fq_codel: an overhead selector. Everything else will be set to a sensible default.

ematch will be useful if someone want to classify packets based on ipset. For example,
Code:

I couldn't get ematch to work. Wasted a whole evening on it. tc keeps complaining about a syntax problem, even after updating to the latest tc version (5.11.0), and copying all files to /etc/iproute2/ . Same problem with both u32() and cmp() tests that I did.