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:
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.
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.
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.
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, thestat
variable will have a value ofSnSR::CLOSED
causing the function to return immediately with a value of0
without resetting the_sockindex
variable to the defaultMAX_SOCK_NUM
.The problem manifests itself at least when the following chain of events happen:
Object A holds an instance of
EthernetClient
. It tries to establish a TCP connection troughEthernetClient::connect
which fails because the port is not open on the server. Its instance is left with_sockindex
at0
.Object B performs a UDP exchange (
EthernetUDP::begin
,EthernetUDP::beginPacket
,EthernetUDP::write
,EthernetUDP::endPacket
,EthernetUDP::parsePacket
, read but noEthernetUDP::stop
yet). It is attributed_sockindex
of0
.Object A tries again to connect, his instance still has a
_sockindex
of0
, which leads to chaos because it's referencing a completely different socket.