TCP Timeout Issue and mistake in datasheet.

Question

Hello, Here my test setup: Establish a TCP4 connection. Unplug the ethernet cable. Write TCP buffer and send SEND command. Read out the SN_IF register. i tried out the TCP send timeout function of the W6100. From reading the datasheet i thought, that SENDOK only occurs, if no timeout occurs. But reading the SN_IF register, i found out, that the SENDOK flag sets, although the cable is unplugged. After the timeout time, also the TIMEOUT flag sets. QUESTION 1: Does SENDOK appear independent from a timeout? QUESTION2: Assuming i would send a TCP packet over the internet, when a packet gets lost and meanwhile i send another 20 packets (because the SENDOK flag tells me, everything is OK) - how would i know, from which packet sent this TIMEOUT comes? And more irritating to me is, that if a timeout occurs, the socket automatically closes, but if i unplug the cable or loose LINK all sockets remain established? Did i miss something here? Thank you, Regards

Welocs · Answer

I forgot the mistake in the datasheet: On page 90 the code: Blockzitat /* wait until SEND or SEND6 Command is completed or Timeout is occurred */ while(Sn_IR[SENDOK] == ‘0’ and Sn_IR[TIMEOUT] = ‘0’); <<< it should be "=="

Eugeny · Answer

Welocs: But reading the SN_IF register, i found out, that the SENDOK flag sets, although the cable is unplugged. Only one explanation: it can not sense unplugged cable on the TX line, and just sends into nowhere. Therefore conclusion - if you cut RX lines and socket was setup before, you still can send some data until socket breaks / times out. Welocs: QUESTION 1: Does SENDOK appear independent from a timeout? I suspect timeout occurs because W6100 does not receive ACK to the packet sent. It will of course not receive because cable is unplugged. Welocs: but if i unplug the cable or loose LINK all sockets remain established? See something good in bad. If your cable was unplugged by mistake, you have some time to reconnect it and continue data transfer. Welocs: Assuming i would send a TCP packet over the internet, when a packet gets lost and meanwhile i send another 20 packets (because the SENDOK flag tells me, everything is OK) - how would i know, from which packet sent this TIMEOUT comes? I suspect while you get SENDOK, the TX buffer pointers are not being internally shifted until socket receives ACK for the data sent. In other words - you can send data of maximum size of TX buffer, and W6100 will give you no free space in TX buffers until it receives ACK for some data and frees space for your further data.

Eugeny · Answer

Welocs: You know, that the W6100 has the capability to sense that? I think it can sense connection to the transformer (resistance/capacitance, as you said), but can not sense connection after the transformer, at least reliably. Welocs: Why you have the flag for this? Not me, W6100. Why not? For debugging purposes? Probably it is useful for some implementations, but not for those publicly shared. Welocs: then you don’t believe, there are thiefs and hackers. Having physical access to device is a serious advantage, and there may be no difference if you have W6100 or i219 controller. Welocs: i don’t have any information about which data packet got lost here. You do not need to. TCP handles the session. You just push data when space allows. If something fails, you get to restart - from the beginning, or through additionally defined protocol informing you what data receiver actually received in previous session. Welocs: I hope wiznet is going to implement a limited packet tracking. WIZnet chips’ purpose is highest level programming possible (with some low level mechanisms). You can use W6100 in MACRAW mode making your own TCP/IP implementation receiving raw data and then you have full control over the packets. But in usual life you want simpler things, because complex things are already there and cost much more including proprietary firmware (e.g. networking cards). Welocs: the user doesn’t have any chance here to resend the packet or analyse the error. User opens connection and sends/receives data. If it fails, user restarts. This is no probem is you send several packets, of course if you send 1GB file you need to design some mechanism to restart at the point when it failed, but this mechanism is above TCP/IP level. Welocs: But NOT closing all sockets, when the cable is unplugged really is an security issue. This unplugging of the cable bears absolute the same risks as having man-in-the-middle scenarios, but in addition, it requires physical access to the device.