Opened 2 years ago

Closed 2 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


(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)

syslog_tail (7.7 KB ) - added by ttcoder 2 years ago.
captured over a few minutes of Web+ attempting to connect to ..etc; the driver is not very verbose..

Download all attachments as: .zip

Change History (10)

comment:1 by ttcoder, 2 years ago

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:

~/Desktop> ifconfig /dev/net/iprowifi2200/0 -ht
~/Desktop> ping
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=51 time=46.539 ms
64 bytes from icmp_seq=1 ttl=51 time=47.728 ms
64 bytes from icmp_seq=4 ttl=51 time=48.257 ms
64 bytes from icmp_seq=5 ttl=51 time=47.476 ms
64 bytes from icmp_seq=7 ttl=51 time=48.648 ms
64 bytes from icmp_seq=8 ttl=51 time=50.316 ms
64 bytes from icmp_seq=9 ttl=51 time=47.666 ms
--- ping statistics ---
10 packets transmitted, 7 packets received, 30% packet loss
round-trip min/avg/max/std-dev = 46.539/48.090/50.316/1.094 ms
~/Desktop> uname -a
Haiku shredder 1 hrev52079 Jul  7 2018 09:16:33 BePC x86 Haiku
~/Desktop> listdev 
device Network controller [2|80|0]
  vendor 8086: Intel Corporation
  device 4220: PRO/Wireless 2200BG [Calexico2] Network Connection

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..

Last edited 2 years ago by ttcoder (previous) (diff)

comment:2 by diver, 2 years ago

Component: Drivers/NetworkDrivers/Network/iprowifi2200

comment:3 by diver, 2 years ago

Do you have packet loss if you ping your gateway?

by ttcoder, 2 years ago

Attachment: syslog_tail added

captured over a few minutes of Web+ attempting to connect to ..etc; the driver is not very verbose..

comment:4 by ttcoder, 2 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
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=64 time=5.520 ms
64 bytes from icmp_seq=1 ttl=64 time=3.253 ms
64 bytes from icmp_seq=35 ttl=64 time=4.659 ms
64 bytes from icmp_seq=37 ttl=64 time=3.763 ms
64 bytes from icmp_seq=38 ttl=64 time=3.222 ms
64 bytes from icmp_seq=39 ttl=64 time=3.832 ms
64 bytes from icmp_seq=40 ttl=64 time=3.165 ms
--- 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
PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=51 time=46.103 ms
64 bytes from icmp_seq=1 ttl=51 time=46.039 ms
64 bytes from icmp_seq=2 ttl=51 time=47.914 ms
64 bytes from icmp_seq=62 ttl=51 time=355.218 ms
64 bytes from icmp_seq=63 ttl=51 time=46.139 ms
64 bytes from icmp_seq=64 ttl=51 time=46.704 ms
64 bytes from icmp_seq=65 ttl=51 time=44.785 ms
--- 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
PING ( 56 data bytes
64 bytes from icmp_seq=56 ttl=52 time=35.160 ms
64 bytes from icmp_seq=57 ttl=52 time=37.021 ms
64 bytes from icmp_seq=58 ttl=52 time=38.429 ms
--- 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 waddlesplash, 2 years ago

Hey, someone who actually uses the 2200 driver! I'll prepare a new build later today, hopefully.

comment:6 by ttcoder, 2 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).

Version 0, edited 2 years ago by ttcoder (next)

comment:7 by waddlesplash, 2 years ago

Please retest after hrev52091.

comment:8 by ttcoder, 2 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 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 waddlesplash, 2 years ago

Resolution: fixed
Status: newclosed

Nothing really changed between -91 and -94 for that driver (unless the scheduler fix somehow affected it? That'd be interesting...). Thanks for testing!

Note: See TracTickets for help on using tickets.