UBLOX_EVK_ODIN_W2 - connect fails unless security is specified

[JanneKiiskila]

Note: This is just a template, so feel free to use/remove the unnecessary things

Description

• Type: Bug
• Priority: Major

---

Bug

Target
UBLOX_EVK_ODIN_W2

Toolchain:
GCC_ARM|ARM|IAR

Toolchain version:

mbed-cli version:
(mbed --version)
0.9.10

meed-os sha:
(git log -n1 --oneline)

ce9d252 (HEAD -> mbed-os-5.3, origin/master, origin/HEAD) Merge pull request #3409 from jeromecoutant/PR_ST_L1_ASSERT

DAPLink version:

Expected behavior

WiFi should be able to connect with wifi.connect(ssid, passwd);

Actual behavior

It doesn't connect, unless you specify the security mode as well.

Steps to reproduce

Build the mbed-os-example-client and try that.

---

#3 – seems ESP8266 and ODIN behave differently on the connect. The WiFi example has DIFFERENT connect parameters than mbed client.
Client has this.

#if MBED_CONF_APP_NETWORK_INTERFACE == WIFI
connect_success = wifi.connect(MBED_CONF_APP_WIFI_SSID, MBED_CONF_APP_WIFI_PASSWORD);
network_interface = &wifi;
while, Wifi example has this:

output.printf("\r\nConnecting...\r\n");
 int ret = wifi.connect(MBED_CONF_APP_WIFI_SSID, MBED_CONF_APP_WIFI_PASSWORD, NSAPI_SECURITY_WPA_WPA2);

I think the WiFi driver should be able to negotiate the security mode by itself.

[JanneKiiskila]

@MarceloSalazar - I think this issue explains your OOB testing finding.

[bulislaw]

@andreaslarssonublox Could you have a look at that from the Odin side please.

[bulislaw]

It's not a bug, that's the way WiFi API is defined -> the security parameter defaults to no encryption, ESP is quite dummy (or smart depending on direction you look at it) and doesn't care about the encryption it'll try in any case. But hopefully we can make Odin behave similarly.

[geky]

This does point out that the esp8266 does not do what the default parameter implies. Currently WiFiInterface::connect defaults to NSAPI_SECURITY_NONE, but the esp8266 automatically determines the security type.

We could change the default parameter to something like NSAPI_SECURITY_AUTO, or we could just remove the default parameter to avoid the confusion. Thoughts?

[JanneKiiskila]

My vote is on the auto, that would make most sense. If we fix it to something, then apps will have try to do some "try this and if that fails, try that".. complicated, fussy and not developer friendly.

[bulislaw]

Let's wait for @andreaslarssonublox to hear if it's feasible to implement auto.

[andreaslarssonublox]

I think it's possible to use the auto security mode for Open, WEP and WPA/WPA2. The drawback is that we need to do a scan before to retrieve the security mode of the access point. Another drawback might be that the application is not aware of the chosen security mode if NSAPI_SECURITY_AUTO is used.
It will also not work when we add enterprise security later on since it requires certificates and some other stuff. Most likely we will need another connect API for that or modify the existing one.

We can try to align the behavior of ODIN with ESP8266 and change the default to NSAPI_SECURITY_AUTO in the next release of the binary(after 5.3.0 I guess).

[JanneKiiskila]

Which one is faster - scan the network for it to tell what the security is, OR just try looping around the different security modes one by one and then return error if all of them fails? Enterprise is a different issue, agree on that.

[tommikas]

I've just been playing around with this. It seems that not only it doesn't connect, the connect call never returns. I'd expect it to timeout and return some error code.

This seems to happen if any of the parameters SSID, pass phrase, or security is wrong for the ap being connected to.

[JanneKiiskila]

Sounds like we would need a test case for something like that. That's definitely a bug.

[bulislaw]

Yes, we should add some 'negative' tests as well. I'll take an action to add some in the near future.

[andreaslarssonublox]

@tommikas
The default behavior is that the driver will wait infinitely to connect to the AP. You should be able to set a finite timeout with set_timeout in OdinWiFiInterface.h.

[JanneKiiskila]

@andreaslarssonublox - we can't have a thinking in place that each network stack works the same way. The life of clients/apps gets way too complicated, if we cant' rely on the network stacks working the same way.