DCSP marking

[Deleted member 89527]

Can't get any of this stuff working on my router. Am I expected to have to reboot in between each change? That's the only thing I haven't tried. Every packet that supposed to be getting marked is coming through as "tos 0x0" which is just = CS0 in DSCP as far as I can see.

dnsmasq-conf.add

ipset=/ttvnw.net/justin.tv/vidstream # Twitch

ipset create vidstream hash:ip

iptables -t mangle -A PREROUTING -m set --match-set vidstream src -j DSCP --set-dscp-class AF41

 

[dave14305]

What interface are you running tcpdump on to determine the DSCP?

 

[Deleted member 89527]

What interface are you running tcpdump on to determine the DSCP?

br0 because that's what I have Cake set on. nowash set of course ...

I can't get them tagged on the windows side either because it's impossible to use their very limited regex to catch domains. I'd have to enter every address or IP manually it seems.

EDIT: not even the Regex examples on the Microsoft article is accepted LOL https://learn.microsoft.com/en-us/p...ows-server-2012-R2-and-2012/jj159288(v=ws.11)

 

[Deleted member 89527]

None of these guides working either ffs ...

Applying IPSet in Lede

I have been having trouble setting ipset based on host address. Here are the steps I followed with little success recently: 1. Apply list of host to /etc/dnsmasq.conf like this ipset=/somehost.com/

stackoverflow.com

ipset-dns - A lightweight DNS forwarder that adds resolved IPs to a given netfilter ipset.

git.zx2c4.com

 

[dave14305]

Are there IPs listed in the ipset after you test? And do the packet counters increase on the iptables rule?

 

[Deleted member 89527]

Are there IPs listed in the ipset after you test? And do the packet counters increase on the iptables rule?

No it doesn't seem to be hitting the ipset rules.

 

[dave14305]

If the ipset has no IPs listed, then it suggests that the test client is not using the router for its DNS lookups, which is required for the ipset to properly populate. Do you use DNS Director to force the clients to use the router?

 

[Deleted member 89527]

If the ipset has no IPs listed, then it suggests that the test client is not using the router for its DNS lookups, which is required for the ipset to properly populate. Do you use DNS Director to force the clients to use the router?

Probably an AdguardHome issue then. I can force lookup these particular IPs so they populate the ipset at least?

 

[dave14305]

Probably an AdguardHome issue then. I can force lookup these particular IPs so they populate the ipset at least?

Yes, if Adguard Home receives the client queries first, you could set the upstream server for those specific domains to be the router’s loopback IP 127.0.0.1 (and whatever port you have dnsmasq listening).

 

[Deleted member 89527]

Solved: force nslookups with 127.0.0.1:553 appended.

This sucks for automatic detection though ... there's no other way but to get rid of AdGuard Home in between?

 

[dave14305]

Solved: force nslookups with 127.0.0.1:553 appended.

This sucks for automatic detection though ... there's no other way but to get rid of AdGuard Home in between?

It does appear that AGH supports their own implementation of ipsets, so you can probably do all this in AGH instead. Check their Wiki.

Configuration

Network-wide ads & trackers blocking DNS server. Contribute to AdguardTeam/AdGuardHome development by creating an account on GitHub.

github.com

 

[Deleted member 89527]

Oh, Adguard has support for this. Doh.

 

[Deleted member 89527]

Instead of opening a new thread ...

Shouldn't these marks be added in the OUTPUT part of the chain or does it not matter? And if I only see the packet marked with my ToS in one direction does that matter too? Surely that means somewhere along the way it got dropped? If I sent ToS 0xa0 and get 0x0 back does that mean QoS has been ignored? @dave14305

 

[dave14305]

Shouldn't these marks be added in the OUTPUT part of the chain or does it not matter?

It would be useful to see your existing setup:

tc qdisc
iptables-save -c -t mangle

Usually you would put marking rules in POSTROUTING so you can be sure of the egress interface (where CAKE or any other qdisc will be configured). POSTROUTING will see both forwarded traffic and traffic originating from the router (OUTPUT).

But it sounds like you have a non-standard setup using br0 probably due to your VPN setup.

 

[Deleted member 89527]

It would be useful to see your existing setup:

tc qdisc
iptables-save -c -t mangle

Usually you would put marking rules in POSTROUTING so you can be sure of the egress interface (where CAKE or any other qdisc will be configured). POSTROUTING will see both forwarded traffic and traffic originating from the router (OUTPUT).

But it sounds like you have a non-standard setup using br0 probably due to your VPN setup.

Non standard setup using br0 yeah, as instructed by Lynx. Does that make it impossible to preserve markings in both directions?

tc qdisc
qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth1 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth2 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth3 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth4 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth5 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth6 root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc cake 8052: dev br0 root refcnt 2 bandwidth 115200Kbit diffserv4 dual-dsthost nat nowash ingress no-ack-filter split-gso rtt 30ms noatm overhead 102 mpu 64
qdisc cake 8051: dev wgc1 root refcnt 2 bandwidth 18432Kbit diffserv4 dual-srchost nat nowash ack-filter split-gso rtt 30ms noatm overhead 102 mpu 64

