Rainad I've looked into the wireshark logs that you provided but with only one side of the conversation is not really easy to guess what's going on. Which side is sending the RST? What is causing it to send the RST? Does this happen right away in the TCP setup, or is it later in the session? If later, is there any reason that the station would abort the session in the middle of the data transfer? There are acceptable times for RST packets, however, if there are a large number of RST packets in a conversation, this is definitely something to troubleshoot. One station or the other stopped sending information or ACKs for some reason. RST packets are a sign that the TCP connections are half open. This cannot work by definition of the protocol. This is a half-open connection where only one side is involved in the TCP session. If a station involved in a TCP session notices that it is not receiving acknowledgements for anything it sends, the connection is now unsynchronized, and the station should send a reset. The Reset bit is designed to allow a station to abort the TCP connection with another station. Is it due to some incorrect packet sent by pic? One information that I found on the internet about it is: According to RFC 793, which specifies an Option in the Flags portion of the TCP header called Reset (or RST). And 30 sec later is another connection made that is successful. Looking again at the wireshark capture I realised that the DDNS_STATUS_CHECKIP_ERROR is because of the RST packet send by the server. Another one I get is in case SM_CHECKIP_SKT_OBTAINED, which is a timeout. I have attached the capture which shows that the packet with correct IP is captured/received but not processed by the ddns code. While doing wireshark capture for stack problem, I have also looked at receiving DDNS status DDNS_STATUS_CHECKIP_ERROR (case SM_CHECKIP_DISCONNECT).
I hope that this will help someone who has the same problem - unless I am wrong and the code should work as it is? My solution to my problem (unless I missed something) was to add in case SM_CHECKIP_FIND_ADDRESS, smDDNS++.
This means that on the next run of the task we end up in case SM_CHECKIP_DISCONNECT, lastKnownIP is equal to ipParsed and we go back to SM_DONE - no update required!!!. But when smDDNS is increased it is changed from SM_CHECKIP_FIND_ADDRESS to SM_CHECKIP_DISCONNECT and not to SM_IP_UPDATE_HOME. The comment in the code is - Need to perform an update - i.e. In case SM_CHECKIP_DISCONNECT:, if the ipParsed in not equal to lastKnownIP, the lastKnownIP is assigned new value and smDDNS is increased. From the case SM_CHECKIP_FIND_ADDRESS:, if the IP address is found, the code goes straight into case SM_CHECKIP_DISCONNECT:, without increasing smDDNS. Looking in the code, I saw that there is no chance to get to the case SM_IP_UPDATE_HOME, and have ddns updated. IP address has not changed and no update is forced If( (ipParsed.Val =lastKnownIP.Val) & (!bForceUpdate)) If(!TCPIP_Helper_StringToIPAddress((char*)vBuffer, &ipParsed)) Parse the IP address that was read, invalidating on failure TCPIP_TCP_ArrayGet(MySocket, vBuffer, wPos) Read and terminate that string as the IP address (preventing buffer overflows) WPos = TCPIP_TCP_ArrayFind(MySocket, (const uint8_t*)"", 7, 0, 0, false)
Search out the "" delimiter in the response If(!TCPIP_TCP_IsConnected(MySocket) || SYS_TMR_TickCountGet() - DDnsTimer > 6*SYS_TMR_TickCounterFrequencyGet()) but don't break because data may still be waiting. Check if remote node is still connected. And again, I have spent a couple of hours to figure out why it doesn't work - IP address has changed and I always had a status DDNS_STATUS_UNCHANGED, no update required (in ddns.c) Below is part of the code from ddns.c smDDNS++ The last thing to do was to get DDNS working. And after a couple of hours spent on porting it, surprise, surprise - MLA code works without any problems.
After a lot of struggle, and giving up on SD Card and USB Host drivers from Harmony - I spent a couple of days trying to get them working I have decided to port old MLA code for SD Card and USB to my Harmony project. An example of an app provided with Harmony, using Wolf SSL worked so there was a hope that I can get my project converted (re-done). I have tried adding Wolf SSL but I couldn't get it to work so I decided to try MPLAB X and Harmony. , I have started recently with Harmony and MPLAB X because my project that worked for a couple of years compiled with MPLAB 8 and using TCPIP stack v5xx stopped working - Goggle stopped accepting SSL connection.