My understanding, based on the discussions and online searches, is that:
1) The hanging problem is dependent on the network or more specifically, other devices co-existing on the network. On some networks, this does not happen, on others it does. It’s not easy to reproduce and it may take many hours or even days for the symptoms to occur. I haven’t found a reliable way to trigger the symptom to happen quickly, so debugging is hard.
2) The issue does not seem to be due to the Ethernet module itself. Instead, it seems to be fundamentally due to the UIPEthernet library (https://github.com/UIPEthernet/UIPEthernet). Therefore I am pretty sure it’s a software problem. We haven’t used this library for long enough so still trying to understand the issues. Prior to UIPEthernet, we’ve been using EtherCard library (https://github.com/njh/EtherCard) for many years and that worked quite reliably with no hanging issues. However, the biggest drawback of EtherCard library is that it’s incompatible with Arduino’s Ethernet library, therefore the firmware code was a lot more messy. While we could switch back to EtherCard library again, that should only be a backup plan if everything else fails.
3) The current wired Ethernet module we use is ENC28J60, which requires software TCP/IP stack (implemented by UIPEthernet and EtherCard libraries). As discussed above, we’ve started testing an alternative Ethernet module: W5500, which has hardware-integrated TCP/IP stack therefore should be much more reliable than ENC28J60. If you want to give it a try, you can send a support ticket (as described above) to request an adapter, which can convert W5500 header layout to ENC28J60 layout, therefore can be directly plugged into OS 3.2’s Ethernet connector. Since we do not have W5500 modules in stock, you do need to buy one yourself, and also update your firmware to a version specifically compiled for W5500 (will be posted shortly).
4) Given that the issue is network dependent, another possible work-around is to use a separate router (call it the secondary router), such as a spare router you may have, or buy a cheap router like this one (https://www.amazon.com/TP-Link-N300-Wireless-Wi-Fi-Router-TL-WR841N/dp/B001FWYGJS). Have your OS as the only device plugged into the secondary router, and connect its WAN port to one of your primary router’s network ports. You can configure the secondary router to disable its WiFi (i.e. Ethernet only), and set up a port forwarding record so that you can access your OS from the primary network. The idea is to isolate OS from your primary router so it’s not affected by other devices, but you can still access it through port forwarding on the secondary router. I know this is cumbersome and not meant as a permanent solution, but it’s a useful experiment to try. In fact, if your router supports VLAN (virtual lan), you can make use of that to avoid the hassle of getting a secondary router.
5) Keep in mind that OS 3.2 has built-in WiFi — if wired Ethernet is not essential to you, I suggest that you keep the controller in WiFi mode until we figure out the issue with the wired Ethernet.
In any case, the current situation is that I am still debugging UIPEthernet library to see if we can fix the issue in software. At the same time we are planning to transition to W5500 modules once it has been tested out. In the meantime, you can try out the work-around in bullet 4) above to see if it addresses the problem.