View previous topic :: View next topic |
Author |
Message |
skizot722 n00b
![n00b n00b](/images/ranks/rank_rect_0.gif)
![](images/avatars/gallery/Zelda/Zelda_-_Link.jpg)
Joined: 02 Aug 2004 Posts: 6
|
Posted: Tue Aug 17, 2004 5:33 pm Post subject: wifi troubles.... please help |
|
|
I've got a Linksys WMP11 v2.7 (yes, the crappy Broadcom 4301 chipset) working with ndiswrapper. The problem is that when I'm listening to mythmusic i'm getting a lot of skipping. There's not an option to setup a cache/buffer in that prog either. However, when using mplayer and listening to a live 128 kbps radio stream with -cache 256 set i still get some skipping. Now, to the wifi stuff. I'm rather concerned with the output of iwconfig, which yields:
Code: | # iwconfig
lo no wireless extensions.
eth0 no wireless extensions.
wlan0 IEEE 802.11b ESSID:"wifi"
Mode:Managed Frequency:2.447GHz Access Point: XX:XX:XX:XX:XX:XX
Bit Rate:11Mb/s Tx-Power:16 dBm
RTS thr:2347 B Fragment thr:2346 B
Encryption key:off
Power Management:off
Link Quality:100/100 Signal level:-68 dBm Noise level:-256 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:1248 Invalid misc:161002 Missed beacon:0 |
Note the values for "Tx excessive retries" and "Invalid misc." What are these values anyways? Now, when doing a ping test (to the AP), I'm not seeing anything unusual:
Code: | # ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 ttl=63 time=5.18 ms
64 bytes from 192.168.1.100: icmp_seq=2 ttl=63 time=1.85 ms
64 bytes from 192.168.1.100: icmp_seq=3 ttl=63 time=2.26 ms
64 bytes from 192.168.1.100: icmp_seq=4 ttl=63 time=2.21 ms
64 bytes from 192.168.1.100: icmp_seq=5 ttl=63 time=2.14 ms
64 bytes from 192.168.1.100: icmp_seq=6 ttl=63 time=1.98 ms
64 bytes from 192.168.1.100: icmp_seq=7 ttl=63 time=2.11 ms
64 bytes from 192.168.1.100: icmp_seq=8 ttl=63 time=2.01 ms
64 bytes from 192.168.1.100: icmp_seq=9 ttl=63 time=2.19 ms
64 bytes from 192.168.1.100: icmp_seq=10 ttl=63 time=1.87 ms
64 bytes from 192.168.1.100: icmp_seq=11 ttl=63 time=1.98 ms
64 bytes from 192.168.1.100: icmp_seq=12 ttl=63 time=2.04 ms
64 bytes from 192.168.1.100: icmp_seq=13 ttl=63 time=1.84 ms
64 bytes from 192.168.1.100: icmp_seq=14 ttl=63 time=2.12 ms
64 bytes from 192.168.1.100: icmp_seq=15 ttl=63 time=2.35 ms
64 bytes from 192.168.1.100: icmp_seq=16 ttl=63 time=2.04 ms
64 bytes from 192.168.1.100: icmp_seq=17 ttl=63 time=2.04 ms
64 bytes from 192.168.1.100: icmp_seq=18 ttl=63 time=2.65 ms
64 bytes from 192.168.1.100: icmp_seq=19 ttl=63 time=2.07 ms
64 bytes from 192.168.1.100: icmp_seq=20 ttl=63 time=2.30 ms
64 bytes from 192.168.1.100: icmp_seq=21 ttl=63 time=1.87 ms
--- 192.168.1.100 ping statistics ---
21 packets transmitted, 21 received, 0% packet loss, time 20018ms
rtt min/avg/max/mdev = 1.845/2.247/5.188/0.685 ms |
also, dmesg said a couple things about ndiswrapper:
Code: | ndiswrapper version 0.9 loaded
ndiswrapper: driver wmp11v27.sys added
ndiswrapper: using irq 12
wlan0: ndiswrapper ethernet device XX:XX:XX:XX:XX:XX using driver wmp11v27.sys
ndiswrapper (set_auth_mode:479): setting auth mode failed (C0010015)
ndiswrapper (iw_set_tx_power:355): setting tx_power failed (C0010015) |
I've tried version 0.8 and 0.7 both returning the same thing. As far as the skipping goes, there shouldn't be any reason for it on an 11 mbit connection. Does anyone have ideas/suggestions? I'd really like to get this resolved. I'm thinking it might just be a problem with ndiswrapper, but according to their site this chipset is supported. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
Cartroo n00b
![n00b n00b](/images/ranks/rank_rect_0.gif)
Joined: 04 Aug 2004 Posts: 41
|
Posted: Tue Aug 17, 2004 7:15 pm Post subject: |
|
|
The high "excessive retries" count probably indicates that your connection is not reliable - the card believes its packets are not being received and hence is retransmitting.
Have you tried playing with the channel you use? I've found lots of problems with certain cards which were fixed by changing channels. The fact that the ping works correctly doesn't really indicate much about the connection since it's very low bandwidth.
You could also try using the rate argument to limit the maximum bandwidth to see if that helps. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
skizot722 n00b
![n00b n00b](/images/ranks/rank_rect_0.gif)
![](images/avatars/gallery/Zelda/Zelda_-_Link.jpg)
Joined: 02 Aug 2004 Posts: 6
|
Posted: Tue Aug 17, 2004 11:46 pm Post subject: |
|
|
I tried changing it to different channels. Still getting a ton of invalid misc and Tx excessive retries. I still get more and more packets for each of those two with the wifi off... wtf. I really don't know what else to try besides going out and getting a different card. Any other ideas??? |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
gnuageux Veteran
![Veteran Veteran](/images/ranks/rank_rect_5_vet.gif)
![](images/avatars/161644882641fd6ea588345.png)
Joined: 17 Apr 2004 Posts: 1201
|
Posted: Wed Aug 18, 2004 9:30 am Post subject: |
|
|
Hmmmm checked for duplex mismatches? _________________ The realOTW: http://forums.realotw.org/index.php
Registered Linux user#364538 |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
Cartroo n00b
![n00b n00b](/images/ranks/rank_rect_0.gif)
Joined: 04 Aug 2004 Posts: 41
|
Posted: Thu Aug 19, 2004 1:22 pm Post subject: |
|
|
Have you tried doing something like:
Code: | iwconfig wlan0 rate 2M fixed |
I've seen some comments on mailing lists that slowing down the data transfer can solve this problem. It makes sense - if the link is (for some reason) unreliable then crowding it out with high-rate traffic is going to make the problem worse. Even if it's not a permanent solution, it would be interesting to see whether that stops the errors.
Note that I've never played with the rate argument myself - I get the impression that it has to come from a fixed list of rates supported by your card, so you might try other values instead of the 2M (5.5M is one I've seen used before).
This will, of course, slow your traffic down but depending what's going wrong you might actually find it decreases latency and hence skipping.
Also that error about not being able to set the TX power is interesting - I don't know enough to know for sure, but I suppose it's possible that your output power is too low, though 16dBm seems quite reasonable to me. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
|