I believe I have found an issue. I raised it in the form of PR #176 two years ago, but it received little attention, so I'm opening a proper issue here.

When a connection established through EthernetClient::connect fails, the stat variable will have a value of SnSR::CLOSED causing the function to return immediately with a value of 0 without resetting the _sockindex variable to the default MAX_SOCK_NUM.

The problem manifests itself at least when the following chain of events happen:

1. Object A holds an instance of EthernetClient. It tries to establish a TCP connection trough EthernetClient::connect which fails because the port is not open on the server. Its instance is left with _sockindex at 0.

2. Object B performs a UDP exchange (EthernetUDP::begin, EthernetUDP::beginPacket, EthernetUDP::write, EthernetUDP::endPacket, EthernetUDP::parsePacket, read but no EthernetUDP::stop yet). It is attributed _sockindex of 0.

3. Object A tries again to connect, his instance still has a _sockindex of 0, which leads to chaos because it's referencing a completely different socket.