ESP8266 Community Forum

- Fri Apr 10, 2015 3:11 am #14077 OK. I have some findings... i'll post everything in the UDP bug thread where others will stand a better chance of seeing it.

- Fri Apr 10, 2015 3:37 am #14079

Hey.. sorry for the distasteful comment I've made in my previous reply.. duh..

You're making an effort to get this thing sorted, so you're forgiven

I then checked the referenced bug report and spent the evening crashing my ESP8266 by sending UDP packets. I suspect the root cause is too many instances of UDP opening with differnt port numbers that increment from 4097 (dunno why it starts there) until the heap is exhausted and the watchdog kicks in. Anyway, seems like Udp.begin(port number) does not control which port the UDP packet transmits from hence preventing the NTP reply from reaching the correct port on it's way back to the ESP8266. It MUST be the same port number. Now - I wonder if I can force Udp to listen to that arbitrary egress port (4097) with the Udp.begin.. guess not.
BUG.

In my testing I saw the mentioned port increment too, but could not declare it. My detailed knowledge of internal UDP communication is too limited to pinpoint the root cause.

Thanks for your input, hope that IGRR picks this one up.

- Sat Apr 11, 2015 12:45 pm #14195 Thanks for bringing this up again, Gerard, and thanks @dnts for your findings. One-line fix, actually, so stupid of me
I've added NTP Client sample to the package.

- Sat Apr 11, 2015 3:35 pm #14216

Thanks for bringing this up again, Gerard, and thanks @dnts for your findings. One-line fix, actually, so stupid of me
I've added NTP Client sample to the package.

I'm glad that you've been able to solve it.

When will you publish a new release (for OSX)? Don't really want to build from source, is there a "nightly build"?