RCM6600W. Issue connecting to a mixed mode AP when set to CCMP?

Rabbit
, , , ,
1

I have an AP which is broadcasting mixed TKIP/AES-CCMP, and I am having an issue connecting an RCM6600W to it. This table summarizes what I’m seeing.

----AP----::-RCM6600W-::-Can Connect
—TKIP—::–TKIP----::—Yes------
—CCMP—::–CCMP----::—Yes------
-CCMP/TKIP::–TKIP----::—Yes------
-CCMP/TKIP::–CCMP----::—No-------

It appears there was previously a fix regarding this:

https://github.com/digidotcom/DCRabbit_10/commit/8b736d61833b1bcbcca9a133e49244f9ce464dd9

Poking around that area in the code in a bit to see if I can find something related to what I’m seeing.

Fortunately TKIP works with mixed mode, so I can just swap back and forth between TKIP and CCMP when attempting to connect, but ideally I’d like to get this working without having to do that, as it means either more user configuration or introducing the chance of using TKIP when CCMP was available.

If this isn’t a known issue, I’ll make a minimal case to reproduce.

Edit: I am running the updated libraries from github.

Edit2: Was running the following in the background while posting this:

{
  int result = sock_init();
  while(1){
    result = ifup(IF_WIFI0);
    if(result == IFCTL_OK){
      printf("Success!

");
break;
}
else if(result == IFCTL_FAIL){
printf(“Troubleshooting!”);
break;
}
tcp_tick(NULL);
}
}
ip_print_ifs();

It died with a memory allocation error. :frowning:

Running tcp_tick(NULL) in a hard loop after connecting to see if this is only when repeatedly failing to connect.

Edit3: No issues running tcp_tick() in a loop after successfully connecting. Going to try a loop when the ssid is wrong; absence of a network being a realistic scenario.

Edit4: Day and a half running with no allocation errors. This would imply that the failure to connect with those specific settings and the allocation error may be related.

2

Can you share more of your test code, preferably via email (address on that GitHub commit). The commit should have resolved the issue, and I was successfully connecting with CCMP to a Linksys router running in mixed mode.

3

Sure. Should be able to do so later tonight. I’m testing with an Engenius ECB600. Possible it’s either myself or the router.

4

It’s necessary to configure the stack for both TKIP and CCMP encryption, if you want to use CCMP on a mixed-mode access point.

#define IFC_WIFI_ENCRYPTION (IFPARAM_WIFI_ENCR_TKIP | IFPARAM_WIFI_ENCR_CCMP)

I believe this is because the groupwise key uses TKIP on a mixed-mode network, and the pairwise key is CCMP. This is because broadcast messages are relayed by the AP as-is and all devices joined to the network need to decrypt them. Unicast messages are sent to the AP with the pairwise CCMP key, and then re-encrypted (IIRC) using the pairwise key of the target device.

1 Like
5

Finally had a chance to test this out and it did work!

We’re giving end users the option to manually set pairwise encryption, and needed to follow through with that setting as well:

https://gist.github.com/caseymarquis/689fa4632c8fb23f4eaf251fbfc1d46f

The above doesn’t allow for an option to only connect to either CCMP or TKIP, but we were more concerned with ease of connection than preventing that.

6

Interestingly, I found this comment in tcp_config.lib when updating documentation related to mixed mode:


			Use of IFC_WIFI_ENCRYPTION with either TKIP or CCMP:
			----------------------------------------------------
			When it is desired to associate with an AP which supports either WPA
			or WPA-2 (i.e. TKIP or CCMP), it is necessary to explicitly allow
			both forms of encryption i.e.
				#define IFC_WIFI_ENCRYPTION  \
     				IFPARAM_WIFI_ENCR_CCMP | IFPARAM_WIFI_ENCR_TKIP

			If you don't allow TKIP, then it is not possible to agree on an
			acceptable group transient key.  In summary, use the above bitwise
			OR of the two encryption settings when defining the encryption suite.
			This will work also with APs set to just use CCMP.  If an AP is set
			to just TKIP, then don't use IFPARAM_WIFI_ENCR_CCMP otherwise it will
			not associate, since it would not be correct to allow association
			with a theoretically weaker form of protection (TKIP) when a stronger
			protection (CCMP) was specified.

So, I think that you might need to update that gist to add TKIP if CCMP is set, but leave it as just TKIP if CCMP isn’t set.

Digi probably should have designed the stack so that use of CCMP implied/enabled TKIP as well for mixed mode networks. I would hesitate to make a change like that now, for fear of breaking existing user code.

7

re-posting as a new topic since this one is outdated