Changing TTL in OpenWrt 22.03

[mbg]

Thank you,

is this only available in beta firmware as 4.6.8 is the latest stable?
when will 4.8.0 be released as stable?

[bruce]

Yes. The v4.6.8 supported to config the TTL if I do not forget, if no, please upgrade to the v4.8.0 beta first, stable v4.8.0 is coming soon.

GL.iNet download center

[NetOnDeck]

Does Beryl AX GL-MT3000 also support this from the UI?

[bruce]

Yes, MT3000 supported.

[cbz]

Hi -

I have an AR750, running 4.3.25, using it in the router/repeater setup connecting to the upstream connection via WiFi. Both nftables and legacy iptables are present on this router. Looking at /etc/init.d/firewall it looks like it uses fw4 on a restart, so I presume the legacy rules are down to some packages that haven't migrated over.

I added the rule using the directives above (incidentally, there's an alternate way of setting these up by creating a file under /etc/nftables.d/ though the syntax is somewhat different - can cover it for anyone interested). I can also verify via nft list ruleset that the rule goes in after a fw4 reload (fwiw I also used a value of 64 rather than 65 -- as this is more of a default standard).

The rule fails to work properly though, NATted packets are unaffected by the rule, though packets originating on the router itself (ping/ntp etc) are re-written.

Furthermore the fact that the packets from client machines are making it through having had their original TTLs (128 in the case of Windows) decremented, leads me to suspect that in this scenario the particular mangle_postrouting chain isn't being hit at all (otherwise whatever value outputted wouldn't be related to the input value - but would in some way be related to the value in the rule)

[9b9e69c2-4b75-4420]

Even easier:

GL sft1200 opal on MSC cruise

uci batch <<- __EOF add firewall rule rename firewall.@rule[-1]='custom_ttl' set firewall.custom_ttl.name='Set TTL to 64' set firewall.custom_ttl.src='wan' set firewall.custom_ttl.proto='ip' set firewall.custom_ttl.target='ACCEPT' set firewall.custom_ttl.ttl='64' reorder firewall.custom_ttl='1' set firewall.custom_ttl.enabled='1' __EOF uci commit firewall && /etc/init.d/firewall restart

[cbz]

@cbz

Furthermore the fact that the packets from client machines are making it through having had their original TTLs (128 in the case of Windows) decremented, leads me to suspect that in this scenario the particular mangle_postrouting chain isn't being hit at all (otherwise whatever value outputted wouldn't be related to the input value - but would in some way be related to the value in the rule)

To add to this, this is only evident when sniffing the network layer -- within the filtering code, it appears to think the packet is locally modified (via log statements and look at the TTL values before and after the TTL instructions).

[cbz]

I'm reasonably convinced that this is something to do with conntrack/nat, it appears that packets originating on the router itself are fine, further the first couple of outgoing packets from new connections initiated by devices behind the router are also fine, the rest of them show up unmodified (again -- this can only be detected by sniffing the packets on the upstream router, not on the router itself).