I have a problem with sockets:(Coldfire DilnetPC DNP5280)
I have a listen socket that can send data to a remote client. If a client connects, the server socket opens a file and sent its bytes to the socket so the remote client can process the bytes.
I noted that when i disrupt (eg 0.2sec ) the network connection the transfer does not resume. The same happens when using a slow connection.(e.g. with a gateway through internet)
The program seems to block on the send() function. The full sendbuffer seems to block the send() becorse the data can't be delivered but it should resume as ethernet communication proceeds.
I would expect get a return value of -1 when the network disruption takes too long (causing a sent timeout) but this is not the case.
When i do this experiment between two windows machines i don't get this problem. (transfer resumes a few moments i reconnect the network ) neither does it occur between 2 linux desktop machines.
Is there a problem with the TCPIP stack in ucLinux ? or with the low level network driver ?
any help much appreciated.
Johan.
Didn't find your answer? Ask the community — no account required.
M
Michael Schnell
If the Network connection is broken, neither of the sockets is informed that the connection is lost. Both think it's still working.
The one that some time later sends a packet does not receive an acknowledge packet from the addressees stack, so, after some 90 seconds it declares the connection broken and the application is informed. Still the other end thinks the connection is still working (though idle).
If (e.g.) the client application knows that the connection is broken, it might try a reconnect. If the cable is restored, the server will decline the connect, as it thinks there is still a working connection.
To improve this situation you need to implement a life check protocol lin the application or use the stack's "keep alive" feature.
-Michael
S
Sagaert Johan
Discovered that after a disruption (or network congestion ) the board retries to sent the packet but it has checksum errors on the data part !!
This seems to be a serious bug in the uclinux..... see below for a snippet made with etherreal
The boards repeats the bad packet several times until the conection times out after severla minutes .
Frame 3484 (254 on wire, 254 captured) Arrival Time: Dec 30, 2006 23:55:43.758822000 Time delta from previous packet: 0.811065000 seconds Time relative to first packet: 47.427310000 seconds Frame Number: 3484 Packet Length: 254 bytes Capture Length: 254 bytes Ethernet II Destination: 00:09:f3:0f:22:dc (WELL_0f:22:dc) Source: 02:80:ad:20:b8:b2 (02:80:ad:20:b8:b2) Type: IP (0x0800) Internet Protocol, Src Addr: 192.168.1.61 (192.168.1.61), Dst Addr: dD577BF9E.access.telenet.be (213.119.191.158) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 240 Identification: 0x030f Flags: 0x04 .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: TCP (0x06) Header checksum: 0xdffd (correct) Source: 192.168.1.61 (192.168.1.61) Destination: dD577BF9E.access.telenet.be (213.119.191.158) Transmission Control Protocol, Src Port: 2050 (2050), Dst Port: 2126 (2126), Seq: 1948016716, Ack: 471731837, Len: 200 Source port: 2050 (2050) Destination port: 2126 (2126) Sequence number: 1948016716 Next sequence number: 1948016916 Acknowledgement number: 471731837 Header length: 20 bytes Flags: 0x0018 (PSH, ACK) 0... .... = Congestion Window Reduced (CWR): Not set .0.. .... = ECN-Echo: Not set ..0. .... = Urgent: Not set ...1 .... = Acknowledgment: Set .... 1... = Push: Set .... .0.. = Reset: Not set .... ..0. = Syn: Not set .... ...0 = Fin: Not set Window size: 5840 Checksum: 0x69cc (correct) Data (200 bytes)