[Christophe Lohr <Christophe.Lohr@xxxxxxxxxxxxxxxx>]

Ed.Staszko@xxxxxxxxxxxxxxxxx a écrit :
>
>
> It appears to be a mis-calculation of the length.
> If you subtract the sequence numbers in the first trace (2874589889 -
> 2874588441) you get 1448, the same value as in the second.
> I don't know the reason for the miscalculation, but the actual packet
> length does not exceed the MTU.
>
>   

Hi,
  I'm not sure to understand what your are computing.

Following is a filtered view of the same trace  :
  1  192.168.100.11 -> 192.168.100.17 TCP 74 38587 > 7575 [SYN]
Seq=2874587416 Len=0 MSS=1460 WS=6
  2  192.168.100.11 -> 192.168.100.17 TCP 66 38587 > 7575 [ACK]
Seq=2874587417 Win=92 Len=0
  3  192.168.100.11 -> 192.168.100.17 TCP 1090 38587 > 7575 [PSH, ACK]
Seq=2874587417 Win=92 Len=1024
  4  192.168.100.11 -> 192.168.100.17 TCP 1514 38587 > 7575 [ACK]
Seq=2874588441 Win=92 Len=1448
  5  192.168.100.11 -> 192.168.100.17 TCP 2962 38587 > 7575 [ACK]
Seq=2874589889 Win=92 Len=2896
  6  192.168.100.11 -> 192.168.100.17 TCP 2962 38587 > 7575 [ACK]
Seq=2874592785 Win=92 Len=2896
  7  192.168.100.11 -> 192.168.100.17 TCP 2962 38587 > 7575 [ACK]
Seq=2874595681 Win=92 Len=2896
  8  192.168.100.11 -> 192.168.100.17 TCP 2962 38587 > 7575 [PSH, ACK]
Seq=2874598577 Win=92 Len=2896
  9  192.168.100.11 -> 192.168.100.17 TCP 346 38587 > 7575 [PSH, ACK]
Seq=2874601473 Win=92 Len=280
 10  192.168.100.11 -> 192.168.100.17 TCP 1514 38587 > 7575 [ACK]
Seq=2874601753 Win=92 Len=1448
 11  192.168.100.11 -> 192.168.100.17 TCP 2962 38587 > 7575 [ACK]
Seq=2874603201 Win=92 Len=2896
 12  192.168.100.11 -> 192.168.100.17 TCP 5858 38587 > 7575 [ACK]
Seq=2874606097 Win=92 Len=5792
 13  192.168.100.11 -> 192.168.100.17 TCP 4410 38587 > 7575 [PSH, ACK]
Seq=2874611889 Win=92 Len=4344
 14  192.168.100.11 -> 192.168.100.17 TCP 946 38587 > 7575 [PSH, ACK]
Seq=2874616233 Win=92 Len=880
 15  192.168.100.11 -> 192.168.100.17 TCP 1514 38587 > 7575 [ACK]
Seq=2874617113 Win=92 Len=1448
 16  192.168.100.11 -> 192.168.100.17 TCP 1514 38587 > 7575 [ACK]
Seq=2874618561 Win=92 Len=1448
 17  192.168.100.11 -> 192.168.100.17 TCP 1514 38587 > 7575 [ACK]
Seq=2874620009 Win=92 Len=1448
 18  192.168.100.11 -> 192.168.100.17 TCP 5858 38587 > 7575 [ACK]
Seq=2874621457 Win=92 Len=5792
 19  192.168.100.11 -> 192.168.100.17 TCP 2962 38587 > 7575 [ACK]
Seq=2874627249 Win=92 Len=2896
 20  192.168.100.11 -> 192.168.100.17 TCP 20338 38587 > 7575 [ACK]
Seq=2874630145 Win=92 Len=20272


If you do (sequence number of frame 5) minus (sequence number of frame
4), you got length of frame 4, not length of frame 5... which is still
too big...

So, what's the problem with length of my packets?

(Note for Andreas:  there is no Jumbo Frames, MTU is 1500, and TCP
initialisation annouces MSS=1460)


Regards,
Christophe.


