I have the ethernet2 library installed via "manage libraries". in IDE 1.6.12
I'm trying to shorten the timeout when client.connect() fails, the default is 31.8 seconds.
If I disable retries by:
w5500.setRetransmissionCount(0);
then it fails to connect even when is should.
Using:
w5500.setRetransmissionCount(1);
I get a timeout of 600ms. This makes sense, the initial timeout of the default 200ms plus the 1 retry of 2x200ms.
Is there a way to not retry at all? Ideally I want to timeout at 50ms (the connection is on a LAN so it should be quick) then get on with running other code. I could set the timeout to 16.6ms and 1 retry to give me a 49.8ms timeout, but this doesn't seem very neat 
Any ideas?
Are you using a domain name in the connect call? If so, use an IP instead. The default timeout if using an IP should be about 1.6 seconds.
Have you tried modifying the retransmission time? The default is 2000.
W5500.setRetransmissionTime(500);
edit: BTW, the setRetransmissionCount is a misnomer. It should have been setConnectCount. If you use '0' as a parameter, it will never attempt to connect. If you use '1', it will attempt to connect only once.
I am using IP address's.
The timeout appears to be from this in the data sheet:
TCPTO = (0x07D0+0x0FA0+0x1F40+0x3E80+0x7D00+0xFA00+0xFA00+0xFA00+0xFA00) X 0.1ms
= (2000 + 4000 + 8000 + 16000 + 32000 + ((8 - 4) X 64000)) X 0.1ms
= 318000 X 0.1ms = 31.8s
Each retry takes twice as long as the last, which I why I am seeing 600ms with 1 retry (default timeout value).
This give an error:
w5500.setConnectCount(1);
error: 'class W5500Class' has no member named 'setConnectCount'
While we're at it, is it possible to override the SPISettings to give a faster SPI speed? I prefer to override rather than modify the library where possible...
No, don't use setConnectCount. It doesn't exist. That is what I have found setRetransmissionCount should have been called. If you use '0' for a parameter, what happens? It never attempts to connect. If the datasheet is correct, it should attempt at least once, correct? Have you tried watching the connection attempt with Wireshark?
I see the datasheet on the w5500 has a different timeout time calculation than the w5100/w5200. It does appear to double the timeout value each attempt.
edit: The ARP timeout value calculation has not changed. If the device does not answer the ARP request, the timeout should be 1.8 seconds.
edit2: The only way I can see you get a 30 second timeout is if the device is answering the ARP request, but the port you are attempting to connect to on that device is not open. Is that correct?
There are issue with using wireshark, firstly the servers aren't PCs. Secondly, If I didsetup a PC as a server, it would connect and not timeout. I could setup a PC without the server part but it's difficult to guarantee that it will look like it doesn't exist on the network and yet see the incoming packets.
I don't think ARP is happening since the experienced timeout is 600ms with 200ms/1retry. For clarification, I'm deliberately trying to connect to an IP which I know doesn't exist on the network to test this part of the code.
Setting the retries to 0 fails instantly, 2ms including the serial.print() time! This is why I'm convinced it's not even trying, the activity LED doesn't flicker either. I can't find anything in the datasheet that explicitly states what it does with retries set to 0.
31.8 seconds is the default TCP timeout, this is the total timeout after all the (default number of) retries.
The ARP timeout should be 1.8 seconds. It does not double the timeout like the TCP connect does. Wireshark should work on any computer on the localnet. It needn't be on the sender or receiver.
The Ethernet switch won't pass packets to a PC which isn't intended to receive them will it? I can give it a go....
OK, the PC does see something going on when I set the retries to 1, when I set it to 0 nothing.