-
Notifications
You must be signed in to change notification settings - Fork 128
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Testing with NTP UDP code, fails #80
Comments
Seeing the same issue on a Arduino WIFI101 and Arduino Zero. Slightly different sketch. Sketch assumes an Adafruit 4-digit 7-segment I2C display, but it's not necessary if you comment the serial output back in (different issue: serial writes block the sketch when my MBP goes to sleep). It may take 90 minutes or so for the problem to occur. I have also observed one instance in which it spontaneously recovered overnight. That is, failing for maybe 12 hours, then mysteriously recovering. The sketch uses us.pool.ntp.org, but I have also used it with my own local NTP server, and the problem still occurs. Can't think of anything to try to narrow it down. Seems like a firmware issue.
|
@trlafleur can you please try again with removing the following from
You already have the |
I had already fixed the main loop... thanks... In running my test program with DEBUG Print enable, I get this message when the call's stop working. From this point on, its just stops working.
|
@trlafleur after how long did this occur? Also, could you please let me know what firmware your board is running? See CheckWifi101FirmwareVersion.ino Could use please add the following to the switch statement in the case SOCKET_MSG_SENDTO:
{
sint16 *sentBytes = (sint16 *)pvMsg;
printf("SOCKET_MSG_SENDTO: sock = %d, sent bytes = %d\n", sock, *sentBytes);
}
break; and also remove the following from setsockopt(_socket, SOL_SOCKET, SO_SET_UDP_SEND_CALLBACK, &u32EnableCallbacks, 0); I'm looking into some changes to the underlying UDP socket, will push another branch later. However, I haven't been able to reproduce your issue yet, but am seeing the RSSI set to 0 (like #86) when there is a received UDP packet. |
One more thing for you to try later is changing the following in the sketch:
to:
|
<3 min On Wed, Aug 17, 2016 at 12:30 PM, Sandeep Mistry [email protected]
~~ _/) ~~~~ _/) ~~~~ _/) ~~~~ _/) ~~ Tom Lafleur |
firmware: (APP)(INFO)Firmware ver : 19.4.4 (APP)(INFO)Min driver ver : 19.3.0 (APP)(INFO)Curr driver ver: 19.3.0 IDE 1.6.10 |
Same issue with while ()
|
Made your two driver changes from above... Still stops working. Ran for about 5mins
|
Something to note: Just adding a call to WiFi.RSSI() to my RXpacket function, increases packet receive times from ~40ms to over 1000ms... That's a lot of overhead just to get the RSSI!!!!!
|
@trlafleur there's a new branch for you to try out: https://github.com/sandeepmistry/WiFi101/tree/samd-debug-enable_socket-buffer-experiments I think the RSSI call is timing out because a flag is incorrect set, the branch above should address this. |
Its been running now for 10min... RSSI is working, no delay...
|
@trlafleur cool, let's leave it running, and maybe also try the original version without RSSI? I can submit a pull request with just sandeepmistry@c2be9f6 for further testing, once we think things are stable. |
I'm at 1 hr now, still working... On Thu, Aug 18, 2016 at 11:16 AM, Sandeep Mistry [email protected]
~~ _/) ~~~~ _/) ~~~~ _/) ~~~~ _/) ~~ Tom Lafleur |
Spoke too soon... Interesting that sent bytes is -1
|
I've had it running overnight with 5-minute NTP updates, and it's still going... |
I have three units working, one has been running for two days, other two, anywhere from 2 min to all night, when I restarted the two day unit, it failed in 20 min... ~~ _/) ~~~~ _/) ~~~~ _/) ~~~~ _/) ~~ Tom Lafleur
|
Failing again:
|
@trlafleur @driverblock I think we're onto something with the However, if I change the IP address of the NTP server in the sketch to a non-existent host on the network I can easily get the -1. In a few seconds. I'm going to setup a Wireshark capture now. Would you be able to do this as well? Make sure to setup a capture filter for only the MKR1000's IP address only. I'm wondering if a ICMP message is received the firmware stops sending. |
I might be testing a different scenario, but in this case the ARP request for the non-existent host on the network fails and the UDP packet is not sent. |
In another program I'm using the MRK1000, I get these message from time to time...
|
@trlafleur one step at a time, please open a new issue to track the issue from the last comment if the sketch is different. It would be great if you can get a Wireshark capture of the -1 case. |
Also, please try to ping the board when the |
sketch is the same Interesting, when I ping it from a Mac... I get DUP messages
On Fri, Aug 19, 2016 at 10:33 AM, Sandeep Mistry [email protected]
~~ _/) ~~~~ _/) ~~~~ _/) ~~~~ _/) ~~ Tom Lafleur |
Ping do work when the NTP request stop, I get the message below...
|
@trlafleur would you able to share a saved Wireshark capture (upload the .pcap file) to this Github issue. You can add a capture filter like The duplicate pings in #80 (comment) seem very suspicious. Could something else on the network be using the same IP address as your board? I'm going to continue try to reproduce this locally ... |
I've been able to reproduce with the original NTP client example with a longer overnight test.
Will try setting up a test access point to Wireshark/tcpdump next. |
I have been able to run for two days, do a reload, runs for 10 mins. It almost like something is not initialized correctly ~~ _/) ~~~~ _/) ~~~~ _/) ~~~~ _/) ~~ On Aug 23, 2016, at 5:49 AM, Sandeep Mistry [email protected] wrote: I've been able to reproduce with the original NTP client example with a longer overnight test. start: The UTC time is 21:20:59 — |
Having a very difficut time capturing the sent_bytes = -1 problem. I have seen it occur once recently. That was on a restart, but I didn't have wireshark running at the time. However, I have captured a failure to receive a NTP packet from the server. Trace is here, pcap is attached. You can see in the trace where is says "no packet yet". That indicates that the packet was not received. This is all running on my LAN. I have my windows machine set up as an NTP server. Server is 192.168.1.18. Wifi chip is 192.168.1.166. IP Address: 192.168.1.166 Starting connection to server... (APP)(DBG)[socket][589]1 Socket 7 session ID = 1 (APP)(DBG)[m2m_ip_cb][424]send callback session ID = 1 SOCKET_MSG_SENDTO: sock = 7, sent bytes = 48 (APP)(DBG)[m2m_ip_cb][424]send callback session ID = 1 SOCKET_MSG_SENDTO: sock = 7, sent bytes = 48 SOCKET_MSG_SENDTO: sock = 7, sent bytes = 48 (APP)(DBG)[m2m_ip_cb][424]send callback session ID = 1 SOCKET_MSG_SENDTO: sock = 7, sent bytes = 48 (APP)(DBG)[m2m_ip_cb][424]send callback session ID = 1 SOCKET_MSG_SENDTO: sock = 7, sent bytes = 48 SOCKET_MSG_SENDTO: sock = 7, sent bytes = 48 |
Update! I just got the sent_bytes = -1 error. Connected to wifi Starting connection to server... (APP)(DBG)[socket][589]1 Socket 7 session ID = 1 (APP)(DBG)[m2m_ip_cb][424]send callback session ID = 1 SOCKET_MSG_SENDTO: sock = 7, sent bytes = -1 SOCKET_MSG_SENDTO: sock = 7, sent bytes = -1 SOCKET_MSG_SENDTO: sock = 7, sent bytes = -1 SOCKET_MSG_SENDTO: sock = 7, sent bytes = -1 There's nothing on wireshark except some ARP |
@driverblock great! This feels like a firmware bug to me. @driverblock could you please open an issue with Atmel Support (http://www.atmel.com/design-support/), you can include a link to this issue. Then please add the case number here as a comment. |
@driverblock one more question, did you switch access points between the tests. I see an Apple MAC address in the first .pcap file and a Verizon in the second. Or are you running the NTP server on a Mac? |
I'm running win 10 on an old iMac. Verizon is the router. Not sure why the ARP traces are different |
Will do |
@driverblock thanks! One more question, was the IP pingable when this happened? Just want to make sure it was still connected to the AP at this time. |
Rats. I didn’t see this in time. I’ll t ry to get it to happen again. |
Atmel support case # 00045355 https://atmelsupport.force.com/customers/500G0000011kchi |
@driverblock thank you! Apologies for not asking you to try the ping test earlier. |
Update: Atmel reports that they have reproduced the problem:
|
@driverblock thanks for the update! |
Hi @driverblock, any news from Atmel on this. It might be worthwhile to nudge them again. |
Just got an update this morning - they're still working on it. |
@sandeepmistry - Just heard back from Atmel. They've identified the problem and it will be fixed in firmware release 19.5.2
|
@driverblock great, thanks for the update! According to @trlafleur's post in #90 (comment), 19.5.2 release date has been pushed out to January now. |
@trlafleur @driverblock any news from Atmel/Microchip on this? There's PR build of the IDE that contains the new v19.5.2 WINC1500 firmware: arduino/Arduino#6069 (comment). Any one up for testing it with the master version of the library to see if this has been fixed? |
I'm going to close this for now due to lack of feedback. v19.5.2 of the WINC1500 firmware has been out for some time now, and should include the fix. |
In testing with the UdpNTPClient, I have noticed that after some time (often less that 5 to 10min)
The WiFi101 stack stops sending the NTP request packets, but return no error to the program. This has been verified using Wireshark and the test program below.
Using IDE 1.6.9, SAMD 1.6.6, on a Adafruit feather M0 WINC1500
My modified test program and output.
The text was updated successfully, but these errors were encountered: