http://bugzilla.suse.com/show_bug.cgi?id=993426 http://bugzilla.suse.com/show_bug.cgi?id=993426#c6 --- Comment #6 from Luiz Angelo Daros de Luca --- (In reply to Marcus Meissner from comment #5)

Would it be sufficient to load the

mdoule via FW_LOAD_MODULES="nf_conntrack_tftp"

and

FW_SERVICES_ACCEPT_RELATED_EXT="my.tftp-server.ip,udp,,69"

it injects a susefirewall2 rule like:

iptables -A input_ext -s 192.168.1.0/32 -p udp -m udp --dport 69 -m conntrack --ctstate RELATED -j ACCEPT

(not sure about the -m udp and where it comes from)

I did not test but I guess that it is not enough. I'll not match the incoming data packets from server as they do not use port 69 anymore. The helper must match on the outgoing packet (not input_ext) in order to open the return path. This is a normal tftp traffic. Ports xyz and abc are random high ports: client xyz -> 69 server (request read) client xyz <- abc server (data) client xyz -> abc server (ack) client xyz -> 69 server (request write) client xyz <- abc server (ack) client xyz -> abc server (data) Nothing is received from port 69. The "-j CT --helper tftp" matching the outgoing (not incoming) first packet does the magic of "accepting anything from the tftp to the xyz UDP port". Before (linux<4.7.0), this was simply automatic for any tftp outgoing request, for any destination when nf_conntrack_tftp was loaded. Now, I need to call manually the helper. -- You are receiving this mail because: You are on the CC list for the bug.