Nmap Development mailing list archives
Re: Odd packet capture behavior with Jumbo Ethernet frames.
From: "Dario Ciccarone \(dciccaro\) via dev" <dev () nmap org>
Date: Fri, 19 Apr 2019 17:24:56 +0000
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/
Current thread:
- Odd packet capture behavior with Jumbo Ethernet frames. Brian Cowan (Apr 19)
- Re: Odd packet capture behavior with Jumbo Ethernet frames. Dario Ciccarone (dciccaro) via dev (Apr 19)
- RE: Odd packet capture behavior with Jumbo Ethernet frames. Brian Cowan (Apr 19)
- Re: Odd packet capture behavior with Jumbo Ethernet frames. Dario Ciccarone (dciccaro) via dev (Apr 19)