Hello Guy Harris
Thanks for your fast response.
Jumbo frames are not used on the CERN
site.
Following is printout of the problem:
1) tcpdump command:[EMAIL PROTECTED] d]# tcpdump -A port 12509 -s0 -c1000 > /tmp/tcpdummed
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
1000 packets captured
1000 packets received by filter
0 packets dropped by kernel2) Relevant part from the result:11:33:55.601653 IP lxfs5623.cern.ch.32962 > lcgmon002d.cern.ch.12509: UDP, length: 1637
E.....`.=..........x..0..m..A0 0 lxfs5623#4105 1093426434 1#9024 1093426434 11#20002 1093426434 1.83#9011 1093426434 0.71 0.00 34.73 64.55 300.02 0#9012 1093426434 5144.65 1543395#9013 1093426434 11300.92 3390275#9022 1093426434 0.02 5 0.09 27#9023 1093426434 0.36 108 27074.36 8122308#9025 1093426434 2088244 8196 407128 522216 0 8804 1021656 0.39 99.15#9031 1093426434 98#9032 1093426434 0.64 192#9101 1093426434 sda1 ext3 5041 50 0.0 8.7 0 #9101 1093426434 sda2 ext3 5041 0 0.2 0.3 0 #9101 1093426434 sda6 ext2 1011 0 0.0 0.1 0 #9101 1093426434 sda3 ext3 62006 0 0.1 9.6 0 #9101 1093426434 sdb1 ext3 114407 68 0.0 1867.5 4 #9101 1093426434 sdc1 ext3 114407 60 0.0 1727.7 4 #9101 1093426434 sdd1 ext3 114407 58 0.0 2463.6 5 #9101 1093426434 sde1 ext3 114407 60 0.0 2135.8 6 #9101 1093426434 sdf1 ext3 114407 58 0.0 2396.1 5 #9101 1093426434 sdg1 ext3 114407 59 0.0 2123.3 6 #9101 1093426434 sdh1 ext3 114407 56 0.0 2700.9 8 #9101 1093426434 sdi1 ext3 114407 51 0.0 2633.7 6 #9101 1093426434 sdj1 ext3 114407 55 0.0 2259.0 6 #9101 1093426434 sdk1 ext3 114407 62 0.0 1457.5 5 #9101 1093426434 sdl1 ext3 114407 54 0.0 2153.1 6 #9101 1093426434 sdm1
11:33:55.665680 IP lxb0833.cern.ch.37347 > lcgmon002d.cern.ch.12509: UDP, length: 854
[EMAIL PROTECTED] 0 lxb0833#10004 1093426420 4517 5982 0.02 4740 548 0.21 0.54 32948 3032 1.19#10005 1093426420 600#9011 1093426415 0.32 84.64 1.04 14.00 308.74 0#9012 1093426415 176.91 54665#9013 1093426415 192.05 59342#9022 1093426415 39.12 12087 149.17 46094#9023 1093426415 277.23 85664 626.68 193644#9025 1093426415 1811592 284880 20452 1428 0 3364 251540 13.59 98.68#9032 1093426415 0.36 112#9101 1093426417 hda1 ext3 5041 74 15.1 3.9 5 #9101 1093426417 hdc1 ext3 16242 2 28.7 16.1 0 #9101 1093426417 hda3 ext3 12206 0
0.3 1.8 1 #9101 1093426417 hdc3 ext2 1007 73 72.2 4.0 3 #9101 1093426417 hdc2 ext3 2015 10 4.7 4.1 0 #9201 1093426417 131 16 28 0#9202 1093426417 3625105 0.12 4156953 0.14#9203 1093426417 129529 0.02 129529 0.02#.11:33:55.714347 IP alice004d.cern.ch.34478 > lcgmon002d.cern.ch.12509: UDP, length: 106
E....:@.=..........x..0..r.<A0 0 alice004d#10004 1093426435 4507 2165 0.01 4740 1004 0.10 0.17 28076 20176 1.96#10005 1093426435 600#.Explanation: The first payload is 1637 bytes long according to tcpdump, has one printed recorded record that is 676 bytes long (including the binary header),and does not have the correct payload end: #. (the . is added by tcpdump), as the shorter payloads have.
As far as I know, UDP
massages are IP messages, which is in can be
as big as 64K. IP message may consist of a
few Ethernet messages.
Please update me if there is a way to work around
the problem,
or if this is a tcpdump problem.
Thanks
David Front
CERN IT
----- Original Message -----
From: "Guy Harris" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 25, 2004 9:48
AM
Subject: Re: [tcpdump-workers] 'tcpdump -s0'
payload length limit?
>
> > I notice that 'tcpdump -s0' truncates packets with payloads longer than
> > (~1400 or) ~1500 bytes.
> > Is there a way to get full long payloads (or is this due to a (Ethernet MTU)
> > limit, or a tcpdump limitation/bug)?
>
> Is this on Ethernet? If so, why are there packets with payloads longer
> than 1500 bytes? (Are they gigabit Ethernet jumbo frames?)
>
> "-s 0" is equivalent to "-s 65535", which causes tcpdump to supply a
> snapshot length of 65535 to libpcap. 65535 is more than large enough
> for most if not all of the network types libpcap supports.
> -
> This is the tcpdump-workers list.
> Visit https://lists.sandelman.ca/ to unsubscribe.
>