Opened 4 months ago

Closed 4 months 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:
Has a Patch: no 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)

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

Download all attachments as: .zip

Change History (10)

comment:1 Changed 4 months ago by ttcoder

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 www.haiku-os.org
PING haiku.netlify.com (35.158.109.181): 56 data bytes
64 bytes from 35.158.109.181: icmp_seq=0 ttl=51 time=46.539 ms
64 bytes from 35.158.109.181: icmp_seq=1 ttl=51 time=47.728 ms
64 bytes from 35.158.109.181: icmp_seq=4 ttl=51 time=48.257 ms
64 bytes from 35.158.109.181: icmp_seq=5 ttl=51 time=47.476 ms
64 bytes from 35.158.109.181: icmp_seq=7 ttl=51 time=48.648 ms
64 bytes from 35.158.109.181: icmp_seq=8 ttl=51 time=50.316 ms
64 bytes from 35.158.109.181: icmp_seq=9 ttl=51 time=47.666 ms
--- haiku.netlify.com 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 4 months ago by ttcoder (previous) (diff)

comment:2 Changed 4 months ago by diver

Component: Drivers/NetworkDrivers/Network/iprowifi2200

comment:3 Changed 4 months ago by diver

Do you have packet loss if you ping your gateway?

Changed 4 months ago by ttcoder

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 Changed 4 months ago by ttcoder

@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 Changed 4 months ago by waddlesplash

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

comment:6 Changed 4 months ago by ttcoder

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 )

Last edited 4 months ago by ttcoder (previous) (diff)

comment:7 Changed 4 months ago by waddlesplash

Please retest after hrev52091.

comment:8 Changed 4 months ago by ttcoder

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 Changed 4 months ago by waddlesplash

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.