Bug#511165: Does not show up with standard clients
I tried to further locate when the bug appears. As it turned out the
command line ftp client does not cause the kernel panic, neither in
passive nor in standard mode. I also ran the ftpsync Perl script without
In order to allow the systems to access ftp, I added the following rule
to the applicable chain:
iptables -A _chain_ -p tcp -o ppp0 -s _client-system_ --syn -m state
--state NEW -j ACCEPT
(yes, there is a state established, related rule somewhere at the top of
the stack.) However, even after having performed the ftpsync, using gFTP
through frox panicked the firewall.
However, during further searching for the point of no return, I found
that my proxy did not even have permission to open a connection to port
21. After allowing this, I can browse ftp:// URLs through the same
squid3 as used by frox without problems. The kernel panic using gFTP
If nf_nat_ftp and nf_conntrack_ftp are not loaded during browser access,
the data connection is just dropped by the firewall. Nothing evil happens.
This is the frox configuration file. So far untested, but a very similar
one ran for a couple of years on my Etch server.
/# grep -v '^#' /etc/frox.conf | grep -v '^ *$'
ACL Allow sleipnir - *
gFTP on sleipnir is configured to use:
Typ: user@host NOAUTH
... and yes proxy.mgr resolves to the OpenVZ container homing the frox.
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com
|All times are GMT. The time now is 09:59 AM.|
VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.