Odd packet capture behavior with Jumbo Ethernet frames.
Brian Cowan <[email protected]> Fri, 19 Apr 2019 12:06:58 -0400
| Newsgroups | gmane.comp.security.nmap.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============3097488035512390925==
Content-Type: multipart/alternative;
boundary="_4037C307-D1C7-4A58-A56E-93B61D9F39D9_"
--_4037C307-D1C7-4A58-A56E-93B61D9F39D9_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
Hello all, please forgive me if I don=E2=80=99t completely meet requirement=
s. Literally my first time posting here.
I am attempting a tshark/wireshark capture on an Ethernet network that appe=
ars to support jumbo frames. The network in question is a VMWare internal n=
etwork, and in production, so I can=E2=80=99t necessarily provide full capt=
ures.
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 tha=
t it=E2=80=99s a UDP transfer of cleartext=E2=80=A6)
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, b=
ad length 4052 > 1472
And, I can see that the data I am looking for is in fact in the packet usin=
g =E2=80=9Cstrings=E2=80=9D on the packet.
=20
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:\Us=
ers\brianc\Desktop\test4.pcap port 371
Capturing on 'Ethernet'
6
PS C:\Users\brianc> & 'C:\Program Files\Wireshark\tshark.exe' -r C:\Users\b=
rianc\Desktop\test4.pcap
1 0.000000 10.0.2.15 =E2=86=92 192.168.7.46 CLEARCASE 134 V3 proc-=
1 Call
2 0.001098 192.168.7.46 =E2=86=92 10.0.2.15 CLEARCASE 78 V3 proc-1=
Reply (Call In 1)
3 0.001516 10.0.2.15 =E2=86=92 192.168.7.46 CLEARCASE 182 V3 proc-=
16 Call
4 0.002004 192.168.7.46 =E2=86=92 10.0.2.15 IPv4 1514 Fragmented I=
P protocol (proto=3DUDP 17, off=3D0, ID=3D01d0)
5 0.247073 10.0.2.15 =E2=86=92 192.168.7.46 CLEARCASE 182 V3 proc-=
16 Call
6 0.247522 192.168.7.46 =E2=86=92 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 le=
ngth 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=E2=80=
=A6
This incidentally also happens when capturing using Linux/tcpdump, so it=E2=
=80=99s possible this is upstream behavior depending on how closely related=
npcap is to libpcap.=20
Any hints would be appreciated, because this is (frankly) driving me insane=
. I=E2=80=99ve entered a tshark/wireshark defect since it should at least T=
ELL me about the UDP packet size issue but it doesn=E2=80=99t.
Thanks,
Brian
--_4037C307-D1C7-4A58-A56E-93B61D9F39D9_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc=
hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of=
fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta ht=
tp-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta name=
=3DGenerator content=3D"Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=3DEN-US link=3Dblue vlink=3D"#954F72"><div cla=
ss=3DWordSection1><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoN=
ormal>Hello all, please forgive me if I don=E2=80=99t completely meet requi=
rements. Literally my first time posting here.<o:p></o:p></p><p class=3DMso=
Normal><o:p> </o:p></p><p class=3DMsoNormal>I am attempting a tshark/w=
ireshark capture on an Ethernet network that appears to support jumbo frame=
s. The network in question is a VMWare internal network, and in production,=
so I can=E2=80=99t necessarily provide full captures.<o:p></o:p></p><p cla=
ss=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>What I am seeing i=
s ethernet packets coming in, with UDP lengths more than the packet size. B=
etter, all the data is actually in the packet. (helps that it=E2=80=99s a U=
DP transfer of cleartext=E2=80=A6)<o:p></o:p></p><p class=3DMsoNormal><o:p>=
</o:p></p><p class=3DMsoNormal>When I use tshark or wireshark, they t=
runcate the packet display, making it look as if the data is being incomple=
tely transferred. When I use tcpdump to examine the packets, I see this in =
the header:<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p clas=
s=3DMsoNormal>>>> 11:30:04.306501 IP 10.134.49.78.clearcase > 1=
0.134.57.194.54822: UDP, bad length 4052 > 1472<o:p></o:p></p><p class=
=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>And, I can see that =
the data I am looking for is in fact in the packet using =E2=80=9Cstrings=
=E2=80=9D on the packet.<o:p></o:p></p><p class=3DMsoNormal> <o:p></o:p></p=
><p class=3DMsoNormal>When I capture the packet, this is what tshark tells =
me:</p><p class=3DMsoNormal>PS C:\Users\brianc> & 'C:\Program Files\=
Wireshark\tshark.exe' -i 4 -w C:\Users\brianc\Desktop\test4.pcap port 371</=
p><p class=3DMsoNormal>Capturing on 'Ethernet'</p><p class=3DMsoNormal>6</p=
><p class=3DMsoNormal>PS C:\Users\brianc> & 'C:\Program Files\Wiresh=
ark\tshark.exe' -r C:\Users\brianc\Desktop\test4.pcap</p><p class=3DMsoNorm=
al>=C2=A0=C2=A0=C2=A0 1=C2=A0=C2=A0 0.000000=C2=A0=C2=A0=C2=A0 10.0.2.15 =
=E2=86=92 192.168.7.46 CLEARCASE 134 V3 proc-1 Call</p><p class=3DMsoNormal=
>=C2=A0=C2=A0=C2=A0 2=C2=A0=C2=A0 0.001098 192.168.7.46 =E2=86=92 10.0.2.15=
=C2=A0=C2=A0=C2=A0 CLEARCASE 78 V3 proc-1 Reply (Call In 1)</p><p class=3DM=
soNormal>=C2=A0=C2=A0=C2=A0 3=C2=A0=C2=A0 0.001516=C2=A0=C2=A0=C2=A0 10.0.2=
.15 =E2=86=92 192.168.7.46 CLEARCASE 182 V3 proc-16 Call</p><p class=3DMsoN=
ormal>=C2=A0=C2=A0=C2=A0 4=C2=A0=C2=A0 0.002004 192.168.7.46 =E2=86=92 10.0=
.2.15=C2=A0=C2=A0=C2=A0 IPv4 1514 Fragmented IP protocol (proto=3DUDP 17, o=
ff=3D0, ID=3D01d0)</p><p class=3DMsoNormal>=C2=A0=C2=A0=C2=A0 5=C2=A0=C2=A0=
0.247073=C2=A0=C2=A0=C2=A0 10.0.2.15 =E2=86=92 192.168.7.46 CLEARCASE 182 =
V3 proc-16 Call</p><p class=3DMsoNormal>=C2=A0=C2=A0=C2=A0 6=C2=A0=C2=A0 0.=
247522 192.168.7.46 =E2=86=92 10.0.2.15=C2=A0=C2=A0=C2=A0 CLEARCASE 294 V3 =
proc-16 Reply (Call In 5)</p><p class=3DMsoNormal><o:p> </o:p></p><p c=
lass=3DMsoNormal>Tcpdump (Thanks WSL) shows me this for the same capture:</=
p><p class=3DMsoNormal>11:57:09.956178 IP 10.0.2.15.53321 > LP3-US-51628=
051.clearcase: UDP, length 92</p><p class=3DMsoNormal>11:57:09.957276 IP LP=
3-US-51628051.clearcase > 10.0.2.15.53321: UDP, length 36</p><p class=3D=
MsoNormal>11:57:09.957694 IP 10.0.2.15.53321 > LP3-US-51628051.clearcase=
: UDP, length 140</p><p class=3DMsoNormal>11:57:09.958182 IP LP3-US-5162805=
1.clearcase > 10.0.2.15.53321: UDP, bad length 4372 > 1472</p><p clas=
s=3DMsoNormal>11:57:10.203251 IP 10.0.2.15.53321 > LP3-US-51628051.clear=
case: UDP, length 140</p><p class=3DMsoNormal>11:57:10.203700 IP LP3-US-516=
28051.clearcase > 10.0.2.15.53321: UDP, length 252</p><p class=3DMsoNorm=
al><o:p> </o:p></p><p class=3DMsoNormal>What makes things more interes=
ting is that it happens on some, but not all, networks, and some, but not a=
ll, hosts. For example, I can reproduce it on my production VM, and on one =
VirtualBox NAT network but not another=E2=80=A6<o:p></o:p></p><p class=3DMs=
oNormal><o:p> </o:p></p><p class=3DMsoNormal>This incidentally also ha=
ppens when capturing using Linux/tcpdump, so it=E2=80=99s possible this is =
upstream behavior depending on how closely related npcap is to libpcap. <o:=
p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>=
Any hints would be appreciated, because this is (frankly) driving me insane=
. I=E2=80=99ve entered a tshark/wireshark defect since it should at least T=
ELL me about the UDP packet size issue but it doesn=E2=80=99t.</p><p class=
=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Thanks,</p><p class=
=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Brian</p></div></bod=
y></html>=
--_4037C307-D1C7-4A58-A56E-93B61D9F39D9_--
--===============3097488035512390925==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/
--===============3097488035512390925==--