I have a Gentoo-based server with 2.6.24-gentoo-r8 kernel, firewalled. For a test-setup, i needed a DNAT rule in NAT PREROUTING chain to duplicate a port (my FTP server does not listen on localhost): DNAT tcp -- * * 0.0.0.0/0 <server_ip> tcp dpt:60002 to:<server_ip>:21 On the other side, simply doing a: nc <server_ip> 60002 provokes a kernel panic on the server (or it seems to, as it is not mirrored by netconsole, alas. If someone has access to x86_64 hardware and kernel...). Precisions: - this only happens if the DNAT port is 21. When using another port, there's no problem. Perhaps a netfilter ftp helper problem ? - This did not happen with 2.6.22-gentoo-r8 kernel on x86_64. - This happens with 2.6.24-gentoo-r4 and 2.6.24-gentoo-r8 kernel on x86_64. - Altough the setup is not exactly the same on my test box, this does not seems to happen on x86 with 2.6.24-gentoo-r4. Can someone confirm the problem on x86_64 or x86 ? I'll attach my .config to the bug report, along with the firewall rules i have in use. Reproducible: Always Steps to Reproduce: 1. Set up a DNAT rule: iptables -t nat -A PREROUTING -p tcp --dport 60002 -j DNAT --to <external_ip>:21 2. From another host, connect to <external_ip>:60002. 3. Enjoy the kernel panic. Actual Results: Either have my connection refused if there's no server running on port 21, or connection accepted. Expected Results: Seems to have panic'd, altough i have no trace of it (neither with netconsole).
Created attachment 156235 [details] Kernel config for my x86_64 server
Created attachment 156237 [details] The relevant firewall rules on the server Replace SERVER_IP by the external IP of the box you are testing.
(In reply to comment #0) > I have a Gentoo-based server with 2.6.24-gentoo-r8 kernel, firewalled. > > For a test-setup, i needed a DNAT rule in NAT PREROUTING chain to duplicate a > port (my FTP server does not listen on localhost): > DNAT tcp -- * * 0.0.0.0/0 <server_ip> > tcp dpt:60002 to:<server_ip>:21 > > On the other side, simply doing a: > nc <server_ip> 60002 > > provokes a kernel panic on the server (or it seems to, as it is not mirrored by > netconsole, alas. If someone has access to x86_64 hardware and kernel...). > > Precisions: > - this only happens if the DNAT port is 21. When using another port, there's no > problem. Perhaps a netfilter ftp helper problem ? > - This did not happen with 2.6.22-gentoo-r8 kernel on x86_64. > - This happens with 2.6.24-gentoo-r4 and 2.6.24-gentoo-r8 kernel on x86_64. > - Altough the setup is not exactly the same on my test box, this does not seems > to happen on x86 with 2.6.24-gentoo-r4. > > Can someone confirm the problem on x86_64 or x86 ? > > I'll attach my .config to the bug report, along with the firewall rules i have > in use. > > Reproducible: Always > > Steps to Reproduce: > 1. Set up a DNAT rule: iptables -t nat -A PREROUTING -p tcp --dport 60002 -j > DNAT --to <external_ip>:21 > 2. From another host, connect to <external_ip>:60002. > 3. Enjoy the kernel panic. > > Actual Results: > Either have my connection refused if there's no server running on port 21, or > connection accepted. > > Expected Results: > Seems to have panic'd, altough i have no trace of it (neither with netconsole). > Woops: forgot to add an essential point: You must NOT have something listening on the port 21 for the panic to occur immediately. In fact, I found the bug when doing simultaneous connections to the FTP server, so i imagine that if you have several simultaneous connections, this also occurs.
I don't have the environment to reproduce it here. Is there any way you can get the trace? Can you test on a newer kernel such as 2.6.25 or 2.6.26-rc?
(In reply to comment #4) > I don't have the environment to reproduce it here. Is there any way you can get > the trace? Can you test on a newer kernel such as 2.6.25 or 2.6.26-rc? > I will try to do that as soon as possible, as soon as i get access to a local server with x86_64 system, since i cannot get anything via netconsole. That may take a few days, though. Thanks for your reply.
Please feel free to reopen when you've had a chance to test. Thanks.
