I have two OS V3’s with this problem.
It is too bad that firmware update is not available over wired Internet. Once OS is installed in a steel box in the next building basement it is a pain doing a software update. Is it difficult to use wired?
Disconnecting all the zones to remove the OS and take it to a more convenient location would be even more work.
I have been following this thread.
To me this seems like a problem in the UIPEthernet library for ENC28J60. It cannot handle broadcast events correctly if there are too many in a short time. I am no expert in the Ethernet stack. But it seems to me that all devices on the network have to process all broadcast events (in case the recipient needs to respond) and then quickly look to see if the broadcast is needed by the client(OS). If not it should quickly discard the packet. If the software is slow or the buffer not big enough, then a sudden sequence of events may just overwelm the ignore-broadcast implementation either by buffer overrun or just slow software response. This would be true for all broadcast events, not just DHCP.
Could it be that this library has not been rigorously tested on larger networks where there is a lot going on and many other programs issuing broadcasts. The collective experience here is that when testing on a larger network, you may have to wait 24 hours or more to know the software really works. I wonder if this was the case when testing UIPEthernet?
To me, turning on DHCP only when needed is not a real fix. It is just reducing the window (significanly), but the same crash could occur when the window is open. That might mean a crash once a month instead of evry few hours.
I have been reading Issues on the UIPEthernet github site. @jandrassy (a committer) says
UIPEthernet library is made for small MCUs. To store the TCP packets before the application reads them, the library uses the 8kB memory of the ENC28J60. To have more for stored packets the part of memory reserved for receive ring buffer is small.
But the enc28j80 puts in the RX ring buffer almost every packet seen on network and the library must analyse the packet. Some packets are ignored, some are processed for support protocols and the packets for the host are moved to other part of the enc28j60 internal memory to have place for the next packet from the network. The processing of the RX ring buffer is done in maintain() and in every UIPEthernet library function called by host application.
In a network with large traffic sometimes the RX ring buffer doesn’t have place for a packet.
Is this where the problem lies?