- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Test using SDK-5.1.0.
I tried below command but it fails.
> join_ent LAB-ENT-TEST peap testuser testpass wpa2␍␊
besl_supplicant_init OK␍␊
besl_supplicant_start OK␍␊
Joining : LAB-ENT-TEST␍␊
Supplicant received link event␍␊
Supplicant completed successfully␍␊
Failed to join : LAB-ENT-TEST␍␊
Joining : LAB-ENT-TEST␍␊
Failed to join : LAB-ENT-TEST␍␊
Joining : LAB-ENT-TEST␍␊
Failed to join : LAB-ENT-TEST␍␊
Join result 1007: ␍␊
wifi_join fails␍␊
Can someone confirm if BCM4343W and BCM43438 support enterprise security or not?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I got confused while reading the code:
Looking at the implementation:
join_ent()
....
besl_supplicant_start() success then...
wifi_join()
wiced_network_up()
wiced_join_ap()
wiced_join_ap_specific()
The part reading ap->security_key_length, ap->security_key from DCT (in wiced_join_ap()) is very strange for
enterprise security because there is no valid security_key_length/security_key setting in DCT at all.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
CYW4343W and CYW43438 support enterprise security. Please post the scan results containing LAB-ENT-TEST.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
grsr wrote:
CYW4343W and CYW43438 support enterprise security. Please post the scan results containing LAB-ENT-TEST.
Good to know that. I will post scan result after I back to office.
Can you explain the question I mentioned in this thread about the join_ent() process?
It looks does not make sense to me that it calls wiced_join_ap() which read security_key/key_length from DCT and pass it to wiced_join_ap_specific(). comments?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The function wifi_join() is common to both commands "join" and "join_ent". In case of "join_ent", the function is called as wifi_join( ssid, strlen(ssid), auth_type, NULL, 0, NULL, NULL, NULL ) which means that key points to NULL and key_length=0. Within wifi_join(), the DCT is modified as per the information specified in the parameters of function wifi_join() before calling wiced_network_up(). Which means that security_key=NULL and key_length=0 should be read from DCT during wiced_join_ap() if I interpreted correctly. Now coming to your question, I believe wifi_join() (and consequently the code section in wiced_join_ap()) has been used in "join" and "join_ent" to re-use the code to connect to the AP. For enterprise security, NULL and 0 will be used for those parameters. For non-enterprise security, the appropriate parameters in "join" command will be used.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
grsr wrote:
The function wifi_join() is common to both commands "join" and "join_ent". In case of "join_ent", the function is called as wifi_join( ssid, strlen(ssid), auth_type, NULL, 0, NULL, NULL, NULL ) which means that key points to NULL and key_length=0. Within wifi_join(), the DCT is modified as per the information specified in the parameters of function wifi_join() before calling wiced_network_up(). Which means that security_key=NULL and key_length=0 should be read from DCT during wiced_join_ap() if I interpreted correctly. Now coming to your question, I believe wifi_join() (and consequently the code section in wiced_join_ap()) has been used in "join" and "join_ent" to re-use the code to connect to the AP. For enterprise security, NULL and 0 will be used for those parameters. For non-enterprise security, the appropriate parameters in "join" command will be used.
Your reading seems wrong.
join_ent()
wifi_join( ssid, strlen(ssid), auth_type, NULL, 0, NULL, NULL, NULL )
for enterprise AP, wifi_join does not save credentials. it only saves SSID.
The key and key_length parameters are not used at all in wifi_join() for enterprise AP case.
Then wiced_network_up() -> wiced_join_ap() calls
result = wiced_join_ap_specific( &ap->details, ap->security_key_length, ap->security_key );
the ap->security_key_length is not 0 and ap->security_key is never null because it's address of an array.
I know it because I print it while testing, it shows the default CLIENT_AP_PASSPHRASE.
You can add below in the begin of wiced_join_ap_specific() to verify:
WPRINT_WICED_INFO(("Key %u: %s\n", (unsigned) security_key_length, security_key));
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So the security key and key length are getting saved in DCT only for non-enterprise AP which is why the default values were read from DCT.
if ( ( auth_type & ENTERPRISE_ENABLED ) == 0 )
{
/* Save credentials for non-enterprise AP */
memcpy((char*)dct_wifi_config->stored_ap_list[0].security_key, (char*)key, MAX_PASSPHRASE_LEN);
dct_wifi_config->stored_ap_list[0].security_key_length = key_length;
}
This means that in enterprise security, wiced_join_ap() calls wiced_join_ap_specific( &ap->details, ap->security_key_length, ap->security_key ) But if you keep going further into wwd_wifi_prepare_join(), security_key and security_key_length are not used for enterprise security if you check case WICED_SECURITY_WPA_AES_ENT, only a break statement is written.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Below is my testing AP info:
Cell 12 - Address: BA:55:10:CF:AA:D0
Channel:8
Frequency:2.447 GHz (Channel 😎
Quality=70/70 Signal level=-23 dBm
Encryption key:on
ESSID:"LAB-ENT-TEST"
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
24 Mb/s; 36 Mb/s; 54 Mb/s
Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 48 Mb/s
Mode:Master
Extra:tsf=00000000bddd945a
Extra: Last beacon: 3548ms ago
IE: Unknown: 000C4C41422D575053322D454E54
IE: Unknown: 010882840B162430486C
IE: Unknown: 030108
IE: Unknown: 2A0100
IE: Unknown: 2F0100
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : CCMP
Pairwise Ciphers (1) : CCMP
Authentication Suites (1) : 802.1x
IE: Unknown: 32040C121860
IE: Unknown: 2D1AFC191BFFFF000000000000000000000000000000000000000000
IE: Unknown: 3D1608080000000000000000000000000000000000000000
IE: Unknown: 4A0E14000A002C01C800140005001900
IE: Unknown: 7F0101
IE: Unknown: DD090010180200F02C0000
IE: Unknown: DD180050F2020101000003A4000027A4000042435E0062322F00
In wiced_join_events_handler, I got below events:
WLC_E_AUTH (3)
WLC_E_LINK (16)
WLC_E_SET_SSID (0)
In wwd_wifi_check_join_status(), my code run into below case:
case JOIN_AUTHENTICATED | JOIN_LINK_READY | JOIN_SSID_SET :
return WWD_NOT_KEYED;
That is the reason it fails with 1007 (WWD_NOT_KEYED).
So wwd_wifi_is_ready_to_transceive( (wwd_interface_t) event_header->interface ) fails.
Compare WWD_NOT_KEYED and WWD_SUCCESS, it looks like JOIN_SECURITY_COMPLETE is missed.
Any idea?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please share Wireshark logs for analysis.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have problem to capture the wireshark log to debug this, it seems does not
capture all packets.
But I use radsniff to get the debug log on freeRADIUS server.
Attached 2 log files:
log-wiced-err is the log using wiced device to join the AP.
log-iphone-ok is the log using iphone to join the AP.
From log-wiced-err, it never reach Access-Accept state and the join_ent returns 1007 error.
From log-iphone-ok, the end of log shows Access-Accept and the join success.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
grsr
Here is FreeRADIO debug log:
Connect using wiced device: (join AP failure)
Found Auth-Type = EAP
# Executing group from file /etc/freeradius/sites-enabled/default
+group authenticate {
[eap] Request found, released from the list
[eap] EAP/peap
[eap] processing type peap
[peap] processing EAP-TLS
TLS Length 154
[peap] Length Included
[peap] eaptls_verify returned 11
[peap] (other): before/accept initialization
[peap] TLS_accept: before/accept initialization
[peap] <<< Unknown TLS version [length 0005]
[peap] <<< Unknown TLS version [length 0095]
[peap] TLS_accept: unknown state
[peap] >>> Unknown TLS version [length 0005]
[peap] >>> Unknown TLS version [length 0031]
[peap] TLS_accept: unknown state
[peap] >>> Unknown TLS version [length 0005]
[peap] >>> Unknown TLS version [length 02c0]
[peap] TLS_accept: unknown state
[peap] >>> Unknown TLS version [length 0005]
[peap] >>> Unknown TLS version [length 020f]
[peap] TLS_accept: unknown state
[peap] >>> Unknown TLS version [length 0005]
[peap] >>> Unknown TLS version [length 0004]
[peap] TLS_accept: unknown state
[peap] TLS_accept: unknown state
[peap] TLS_accept: unknown state
[peap] TLS_accept: Need to read more data: unknown state
[peap] TLS_accept: Need to read more data: unknown state
In SSL Handshake Phase
In SSL Accept mode
[peap] eaptls_process returned 13
connect using iphone: (join AP ok)
Found Auth-Type = EAP
# Executing group from file /etc/freeradius/sites-enabled/default
+group authenticate {
[eap] Request found, released from the list
[eap] EAP/peap
[eap] processing type peap
[peap] processing EAP-TLS
TLS Length 134
[peap] Length Included
[peap] eaptls_verify returned 11
[peap] <<< Unknown TLS version [length 0005]
[peap] <<< TLS 1.0 Handshake [length 0046], ClientKeyExchange
[peap] TLS_accept: unknown state
[peap] TLS_accept: unknown state
[peap] <<< Unknown TLS version [length 0005]
[peap] <<< TLS 1.0 ChangeCipherSpec [length 0001]
[peap] <<< Unknown TLS version [length 0005]
[peap] <<< TLS 1.0 Handshake [length 0010], Finished
[peap] TLS_accept: unknown state
[peap] >>> Unknown TLS version [length 0005]
[peap] >>> TLS 1.0 ChangeCipherSpec [length 0001]
[peap] TLS_accept: unknown state
[peap] >>> Unknown TLS version [length 0005]
[peap] >>> TLS 1.0 Handshake [length 0010], Finished
[peap] TLS_accept: unknown state
[peap] TLS_accept: unknown state
[peap] (other): SSL negotiation finished successfully
SSL Connection Established
[peap] eaptls_process returned 13
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When join_ent was tested with IAS radius server using PEAP and EAP-TLS, there was an association failure. A ticket had been raised on this issue and it is still being worked on. Basically this issue is seen because of mismatch in TLS versions of client and server. You need to check if this mismatch is seen in your test also. I can see >>> Unknown TLS version in the logs.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I still hit Join result 1007 while testing peap with join_ent on SDK-6.0.0.
The same error was also reported by particle community: (see the latest post)
https://community.particle.io/t/setting-up-photon-p1-on-wpa-enterprise-0-7-0/34167/25
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Test again on sdk-6.0.0 and found some difference with ThreadX v.s. FreeRTOS.
Both test fails, but fails at different place:
With ThreadX build:
> join_ent LAB-WPA2-ENT peap bob hello wpa2␍␊
Joining : LAB-WPA2-ENT␍␊
Failed to join : LAB-WPA2-ENT␍␊
Joining : LAB-WPA2-ENT␍␊
Failed to join : LAB-WPA2-ENT␍␊
Joining : LAB-WPA2-ENT␍␊
Failed to join : LAB-WPA2-ENT␍␊
Join result 1007: ␍␊
Error setting supplicant event handler 2␍␊
De-init supplicant␍␊
After join_ent
Attached log shows Access-Accept at the end of the log.
With FreeRTOS build:
> join_ent LAB-WPA2-ENT peap bob hello wpa2␍␊
Joining : LAB-WPA2-ENT␍␊
Failed to join : LAB-WPA2-ENT␍␊
Joining : LAB-WPA2-ENT
(Sometime stuck here, sometimes got Join result 1007)
Attached log shows Access-Challenge at the end of the log.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It appears that the TLS version used by your server is v1.0. SDK 6.0 has included compatibility for TLSv1.0 and TLSv1.1. Go to include/wiced_defaults.h and adjust the value of both WICED_TLS_MINOR_VERSION_MIN and WICED_TLS_MINOR_VERSION_MAX as per the appropriate TLS version. The TLS version is set in \mbedtls_open\include\mbedtls\config.h as shown below:
#if (WICED_TLS_MINOR_VERSION_MIN == 0)
#define MBEDTLS_SSL_PROTO_TLS1 /* TLSv1_0 */
#endif
#if ( ((WICED_TLS_MINOR_VERSION_MIN <= 1) && (WICED_TLS_MINOR_VERSION_MAX >= 1)) )
#define MBEDTLS_SSL_PROTO_TLS1_1 /* TLSv1_1 */
#endif
#if ( ((WICED_TLS_MINOR_VERSION_MIN <= 2) && (WICED_TLS_MINOR_VERSION_MAX >= 2)) )
#define MBEDTLS_SSL_PROTO_TLS1_2 /* TLSv1_2 */
#endif
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
grsr wrote:
It appears that the TLS version used by your server is v1.0. SDK 6.0 has included compatibility for TLSv1.0 and TLSv1.1. Go to include/wiced_defaults.h and adjust the value of both WICED_TLS_MINOR_VERSION_MIN and WICED_TLS_MINOR_VERSION_MAX as per the appropriate TLS version. The TLS version is set in
In my previous test, I already set below setting in include/wiced_defaults.h:
#define WICED_TLS_MINOR_VERSION_MIN (0)
#define WICED_TLS_MINOR_VERSION_MAX (2)
I also tried below settings, all fails:
WICED_TLS_MINOR_VERSION_MIN=0 && WICED_TLS_MINOR_VERSION_MAX=0
WICED_TLS_MINOR_VERSION_MIN=1 && WICED_TLS_MINOR_VERSION_MAX=1
WICED_TLS_MINOR_VERSION_MIN=2 && WICED_TLS_MINOR_VERSION_MAX=2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi grsr
Correct my previous post.
On ThreadX build:
It works with WICED_TLS_MINOR_VERSION_MIN=0 && WICED_TLS_MINOR_VERSION_MAX=0.
On FreeRTOS build:
It fails with WICED_TLS_MINOR_VERSION_MIN=0 && WICED_TLS_MINOR_VERSION_MAX=0.
However, we are using FreeRTOS build so this is still a problem.
Can you check if FreeRTOS build works for you?
Besides, I though WICED_TLS_MINOR_VERSION_MIN=0 && WICED_TLS_MINOR_VERSION_MAX=2
should work but it does not work. We cannot assume the customer's server is a
fixed TLS version.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
grsr
To make it clear: ( I tried with more combinations)
On ThreadX build:
WICED_TLS_MINOR_VERSION_MIN=0 && WICED_TLS_MINOR_VERSION_MAX=0 works
WICED_TLS_MINOR_VERSION_MIN=0 && WICED_TLS_MINOR_VERSION_MAX=1 works
WICED_TLS_MINOR_VERSION_MIN=0 && WICED_TLS_MINOR_VERSION_MAX=2 fails
On FreeRTOS build
WICED_TLS_MINOR_VERSION_MIN=0 && WICED_TLS_MINOR_VERSION_MAX=0/1/2 all fails
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
grsr
The first error in FreeRTOS build is because:
eap_ssl_receive_packet() return timeout.
Maybe someone from cypress can take a look at this issue.
Note, increase timeout value does not help.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
grsr
Debugging for a while for FreeRTOS build and I give up now.
I think it might be something wrong in your binary library for FreeRTOS build.
The SDK changelog said the enterprise security was tested on SDK-5.0.
I'm so surprised that it actually does not work even in SDK-6.0.
Also note, to have better coverage of TLS support,
I think the default WICED_TLS_MINOR_VERSION_MIN/MAX setting should be
WICED_TLS_MINOR_VERSION_MIN=0
WICED_TLS_MINOR_VERSION_MAX=2
rahter than
WICED_TLS_MINOR_VERSION_MIN=2
WICED_TLS_MINOR_VERSION_MAX=2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I reproduced this issue with FreeRTOS in my setup and raised a ticket on this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It took time because I had to spend time to bring up the setup (on my own). Once I was able to reproduce, I reported the issue. Sorry but issue is not resolved, so it will still exist in 6.1.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Your SDK supports PEAP, then your team should have no problem to setup the test at all.
If you have problem to setup the test, I believe you should be able to find someone to help testing it.
ps.
I do appreciate your help.
It's seems the problem is in the *process* of handling user's reported issues.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
grsr wrote:
I reproduced this issue with FreeRTOS in my setup and raised a ticket on this.
My test with PEAPv0 shows it still does not work.
So does it work for you with sdk-6.2?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I tested PEAP and EAP-TTLS with Freeradius 3.0.16 and openssl version 1.1.0h in WICED SDK 6.2. Unfortunately both still fail with FreeRTOS for all TLS versions. I will send feedback internally to the software development team.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
grsr wrote:
I tested PEAP and EAP-TTLS with Freeradius 3.0.16 and openssl version 1.1.0h in WICED SDK 6.2. Unfortunately both still fail with FreeRTOS for all TLS versions. I will send feedback internally to the software development team.
grsr
Can you confirm if next sdk release will fix this issue or not?
I just found I reported this issue in August of last year, which means I wait for almost 1 year for the fix but still not sure about the status.
mifo
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi grsr
Any chance to provide the fix for testing?
So we can make sure it work in next official release.
(It's really painful if find issues *after* release as it means need to wait quite long time for yet another release.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
axel.lin_1746341 wrote:
Hi grsr
Besides, I though WICED_TLS_MINOR_VERSION_MIN=0 && WICED_TLS_MINOR_VERSION_MAX=2
should work but it does not work. We cannot assume the customer's server is a
fixed TLS version.
grsr
I found sdk-6.1 still set default to
WICED_TLS_MINOR_VERSION_MIN=2 && WICED_TLS_MINOR_VERSION_MAX=2
Why not set default to
WICED_TLS_MINOR_VERSION_MIN=0 && WICED_TLS_MINOR_VERSION_MAX=2
for better covering of testing? (Whic was the default setting before switching to mbedtls)
Any comment?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Our default recommendation is to use TLSv1.2 as it provides the best security. With the current mbedTLS, source is available and the user can configure their min and max TLS version using wiced_defaults.h.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
grsr wrote:
Our default recommendation is to use TLSv1.2 as it provides the best security. With the current mbedTLS, source is available and the user can configure their min and max TLS version using wiced_defaults.h.
My point is to get better coverity of testing.
You will have to make it work for all cases TLSv1.0, TLSv1.1, TLSv1.2 any way.
In additional, when the wiced device is a client, your users usually
have to set WICED_TLS_MINOR_VERSION_MIN=0 && WICED_TLS_MINOR_VERSION_MAX=2
because they are not sure the supported TLS version on customer's server.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I just hope you can make sure the enterprise security can work in upcoming release for FreeRTOS build.
PEAPv0 and EAP-TTLS don't work with sdk-6.1 for FreeRTOS build.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
grsr wrote:
Our default recommendation is to use TLSv1.2 as it provides the best security. With the current mbedTLS, source is available and the user can configure their min and max TLS version using wiced_defaults.h.
It's strange the sdk-6.2 add comments to tell people don't change TLS min/max version setting:
/* Note: Please don't try to change TLS MINOR VERSION MIN & MAX values,
* as few wiced prebuilts are compiled using below values changing the values can cause issues
* */
But it was fine to change MIN/MAX values in older sdks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Axel have you tested enterprise with wiced-sdk 6.2.1 release version? Is it working for you?
I'm getting same error (1007) after trying to join to EAP-PEAP network with FreeRTOS lwip, wiced-sdk 6.2.1.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
antanas_3663311 wrote:
Axel have you tested enterprise with wiced-sdk 6.2.1 release version? Is it working for you?
I'm getting same error (1007) after trying to join to EAP-PEAP network with FreeRTOS lwip, wiced-sdk 6.2.1.
It does not work with sdk-6.2.1. I'm waiting new release for the fix.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Alex, do you know if the issue still remains with later wiced sdks?
Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If security type is Enterprise, we have to clear the security key i think.