From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 Description of problem: Everything works great with RHL8, but I can't get the wireless network card working reliably under RHL9. I have a Dell Inspiron 2650 with a Truemobile 1150 PC Card being used with a Siemens/Efficient Networks SpeedStream 2524 Wireless/Powerline/Ethernet router. The router has a built-in DHCP server that assigns IP addresses in the 192.168.254.x range, and is connected to the Internet via a Cisco 678 DSL CPE that dynamically assigns the Siemens router an ip address on the 10.0.0.x range. The Cisco has a dynamically assigned routable ip address provided by my ISP. The NEAT configuration utility was used for configuration under both versions of RHL. Under RHL9, like with RHL8, the card is detected fine, and the configuration appears to completely smoothly with no errors. However, after upgrading to RHL9 and setting up the wireless card with NEAT, I tried to access a few websites after configuring the wireless card and got very strange results. If I tried to access www.news.com in Mozilla, the text would mostly load (except for some graphics / ads which normally load fine). However, news.bbc.co.uk would not come up at all, and neither would slashdot.org or pretty much any other website I tried. These same sites load quickly and completely under RHL 8. The status bar of Mozilla shows that the ip address of the website resolves, but the page never loads. Using ping to query remote sites does work fine. The up2date tool would not work (rhn_register seems able to verify the username and password supplied but is hanging on the part where it sends the system data to the remote server). I could find no errors in /var/log/messages, /var/log/secure, dmesg, etc. /sbin/lsmod showed all of the modules I expected to be listed (orinoco_cs, hermes, etc). After re-installing RHL 8, all network problems disappeared, and all the websites which would not load under RHL 9 load fine. Installing RHL9 again didn't help; I got the same results as before. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Install RHL9 2. Configure a Wireless adapter as above, activate adapter 3. Try to surf around using Mozilla Actual Results: Strange behavior, most websites failed to load, anything involving the network seemed to act flaky. Expected Results: Wireless network should work fine, like it did in RHL8. Additional info: There is a built-in 10/100 network port in the laptop (eth0), but no network cable is plugged in, so the network script fails to bring up networking on eth0 at boot time on both RHL 8 & 9. The wireless card is configured as eth1. I have WEP (128 bit) enabled on the router, the mode is set to "Managed", and the key was entered in NEAT in hex style (RHL 9 insisted on having a 0x placed in front of the key, whereas my RHL 8 config does not have a 0x in front of the key). RHL 9 was installed cleanly, I did not choose to upgrade the RHL 8 installation.
I have the same Dell laptop and networking card, but with an Apple AirPort Base station. I also had no problems whatsoever with RHL 8 and my wireless card. Like the original submitter, after upgrading to RHL 9, my wireless connection has become unreliable to the point where I'm probably going to roll back to RHL 8. Interesting symptoms: * ssh to a remote host (w/ agent-forwarding) times out, but ssh -1 works * links and Mozilla both time out when trying to connect to another host on the local network, but perl -MLWP::Simple -e'get "http://host/"' and telnet host 80 works fine * also XMMS is able to play files off of a local HTTP server, but trying to access those same files via Mozilla or links times out The only hunch I have -- and it's a stretch -- is that something having to do with buffering or packet size may be going on. Mozilla and links, being optimized for fast downloading, probably use aggessive buffering and send fat packets. XMMS and, certainly, telnet swing more toward low-latency, and so they probably prefer more frequent, smaller packets. Just a hunch.
sounds more like a kernel driver issue... not a configuration thing...
If ssh2 succeeds and ssh1 fails, you've most likely got a MTU problem. ssh2 uses a large packet as part of the key exchange mechanism while connecting, which ssh1 doesn't do, so ssh1 will happily connect when ssh2 is being blocked by MTU issues. you could try turning down the MTU using ifconfig, but there may be a larger underlying problem here.
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/