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?
Marcelo