Mangle Prerouting Chain

[orinocopaul]

Greetings,
Trying to target the above packages in order to increase the TTL value.

I have tried nft ... fw4 mangle_forward and mangle_prerouting rules. No results. The rules are loaded into the nft chain (I can see that with nft list ruleset). Am I missing some nft-related OpenWRT packages? I recently updated to 23.05.2.

PS. I am basically trying to use a Chromecast device across multiple subnets.

[thpryrchn]

@orinocopaul

Chromecast device across multiple subnets

This has been asked a few times... I did find a nifty guide to help you do it!

https://blog.christophersmart.com/2020/03/30/resolving-mdns-across-vlans-with-avahi-on-openwrt/

[orinocopaul]

Hi Chris,

Great stuff! I used your guide for setting up avahi, firewall etc. All of that works.

My problem is that Google Chrome browser is sending packages with a TTL of 1. I imagine this makes it hard for the avahi repeater to pick it up and send it to the other subnet. To fix that I used something like:

nft add rule inet fw4 mangle_prerouting iifname {"br-lan.1", "br-lan.2"} ip daddr 224.0.0.251 ip ttl set 37

This rule translates to something like this:

chain mangle_prerouting {
                type filter hook prerouting priority mangle; policy accept;
                iifname "br-lan.1" ip daddr 224.0.0.251 ip ttl set 37
                iifname "br-lan.2" ip daddr 224.0.0.251 ip ttl set 37
}

It's not working.

[orinocopaul]

tcpdump provides the following:

Just wondering how I could target these specific packets and increase the TTL value. The nft mangle_prerouting rule that I am curremtly using (see previous post) is not really working. Am I missing some nft-related OpenWRT packages? I recently updated to 23.05.2.

[efahl]

There are a couple things you can add to your nft rule to help debug. The easiest is just to add a counter, which will give you a hint as to whether the rule is firing or not. Listing the chain then shows how many packets/bytes it has actually processed:

$ nft add rule inet fw4 mangle_prerouting iifname {"br-lan.1", "br-lan.2"} ip daddr 224.0.0.251 counter ip ttl set 37

$ nft list chain inet fw4 mangle_prerouting
table inet fw4 {
        chain mangle_prerouting {
                type filter hook prerouting priority mangle; policy accept;
                iifname { "br-lan.1", "br-lan.2" } ip daddr 224.0.0.251 counter packets 0 bytes 0 ip ttl set 37
        }
}

Likewise, the log statement can add some more output:

nft add rule ...  ip ttl set 37    log flags all

and then logread shows them something like this, you can see the TTL= value near the middle of the line.

Fri Mar  1 08:51:51 2024 kern.warn kernel: [261220.223513] IN=eth0 OUT= MACSRC=99:99:cb:23:99:2c MACDST=99:15:99:01:a9:23 MACPROTO=0800 SRC=10.1.1.186 DST=224.0.0.251 LEN=40 TOS=0x00 PREC=0x00 TTL=37 ID=65036 DF PROTO=TCP SPT=52121 DPT=22 SEQ=3694627119 ACK=1066242162 WINDOW=8209 RES=0x00 ACK URGP=0

You could add one of these log commands in a later chain, maybe mangle_output or somewhere, to see what's actually being sent...

EDIT: See "LOG STATEMENT" section, here:
https://www.netfilter.org/projects/nftables/manpage.html

[orinocopaul]

Great tips! Used both counter and logread to determine quickly that the ttl-value is not the issue.

I now think the problem is avahi-daemon-related.The reflector is not completely reliable. It takes two or sometimes even ten unsuccessful searches for the Chromecast device to become available inside Chrome.

For every four packets sent by the Chromecast device, avahi is reflecting only two packets. How can I increase the realiability of the avahi-daemon service? Should I install some additional OpenWrt packages?

[orinocopaul]

Solved!

Add cache-entries-max=0 to your /etc/avahi/avahi-daemon.conf file and it will reflect chromecast symmetrically across multiple subnets. All it takes to increase reliability from 10% to 100% on Windows machines. macOS does not care: works either way!

Thank your for the nftables tips on TTL mangling and nft debugging! However, the avahi-daemon repeats TTL=1 packets anyway. They show up on the other side with TTL=255 by default.

[server]
#host-name=foo
#domain-name=local
use-ipv4=yes
use-ipv6=yes
cache-entries-max=0
check-response-ttl=no
use-iff-running=no