Yet another SPI SPWF04S problem

[Matti Sillanpaa]

Posted on June 14, 2017 at 12:07

Hi all.

I'm having trouble connecting to AP with SPI mode. I tried to same network with putty and USB-to-UART cable and it connected fine (I only did ping over the connection, so not much). However with SPI it connects and drops it right away and repeats it forever.

Initializing SPWF04SA Interface..

>> Configuration Failure no 2 <-----i nteresting, 'RAM cannot be mounted' <<WIND 7, status 0 10 <<WIND 1, status 0 170216-fd39c59-SPWF04S <<WIND 13, status 0 SPWF04SA <<WIND 65, status 0 1 <<WIND 0, status 0 <<WIND 3, status 0 20 <<WIND 32, status 3 >>AT <<OK >>AT <<OK >>AT <<WIND 49, status 2 0 <<OK >>AT <<OK >>AT <<OK <<WIND 32, status 3 wifi started and ready... >>AT <<corrupted OK packet!! <<OK End of Initialization.. >>connecting to AP... TPNY, xxxxxxxxxx, 2 >>AT <<corrupted OK packet!! <<OK >>AT <<OK >>AT <<OK >>AT <<OK >>AT <<OK >>AT <<OK <<WIND 32, status 3 <<WIND 21, status 4 <<WIND 35, status 4 00 <<WIND 19, status 7 98:DE:D0:EA:4C:62 <<WIND 25, status 7 TPNY <<WIND 41, status 7 2 <<WIND 21, status 4 <<WIND 35, status 4 00 <<WIND 21, status 4 <<WIND 35, status 4 00 <<WIND 19, status 7 98:DE:D0:EA:4C:62 (after this it loops back line <<WIND 25 status 7)

The RAM mount thing is a littlebit worrying.

Othervise it seems to connect-disconnect-connect forever.

My setup is STM32F469NI, 1Mhz (currently) SPI and X-Nucleo-IDW04A1 board.

#spwf04sa Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Matti Sillanpaa]

Posted on June 16, 2017 at 08:25

Hi Mridu.

It seemed to work. The I've tried to connect our network 3 times and each time it connected just fine. Thanks for that.

*****************

As separate note our socket connection opening still fails. Has the usage logic changed there? Compared to SPWF01SA? I see there's new websocket. Should I use that?

I get no WIND messages after connection attempt. Last WIND message was wifi connected:

<<WIND 24, status 10

The AT command seems legit:

AT+S.SOCKON=api.amazon.com,443,NULL,s

compared to spec:

AT+S.SOCKON=<hostname>,<port>,<NULL>,<kind><cr>

[Mridupawan Das]

Posted on June 16, 2017 at 10:58

you can check the doc: AN4963

: Security on SPWF04S module

at 

http://www.st.com/en/wireless-connectivity/spwf04sc.html

[Matti Sillanpaa]

Posted on June 16, 2017 at 09:10

Ok. So has this changed vs SPWF01? It worked just fine in this area.

If I need to do something with certificates, are there any instructions how to work with those.

[Matti Sillanpaa]

Posted on June 16, 2017 at 11:02

Ok, I'll check that. Thanks a lot for support.

Any plans on adding that anynomous mode to SPWF04?

[Matti Sillanpaa]

Posted on June 16, 2017 at 13:28

Hi again Mridu!

Ok, I'm trying to apply the stuff from the documentation to your driver code. I'm trying to use the:

WiFi_Status_t wifi_socket_client_security(uint8_t* tls_mode, uint8_t* ca_certificate, uint8_t* certificate, uint8_t* certificate_key, uint8_t* client_domain, uint32_t tls_epoch_time)

I got the CA cerficate from amazon. Also I've got the Subject key identifier. I've used python script to constuct byte header from the CA certificate.

Is it really so, that the client_domain parameter is the subject key identifier? Atleast the /*AT+S.TLSCERT=auth,<Peer CA Authority Key Id>*/ would match it. How should I use the function in this case? I'm calling it after the AP connection has been established and before the socket connection is attempted to be formed (I'm not waiting for any callback).

wifi_socket_client_security('o', &cert_data, NULL, NULL, key, 1497610496);

Where the 'o' is the one way authorization, cert_data is the uint8_t stucture containing the DER encoded binary X.509 (.CER), key is pointer to Subject key structure and the last one is EPOC time half an hour a go.

***********

The wifi_init calls the certificate clean.

/*AT+S.TLSCERT2=content,2 -> clean certificates*/

This means that after every boot the certificates need to be reloaded?

[Gerardo GALLUCCI]

Posted on June 16, 2017 at 14:00

Hi,

no plans for anonymous on 04.

Using a cipher with anonymous authentication means that no authentication of the server will be done inside the TLS handshake and thus the connection is open for 'man in the middle' attacks.

[Matti Sillanpaa]

Posted on June 16, 2017 at 14:57

Also a little worrysome discovery. The wifi_socket_client_security uses strlen and sprintf to handle the certificate file. However the certificate file contains lots of null-characters, so I don't think it works like it should. Unless of course this is intended behaviour, and only the start of file is valid data.

EDIT: even more worrying is that also the send function relys on strlen. Hopefully the socket write doesn't behave similarily as there also might be non-string content.

[Mridupawan Das]

Posted on June 19, 2017 at 07:45

Hi Matti,

it's not necessary to reload certificates each time you re-start(re-boot). You can remove the init tls clean command if you wish. Also while testing we have seen certificates mostly without any NULL character in between. And yes if there is NULL character in between the certificates then certainly using strlen will be an issue. We will modify usage of strlen on certificates. For the time being you can use any other means to measure the strlen.

regards,

Mridu

[Matti Sillanpaa]

Posted on June 19, 2017 at 09:08

What about the SPWF04 side? It doesn't rely on null termination?

EDIT: The spwf04WiFi->cmd_funcArgs has another rather large bug. It doesn't do any size checking and the WiFi_SPI_Packet buffer is only 128 bytes in size. Even if there was no null-characters in the certificate, the 1,5k size would mean that no certificate would be transferred completely.

Is there any release not or such that would list which features work in what mode (UART/SPI)?

[Mridupawan Das]

Posted on June 19, 2017 at 11:43

Null termination should not be a problem on the module. I will confirm this though.

The SPI_Packet buffer only contains the packet structure. The certificate will be in WiFi_AT_Cmd_Buff buffer and the data ptr will keep track of this and use this to write it to the module. (Check if (data && len > 0) condition). Typically 2k size of 

WiFi_AT_Cmd_Buff should be OK. You can play around with the buffer size as you wish.