Re: Odd packet capture behavior with Jumbo Ethernet frames.

["Dario Ciccarone \(dciccaro\) via dev" <dev () nmap org>]

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/