cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Studio Wi-Fi Combo

AxLi_1746341
Honored Contributor

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?

0 Likes
33 Replies
AxLi_1746341
Honored Contributor

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.

0 Likes
GauravS_31
Moderator
Moderator

CYW4343W and CYW43438 support enterprise security. Please post the scan results containing LAB-ENT-TEST.

0 Likes
AxLi_1746341
Honored Contributor

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?

0 Likes
GauravS_31
Moderator
Moderator

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.

AxLi_1746341
Honored Contributor

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));

0 Likes
GauravS_31
Moderator
Moderator

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.

AxLi_1746341
Honored Contributor

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?

0 Likes
GauravS_31
Moderator
Moderator

Please share Wireshark logs for analysis.

0 Likes
AxLi_1746341
Honored Contributor

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.

0 Likes
AxLi_1746341
Honored Contributor

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

0 Likes
GauravS_31
Moderator
Moderator

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.

0 Likes
AxLi_1746341
Honored Contributor

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

0 Likes
AxLi_1746341
Honored Contributor

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.

0 Likes
GauravS_31
Moderator
Moderator

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

0 Likes
AxLi_1746341
Honored Contributor

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

0 Likes
AxLi_1746341
Honored Contributor

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.

0 Likes
AxLi_1746341
Honored Contributor

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

AxLi_1746341
Honored Contributor

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.

AxLi_1746341
Honored Contributor

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

0 Likes
GauravS_31
Moderator
Moderator

I reproduced this issue with FreeRTOS in my setup and raised a ticket on this.

GauravS_31
Moderator
Moderator

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.

0 Likes
AxLi_1746341
Honored Contributor

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.

0 Likes
AxLi_1746341
Honored Contributor

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?

0 Likes
GauravS_31
Moderator
Moderator

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.

0 Likes
AxLi_1746341
Honored Contributor

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

0 Likes
AxLi_1746341
Honored Contributor

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.)

0 Likes
AxLi_1746341
Honored Contributor

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?

0 Likes
GauravS_31
Moderator
Moderator

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.

AxLi_1746341
Honored Contributor

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.

0 Likes
AxLi_1746341
Honored Contributor

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.

0 Likes
AxLi_1746341
Honored Contributor

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.

0 Likes
user_3663311
New Contributor II

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.

0 Likes
AxLi_1746341
Honored Contributor

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.

0 Likes