Difficulty detecting APs
I have a Philips PCMCIA Wifi Card, which shows up in lspci as
0600.0 Network controller RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01)
I have a very weird problem with it. Although everything works fine most of the time when the device is relatively near an access point, in many cases it does not or only detects a very limited number of access points. In the weekend, I was in a hotel with my brother and on the exact same spot where my card only found 1 single access point, his notebook saw 16 of them! (I used "iwlist scan" on both systems.) His notebook could even connect to some of them (and load webpages), while my card couldn't connect at all (also when I entered the ESSID and MAC address manually).
I'm using Ubuntu Hardy, which I understand uses the rt2x00 drivers. I am using the default drivers that came with it. Other than this, they work fine with all kinds of access points once I get the card to connect.
Is this problem known? I have the impression I could change a setting, so the card would use more power or try harder in some other way to find access points. What settings influence this?
I've observed similar - it normally sees my AP but rarely more than 1 of my neighbour's while other devices see 6 or more. There is code in the driver which is supposed to set maximum sensitivity during a scan which could cause this sort of problem if it failed. The best way to tell if the problem is Tx power or Rx sensitivity would be to try doing passive scans but I don't know if there is an easy way to do that. The other option would be to use monitor mode on a card that can measure rx power and compare the probe request power from an rt2x00 device to another device at the same range (or the rt2x00 device using legacy drivers).
The only other cards I have here are a madwifi pci card (currently in a system acting as an access point) and a hermes2 pcmcia card (which has rather bad Linux driver support, but I could do a scan with it).
Do you think I could measure this with the madwifi card? The system is using Linux and it's not really a problem to take down the access point for a while and let it run some testing programs.
There are several different variants of madwifi drivers plus the newer ath5k driver that you could be using on the AP so it is hard to tell what that supports - the only way to tell reliably is to test it. Depending upon the driver the instructions at http//madwifi.org/wiki/UserDocs/MonitorModeInterface
might help with setting up a monitor mode interface on it. For best results then set the channel to one you know is occupied. If you can do that and run wireshark on that interface you should be able to see the Probe messages generated when you do a scan from the rt2500 and the responses it generates. Check that the received signal strength is included in the headers. Look at the received level of the probe running both the rt2x00 and legacy drivers and see if it is similar. Also look to see if there are probe responses from the distant APs that the rt2x00 driver fails to spot.
Seems I didn't even have to disable my other ap interfaces. I created a 3rd interface as a monitor interface and ran Wireshark to create the attached dump.
I'm not really sure whether I'm doing the right thing though, so I'm attaching a dump with just one scan. I wasn't able to find the signal strength in the information in Wireshark. Is it already in the dump? Do I need to enable more options to create a packet dump that is interesting?
Interesting - the Probe Request messages all include 2 contradictory signal strength indications (SSI Signal, part of the RadioTap header). I suspect the first is actually signal strength and the second signal to noise. All of the other messages seem to be lacking those fields.
If we assume your card can't reliably capture signal strength then the remaining useful info it could obtain is whether Probe Response messages are sent by the distant APs when using the rt2x00 drivers. To do this you need to first do a scan with the legacy driver and find out what channel numbers are used by the weaker APs. Then tune the monitor mode card to one of those channels and still using the legacy driver perform a scan and check that you can see the Probe Response message from the weak AP on that channel. Switch to the rt2x00 driver and repeat the scan. Check if you can still see the Probe Response message. If you can then the problem must be related to rx sensitivity, if you can't (but can see the Probe request) then there is a Tx power control issue. If you don't even see the probe request then either something has gone wrong with the test (time to recheck with legacy drivers) or there is a problem with the scanning process.
Well, it happens to be so the wifi still works kind of unstable here. Sometimes I have a stable connection over a longer period of time, but there are also cases where it stops working regularly. Maybe this is related somehow, so I'm thinking of showing the capture to the madwifi people.
I will also try to get the old driver to work & try to capture a scan with it.
I did not tune the monitor interface to a particular channel for this scan btw. I just created a monitor interface & took a dump with Wireshark. Could that also explain the issue?
Seems I got something!
After looking around a bit on the madwifi site & my system, I noticed that diversity antenna was enabled while there is only a single antenna sticking out of the system. I changed the settings to use only a single antenna. I guess this will improve things.
The scan also seems interesting. I first did a scan with the old driver and after that I did one with the new driver. The results are again attached.
It seems that with the second scan, the received signal is indeed weaker.
Some things I should note and I could maybe do to improve the scan (get more results)
The rt2500 actually detects two more accesspoints (more easily with the old driver indeed it seems) which are not seen by the madwifi card. The rt2500 is actually a floor higher and on the other side of the house than the madwifi, so I could do the tests again with the rt2500 more close to the madwifi. I can move the rt2500, but not the madwifi (so I can't bring it to the range of the other APs).
I have an old Linksys AP which I could move so it is likely detected by the madwifi. (Now it's only detected by the rt2500.)
I have the Hermes 2 card with which I could also do a scan.
Let me know if any of that would be useful.
You have only attached one scan to the second post but if the scan's you have done have established that you are getting lower Tx power with the rt2x00 driver than the legacy driver then that at least suggests a starting point to examine. No promises as to when I'll get round to it tho.
The attached file should contain both scans.
I started Wireshark on the monitor interface & then I
- scanned while I had the old driver loaded
- quickly unloaded the old driver & loaded the new one
- scanned again with the new driver
After this I stopped Wireshark. I believe the first probe request is the first attempt with the old driver and the one about half a minute later is the second one with the new driver. I hope you can also see this in the capture.
It would be interesting if this could be looked at. I am not an expert with this, but it seems that the signal with the older drivers is about 8x (9 dB) stronger, which I guess can make a big difference sometimes. I'm dependent on the new driver myself, because I need it's wpa_supplicant support in several locations, so I will not be switching to the old driver for now.
If there is anything else I can do or try to solve this, I will do my best to help. Thanks a lot for all the information.
Not sure if this is really valuable info, but I'm on holiday now, where I can only access the internet using wifi, so I tested a bit here.
The accesspoint connection is unprotected. After logging in through a secure webpage your mac address is added to a white list (I think that's how it works).
First I worked with the new drivers, these worked at first, but the connection wasn't very stable.
Then I tried the old drivers, those worked quite a bit more stable.
Then I tried the MS Windows drivers with NDISWrapper and suddenly "iwlist scan" gave an additional accesspoint I could use and the connection quality was much higher. Also the connection is even more stable.
Maybe things would work even better with the latest GIT version of the driver. I could only try the version included with Ubuntu 8.04 now.