Bug 89124
Summary: | Wireless Network card flaky under RHL9, worked great with RHL8 | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Drel Douay <rhl9bugs.5.drel> |
Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 9 | CC: | tom |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-09-30 15:40:48 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Drel Douay
2003-04-17 21:14:03 UTC
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/ |