On Friday 13 May 2011 19:40:41 Ignacy Gawedzki wrote: > On Fri, May 13, 2011 at 12:39:53PM -0400, thus spake Brian Prodoehl: > > Have you tested only with hw crypto? Try passing the nohwcrypt param > > to the module while loading. > > I just tried that and at first it seemed to make no difference. But at some > point, one of the two nodes of my testbed started to send encrypted frames > (both broadcast and unicast) and the other node could receive them okay. > > Unfortunately, I just can't make the other node work (the difference being it > is a x86_64 netbook vs. an i386 embedded atom industrial PC for the first > node). > > My preliminary tests show that setting the nohwcrypt option makes no difference. not too surprising, the driver does not set IEEE80211_HW_SUPPORTS_PER_STA_GTK. Therefore the software crypto is always used in this case. Note: there's a special bit [RX_MAC_CONTROL - bit 6] which instructs the key cache controller to do the "key security settings" lookup with addr2 for all bc/mc frames. If we enable this bit and modify carl9170_op_set_key to set the per station gtk correctly [i.e.: use sta->addr as MAC and put the keys into the per-sta space [0-63?]] we should be able to enable PER_STA_GTK... although the driver will be restricted to a single vif [I think]. > Next week, I'll hopefully have more time to investigate and find a repeatable > procedure to make that work or break. you should try your setup with mac80211_hwsim first [so we can rule out all driver bugs]. Regards, Chr -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
