cross compiling acx100 wifi kernel module

[smartsmurf]

From looking at your dmesg dump I can see that data packets seem OK, but ar de-justified by 20 bytes:

Code: Select all

4>acx: unknown EID 96 in mgmt frame at offset 89. IE: 60 6C DD 18 00 50 F2 02 01 01 84 00 03 A4 00 00
<4>27 A4 00 00 42 43 5E 00 62 32 2F 00 DD 09 00 03
<4>7F 01 01 00 00 FF 7F DD 0A 00 03 7F 04 01 00 20
<4>00 00 00 A0 00 E5 82 8C 00 0A 00 C4 60 01 00 7F
<4>01 01 00 00 FF 7F DD 0A 00 03 7F 04 01 00 20 00
<4>00 00 DD 0E 00 50 F2 04 10 4A 00 01 10 10 44 00
<4>01 02 F1 00 D7 82 DD 00 0A 00 14 61 01 00 

So, I modified some code in order to set the physical header length from 8 to 28 in the case of unknown radio 0x1B:

Code: Select all

	if ((adev->rx_config_1 & RX_CFG1_INCLUDE_PHY_HDR)
		|| (adev->firmware_numver >= 0x02000000)){
		if( IS_ACX111(adev) ){
			adev->phy_header_len = (adev->radio_type == RADIO_UNKNOWN_1B) ? 28 : 8;
		} else {
			adev->phy_header_len = 4;
		}
	} else {
		adev->phy_header_len = 0;
	}
	log(L_INIT, "setting phy_header_len to %04d\n", adev->phy_header_len );  

Modified driver is attached.

To show the "L_INIT" debug output (which might be important in your case), you need to add acx_debug=2 as driver parameter.

Good luck.

PS: just for clarification - the driver only supports WEP encryption. No WPA...

<< attachment removed >>

[smartsmurf]

Yes. But step by step

Indeed.
Next step is to get rid of that error:

Code: Select all

<4>issue_cmd(cmd:ACX1xx_CMD_INTERROGATE,buflen:24,type:0x0005)
<4>ctrl inpipe=0x80000380 outpipe=0x80000300
<4>sending USB control msg (out) (blocklen=8)
<4>wrote 8 bytes
<4>sending USB control msg (in) (acklen=28)
<4>acx: issue_cmd(): USB read error -75
<4>acx: issue_cmd(cmd:ACX1xx_CMD_INTERROGATE) FAILED 

New module is attached.

<<attachment removed>>

[smartsmurf]

This will be not easy. "104" is the error code representing ECONNRESET. This means your device reset itself (=disconnect/reconnect from USB) while in the process of joining which might be due to wrong firmware or improper initialization of the JOIN request. Reason for this behaviour is not obvious.
You might try "insmod acx.ko debug=0x80A" to enable some debug flags in order to see more details.

[smartsmurf]

Attached another module worth trying. Please use this time the following command line

Code: Select all

insmod acx.ko debug=0x90A

which will also show data packets. Thanks!

[smartsmurf]

I didn't find that "tx buffers full" message in your logs. Actually I believe there are responses. You can see

Code: Select all

using buf#3 free=7 len=30 
...
using buf#4 free=7 len=30 
...
using buf#5 free=7 len=30 
...
using buf#6 free=7 len=30 

And "free=7" means, that there are still 7 buffers available, so "adev->tx_free++" must be called at some point inbetween.

Currently I see another suspicios entry:

Code: Select all

<4>drivers/net/wireless/acx/common.c: 2958 rx: UNKNOWN time:2768306226 len:4294967268 signal:100 SNR:11 macstat:9F phystat:F0 phyrate:4 status:1
<4>rx: 802.11 buf[4294967268]: 
<4>drivers/net/wireless/acx/common.c: 2979 rx: NOT receiving packet (UNKNOWN): size too small (4294967268) 

Although not directly related to the AUTH issue, it might lead to overflow and corruption somehow...