Re: [tcpdump-workers] 'tcpdump -s0' payload length limit?
Hello Guy Harris Thanks for the detailed answer! David Front CERN IT - Original Message - From: "Guy Harris" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, August 25, 2004 8:18 PM Subject: Re: [tcpdump-workers] 'tcpdump -s0' payload length limit? > > On Aug 25, 2004, at 11:09 AM, Guy Harris wrote: > > > Note, however, that the reassembly is *NOT* done at the low-layer > > capture level, so a capture filter of "port 12509" will only capture > > the first fragment of a fragmented datagram, and Ethereal and > > Tethereal will *NOT* be able to reassemble the packet. You would have > > to specify a filter that looks only at the IP headers, such as a > > filter that checks for UDP, or that checks for UDP traffic between two > > particular hosts, in order to capture *all* the fragments. > > Or you could use a filter that captures traffic to/from port 12509 *or* > that has a non-zero fragment offset, so it captures port 12509 traffic > *and* all fragments other than first/only fragments. That might > capture fragments that you don't need, but that's the best you can do. > Constructing such a filter is left as an exercise to the reader. > > Such a filter, used with tcpdump, would get the subsequent fragments; > tcpdump wouldn't reassemble them, but it'd at least print them, which > might be enough. > > - > This is the tcpdump-workers list. > Visit https://lists.sandelman.ca/ to unsubscribe. > - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] 'tcpdump -s0' payload length limit?
On Aug 25, 2004, at 11:09 AM, Guy Harris wrote: Note, however, that the reassembly is *NOT* done at the low-layer capture level, so a capture filter of "port 12509" will only capture the first fragment of a fragmented datagram, and Ethereal and Tethereal will *NOT* be able to reassemble the packet. You would have to specify a filter that looks only at the IP headers, such as a filter that checks for UDP, or that checks for UDP traffic between two particular hosts, in order to capture *all* the fragments. Or you could use a filter that captures traffic to/from port 12509 *or* that has a non-zero fragment offset, so it captures port 12509 traffic *and* all fragments other than first/only fragments. That might capture fragments that you don't need, but that's the best you can do. Constructing such a filter is left as an exercise to the reader. Such a filter, used with tcpdump, would get the subsequent fragments; tcpdump wouldn't reassemble them, but it'd at least print them, which might be enough. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] 'tcpdump -s0' payload length limit?
On Aug 25, 2004, at 11:05 AM, David Front wrote: 11:33:55.601653 IP lxfs5623.cern.ch.32962 > lcgmon002d.cern.ch.12509: UDP, length: 1637 "UDP, length: 1637" means that the *UDP* packet length is 1637 bytes. That doesn't mean that the *Ethernet* packet is 1637 bytes, as you note later: IP message may consist of a few Ethernet messages. A 1637-byte UDP message will be put inside a single IP message - but if you send that over Ethernet, it will be split into two fragments, each one in a separate Ethernet message. Tcpdump doesn't reassemble fragmented IP datagrams, so it'll only print the data in the first fragment. Please update me if there is a way to work around the problem, or if this is a tcpdump problem. It's a tcpdump problem (having nothing to do with truncating Ethernet packets - the Ethernet packet packet really *is* that short), but there is a workaround - use a network analyzer that *does* reassemble fragmented IP datagrams. Ethereal and Tethereal will reassemble fragmented IP datagrams, if configured to do so. Note, however, that the reassembly is *NOT* done at the low-layer capture level, so a capture filter of "port 12509" will only capture the first fragment of a fragmented datagram, and Ethereal and Tethereal will *NOT* be able to reassemble the packet. You would have to specify a filter that looks only at the IP headers, such as a filter that checks for UDP, or that checks for UDP traffic between two particular hosts, in order to capture *all* the fragments. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] 'tcpdump -s0' payload length limit?
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/tcpdummedtcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes1000 packets captured1000 packets received by filter0 packets dropped by kernel 2) Relevant part from the result: 11:33:55.601653 IP lxfs5623.cern.ch.32962 > lcgmon002d.cern.ch.12509: UDP, length: 1637E.`.=..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 sdm111: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: 106E:@.=..x..0..r.#. 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? > David Front wrote:> > > 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
Re: [tcpdump-workers] 'tcpdump -s0' payload length limit?
David Front wrote: 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.
[tcpdump-workers] 'tcpdump -s0' payload length limit?
Hello 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)? Thanks David Front CERN, IT - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
