Yes, the timing is correct with 2 retries of 3 seconds, athough it appears that I’ve solved the issue.
The ports are allocated by a function in w5500_iface.c that were added I believe by my Nigerian programmer (yeah, there is one :-)) as we were havig issues with port allocations at one point, so was changed to the following:
if (++local_port_offset < W5500_LOCAL_PORT_OFFSET)
local_port_offset = W5500_LOCAL_PORT_OFFSET;
anything requiring a port was calling this function . . . although not everything.
socket.c had the following in case the port wasn’t send in for whatever reason, and it was allocating, you guessed it, 2 ports on startup.
port = w5500_get_unused_port();
// if(sock_any_port == 0xFFF0)
// sock_any_port = SOCK_ANY_PORT_NUM;
// LOGLN_INFO(“Sock Allocated Port: %d”, port);
So the fix was to simply call the function w5500_get_unused_port(); in w5500_iface.c to ensure duplicate ports were not being issued. I’m not sure how far away from the original code this is, I don’t think it’s far off from a quick check, however certain mods were required to make everything work.
So, bottom line, mystery solved.
OK, one coffee later and thinking about it a little more it seems that if the two ports allocated on startup (and I suspect without checking that they are DHCP and NTP clients) are not being closed, then this issue will eventually happen twice at some point in the future when the cycle comes around again.
My project is current hosting a webserver for configuration, and clients for DHCP, NTP, Syslog, DNS and MQTT so there’s a bit going on.
So, should ports ALWAYS be closed when the call has been made or should those allocated be tracked somehow as they’re allocated and released. When allocating a port one would do a lookup to see if a port in the pool is currently in use. Seems like effort compared to just closing the port.