Nmap Development mailing list archives
RE: Odd packet capture behavior with Jumbo Ethernet frames.
From: Brian Cowan <brcowan () gmail com>
Date: Fri, 19 Apr 2019 14:29:51 -0400
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/
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)