Re: Socket send problem (ucLinux)

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)

0000 00 09 f3 0f 22 dc 02 80 ad 20 b8 b2 08 00 45 00 ....".... ....E.
0010 00 f0 03 0f 40 00 40 06 df fd c0 a8 01 3d d5 77 ....@.@......=.w
0020 bf 9e 08 02 08 4e 74 1c 60 4c 1c 1e 0e 7d 50 18 .....Nt.`L...}P.
0030 16 d0 69 cc 00 00 68 65 6c 6c 6f 20 77 6f 72 6c ..i...hello worl
0040 64 31 31 37 20 20 20 20 20 20 20 20 20 20 20 20 d117
0050 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
0060 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
0070 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
0080 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
0090 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00a0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00b0 20 20 20 0a 0d 00 23 23 23 23 23 23 23 23 23 23 ...##########
00c0 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 ################
00d0 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 ################
00e0 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 ################
00f0 23 23 23 23 23 23 23 23 23 23 23 23 23 23 ##############

Frame 3497 (60 on wire, 60 captured)
Arrival Time: Dec 30, 2006 23:55:43.953376000
Time delta from previous packet: 0.194554000 seconds
Time relative to first packet: 47.621864000 seconds
Frame Number: 3497
Packet Length: 60 bytes
Capture Length: 60 bytes
Ethernet II
Destination: 02:80:ad:20:b8:b2 (02:80:ad:20:b8:b2)
Source: 00:09:f3:0f:22:dc (WELL_0f:22:dc)
Type: IP (0x0800)
Trailer: 2A51DBC67616
Internet Protocol, Src Addr: dD577BF9E.access.telenet.be (213.119.191.158),
Dst Addr: 192.168.1.61 (192.168.1.61)
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: 40
Identification: 0xf35a
Flags: 0x04
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 120
Protocol: TCP (0x06)
Header checksum: 0xb879 (correct)
Source: dD577BF9E.access.telenet.be (213.119.191.158)
Destination: 192.168.1.61 (192.168.1.61)
Transmission Control Protocol, Src Port: 2126 (2126), Dst Port: 2050 (2050),
Seq: 471731837, Ack: 1948016916, Len: 0
Source port: 2126 (2126)
Destination port: 2050 (2050)
Sequence number: 471731837
Acknowledgement number: 1948016916
Header length: 20 bytes
Flags: 0x0010 (ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 16520
Checksum: 0x0835 (correct)

0000 02 80 ad 20 b8 b2 00 09 f3 0f 22 dc 08 00 45 00 ... ......"...E.
0010 00 28 f3 5a 40 00 78 06 b8 79 d5 77 bf 9e c0 a8 .(.Z@.x..y.w....
0020 01 3d 08 4e 08 02 1c 1e 0e 7d 74 1c 61 14 50 10 .=.N.....}t.a.P.
0030 40 88 08 35 00 00 2a 51 db c6 76 16 @..5..*Q..v.

Frame 3667 (254 on wire, 254 captured)
Arrival Time: Dec 30, 2006 23:55:46.028327000
Time delta from previous packet: 2.074951000 seconds
Time relative to first packet: 49.696815000 seconds
Frame Number: 3667
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: 0x0312
Flags: 0x04
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: TCP (0x06)
Header checksum: 0xdffa (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: 1948016916, Ack: 471731837, Len: 200
Source port: 2050 (2050)
Destination port: 2126 (2126)
Sequence number: 1948016916
Next sequence number: 1948017116
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: 0x6903 (incorrect, should be 0xaf49)
Data (200 bytes)

0000 00 09 f3 0f 22 dc 02 80 ad 20 b8 b2 08 00 45 00 ....".... ....E.
0010 00 f0 03 12 40 00 40 06 df fa c0 a8 01 3d d5 77 ....@.@......=.w
0020 bf 9e 08 02 08 4e 74 1c 61 14 1c 1e 0e 7d 50 18 .....Nt.a....}P.
0030 16 d0 69 03 00 00 00 00 00 00 68 65 6c 6c 6f 20 ..i.......hello
0040 77 6f 72 6c 64 31 31 38 20 20 20 20 20 20 20 20 world118
0050 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
0060 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
0070 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
0080 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
0090 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00a0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
00b0 20 20 20 20 20 20 20 0a 0d 00 23 23 23 23 23 23 ...######
00c0 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 ################
00d0 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 ################
00e0 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 23 ################
00f0 23 23 23 23 23 23 23 23 23 23 23 23 23 23 ##############




"Michael Schnell" <mschnell_at_bschnell_dot_de@xxxxxxx> wrote in message
news:en6jt0$lsl$01$1@xxxxxxxxxxxxxxxxxxxx

I noted that when i disrupt (eg 0.2sec ) the network connection the
transfer
does not
resume.

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


.

Relevant Pages

  • Re: dx upgrade - unexpected network connection
    ... > Ethernet II (Packet Length: ... > Internet Protocol ... = Don't fragment: Set ... > Header checksum: 0xa61c ...
    (microsoft.public.security)
  • Re: 8159 bytes takes 20 ms, 8160 bytes takes 200 ms?
    ... look for Nagle algorithm in TCP ... > this is what etheral shows, a packet with ack and push flag set, and win2k ... > Header length: 20 bytes ... > Fragment offset: 0 ...
    (microsoft.public.win32.programmer.networks)
  • RE: 8159 bytes takes 20 ms, 8160 bytes takes 200 ms?
    ... > this is what etheral shows, a packet with ack and push flag set, and win2k ... > Time since reference or first frame: ... > Header length: 20 bytes ... > Fragment offset: 0 ...
    (microsoft.public.win32.programmer.networks)
  • Re: IP_HDRINCL
    ... Because the operating system cannot fragment a packet without changing ... the header. ... If the OS fragments the packet, it would have to modify the headers. ...
    (comp.unix.programmer)
  • Re: NDIS passthru packet redirection
    ... I solved this with adjusting the TCP checksum. ... Now I must redirect the answer packet to the calling application. ... TCP header or TCP data isn't changed, the you don't need to update the TCP ...
    (microsoft.public.development.device.drivers)