Hi Pablo, You wrote on Fri, Aug 23, 2019 at 02:34:42PM +0200: > On Wed, Aug 21, 2019 at 04:14:28PM +0200, Thomas Jarosch wrote: > > The find_pattern() debug output was printing the 'skip' character. > > This can be a NULL-byte and messes up further pr_debug() output. > > > > Output without the fix: > > kernel: nf_conntrack_ftp: Pattern matches! > > kernel: nf_conntrack_ftp: Skipped up to `<7>nf_conntrack_ftp: find_pattern `PORT': dlen = 8 > > kernel: nf_conntrack_ftp: find_pattern `EPRT': dlen = 8 > > > > Output with the fix: > > kernel: nf_conntrack_ftp: Pattern matches! > > kernel: nf_conntrack_ftp: Skipped up to 0x0 delimiter! > > kernel: nf_conntrack_ftp: Match succeeded! > > kernel: nf_conntrack_ftp: conntrack_ftp: match `172,17,0,100,200,207' (20 bytes at 4150681645) > > kernel: nf_conntrack_ftp: find_pattern `PORT': dlen = 8 > > Do you use this debugging? I haven't use it for years. unfortunately, yes :) One customer site is having FTP NAT problems after migrating from 3.14 to 4.19. The tcpdump traces look normal to me. Still IP addresses for passive FTP don't get rewritten with 4.19, it instantly works with 3.14. It works fine with 4.19 for me using test VMs. It sounds a bit like this: https://bugzilla.netfilter.org/show_bug.cgi?id=1164 Florian's slides about the NAT helper were helpful in general: https://strlen.de/talks/nfdebug.pdf -> NAT helpers are best effort, but like I said, it should work given the packets dumps I have seen so far. I hope to install a kernel with this debug output at the customer site soon. As it's the central gateway of a township, I can't reboot the machine easily and they have quite strict working hours. I'll keep nagging them ;) Cheers, Thomas
