LAUNCHXL-CC3235S: Connection request mainly gets rejected

Hi,

You should use network sniffer (Wireshark, tcpdump) at your AP to determine what is going on at your case. Without knowledge what is going on at your network is hard to say.

Jan

Yes...subsequent to my post i downloaded wireshark.

Interestingly i notice that the launchpad sends a few packets to 224.0.0.251 - any idea who/what that is?

However, it does not seem to send ANY tcp packets to my listening program...its possible that given my very limited knowledge of wireshark i may be setting the wrong capture parameters...

Hi,

Hard to say what do you see at your Wireshark log (packets 224.0.0.251). It may to be multicast mDNS packets.

Without knowledge what do you captured I am not able answer your question. What is exact place were was Wireshark running? It is your computer where is running your TCP server (your server application written at C#) or did you captured directly from AP or gateway?

Jan

Hi Jan

Thanks for staying with me on this....subsequently to my last post i read the relevant section about capturing..
I now am able to capture the traffic at the server end (now that i installed wireshark on that machine!!).
All is perfectly ok once the server gets the tcp packets from the CC3235.
The problem appears to be that sl_Connect() is not transmitting the TCP connection request packets - yet it returns error -111 (SL_ERROR_BSD_ECONNREFUSED) after a while (i mention 'a while' as i call sl_connect() every 10mS to see if it has connected). 

After some experimentation i have noticed that:
If i call sl_WlanConnect() and then call Sl_Connect() i find that on the SECOND Sl_Connect() i suddenly see the TCP packets arriving at the server!!

Why only on the SECOND call??? why not on the FIRST?

I would like to try and capture the wifi packets (to check whether my network is messing with me) but am UNSURE how to do that at this stage...
my setup is:
the CC3235 transmits to a local hub which then forwards (i assume) the packets to the router which then forwards them back to the hub which then forwards them via cable to the server PC (& vice versa). The router is the DHCP server.

moshe

Hi moshe,

There is not a technical reason to be mandatory call sl_Connect() two times for successfully TCP connection. It looks that you have some implementation  issue inside your code. Do you have properly implement state machine for your WLAN connection? That means after you call sl_WlanConnect(), you need to wait for connection event SimpleLinkWlanEventHandler -> SL_WLAN_EVENT_CONNECT and after that you need to wait for obtaining IP address via asynchronous event SimpleLinkNetAppEventHandler -> SL_NETAPP_EVENT_IPV4_ACQUIRED. When sl_WlanConnect() API returns success it does not mean you are connected into WLAN, it means connection process started.

• For capturing WiFi packets from the air you will need to have compatible WiFi card (WiFi dongle). Nice list you will find here.
• I am sorry but I did not understand your network setup. I am not sure what do you mean by word "local hub". Word hub in networking terminology means something different (similar device like a network switch but it works only at 1st layer). There is no reason to goes your packets via router, unless you are using different VLANs.

Jan

Hi Jan

Yes...based on what you wrote i think i'm not waiting around long enough (currently 10s) for the ipv4 acquired event to happen (i do have a separate task running for those call back events)) & so believe an error has occurred ...i was using a semaphore between the tasks so i dont know why it should fail...but anyway i'll now use semaphores () & an event based loop (with a timeout check) instead.

i downloaded acrylic wifi sniffer which told me my laptops dont have compatible wifi modules - so thank you for that list (usb wifi module ordered!).

My network consists of a wan router thats connected to incoming fibre. I then have a few older routers connected by wire to the main router. These act as local access points for both wired (they all have 4 10baseT ports) & wireless connections....does that make it any clearer?

I'll update you once i rework my wl_connect code.

moshe

Hi,

OK, just make to sure that you old APs does not have enabled DHCP server.

I personally use for WiFi debugging an old TP-Link router/AP from the "dumpster" with uploaded OpenWRT.

Jan

Hi...the saga continues..

The USB WiFi adapter finally arrived after spending many days milling around the aramex depot for unknown reasons..
its the TP-Link Archer T9UH with a RTL8814AU chipset.
This adapter is supposed to have network monitoring capability but it appears only under a Mac but not windows, & even under the mac it didn't capture IP packets only network management ones .
With the acrylic sniffer (& npcap replacing pwincap) i did manage to monitor network packets, but again not IP packets only management packets.
That is rather annoying & i'm not sure if there is another task i need to perform to get it to monitor the data packets.

Nonetheless, i decided to sniff the packets that arrived at the PC server via the ethernet connection. Now doing that, i could see that the 1st TCP connection request was not received at all but the 2nd request was received. 
HOWEVER, if i first disconnected the tcp connection at the launchpad i saw the FIN packet, but when i then reconnected the connection (SYN) packet never arrived, but on the 2nd attempt i got SYN, ACK, RST all from the launchpad & on the PC program i saw the 2 connection requests....

So is the problem somewhere in the network or somewhere in the launchpad?

Moshe

Hi Moshe,

It is really hard to say without deeper debugging of your infrastructure and your code. This are thing which nobody than you can solve.

Maybe FIN ACK packets are lost from some reasons inside your infrastructure, who knows... Maybe you can try to use LINGER socket option before closing socket, like this:

SlSocklinger_t linger;
linger.l_onoff = 1;
linger.l_linger = 5;

status = sl_SetSockOpt(sid, SL_SOL_SOCKET, SL_SO_LINGER, &linger, sizeof(linger));

Jan

Hi Jan

Since my previous post, i was able to sort out the issues around sniffing wireless data packets to & from the local wireless AP so could now see what was transmitted & received at the CC3235.

Deeper delving with Wireshark & the debugger revealed the following....if i simply close the TCP connection to the server & reopen it, i connect every time. So that aspect is not an issue.

BUT...if i close the tcp connection to the server, and THEN i close the wifi connection to the AP, and then i request a connect to the AP, and then i try to start  the tcp connection to the server.. it is THEN that i notice the CC3235 does NOT send the 1st request for the TCP reconnection but sends BOTH requests when i try the 2nd time.

As a separate issue (or maybe its related), I also notice in the debugger that the disconnection event from the AP (when my code initiate the disconnect) is not returned in SimpleLinkWlanEventHandler....is that to be expected?

I'll try the LINGER option to see if it has any effect.

Moshe

Hi Moshe,

I don't see any reason for behaviour why you not see SimpleLinkWlanEventHandler (SL_WLAN_EVENT_DISCONNECT) event when you are disconnected from the WLAN. What connection policy do you use? Do you use connection profiles or do you use manual connection via sl_WlanConnect() API? What SDK version do you use? What ServicePack do you have uploaded inside device (you should have version from particular SDK)?

I think it is now time to capture NWP log from the device (see SWRU455 chapter 20). Because I don't have available tool for analysing NWP log, you will need to wait for answer from TI side.

Jan

Hi Jan

I use sl_WlanConnect().and SDK 5.30
i'll capture the relevent info into a log & rope TI into the issue of needing 2 calls to establish a TCP connection under specific conditions.

A side issue:
When the TCP socket is closed by the remote end i dont get a notification in SimpleLinkSockEventHandler()...in fact i dont see a #define in errors.h for the event like "SOCKET_DISCONNECTED".
Is one expected to check the socket (in between transmissions) by issuing pings to the remote connection??

Moshe

Hi Moshe,

Handler SimpleLinkSockEventHandler() is not called when is closed normal TCP socket. It is called in case sokcet is not able send data (SL_SOCKET_TX_FAILED_EVENT) or issue with SSL socket (SL_SOCKET_ASYNC_EVENT -> SL_SSL_NOTIFICATION_CONNECTED_SECURED).

Sorry I don't understand your comment about checking TCP socket by ping (ICMP and TCP are two different protocols).

btw ... do you use ServicePack from SDK 5.30?

Jan

Hi Jan

I hadn't loaded the service pack.
I tried now by following the directions in the readme for the servicepack but uniflash returned a data verification error when i tried to load either bin files so i'm obviously doing something wrong. Can you point me to a doc that gives step by step about what to load, & in what order & using what program?

The Error is Cortex_M4_0:FileLoader:Verification failed: Values at address 0x00000000 do not match. Please verify target memory and memory map...so (to me) the implication is that the 5.30 version of the servicepack is not the right version for my launchpad...so how would i check WHICH version of servicepack i need to install??

Re the pings....when the remote server terminates closes its TCP connection, the CC3235 does respond to the remote host with ACK to the remote FIN but my program doesn't get any feedback regarding this. Therefore the only way i would know the connection is no longer open is when i try & Tx and get a FAILED event in response. So to avoid the failed response, i could periodically send PINGs which would tell me if the server is still there (tho not if the server was necessarily still listening on a port nor for that matter if my TCP connection was open or not which i suppose is quite a silly exercise in retrospect!).
So my question really is "how to know when the remote TCP server has closed the TCP connection"?

Moshe

Hi Moshe,

Usage of CC32xx devices without loaded Service Pack is not a best idea because your device can be affected bugs and security treats. Description how to use Uniflash you will find here or here. Error message means that you are using Uniflash by wrong way (you need to use serial interface not a JTAG).

Usage of TX for determining if TCP socket is closed is not a best approach. Common way is to use sl_Recv() and check return codes (depends on type sockets - blocking or non-blocking).

Jan

Hi Jan

I really appreciate your staying with me on my issues.

Actually i was trying to do it as per the readme in the servicepak folder. So that clearly didn't explain it very well.
And, I was always using the serial/usb interface of the launchpad. 
I followed your links & read a bit about using uniflash....i DID manage to load my program image together with the servicepack...so thanks for that.
I dont notice any issues with closing & reopening the socket so the servicepack resolved that one....but what i now notice is that 17secs AFTER i close the socket with sl_Close() i get a SimpleLinkSockEventHandler() callback with Event SL_SOCKET_TRIGGER_EVENT_SELECT..is that normal?? 

I presume that the servicepack will remain onboard (during multiple ccs downloads & debugging sessions) until such time as i perform another uniflash download?

i'll use your suggestion for determining socket state in future. 

As for the issue of not getting notified when i issue a sl_WlanDisconnect() - i noticed in wireshark that there was no response from the AP to confirm 'byebye' so presumably one can assume that as soon as one calls the function to disconnect, the radio will be disconnected!

moshe

Hi,

I don't have any idea why do you see event SL_SOCKET_TRIGGER_EVENT_SELECT at your case. I never seen this event.

Service Pack is saved inside SPI flash (sFlash). It will be there unless you reprogram sFlash (by the Uniflash software or Sysconfig image creator). When you upload content of RAM (CC3235S) or XIP flash (CC3235SF) using JTAG it doe affect content of sFlash. That means debugging from CCS does not affect this ServicePack.

What security type do you use (Open, WPA2, WPA3, WEP)? What I remember from the past, WEP works by slightly different way that other encryption types.

Jan

Hi Jan

I normally use WPA2-PSK for security, but i've made this local AP open so that i can see the data in the 802.11 packets. 
(i use a whitelist in the AP to ensure no one can eavesdrop onto the network).
But I will be moving back to the normal security shortly.

moshe

Hi Jan

I thought i would share my findings with you.

I traced the problem of not receiving the 1st socket connection request....
This ONLY happens with a network that has security (i use WPA2-PSK) & not an OPEN network which makes the whole issue even weirder.

I have a MSP430 that connects to a CC1352 (via its UART2) that then connects to the CC3235 (also via UART2) which then communicates with the WiFi network.

So...i issue a "Connect to WiFi" command from the MSP...that passes thru the CC1352 & on to the CC3235 which receives the data & a function in my program calls WLanConnect() & the CC3235 connects to the WiFi...no problem whatsoever (secure/open doesn't matter).
a few seconds later I issue a "Connect to IP addr" command which is received by the CC3235 (checked with scope) but TIRTOS "keeps" that command/data somewhere (but only if the network is secure) in itself & does not call my UART callback function.
i then issue a second "Connect to IP addr"  command which is also received by the CC3235, but now, TIRTOS calls my UART callback function with BOTH sets of data!

I tried calling a dummy UART2_Read() after the CC3235 connected on the WiFi network but that didnt help.

I must also mention that AFTER the 2nd call to connect to the WiFi network i had NO further problems connecting/disconnecting to the IP addr....however...if i disconnect then connect again to the WiFi, the problem repeats itself. 

I shall now take up this issue with TI.

Moshe

Hi Moshe,

This looks like some kind implementation issue at your UART handling inside CC3235. I think that your UART "Connect to WiFi" command have different structure than OPEN or WPA2-PSK is used, right? And maybe you have some issue with handling buffers for UART, thread synchronisation, wrong using of TI Drivers or it can be some weird bug inside driver for UART. Who knows...

CC3235 have separate co-processor called NWP for handling WiFi connectivity and sockets. This co-processor is separate from processor (Cortex-M4) for executing your code. That means type of WiFi security at this co-processor cannot affect function of your UART. It needs to be something else at application processor layer what is causing your issue.

btw... personally, I don't use TI Drivers for peripherals, because this wrapper layer is too limiting. I use driverlib and peripheral registers for some usage.

Jan