AP mode, beaconing with rt73usb?

Live forum: http://rt2x00.serialmonkey.com/viewtopic.php?t=4843

andrey

10-06-2008 06:25:53

Hello. What is the status of AP (or 'master') mode and beaconing in rt73usb? I am testing AP mode on an rt2571usb device and it does not seem to send beacons. I created an ap interface like this

iw dev wmaster0 interface add ap0 type ap

and then brought that up. The interface did get created but the device doesn't send beacons. Is this supported? I am using the 'master' branch from today. Thanks!

IvD

10-06-2008 12:52:40

Well it should work..
Could you provide some more debug information?

IvD

10-06-2008 12:53:28

P.S. You are using hostapd I assume? If not, you better install and use that immediately. ;)

andrey

10-06-2008 17:29:12

hostapd isn't running at this point, I am mainly checking to see if the device will send beacons (having verified that, I plan to patch the driver to support 802.11s mesh[/url4b226voh]). Right now I plug in the device and the rt73usb driver comes up and loads the firmware. I make an interface for the AP and bring that up

iw dev wmaster0 interface add ap0 type ap
iwconfig ap0 channel 6
ifconfig ap0 192.168.8.1 up

...I then use another interface in monitor mode to scan on channel 6 but I don't see 802.11 beacons from my rt2571usb device. I have CONFIG_RT2X00_DEBUG enabled, so I'll check to see what that provides. I'll also rebuild with CONFIG_RT2X00_LIB_DEBUGFS and take a look there. It looks like ad-hoc mode probably works (but via probe responses rather than beacons) though in the driver I see that for IEEE80211_IF_TYPE_AP interfaces, it does configure beaconing.

IvD

10-06-2008 17:33:42

Well if the beacon is provided to rt2x00 then rt73usb should definately be broadcasting it.
See the topic viewtopic.php?f=5&t=4660 for a script to dump the register contents but the <rt2x00 debugfsroot>/queue/queue would also be interesting to see.

andrey

10-06-2008 17:52:41

Thanks. Here's a register dump using that script, having set up an AP interface on channel 6. I'll try to set up hostapd now, perhaps mac80211 doesn't tell the rt73usb driver to send beacons unless hostapd or similar is running. I do see that rt2x00lib_config_intf() in rt2x00config.c gets called with the interface type set to IEEE80211_IF_TYPE_AP, so at least the interface configuration step looks right. That should then call rt73usb_config_intf() from rt73usb.c which enables beaconing, as I understand it.

Also
[code3dt98hdl]
$ cat /sys/kernel/debug/ieee80211/phy0/rt73usb/queue/queue
qid count limit length index done crypto
14 0 12 21796 4 0 0
0 0 12 0 0 0 0
1 0 12 0 0 0 0
2 0 12 0 0 0 0
3 0 12 0 0 0 0
16 0 4 0 0 0 0
[/code3dt98hdl]

IvD

10-06-2008 18:05:50

Yes, but rt73usb_beacon_update() also needs to be called, since that will upload the beacon to the hardware.

andrey

10-06-2008 18:26:18

Ah yes, it doesn't get called. I'll see if I can get that to happen with hostapd running (or just in mesh mode).

By the way, from the documentation for ieee80211_ops I see that beacon_update (which is what rt73usb_beacon_update resolves to) is called for IBSS mode but not, as I understand it, for AP mode. That said, the device seemed to send probe responses rather than beacons when I had it configured in IBSS mode.

IvD

10-06-2008 21:13:06

True but if you check the function rt2x00mac_config_interface()

[code2qt39zw4]
if (conf->type != IEEE80211_IF_TYPE_AP || !conf->beacon)
return 0;

status = rt2x00dev->ops->hw->beacon_update(rt2x00dev->hw, conf->beacon);
if (status)
dev_kfree_skb(conf->beacon);
[/code2qt39zw4]

so yes the beacon_update function is only called by mac80211 in IBSS mode, but rt2x00 will use the same function to upload the beacon in master mode.

andrey

10-06-2008 22:29:12

Yes, and as part of adding mesh support, we need to do this for Mesh Point interfaces as well

