WPA_SUPP problem on ath9k_htc

[chunyeow]

It seems that wpa_supplicant in ath9k_htc is not able to ping others although the keys are correctly installed. ath9k and carl9170 are both working well.

[twpedersen]

did you use nohwcrypt=1? :)

On Tue, Aug 6, 2013 at 6:54 PM, Chun-Yeow notifications@github.com wrote:

It seems that wpa_supplicant in ath9k_htc is not able to ping others although the keys are correctly installed. ath9k and carl9170 are both working well.

— Reply to this email directly or view it on GitHubhttps://github.com/cozybit/wpa_supplicant/issues/4 .

Thomas

[chunyeow]

HW crypto is not allowed even for unicast data frame using AES CCMP for ath9k_htc?

On Wed, Aug 7, 2013 at 10:06 AM, twpedersen notifications@github.comwrote:

did you use nohwcrypt=1? :)

On Tue, Aug 6, 2013 at 6:54 PM, Chun-Yeow notifications@github.com wrote:

It seems that wpa_supplicant in ath9k_htc is not able to ping others although the keys are correctly installed. ath9k and carl9170 are both working well.

— Reply to this email directly or view it on GitHub< https://github.com/cozybit/wpa_supplicant/issues/4> .

Thomas

— Reply to this email directly or view it on GitHubhttps://github.com/cozybit/wpa_supplicant/issues/4#issuecomment-22225310 .

[twpedersen]

On Tue, Aug 6, 2013 at 9:56 PM, Chun-Yeow notifications@github.com wrote:

HW crypto is not allowed even for unicast data frame using AES CCMP for ath9k_htc?

Before it gets to that point, we would still need broadcast / unicast mgmt (path selection) and broadcast data (arp request) to be encrypted / decrypted correctly.

Thomas

[chunyeow]

Agree. This is a bit weird on ath9k_htc since path selection, peering management and ARP request/reply all are working fine, or I miss out somethings.

Node 1: (ath9k_htc) $ iw mesh0 station dump | grep plink mesh plink: ESTAB $ sudo iw mesh0 mpath dump DEST ADDR NEXT HOP IFACE SN METRIC QLEN EXPTIME DTIM DRET FLAGS 00:0b:6b:7d:dc:91 00:0b:6b:7d:dc:91 mesh0 2 228 0 0 0 0 0x14 $ arp -n Address HWtype HWaddress Flags Mask Iface 1.1.1.2 ether 00:0b:6b:7d:dc:91 C mesh0

Node 2: (ath9k) $ iw mesh0 station dump | grep plink mesh plink: ESTAB $ iw mesh0 mpath dump DEST ADDR NEXT HOP IFACE SN METRIC QLEN EXPTIME DTIM DRET FLAGS 64:70:02:1e:46:33 64:70:02:1e:46:33 mesh0 2 8193 0 0 100 0 0x4 $ arp -n IP address HW type Flags HW address Mask Device 1.1.1.1 0x1 0x2 64:70:02:1e:46:33 * mesh0

[chunyeow]

This issue was fixed. It seems that it is the problem of the ath9k_htc firmware issue and has submitted a patch on this. The offset of CCMP header is wrong for mesh frame to work.

[jcard0na]

chunyeow, can you provide a pointer to the firmware version or commit id so we can verify this fix?

[jasonabele]

He just sent it last night, looks like it is here:

https://github.com/qca/open-ath9k-htc-firmware/commit/5c5580bd6b3f970308844fe0d08857f43b7ae28f

thanks chunyeow

[chunyeow]

Yes, this patch is upstream and Adrian has merged it.