rt2x00.serialmonkey.com

Good evening men,
after long time, I send us full report again about support of rt2500pci in Master Mode with recent kernel and recent hostpad.

IMHO block stopper fails:
a) MGMT (TX callback) fail ... no visible AP SSID on client (mode managed) machine on the other side
b) unknown vendor specific information element ignored (vendor OUI 00:10:18 len=9)
c) Error for wireless request "Set ESSID" (8B1A) :
SET failed on device wlan0 ; Operation not supported.
d) Error for wireless request "Set Mode" (8B06) :
SET failed on device wlan0 ; Invalid argument.
e) wlan0 No scan results
!!! but there is 8 other APs around !!!
f) no ESSID string in iwconfig output

Steps to reproduce:
1) download GIT trees (kernel + hostapd)
rt2x00.sh

2) generate configs
config_kernel.txt
config_hostpad.txt

3) patch hostapd
patch hostapd to ignore the lack of acknowledgement: http://eznemegy.blog.hu/2008/12/14/usin ... th_hostapd

4) make and install kernel + hostapd

5) reboot PC with new kernel

6) launch hostapd
hostapd.txt

7) catch full reports for comunity
dmesg.txt
hostapd.txt
ifconfig.txt
iwconfg_errors.txt
iwconfig.txt
lshw.txt
lsmod.txt
rt2x00_regdump.txt (by rt2x00_regdump.sh)
uname.txt
WiFi.txt

Thank you for comments, Petr Novák.

I also see the "MGMT (TX callback) fail" with an rt2500pci card on the git version of 2.6.29 from today, using the git version of hostapd. Symptoms are the same, I cannot see the SSID from other machines, and simply setting the SSID on the machines never results in association with hostapd.

If any debug information is needed, I'll happily provide it.

Same problem here.


This happens only if the card is in "master" - mode


I think thats right, setting the card to master is not supported by iwconfig. (hostap only)


i think u need to be root


Same here, think thats the main-problem...

System:

• Kernel: 2.6.29-rc6-wl (latest git)
• hostapd: v0.7.0
• Ralink RT2500 802.11g Cardbus/mini-PCI (rev 01)

If more informations is needed, please tell me...

I tried to make a dump with the rt2x00_regdump.sh script and hostapd running, but it only shows the following lines:



where is my mistake???

Ahh I hadn't updated my regdump script yet, latest rt2x00.git contains a new version for register dumping, but the script on my kernel.org space wasn't updated accordingly. As soon as I get home from work I'll update the script.

_________________
Regards,
Ivo van Doorn
Project Administrator
http://rt2x00.serialmonkey.com

I still have to complete & test the entire set of scripts for debugfs.
I'll attach the new dumpscript, and will upload it to the kernel.org webspace when I am done with the rest of the scripts.
In any case, this script should work better for you.

_________________
Regards,
Ivo van Doorn
Project Administrator
http://rt2x00.serialmonkey.com

@IvD:

Thank you for your help, i can now run the script.
In the new script I had to change 2 lines, but I think it was a typo:
line 73, 75: ${DEBUG_DIR}/$... to ${DEBUG_DIR}register/$...

for everyone else, who gets:

You need to install "gawk" (debian: apt-get install gawk), the allready installed mawk can't deal with the "--posix" option.

Thanks, I'll fix this in the script.



Hmm, perhaps I should call gawk directly or at a check if the --posix argument is needed or not.
Thanks.

_________________
Regards,
Ivo van Doorn
Project Administrator
http://rt2x00.serialmonkey.com

I see the rt2500pci driver sends incorrect beacon because of misalignment... Please compare with rt73usb driver. First 24 bytes of beacon message put to rt73usb_write_beacon are as follows:
80 0 0 0 ff ff ff ff ff ff 0 e 2e cf a1 88 0 e 2e cf a1 88 10 0
Compare with the beacon on air (tcpdump output):
I have marked bold the message contents. As you see, message starts at 24-byte offset. Now, message passed to rt2500pci_write_beacon:
80 0 0 0 ff ff ff ff ff ff 0 c 43 25 60 0 0 c 43 25 60 0 10 0
Beacon on air:
As you see, the message starts at 25-byte offset.

My investigations: entry->skb->data is not at 4-byte boundary. The allocated skb buffer (which is page aligned) is advanced by ieee80211_tx_status_rtap_hdr size before pass to the function, which is equal to 13.
After message align in memory (memmove), the beacon looks much better:

Anyway, even if the correct beacon is sent, connection with the AP cannot be estabilished....

Success! I have managed to connect to hostap working on the rt2500pci based card. Namely, the alignment problem exists not only in beacon frame. The rt2x00mac_tx function receives a misaligned skb->data, too. After the alignment correction, the device has started to work.

Fantastic. If you have a patch, I'll be happy to test it later today.

My patch is rather a temporary solution. It uses construct that I'm not sure is fully legal - but at least it works. It is for vanilla kernel 2.6.29.

I think a correct solution should enforce to receive already aligned messages from ieee802 level.
The driver behaves something strange, beacon is sent very frequently at hostapd startup, but at least it works. I think some additional investigations are needed for the driver.

I can report success with the patch also, although I understand why it really isn't ready for inclusion, but at least it shows where the problem is.

I also tested the connection by copying a file, and everything seemd ok, so thanks a lot.

What about the bit rate ? On my machine connection starts at 54 Mb/s, but after a few minutes it goes down to 1 Mb/s. Although only 1m distance is between stations and reported link quality is 97/100. File transfer doesn't exceed ~170 kB/s.

Strange... The bit rate depends on devices pair connected together. It looks the rt2500pci does not like Intel 3945ABG. But in pair with a second Ralink it works at much higher bit rate.

I have found only one more issue to correct. The rt2500pci_interrupt function re-schedules beacon update when beacon timer expires. This is unnecessary, it only causes problems. The RT chip generates the interrupt every time the beacon is sent to air. This occurs periodically, every 100ms or whatever is set. Because the first beacon is sent immediately after set, the interrupt occurs immediately after beacon set, too. This causes that the beacon is sent very frequently, much more frequently than the specified beacon period.

I have removed the rt2x00lib_beacondone call from rt2500pci_interrupt and it seems to work much better. As I see, the rt73usb driver does not have any periodic re-scheduling of beacon update, probably the rt2500pci driver does not need any, too.