Chain PREROUTING (policy ACCEPT)
target prot opt source destination
MARK all -- anywhere anywhere MARK or 0x1
MARK all -- anywhere anywhere MARK or 0x1
DSCP icmp -- anywhere anywhere DSCP set 0x28
DSCP tcp -- anywhere anywhere multiport ports domain,553 DSCP set 0x28
DSCP udp -- anywhere anywhere multiport ports domain,553 DSCP set 0x28
DSCP all -- anywhere anywhere match-set twitch src DSCP set 0x22
TTL all -- anywhere anywhere TTL match TTL == 1 TTL set to 64
MARK all -- anywhere anywhere match-set DomainVPNRouting-1-ipv4 dst MARK xset 0x8000/0xf000
MARK all -- anywhere anywhere match-set ctrader dst MARK xset 0x8000/0xf000
DSCP all -- anywhere anywhere match-set ctrader src DSCP set 0x28
DSCP all -- anywhere anywhere match-set tidal src DSCP set 0x28

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
MARK all -- anywhere anywhere match-set DomainVPNRouting-1-ipv4 dst MARK xset 0x8000/0xf000
MARK all -- anywhere anywhere match-set ctrader dst MARK xset 0x8000/0xf000

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MARK all -- anywhere anywhere MARK or 0x1
MARK all -- anywhere anywhere MARK or 0x1
MARK all -- anywhere anywhere match-set DomainVPNRouting-1-ipv4 dst MARK xset 0x8000/0xf000
MARK all -- anywhere anywhere match-set ctrader dst MARK xset 0x8000/0xf000

To be honest I'm just copying stuff I see on Google on other forums and they have it in PREROUTING ... but sitting back for a moment and thinking about it doesn't make too much sense. The ones I see happening in one direction are set within Windows 10 ... is this just a limitation of Windows perhaps? cTrader is sent as tos 0x28 and replies with 0x0 for some reason ... wash is off. Maybe WireGuard just washes it anyway?

 

[Deleted member 89527]

Some more Googling shows people adding to PRE and POST ... I guess that couldn't hurt?

 

[dave14305]

I’d like to see the iptables rules in a more readable format. Either iptables -t mangle -S or iptables-save -c -t mangle

You have to keep track of which direction you’re expecting your rules to work in when matching src or dst against the ipset. Writing separate rules for br0 (download where remote IPs are src) and wgc1 (upload where remote IPs are dst) would be helpful. Stick with POSTROUTING only for now.

You’ll only see the expected DSCPs if you tcpdump on the correct interface. Using br0, you should only expect to see valid DSCPs for download traffic (the router has already marked them), but not upload (unless the client sets their own DSCP). To check upload, I suppose you can setup tcpdump on wgc1 and see the proper upload DSCP values. Never used such a setup before, but it should be workable.

 

[Deleted member 89527]

I’d like to see the iptables rules in a more readable format. Either iptables -t mangle -S or iptables-save -c -t mangle

You have to keep track of which direction you’re expecting your rules to work in when matching src or dst against the ipset. Writing separate rules for br0 (download where remote IPs are src) and wgc1 (upload where remote IPs are dst) would be helpful. Stick with POSTROUTING only for now.

You’ll only see the expected DSCPs if you tcpdump on the correct interface. Using br0, you should only expect to see valid DSCPs for download traffic (the router has already marked them), but not upload (unless the client sets their own DSCP). To check upload, I suppose you can setup tcpdump on wgc1 and see the proper upload DSCP values. Never used such a setup before, but it should be workable.

iptables -t mangle -S
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A PREROUTING -p icmp -j DSCP --set-dscp 0x28
-A PREROUTING -p tcp -m multiport --ports 53,553 -j DSCP --set-dscp 0x28
-A PREROUTING -p udp -m multiport --ports 53,553 -j DSCP --set-dscp 0x28
-A PREROUTING -m set --match-set twitch src -j DSCP --set-dscp 0x22
-A PREROUTING -m set --match-set ctrader src -j DSCP --set-dscp 0x28
-A PREROUTING -m set --match-set tidal src -j DSCP --set-dscp 0x28
-A PREROUTING -m set --match-set DomainVPNRouting-1-ipv4 dst -j MARK --set-xmark 0x8000/0xf000
-A OUTPUT -m set --match-set DomainVPNRouting-1-ipv4 dst -j MARK --set-xmark 0x8000/0xf000
-A POSTROUTING -p icmp -j DSCP --set-dscp 0x28
-A POSTROUTING -p tcp -m multiport --ports 53,553 -j DSCP --set-dscp 0x28
-A POSTROUTING -p udp -m multiport --ports 53,553 -j DSCP --set-dscp 0x28
-A POSTROUTING -m set --match-set twitch src -j DSCP --set-dscp 0x22
-A POSTROUTING -m set --match-set ctrader src -j DSCP --set-dscp 0x28
-A POSTROUTING -m set --match-set tidal src -j DSCP --set-dscp 0x28
-A POSTROUTING -o eth4 -m set --match-set DomainVPNRouting-1-ipv4 dst -j MARK --set-xmark 0x8000/0xf000

Removing PREROUTING now.

 

[Deleted member 89527]

Again instead of opening more threads...

Bufferbloat test results are perfect after running a program called TCP Optimizer - it's obviously changing a setting that, over time, is getting reverted back to something less optimal. How would I go about diagnosing this?

Right after applying "recommended" TCP Optimizer settings (https://www.speedguide.net/downloads.php) https://www.waveform.com/tools/bufferbloat?test-id=b637b014-aa9a-4356-9e73-9818c455bbbf

This eventually drifts to 10 even 20ms over time after absolutely nothing (that I am aware or in control of) has changed in the testing environment. Kinda driving me to hairloss at this point ...

 

[Coldblackice]

Bufferbloat test results are perfect after running a program called TCP Optimizer - it's obviously changing a setting that, over time, is getting reverted back to something less optimal. How would I go about diagnosing this?

Note what TCP Optimizer needs to keep changing by getting a baseline File->Backup/Export Current-settings. When it reverts to drifting again, grab another snapshot and diff-compare the two, seeing what's changed and needs re-setting.

Or in the GUI, switch back and forth between "Current" and "Optimal" to see what's differing.