From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Reindl Harald <h.reindl@thelounge.net>, kernel@lists.fedoraproject.org
Cc: netfilter@vger.kernel.org
Subject: Re: nf_ct_ftp: dropping packet: partial matching of `227 '
Date: Sat, 16 Apr 2016 23:09:33 -0300 [thread overview]
Message-ID: <5712F05D.1060609@gmail.com> (raw)
In-Reply-To: <571243A8.8040204@thelounge.net>
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
next parent reply other threads:[~2016-04-17 2:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <570F7EB5.4090100@thelounge.net>
[not found] ` <570FDC3E.5050109@gmail.com>
[not found] ` <570FDDF8.7010506@thelounge.net>
[not found] ` <5710115C.4020200@gmail.com>
[not found] ` <5710A364.1050207@thelounge.net>
[not found] ` <571243A8.8040204@thelounge.net>
2016-04-17 2:09 ` Marcelo Ricardo Leitner [this message]
[not found] ` <5712F05D.1060609-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-04-17 8:38 ` nf_ct_ftp: dropping packet: partial matching of `227 ' Reindl Harald
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5712F05D.1060609@gmail.com \
--to=marcelo.leitner@gmail.com \
--cc=h.reindl@thelounge.net \
--cc=kernel@lists.fedoraproject.org \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox