What's new

Bug in CTF?

  • 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!

@sbsnb, what happens if you try the nvram variable discussed in this thread? It seems to somehow let udp packets (like NTP) sidestep CTF. But only for LAN-originated packets, not router packets (i.e. FORWARD table, not OUTPUT table).

Just a thought...but as I type it, I doubt it would help the router's NTP daemon. But I'm hoping you're desperate enough to try it. :rolleyes:

Code:
nvram set ctf_pt_udp=1
nvram commit
service restart_firewall
conntrack -F

Didn't work :(
 
I don't know whether it's relevant to what you're discussing but the original thread about UDP was regarding loopback traffic. The solution there additionally involved moving that rule to the PREROUTING chain (which John then implemented in his firmware).

http://www.snbforums.com/threads/potential-bug-with-udp-nat-loopback-hairpinning.70892/post-670283
I tried iptables -t mangle -A PREROUTING -p udp -m state --state NEW -j MARK --set-mark 0x1/0x7 and it broke things even more. I could not get ntpq -p to have sane output whatsoever.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top