>
> Hi,
>   Wireshark shows (outgoing) tcp packet with a surprising size, larger than
> mss...
>
> Let's consider following "Client" and "Server":
> * Server [192.168.100.17] *
> # tshark -n "host 192.168.100.11 && host 192.168.100.17 && port 7575" >
> server.dump
> # netcat -l -p 7575 > /dev/null
>
> * Client [192.168.100.11] *
> # tshark -n "host 192.168.100.11 && host 192.168.100.17 && port 7575" >
> client.dump
> # netcat 192.168.100.17 7575 </dev/zero
>
> Now, let's have a look at "server.dump" and "client.dump" files:
> * client.dump *
>   0.000000 192.168.100.11 -> 192.168.100.17 TCP 74 38587 > 7575 [SYN]
> Seq=2874587416 Len=0 MSS=1460 TSV=237521906 TSER=0 WS=6
>   0.000835 192.168.100.17 -> 192.168.100.11 TCP 74 7575 > 38587 [SYN,
> ACK] Seq=2859359246 Ack=2874587417 Win=5792 Len=0 MSS=1460 TSV=1201904
> TSER=237521906 WS=6
>   0.000853 192.168.100.11 -> 192.168.100.17 TCP 66 38587 > 7575 [ACK]
> Seq=2874587417 Ack=2859359247 Win=92 Len=0 TSV=237521907 TSER=1201904
>   0.001001 192.168.100.11 -> 192.168.100.17 TCP 1090 38587 > 7575 [PSH,
> ACK] Seq=2874587417 Ack=2859359247 Win=92 Len=1024 TSV=237521907
> TSER=1201904
>   0.001134 192.168.100.11 -> 192.168.100.17 TCP 1514 38587 > 7575 [ACK]
> Seq=2874588441 Ack=2859359247 Win=92 Len=1448 TSV=237521907 TSER=1201904
>   0.001336 192.168.100.17 -> 192.168.100.11 TCP 66 7575 > 38587 [ACK]
> Seq=2859359247 Ack=2874588441 Win=123 Len=0 TSV=1201905 TSER=237521907
>   0.001348 192.168.100.11 -> 192.168.100.17 TCP 2962 38587 > 7575 [ACK]
> Seq=2874589889 Ack=2859359247 Win=92 Len=2896 TSV=237521907 TSER=1201905
>   (..)
>
> Last TCP packet have Len=2896 !!!???
>
> And now, packets received:
> * server.dump *
>   0.000000 192.168.100.11 -> 192.168.100.17 TCP 38587 > 7575 [SYN]
> Seq=2874587416 Len=0 MSS=1460 TSV=237521906 TSER=0 WS=6
>   0.000525 192.168.100.17 -> 192.168.100.11 TCP 7575 > 38587 [SYN, ACK]
> Seq=2859359246 Ack=2874587417 Win=5792 Len=0 MSS=1460 TSV=1201904
> TSER=237521906 WS=6
>   0.000764 192.168.100.11 -> 192.168.100.17 TCP 38587 > 7575 [ACK]
> Seq=2874587417 Ack=2859359247 Win=92 Len=0 TSV=237521907 TSER=1201904
>   0.001016 192.168.100.11 -> 192.168.100.17 TCP 38587 > 7575 [PSH, ACK]
> Seq=2874587417 Ack=2859359247 Win=92 Len=1024 TSV=237521907 TSER=1201904
>   0.001035 192.168.100.17 -> 192.168.100.11 TCP 7575 > 38587 [ACK]
> Seq=2859359247 Ack=2874588441 Win=123 Len=0 TSV=1201905 TSER=237521907
>   0.001266 192.168.100.11 -> 192.168.100.17 TCP 38587 > 7575 [ACK]
> Seq=2874588441 Ack=2859359247 Win=92 Len=1448 TSV=237521907 TSER=1201904
>   0.001285 192.168.100.17 -> 192.168.100.11 TCP 7575 > 38587 [ACK]
> Seq=2859359247 Ack=2874589889 Win=168 Len=0 TSV=1201905 TSER=237521907
>   0.001516 192.168.100.11 -> 192.168.100.17 TCP 38587 > 7575 [ACK]
> Seq=2874589889 Ack=2859359247 Win=92 Len=1448 TSV=237521907 TSER=1201905
>   0.001531 192.168.100.17 -> 192.168.100.11 TCP 7575 > 38587 [ACK]
> Seq=2859359247 Ack=2874591337 Win=213 Len=0 TSV=1201905 TSER=237521907
>   0.001535 192.168.100.11 -> 192.168.100.17 TCP 38587 > 7575 [ACK]
> Seq=2874591337 Ack=2859359247 Win=92 Len=1448 TSV=237521907 TSER=1201905
>   (..)
>
> No trace of large TCP packets...
>
> I can't understand how "Client" do to send TCP packets larger than MTU.
>
> Does Wireshark dump real (outgoing) packets?
>
> Note that "Client" and "Server" are Linux 2.6.18/Fedora4.
>
> Many thanks.
> Regards
>