[code34awh353]
if ((conf->type != IEEE80211_IF_TYPE_AP &&
conf->type != IEEE80211_IF_TYPE_MESH_POINT) || !conf->beacon)
return 0;

status = rt2x00dev->ops->hw->beacon_update(rt2x00dev->hw, conf->beacon);
[/code34awh353]

However after bringing up a mesh interface, I also do not see beacons from this device (even though the above modified version of rt2x00mac_config_interface() does get executed). In general, since this driver sets IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE, mac80211 should assume that the device does beaconing in hardware via beacon templates. In mesh mode, it should then send beacons (at least this is how it was done on the zd1211rw driver, which is somewhat similar). I'm a bit new to this so I might have things slightly wrong though.

I'd like to see some beacons on the air, so I think I'll go back to getting hostapd up and running with this device. If that works, then mesh beacons should be simple enough to generate as well.

andrey

11-06-2008 00:14:14

Ok, I now have hostapd working via nl80211. On the air, again, there are only probe responses from the device, no beacons. I can confirm that the update_beacon() function gets called from rt2x00mac_config_interface() during interface setup but nothing seems to make it out to the air. Perhaps beaconing doesn't work with the current driver? Is there any debug information I can provide? Just in case, here's a register dump while hostapd is running. Thanks again for all of your help.

IvD

11-06-2008 08:12:37

Not sure what might be causing this, when the IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE flag is set mac80211 will provide the beacon once and when that is configured rt2x00 should be transmitting the beacons. However since master mode wasn't enabled in rt2x00 until very recently it has never been that thouroughly tested...
Can you check if 2.6.26-rcX with patch

[code2xpkrrp6]
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -33,6 +33,10 @@ nl80211_type_to_mac80211_type(enum nl80211_iftype type)
case NL80211_IFTYPE_MESH_POINT:
return IEEE80211_IF_TYPE_MESH_POINT;
#endif
+ case NL80211_IFTYPE_AP:
+ return IEEE80211_IF_TYPE_AP;
+ case NL80211_IFTYPE_AP_VLAN:
+ return IEEE80211_IF_TYPE_VLAN;
case NL80211_IFTYPE_WDS:
return IEEE80211_IF_TYPE_WDS;
default:
[/code2xpkrrp6]

does enable beaconing correctly for rt73usb? (just to rule out problems with the latest rt2x00 patches)

andrey

11-06-2008 17:16:46

In this case, I'm at 2.6.26-rc4 via the rt2x00 git ('master' branch) and cfg.c already looks like what you posted.

IvD

11-06-2008 17:39:29

No I mean the real 2.6.26-rcX snapshot from kernel.org.
rt2x00 contains tons of patches that are not in 2.6.26 and if master mode is broken in 2.6.26 as well I can rule out those patches as the cause, but if it works in 2.6.26 (with the cfg changes I posted above) then one of the experimental patches has broken master mode.

andrey

11-06-2008 18:01:22

Ah, understood. Building that now, and then I'll repeat my experiments and report back. Thanks.

andrey

11-06-2008 20:03:43

Ok, I can confirm that with 2.6.26-rc5 from today's git (and with the patch you posted to cfg.c applied), the device still only sends probe responses with hostapd running (no beacons). I'll add some prink's to the driver to double-check that the beacon-related functions get called next.

Iwo

18-06-2008 06:45:51

Hi,

I have the same problem, broadcast SSID and association works, but no beacons.
This is based on today's git of the rt2x00 kernel and hostapd.

I added some debug code to rt73usb_beacon_update(), namely

[code195mqvry] /*
* Fill in skb descriptor
*/
skbdesc = get_skb_frame_desc(skb);
memset(skbdesc, 0, sizeof(*skbdesc));
skbdesc->desc = skb->data;
skbdesc->desc_len = intf->beacon->queue->desc_size;
skbdesc->entry = intf->beacon;

+ dump_skb(skb);
+ dump_stack();
+
/*
* Disable beaconing while we are reloading the beacon data,
* otherwise we might be sending out invalid data.
*/
rt73usb_register_read(rt2x00dev, TXRX_CSR9, &reg);
rt2x00_set_field32(&reg, TXRX_CSR9_TSF_TICKING, 0);
rt2x00_set_field32(&reg, TXRX_CSR9_TBTT_ENABLE, 0);
rt2x00_set_field32(&reg, TXRX_CSR9_BEACON_GEN, 0);
rt73usb_register_write(rt2x00dev, TXRX_CSR9, reg);
[/code195mqvry]

