RE: Odd packet capture behavior with Jumbo Ethernet frames.

[Brian Cowan <brcowan () gmail com>]

When I remove the port filter, I see the data… OK, I am an idiot. NOW I see the stream getting fragmented and 
reassembled. It looks like I got UDP and TCP behavior confused. Mea Culpa. Let me close a few things as I made a rather 
public idiot of myself.

> C:\Program Files\Wireshark\tshark.exe' -s 16384 -i 3 port 371
Capturing on 'Ethernet'
    1   0.000000    10.0.2.15 → 192.168.7.46 CLEARCASE 134 V3 proc-1 Call
    2   0.001282 192.168.7.46 → 10.0.2.15    CLEARCASE 78 V3 proc-1 Reply (Call In 1)
    3   0.004064    10.0.2.15 → 192.168.7.46 CLEARCASE 130 V3 proc-27 Call
    4   0.007742 192.168.7.46 → 10.0.2.15    CLEARCASE 266 V3 proc-27 Reply (Call In 3)
    5   0.644470    10.0.2.15 → 192.168.7.46 CLEARCASE 210 V3 proc-61 Call
    6   0.645062 192.168.7.46 → 10.0.2.15    CLEARCASE 78 V3 proc-61 Reply (Call In 5)
    7   0.650047    10.0.2.15 → 192.168.7.46 CLEARCASE 182 V3 proc-16 Call
    8   0.650884 192.168.7.46 → 10.0.2.15    IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=2192)
    9   0.859271    10.0.2.15 → 192.168.7.46 CLEARCASE 182 V3 proc-16 Call
   10   0.859824 192.168.7.46 → 10.0.2.15    CLEARCASE 294 V3 proc-16 Reply (Call In 9)

And the tshark -r shows the same thing when save the capture to a file. And now the traces are actually missing data. 
So either I missed this the first time or the snaplen isn’t working. I know the data is traveling across the network…

Brian

From: Dario Ciccarone (dciccaro)
Sent: Friday, April 19, 2019 1:24 PM
To: Brian Cowan; dev () nmap org
Subject: Re: Odd packet capture behavior with Jumbo Ethernet frames.

Did you capture the whole frame to begin with? Remember that both tcpdump and tshark  default to a 1500-byte snaplen. 
Use the “-s” option with appropriate Jumbo size (or 0) while  capturing.  

https://www.wireshark.org/docs/man-pages/tshark.html


From: dev <dev-bounces () nmap org> on behalf of Brian Cowan <brcowan () gmail com>
Date: Friday, April 19, 2019 at 12:07 PM
To: "dev () nmap org" <dev () nmap org>
Subject: Odd packet capture behavior with Jumbo Ethernet frames.

 
Hello all, please forgive me if I don’t completely meet requirements. Literally my first time posting here.
 
I am attempting a tshark/wireshark capture on an Ethernet network that appears to support jumbo frames. The network in 
question is a VMWare internal network, and in production, so I can’t necessarily provide full captures.
 
What I am seeing is ethernet packets coming in, with UDP lengths more than the packet size. Better, all the data is 
actually in the packet. (helps that it’s a UDP transfer of cleartext…)
 
When I use tshark or wireshark, they truncate the packet display, making it look as if the data is being incompletely 
transferred. When I use tcpdump to examine the packets, I see this in the header:
 
> > > 11:30:04.306501 IP 10.134.49.78.clearcase > 10.134.57.194.54822: UDP, bad length 4052 > 1472
 
And, I can see that the data I am looking for is in fact in the packet using “strings” on the packet.
When I capture the packet, this is what tshark tells me:
PS C:\Users\brianc> & 'C:\Program Files\Wireshark\tshark.exe' -i 4 -w C:\Users\brianc\Desktop\test4.pcap port 371
Capturing on 'Ethernet'
6
PS C:\Users\brianc> & 'C:\Program Files\Wireshark\tshark.exe' -r C:\Users\brianc\Desktop\test4.pcap
    1   0.000000    10.0.2.15 → 192.168.7.46 CLEARCASE 134 V3 proc-1 Call
    2   0.001098 192.168.7.46 → 10.0.2.15    CLEARCASE 78 V3 proc-1 Reply (Call In 1)
    3   0.001516    10.0.2.15 → 192.168.7.46 CLEARCASE 182 V3 proc-16 Call
    4   0.002004 192.168.7.46 → 10.0.2.15    IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=01d0)
    5   0.247073    10.0.2.15 → 192.168.7.46 CLEARCASE 182 V3 proc-16 Call
    6   0.247522 192.168.7.46 → 10.0.2.15    CLEARCASE 294 V3 proc-16 Reply (Call In 5)
 
Tcpdump (Thanks WSL) shows me this for the same capture:
11:57:09.956178 IP 10.0.2.15.53321 > LP3-US-51628051.clearcase: UDP, length 92
11:57:09.957276 IP LP3-US-51628051.clearcase > 10.0.2.15.53321: UDP, length 36
11:57:09.957694 IP 10.0.2.15.53321 > LP3-US-51628051.clearcase: UDP, length 140
11:57:09.958182 IP LP3-US-51628051.clearcase > 10.0.2.15.53321: UDP, bad length 4372 > 1472
11:57:10.203251 IP 10.0.2.15.53321 > LP3-US-51628051.clearcase: UDP, length 140
11:57:10.203700 IP LP3-US-51628051.clearcase > 10.0.2.15.53321: UDP, length 252
 
What makes things more interesting is that it happens on some, but not all, networks, and some, but not all, hosts. For 
example, I can reproduce it on my production VM, and on one VirtualBox NAT network but not another…
 
This incidentally also happens when capturing using Linux/tcpdump, so it’s possible this is upstream behavior depending 
on how closely related npcap is to libpcap. 
 
Any hints would be appreciated, because this is (frankly) driving me insane. I’ve entered a tshark/wireshark defect 
since it should at least TELL me about the UDP packet size issue but it doesn’t.
 
Thanks,
 
Brian

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/