oem-qa team mailing list archive

[feranick <feranick@xxxxxxxxxxx>]

Fix released on updated kernel 2.6.24-22-lpia on the custom hardy for
the dell mini.

** Changed in: dell-mini
       Status: Confirmed => Fix Released

-- 
wl: telnet/ssh connections blocked when going through NAT to external sites
https://bugs.launchpad.net/bugs/259816
You received this bug notification because you are a member of OEM
Services QA, which is subscribed to The Dell Mini Project.

Status in The Belmont Project: Confirmed
Status in The Dell Project: Fix Released
Status in Dell Inspiron Mini with Custom Dell UI: Fix Released
Status in “linux-restricted-modules” source package in Ubuntu: Fix Released
Status in “linux-restricted-modules-2.6.24” source package in Ubuntu: Invalid
Status in linux-restricted-modules in Ubuntu Hardy: Invalid
Status in linux-restricted-modules-2.6.24 in Ubuntu Hardy: Fix Released

Bug description:
So I finally got around to testing the wl driver on some Dell hardware I had. It took me awhile to notice a huge bug, and to actually place the blame on the wl driver, since it was so obscure.

My configuration is a Linksys WRT54G AP, setup to NAT my local network to the internet (T1). I put the bcm4321 card in my laptop.

Applications such as Firefox, Pidgin and Evolution were working fine. SSH connections to machines on my local LAN were also working fine.

However, I then tried to SSH to machines outside the LAN, and the connections froze. Using -vv on ssh, it actually made the connection, but then stopped shortly after authentication.

Trying to debug the issue, I used telnet to connect to the external ports. A SYN packet was sent, but never got an ACK. It wouldn't even connect to port 80 on web servers that Firefox was connecting to with no problems.

So the issue is not one of protocol or port, but one of how ssh and telnet's TCP-IP is setup, and how the NAT is handled. A direct connection to the internet (Not NAT'd) works fine.

I confirmed this with another person who was also using wl, and he was able to reproduce it with a different AP (still NAT) on both of our 2.6.24 and 2.6.26 kernels (hardy and intrepid).

So this isn't a regression either. I would spend more time on this, but I suspect I wouldn't be able to get further than "yeah, it's broken".