dump_skb() does as it says, including some hexdumps of skb->cb
and skb->data.

The results of a short session with hostapd are attached. In a nutshell,
rt73usb_beacon_update() gets called three times during the hostapd
startup. I assume, the hardware is supposed to continue sending beacons
automatically?

Anyway, the function gets called - can anyone see something unusual
in the hexdumps?

Kind regards,

Iwo

andrey

26-06-2008 18:48:34

I can still reproduce this (and what Iwo describes), is there anything I can do to help troubleshoot?

VoloGrant

17-07-2008 02:31:13

I can still reproduce this (and what Iwo describes), is there anything I can do to help troubleshoot?[/quote3s230tvu]

Andrey,

We have observed some issues related to the length of usb register writes to the device.

Please try the attached patch and let us know how you go.

andrey

17-07-2008 18:22:33

I can still reproduce this (and what Iwo describes), is there anything I can do to help troubleshoot?[/quote3tuzq8pu]

Andrey,

We have observed some issues related to the length of usb register writes to the device.

Please try the attached patch and let us know how you go.[/quote3tuzq8pu]

Hi. What tree is this patch against? I tried it against rt2x00 git (master) and wireless-testing and I get

[code3tuzq8pu]
drivers/net/wireless/rt2x00/rt2x00usb.c: In function ‘rt2x00usb_vendor_request’:
drivers/net/wireless/rt2x00/rt2x00usb.c:89: error: implicit declaration of function ‘rt2x00dev_usb_dev’
drivers/net/wireless/rt2x00/rt2x00usb.c:89: warning: initialization makes pointer from integer without a cast
drivers/net/wireless/rt2x00/rt2x00usb.c:91: warning: unused variable ‘i’
[/code3tuzq8pu]

EDIT ah well, that's easy enough to fix myself ) I'll finish building this and try it now.

andrey

17-07-2008 19:37:43

VoloGrant -- I've tried your patch but I still don't see beacons on the air. My test is to run hostapd and then sniff 802.11 frames. I can scan for and associate to the access point in question, but the device isn't sending any beacons out.

AdamBaker

17-07-2008 20:17:33

Have you verified that your sniffer can detect beacons - preferably by testing it with a known good AP? I have in the past had to fix problems with rt2x00 devices failing to sniff broadcast traffic even though they could sniff addressed traffic between other devices.

VoloGrant

18-07-2008 00:13:48

VoloGrant -- I've tried your patch but I still don't see beacons on the air. My test is to run hostapd and then sniff 802.11 frames. I can scan for and associate to the access point in question, but the device isn't sending any beacons out.[/quote20e4h2nt]

Does your connection to the access point fail after a short period? This should be the case if beacons are not being sent.

We have verified here using our 802.11 packet sniffer that beacons do not work without this patch, and do work with it (vanilla 2.6.26 + enable AP mode patch, latest git version of hostapd).

PS Patch is against vanilla 2.6.26. Can you try again with this kernel?

Iwo

18-07-2008 04:39:22

VoloGrant -- I've tried your patch but I still don't see beacons on the air. My test is to run hostapd and then sniff 802.11 frames. I can scan for and associate to the access point in question, but the device isn't sending any beacons out.[/quote2s2vu5d1]

Andrey,

The transfer size was a problem, but only half the problem. The second bug was related to
the size of the beacon templates. See the attached 3 patches against the current rt2x00 tree.

The first two are fixing the same problem as VoloGrant's. The third one fixes the size bug
for rt2500 and rt73.

Without the last patch, you would have beacons, but with CRC errors. Your sniffer may silently
discard them.

Those patches will get merged into the rt2xx tree, as soon as Ivo finds the time.

Kind regards,

Iwo

andrey

18-07-2008 19:31:49

Thanks folks, I will try these patches out soon and report back. By the way, yes, my sniffer does see 802.11 beacons from known-good APs (and I use it for checking other management frames).

IvD

18-07-2008 21:24:03

The above mentioned patches have been merged into rt2x00.git