Title: ESP8266 resets all WebSocket connections when system time is updated via configTime()

[casterock]

Description: We found a reproducible issue when using WebSockets together with configTime() on ESP8266. When the system time is set or re-synchronized (via SNTP / settimeofday), something in the networking stack breaks and the ESP8266 starts resetting all active WebSocket/TCP connections. The resets are sent by the ESP8266 itself as TCP RST packets, not as clean WebSocket Close frames.

This does not only happen during the initial NTP sync, but also later, when SNTP automatically re-syncs the time while WebSocket connections are already active. After the time update, all existing connections are aborted and clients are forced to reconnect.

From the application point of view, WebSockets appear unstable or randomly disconnect, but Wireshark shows that the root cause is the system time change. If configTime() is only called once at boot and SNTP is stopped afterward (sntp_stop), the problem disappears completely.

This suggests that changing the system time while sockets are active causes an internal inconsistency in lwIP/TCP timers, leading to connection resets.

NOTES
Comment configtTime() solves the problem but can't syn time with NTP
Calling yield() after websocket.loop() don't fix the problem

Using Wireshark, we observed that TCP connections are established correctly (SYN / SYN-ACK / ACK), and the client sends the HTTP GET request for the WebSocket upgrade. In many cases, the ESP8266 never responds with HTTP/1.1 101 Switching Protocols. Instead, shortly after the system time is updated, the ESP8266 sends TCP RST, ACK packets, abruptly resetting the connections. No TCP FIN or WebSocket Close frame is observed. The resets always originate from the ESP8266.