I believe that the wireless rt2860 driver in drivers/staging/, as well
as in the previous non-mainstream sources that it incorporated, sends
out incorrect (unparsable) association frames, which make it
impossible to associate with certain stations.  This is with a
2.6.28.x (Ubuntu) or 2.6.29.x (stock) kernel.

I found this after upgrading my access point from madwifi to ath5k: so
at first I believed it might be a bug in the still experimental ath5k
AP mode driver, or in hostapd, but after some debugging I am convinced
that the error is indeed in rt2860.

The error messages produced by hostapd at the AP end when receiving
this malformed association frame are the following (in what follows,
00:1b:11:14:d5:0f is the access point and 00:22:43:00:6c:54 is the
station attempting to connect, the latter is using the rt2860 driver):

association request: STA=00:22:43:00:6c:54 capab_info=0x411 listen_interval=3
unknown vendor specific information element ignored (vendor OUI 00:0c:43 len=7)
STA 00:22:43:00:6c:54 sent invalid association request

I added a hook in hostapd to dump the incriminated management frame
(invalid association request) emitted by rt2860, and its content was
this:

00000000  00 00 30 01 00 1b 11 14  d5 0f 00 22 43 00 6c 54  |..0........"C.lT|
00000010  00 1b 11 14 d5 0f 80 1f  11 04 03 00 00 0a 44 61  |..............Da|
00000020  76 69 64 6f 75 6e 65 74  01 08 82 84 8b 96 0c 12  |vidounet........|
00000030  18 24 32 04 30 48 60 6c  dd 07 00 0c 43 06 00 00  |.$2.0H`l....C...|
00000040  00 01 00 00 0f ac 02 01  00 00 0f ac 04 01 00 00  |................|
00000050  0f ac 02 00 00                                    |.....|
00000055

Starting from byte 0x1c (00 0a 44 61...), this is supposed to be of
the form one byte content-type, one byte length-of-what-follows (n),
then n bytes of data (repeat to end).  There is valid vendor-specific
(Ralink=00:0c:43) data starting at byte 0x38 (dd 07 00 0c 43 06 00 00
00), but the rest is badly formed.  It seems that the bytes 30 14
(indicating 20 bytes of RSN IE data) is missing immediately before
byte 0x41 (01 00 00 0f ac 02...).

I can't imagine how this could be a result of frame corruption inside
hostapd or the receiving ath5k driver, so it must be an error of the
sending rt2860 driver.  I tried to understand how the management
frames are produced, but I utterly failed to comprehend how the driver
works, so I can only report the bug as above.

I imagine the bug does not turn up when associating with a MadWifi
station, of various embedded devices, because they are much more
lenient when receiving corrupted data and discard the incorrect parts
of the frame before hostapd even gets a chance to see it.