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
problems.
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
still persists.
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 '^ *$'
Listen proxy.mgr
Port 2121
ResolvLoadHack wontresolve.doesntexist.abc
User frox
Group frox
WorkingDir /srv/proxy/frox
LogLevel 25
LogFile /var/log/frox.log
PidFile /var/run/frox.pid
BounceDefend yes
CacheModule http
HTTPProxy 127.0.0.1:8080
MinCacheSize 5000
DoNTP yes
MaxForks 10
MaxForksPerHost 4
ACL Allow sleipnir - *
gFTP on sleipnir is configured to use:
Proxy: proxy.mgr:2121
Typ: u...@host NOAUTH
USER %...@%hh
PASS %hp
... and yes proxy.mgr resolves to the OpenVZ container homing the frox.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
