why are that packages dropped in context of nf_nat_ftp? that are the part of FTP connections and that IP exists, has a valid PTR and is a known client and so what is wrong with cotaining "227"? [845643.840984] nf_ct_ftp: dropping packet: partial matching of `227 ' IN= OUT= SRC=192.168.196.1 DST=xx.120.227.194 LEN=53 TOS=0x10 PREC=0x00 TTL=80 ID=24046 DF PROTO=TCP SPT=21 DPT=55980 SEQ=350417036 ACK=3295683477 WINDOW=15752 RES=0x00 ACK PSH FIN URGP=0 [845645.377695] nf_ct_ftp: dropping packet: partial matching of `227 ' IN= OUT= SRC=192.168.196.1 DST=xx.120.227.194 LEN=53 TOS=0x10 PREC=0x00 TTL=80 ID=24047 DF PROTO=TCP SPT=21 DPT=55980 SEQ=350417036 ACK=3295683477 WINDOW=15752 RES=0x00 ACK PSH FIN URGP=0

Am 14.04.2016 um 20:06 schrieb Marcelo Ricardo Leitner: > Em 14-04-2016 08:27, Reindl Harald escreveu: >> why are that packages dropped in context of nf_nat_ftp? >> >> that are the part of FTP connections and that IP exists, has a valid PTR >> and is a known client and so what is wrong with cotaining "227"? >> >> [845643.840984] nf_ct_ftp: dropping packet: partial matching of `227 ' >> IN= OUT= SRC=192.168.196.1 DST=xx.120.227.194 LEN=53 TOS=0x10 PREC=0x00 >> TTL=80 ID=24046 DF PROTO=TCP SPT=21 DPT=55980 SEQ=350417036 >> ACK=3295683477 WINDOW=15752 RES=0x00 ACK PSH FIN URGP=0 >> >> [845645.377695] nf_ct_ftp: dropping packet: partial matching of `227 ' >> IN= OUT= SRC=192.168.196.1 DST=xx.120.227.194 LEN=53 TOS=0x10 PREC=0x00 >> TTL=80 ID=24047 DF PROTO=TCP SPT=21 DPT=55980 SEQ=350417036 >> ACK=3295683477 WINDOW=15752 RES=0x00 ACK PSH FIN URGP=0 > > 227 is the reply for PASV command > (http://www.serv-u.com/respcode.asp?resp=227), and nf_ct_ftp could get > only part of the reply on that packet. So it drops the packet and waits > for the next one, which shall contain the full information. > > Otherwise it won't be able to expect the new connection sounds reasonable, on the other side the client yesterday had troubles to make passive ftp connections with "connection refused" as far as the admin was able to tell on the phone maybe unrelated and random, we solved that anyways by switch to a webservice on both sides and avoid FTP entirely but since there are many FTP transactions from webcams every few minutes and all the "partial matching of `227 '" came from the same IP containing 227 - hmm

Am 14.04.2016 um 23:53 schrieb Marcelo Ricardo Leitner: >>> Otherwise it won't be able to expect the new connection >> >> sounds reasonable, on the other side the client yesterday had troubles >> to make passive ftp connections with "connection refused" as far as the >> admin was able to tell on the phone >> > It could be that the drop happened and an auxiliary connection was > attempted before the retransmission of the 227 reply, so your firewall > didn't know about it and actively blocked the connection. If it had > silently dropped the new connection request, the client probably would > retransmit the SYN after a bit. > > Now why the cameras are triggering it, good question not the cameras - a ordinary client with filezilla, that one with 227 in his IP address, the cameras blow their images without any problem on the FTP server

Cc'ing netfilter@ too Thread: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.... Em 16-04-2016 10:52, Reindl Harald escreveu: > > Am 15.04.2016 um 10:16 schrieb Reindl Harald: >> Am 14.04.2016 um 23:53 schrieb Marcelo Ricardo Leitner: >>>>> Otherwise it won't be able to expect the new connection >>>> >>>> sounds reasonable, on the other side the client yesterday had troubles >>>> to make passive ftp connections with "connection refused" as far as >>>> the >>>> admin was able to tell on the phone >>>> >>> It could be that the drop happened and an auxiliary connection was >>> attempted before the retransmission of the 227 reply, so your firewall >>> didn't know about it and actively blocked the connection. If it had >>> silently dropped the new connection request, the client probably would >>> retransmit the SYN after a bit. >>> >>> Now why the cameras are triggering it, good question >> >> not the cameras - a ordinary client with filezilla, that one with 227 in >> his IP address, the cameras blow their images without any problem on the >> FTP server > > maybe i made it not clear enough: > > there is no "my firewall" between that is just iptables directly on the > machine running pure-ftpd and so it's killing outgoing localhost traffic > - that is very weird Okay but expected :) because even if conntrack is running on the system itself that is running the service, it ignores that fact and still acts like just a man-in-the-middle.

So you can still reproduce it?

If so, I don't see another way to debug this but to unload nf_conntrack_ftp and take a traffic capture without limiting the packet size (don't use -s option), because I'm afraid that otherwise conntrack will drop the packet and we won't even see it in the capture. Look for a packet containing a "227 " in the beginning of TCP payload. That should be our guy. Feel free to send it only to my email if you prefer.

Unfortunately the pr_debug()s available on that area aren't much helpful for this problem. And which kernel is this?