@ntruchsess I'll try checking ESTAT as well (probably tonight). There is no truncated output since I deliberately stopped with a while(1); whenever the timeout happened. I can try to return false instead and see if everything recovers.
/Fredrik

@MagKas great your sensors are working correctly.

My sketch to debug this is basically a loop that each second opens a tcp-connection to my server, sends a timestamp, and closes the connection, so not much else is involved. I think my current problem is that not all code-paths in the library calling sendPacket() correctly handles sendPacket() returning FALSE. The reason I say this is that I can see the memhandle used when calling sendPacket() increasing when FALSE is returned in some cases. Eventually the library runs out of available memhandles and my sketch stops working. (This is mostly speculations, as I haven't debugged / understood it enough yet).

Is the error return value in sendPacket() needed?

Even if the packet is sent correctly, it may be dropped by the network, thus the library still needs to handle lost packets. Knowing that a packet failed to send is just a special case of lost packets that I don't think really needs to be handled separately. @MagKas solution without the while-loop basically does this by returning OK even when the enc-chip transmit logic freezes and don't send the packet, and that appears to work. The enc-chip will always be reset before sending the next packet, so it won't hang in any strange state. (I can imagine one problem when sending large packets and re-entering sendPacket() before the previous packet has finished transmitting. I don't know if this actually happens in real life.)

Maybe @ntruchsess or anyone else can educate me as to why the return value is needed or why it is a bad idea to remove it?

@Thomas-Ihmann that sounds great, thanks for reporting back

I'm not so lucky. But I am pretty sure my current problems are unrelated to this bug. I haven't had time to debug it further though.

@ntruchsess after I added the timeout my sketch has been running for almost 24h without crashing. The timeout has been triggered 19 times or so, and the library has recovered nicely. I commited my changes to my fork of the repo:
https://github.com/frolswe/arduino_uip/tree/fix_errata12

I don't really think this is a fix to the problem. The hang should not happen at all, but maybe we can use it as a workaround.

@Thomas-Ihmann please try this branch, hopefully your issue are the same as mine

@ntruchsess I now added polling of ESTAT also. When the timeout happens nothing different is seen (no TXABRT). I do see some TXERIF in my logs, seemingly caused by collisions, and it looks like they are handled correctly. I pushed new logs and diff to github, and I would be very grateful for any more tips.
Currently I am testing to return false when the timeout happens as you suggested. I'll let you know the results tomorrow.

@Thomas-Ihmann the enc28 chip can only handle 3.3v, but the breakout board I use have a dedicated 3.3v regulator.

@m26872 maybe I should try a different Arduino.. But I still believe it these should work, so I won't give up yet. I also suspected power issues before, but now I have one 3.3v regulator for the Arduino, and one for the enc28, so I don't think that should not be an issue anymore.
Tjusig sensor node, väldigt lik den design jag tänkt mig på mina sådana (till och med samma låda etc..)

@m26872 that sounds interesting, what kind of sensors do you use? Also, how do you power the enc28? Im using a 3.3V Mini Pro and this enc28. Vraw on the Arduino and Vcc on the enc28 breakout are connected to 5V from the USB adapter. Currently my sensors (DS18B20) are connected directly to my computer for logging, but my plan is to connect them via this Arduino instead.

@m26872 that is good to hear, it is possible to get enc28 stable Maybe I should try with a different switch / network environment.
Did you have the problem with hangs prior to the fix_errata12 branch?

@ntruchsess I'll try checking ESTAT as well (probably tonight). There is no truncated output since I deliberately stopped with a while(1); whenever the timeout happened. I can try to return false instead and see if everything recovers.
/Fredrik

@ntruchsess (Sorry for the delay..)
Thats kind of what I expected, didn't seem right that it wasn't completely hung. I tried to reproduce it using a simpler sketch, and couldn't get to the "responds to pings" state. But several times my new simple sketch has hung completely in sendpacket() waiting for the send to complete. To help debug it, I set the ENC28J60DEBUG define and added a timeout in sendpacket() after 10 seconds. To me this looks like what is described in errata12, but the workaround implemented in the branch looks correct, so I dont know

My sketch is available here. Do you have any tips what I could try to understand this better?
https://github.com/frolswe/uip_debug

This looks great, thanks Magnus.

I am currently testing one of my projects using the fix_errata12 branch of UIPEthernet. It has been running for more than an hour with no problems, while it previously froze very often.

Hopefully this solves my enc28 problems
Thanks
/Fredrik

EDIT:
Froze after three hours or so. Still responds to ping, but not tcp connections.