Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Failing wireless network connections -- an observation



Hi,

In order to test the latest changes in the OpenBSD iwn driver with NetBSD, I 
updated my Linksys WAP54G access point to the latest firmware and enabled the 
"WAP2-mixed" security mode.  Initially, this seemed to work fine.  When I tried 
to capture video from a HDHomerun tuner, however, the capture would invariably 
stop after maybe 100 seconds.  I found that if I deleted the arp entry for the 
tuner and sent it a ping packet, the capture would resume for about 70 
seconds, the stop again.  The arp/ping process could be repeated for another 
70 seconds of capture.  Even if I stop the video capture, pings fail after 
about 70 seconds.  While this was going on, I had no problems accessing Web 
sites and I could ping continuously a printer server that was located right 
next to the tuner (literally and network-wise).  It was just the connection to 
the tuner that failed.  (The tuner, access point and the print server are all 
connected to the same Ethernet switch and all the devices are on a single 
subnet so no routing is involved.)

I found that the current iwn driver as well as the USB rum driver behave the 
same way.

Changing the access point security setting to "WPA2-Personal" appears to avoid 
the problem and I did not notice it using WEP with the old firmware.

I am wondering if the problem is the same one that I have observed in the past 
staying at hotels where my Internet connection would work for only a few tens 
of seconds before disappearing for several minutes. The several minutes 
perhaps related to an arp timeout.  (Next time I will test with arp -d).

This is on a (fairly) recent current amd64.

Regards,
Sverre

PS Why do I see problem with a single device only?

If NetBSD places limits on buffers/resources per IP address, there could be a 
resource starvation on NetBSD that apparently is not reclaimed properly (there 
is a difference in behavior immediately after boot and after the problem has 
been triggered once).

There could be a difference in the tuner network stack and that of the print 
server.



Home | Main Index | Thread Index | Old Index