Re: nf_ct_ftp: dropping packet: partial matching of `227 '

Re: nf_ct_ftp: dropping packet: partial matching of `227 '

[Marcelo Ricardo Leitner]

Cc'ing netfilter@ too
Thread: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/thread/CLNQ6O6OGNEJAFFSNV56KU6P2JAPM5YU/

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

Re: nf_ct_ftp: dropping packet: partial matching of `227 '

[Reindl Harald]

[-- Attachment #1.1.1: Type: text/plain, Size: 2843 bytes --]



Am 17.04.2016 um 04:09 schrieb Marcelo Ricardo Leitner:
> Cc'ing netfilter@ too
> Thread:
> https://lists.fedoraproject.org/archives/list/kernel-TuqUDEhatI4ANWPb/1PvSj/laDblWjpS@public.gmane.orgt.org/thread/CLNQ6O6OGNEJAFFSNV56KU6P2JAPM5YU/
>
>
> 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.

but partial packets on the local system? :-)

> So you can still reproduce it?

not in a way that would make it easy to debug, some days are log floods 
and that for years now and most time there is nothing - until last week 
i thought that would be something to attackers related but then i had a 
customer with borken PASV ftp and his IP address 100 times in the log 
with that message

> 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.

hmm - if i could reproduce it in a way "i want it now" and somewhere 
else than a production server

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

i have always the latest Fedora kernel running
4.4.7-300.fc23.x86_64


[-- Attachment #2: Type: text/plain, Size: 173 bytes --]

_______________________________________________
kernel mailing list
kernel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/kernel@lists.fedoraproject.org