Date: Fri, 2 Aug 2002 13:39:11 -0700 From: Sean Chittenden <sean@chittenden.org> To: current@freebsd.org Subject: IP stack or NetGear MA401 problems on -CURRENT... (July 18th-30th) Message-ID: <20020802203911.GA12551@ninja1.internal>
next in thread | raw e-mail | index | archive | help
Let me try my luck here with a bigger crowd. I just upgraded two laptops from DP1 and July 18th to a July 30th kernel, both of them with NetGear MA401 wireless cards. The short and skinny: the network/wireless used to work and now they don't. *) TCP, UDP, and ICMP are affected so I assume all of IP is affected. *) Using ping as an example, when I ping the gateway and run tcpdump from the laptop, I see the request and the reply come back on tcpdump, however ping reports ~99% packet loss (sometimes a packet or two will show up). *) All firewalls have been turned off (ipf -D/ipfw has a default allow policy. Possibly ipfw2 dragging it's feet somehow?). ;) *) Using SSH as an example, if I'm very careful and type super slow, I can sometimes log into a remote box and issue a few commands, but this is flaky at best. If I try and load mutt, it hangs for about 10min or so, then will sometimes show the contents of my inbox, other times the TCP connection will break. tcpdump shows the local host sending out many ack packets for the same IP sequence and the remote host replying with the appropriate packet, but the application never knows any better. If ICMP and UDP weren't having issues, I'd guess this to be a window sizing issue, but it's not limited to TCP. Doing a DNS query is at best successful 25% of the time. Unfortunately I'm on the road and can't try this against the fxp interfaces that are in my docking stations, so I'm limited to assuming that one of the following was broken between the 18th and the 30th: *) wireless (doubtful given that tcpdump shows the packets being sent and coming back) *) firewall (possible. ipf has been unloaded and ipfw has a default allow policy, so it shouldn't be mucking things up). *) IP stack (given that tcpdump works on raw datagrams, I'd guess that something's broken in the OSes way of handling IP packets. I'm tempted to suspect Matt Dillion's TCP backoff bit, but this isn't TCP specific. :-/) *) Hardware (I'm using two different dell latitudes with two different NetGear cards and am having the exact same behavior so this seems very unlikely. I'm not getting any errors on the interfaces either.) Anyway, I'm stumped and don't know where to poke at. If the network wasn't horked, I'd just sup to the 18th and continue on my merry way, but the network's botched and I'm without a floppy. Anyone have any clues? I'm fresh out of ideas as to where to poke. -sc PS Yeah, I know I shouldn't not have a floppy handy while running -CURRENT, but I'm on the road and -CURRENT's just been so stable recently so I opted to leave 'em at home. ::sigh:: At least one of them has a backup kernel on it, but I can't transfer it to the second. :-/ -- Sean Chittenden To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020802203911.GA12551>