Okay, I've got an odd one, and I'm hoping a kernel developer can at least point me in the right direction.
I've got a Linux box (Fedora Core 5 and kernel 2.6.17-1.2174_FC5), sitting behind a Juniper J2300 router (running JUNOS 7.3R2.6), attempting to FTP to an Alphaserver running Tru64 (5.1B or 4.0G).
With that combination and a stateful firewall enabled on the Juniper, I do not get the FTP banner when I open an FTP connection. The connection just sits there. This is not the traditional FTP problems (active vs. passive, reverse DNS lookup, authentication, etc.).
If I downgrade my Linux box to the FC5 release kernel (2.6.15-1.2054_FC5), it works fine. If I upgrade to the rawhide kernel (2.6.17-1.2583.fc6), it does not work.
Any other combination of OSes works (FTP from WinXP to Tru64, FTP from Linux to Linux or Windows). An FC4 client with a (IIRC) 2.6.16 kernel also works to Tru64.
Now, this appears to be a Juniper JUNOS bug (and our Juniper SE is going to open a case), but what could have changed between Linux kernels 2.6.15 and 2.6.17 that would trigger it? I'm hoping to narrow this down somehow to help Juniper find the problem.
Chris Adams wrote:
Okay, I've got an odd one, and I'm hoping a kernel developer can at least point me in the right direction.
I've got a Linux box (Fedora Core 5 and kernel 2.6.17-1.2174_FC5), sitting behind a Juniper J2300 router (running JUNOS 7.3R2.6), attempting to FTP to an Alphaserver running Tru64 (5.1B or 4.0G).
With that combination and a stateful firewall enabled on the Juniper, I do not get the FTP banner when I open an FTP connection. The connection just sits there. This is not the traditional FTP problems (active vs. passive, reverse DNS lookup, authentication, etc.).
If I downgrade my Linux box to the FC5 release kernel (2.6.15-1.2054_FC5), it works fine. If I upgrade to the rawhide kernel (2.6.17-1.2583.fc6), it does not work.
Any other combination of OSes works (FTP from WinXP to Tru64, FTP from Linux to Linux or Windows). An FC4 client with a (IIRC) 2.6.16 kernel also works to Tru64.
Now, this appears to be a Juniper JUNOS bug (and our Juniper SE is going to open a case), but what could have changed between Linux kernels 2.6.15 and 2.6.17 that would trigger it? I'm hoping to narrow this down somehow to help Juniper find the problem.
I would compare the output of "cat /proc/sys/net/ipv4/*" on 2.6.15-1.2054 and 2.6.17-1.2174 with diff. Then try configuring 2.6.17-1.2174 like 2.6.15-1.2054 and see if it helps.
Also I would advocate being careful running older kernels. I recently had a client who's server was running a kernel two or three versions behind 2.6.17-1.2174, and a local exploit to attain root access was used. It is a known issue and was fixed in the next kernel, but he hadn't updated.
On Wed, 2006-08-23 at 15:47 -0500, Chris Adams wrote:
Okay, I've got an odd one, and I'm hoping a kernel developer can at least point me in the right direction.
I've got a Linux box (Fedora Core 5 and kernel 2.6.17-1.2174_FC5), sitting behind a Juniper J2300 router (running JUNOS 7.3R2.6), attempting to FTP to an Alphaserver running Tru64 (5.1B or 4.0G).
With that combination and a stateful firewall enabled on the Juniper, I do not get the FTP banner when I open an FTP connection. The connection just sits there. This is not the traditional FTP problems (active vs. passive, reverse DNS lookup, authentication, etc.).
If I downgrade my Linux box to the FC5 release kernel (2.6.15-1.2054_FC5), it works fine. If I upgrade to the rawhide kernel (2.6.17-1.2583.fc6), it does not work.
Any other combination of OSes works (FTP from WinXP to Tru64, FTP from Linux to Linux or Windows). An FC4 client with a (IIRC) 2.6.16 kernel also works to Tru64.
Now, this appears to be a Juniper JUNOS bug (and our Juniper SE is going to open a case), but what could have changed between Linux kernels 2.6.15 and 2.6.17 that would trigger it? I'm hoping to narrow this down somehow to help Juniper find the problem.
IIRC, 2.6.17 had some changes to TCP window scaling which breaks on some stupid NAT/firewall/load balancing appliances. (And some versions of BSD pf, apparently.)
Once upon a time, Nicholas Miell nmiell@comcast.net said:
IIRC, 2.6.17 had some changes to TCP window scaling which breaks on some stupid NAT/firewall/load balancing appliances. (And some versions of BSD pf, apparently.)
Thanks to all replies. It does appear related to TCP window scaling; add the Juniper JUNOS stateful firewall protocol algorithms to the affected list. We are working this with Juniper now (but this gives us a much better idea as to where to look).
On Wed, 23 Aug 2006, Nicholas Miell wrote:
Now, this appears to be a Juniper JUNOS bug (and our Juniper SE is going to open a case), but what could have changed between Linux kernels 2.6.15 and 2.6.17 that would trigger it? I'm hoping to narrow this down somehow to help Juniper find the problem.
IIRC, 2.6.17 had some changes to TCP window scaling which breaks on some stupid NAT/firewall/load balancing appliances. (And some versions of BSD pf, apparently.)
FWIW, we experienced breakage with Cisco's IOS Firewall (FTP IP Inspect) in particular. Reducing the window size helped. The issue is being investigated.
Chris Adams wrote:
Okay, I've got an odd one, and I'm hoping a kernel developer can at least point me in the right direction.
I've got a Linux box (Fedora Core 5 and kernel 2.6.17-1.2174_FC5), sitting behind a Juniper J2300 router (running JUNOS 7.3R2.6), attempting to FTP to an Alphaserver running Tru64 (5.1B or 4.0G).
With that combination and a stateful firewall enabled on the Juniper, I do not get the FTP banner when I open an FTP connection. The connection just sits there. This is not the traditional FTP problems (active vs. passive, reverse DNS lookup, authentication, etc.).
If I downgrade my Linux box to the FC5 release kernel (2.6.15-1.2054_FC5), it works fine. If I upgrade to the rawhide kernel (2.6.17-1.2583.fc6), it does not work.
Any other combination of OSes works (FTP from WinXP to Tru64, FTP from Linux to Linux or Windows). An FC4 client with a (IIRC) 2.6.16 kernel also works to Tru64.
Now, this appears to be a Juniper JUNOS bug (and our Juniper SE is going to open a case), but what could have changed between Linux kernels 2.6.15 and 2.6.17 that would trigger it? I'm hoping to narrow this down somehow to help Juniper find the problem.
TCP window scaling?
Try sysctl -w net.ipv4.tcp_window_scaling=0 and see if things start working.
-
Chris Adams -
Jay Cliburn -
Nathan Grennan -
Nicholas Miell -
Pekka Savola