Red Hat Bugzilla – Bug 89124
Wireless Network card flaky under RHL9, worked great with RHL8
Last modified: 2007-04-18 12:53:08 EDT
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,
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):
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.
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.
* 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
* 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
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/