Opened 6 years ago
Closed 6 years ago
#14258 closed bug (fixed)
iprowifi2200 packet loss (weak signal?)
Reported by: | ttcoder | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Drivers/Network/iprowifi2200 | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
(Filed vs. "Network" root, as there is not iprowifi2200 component in the list)
Experiencing heavy packet loss on an Acer Aspire with iprowifi2200 NIC. Oddly, the problem varies greatly with distance to my wifi router: I can browse the web almost normally when a meter away; however I have 30+% packet loss and Web+ won't load sites if I'm 5+ meters away from router. (there are a couple tickets with title "weak wifi signal", maybe related?)
Attachments (1)
Change History (10)
comment:2 by , 6 years ago
Component: | Drivers/Network → Drivers/Network/iprowifi2200 |
---|
by , 6 years ago
Attachment: | syslog_tail added |
---|
captured over a few minutes of Web+ attempting to connect to haiku-os.org ..etc; the driver is not very verbose..
comment:4 by , 6 years ago
@diver seems so, yes:
Ran a test (in the same conditions as the past 2 days, yet I have lower packet loss today, and only 2 sites refuse my connection, weird); anyway here goes:
~/Desktop> ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 data bytes 64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=5.520 ms 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=3.253 ms .. 64 bytes from 192.168.1.1: icmp_seq=35 ttl=64 time=4.659 ms 64 bytes from 192.168.1.1: icmp_seq=37 ttl=64 time=3.763 ms 64 bytes from 192.168.1.1: icmp_seq=38 ttl=64 time=3.222 ms 64 bytes from 192.168.1.1: icmp_seq=39 ttl=64 time=3.832 ms 64 bytes from 192.168.1.1: icmp_seq=40 ttl=64 time=3.165 ms --- 192.168.1.1 ping statistics --- 41 packets transmitted, 39 packets received, 4% packet loss round-trip min/avg/max/std-dev = 3.165/3.994/6.238/0.713 ms /Desktop> ping www.haiku-os.org PING haiku.netlify.com (54.93.39.116): 56 data bytes 64 bytes from 54.93.39.116: icmp_seq=0 ttl=51 time=46.103 ms 64 bytes from 54.93.39.116: icmp_seq=1 ttl=51 time=46.039 ms 64 bytes from 54.93.39.116: icmp_seq=2 ttl=51 time=47.914 ms ... 64 bytes from 54.93.39.116: icmp_seq=62 ttl=51 time=355.218 ms 64 bytes from 54.93.39.116: icmp_seq=63 ttl=51 time=46.139 ms 64 bytes from 54.93.39.116: icmp_seq=64 ttl=51 time=46.704 ms 64 bytes from 54.93.39.116: icmp_seq=65 ttl=51 time=44.785 ms --- haiku.netlify.com ping statistics --- 66 packets transmitted, 65 packets received, 1% packet loss round-trip min/avg/max/std-dev = 43.936/51.854/355.218/38.091 ms ~/Desktop> ping www.free.Fr PING www.free.fr (212.27.48.10): 56 data bytes ... 64 bytes from 212.27.48.10: icmp_seq=56 ttl=52 time=35.160 ms 64 bytes from 212.27.48.10: icmp_seq=57 ttl=52 time=37.021 ms 64 bytes from 212.27.48.10: icmp_seq=58 ttl=52 time=38.429 ms --- www.free.fr ping statistics --- 59 packets transmitted, 42 packets received, 28% packet loss round-trip min/avg/max/std-dev = 35.160/37.597/41.779/1.362 ms
comment:5 by , 6 years ago
Hey, someone who actually uses the 2200 driver! I'll prepare a new build later today, hopefully.
comment:6 by , 6 years ago
Lol! Well if it allows extending Haiku's compatibility and is not too much trouble... This is for a quiet (as in silent!) cute little laptop. I have tickets queued that are more significant, for a T410 and an R61 (that latter one seemingly being an actual regression from the freebsd9-era driver).
(Edit FWIW: well, browsing tickets about something else, I /did/ stumble on someone else using this driver :-b.. Namely Giova84: ticket:9263#comment:14 )
comment:8 by , 6 years ago
From what I recollect of the past few days,
- updating to 52091 assured packet loss to the gateway was never more than 20-ish % (never went to a stage where Web+ would stop loading sites)
- updated to hrev52094 and now consistently between 0% and 5-ish% packet loss. Waited a day or so to ensure it was not just a fluke. I can browse most sites now, except the free.fr webmail which keeps snubbing this particular machine, no biggie.
Started using this for light web browsing, and for keeping a mirror of my fossil repo maintained with fossil sync. (FWIW, pkgman cannot find a "fossil" package online, so had to copy the hpkg from another haiku machine)
Maybe even the remaining 5% will disappear after the change you recommended in ticket:14266#comment:2
I guess it should be safe to close this ticket, thanks!
comment:9 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Nothing really changed between -91 and -94 for that driver (unless the scheduler fix somehow affected it? That'd be interesting...). Thanks for testing!
Comparing with previous revs: this problem seems to manifest in the same way in an older hrev (hrev49959).
Comparing with other OSes: not possible, only OS installed is Haiku.
When not in the immediate vicinity of the wifi router, there is generally around 30% packet loss on wi-fi (wired networking works fine).
In case it matters, I dropped into KDL to runs
ints
: there are unhandled interrupts in some handlers (e.g. for "ata_adapter") but not for iprowifi2200.More info below:
The odd thing is that things go very well for establishing the connection itself (DHCP is negociated in a couple seconds); and the wifi signal strength indicator is about half-strength, it's not down to bottom level..