RE: Odd packet capture behavior with Jumbo Ethernet frames.
Brian Cowan <[email protected]> Fri, 19 Apr 2019 14:29:51 -0400
| Newsgroups | gmane.comp.security.nmap.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============0336475139777412383==
Content-Type: multipart/alternative;
boundary="_7750546D-EF1B-42D7-B166-DDF707B2229A_"
--_7750546D-EF1B-42D7-B166-DDF707B2229A_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
When I remove the port filter, I see the data=E2=80=A6 OK, I am an idiot. N=
OW 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 m=
ade 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 =E2=86=92 192.168.7.46 CLEARCASE 134 V3 proc-=
1 Call
2 0.001282 192.168.7.46 =E2=86=92 10.0.2.15 CLEARCASE 78 V3 proc-1=
Reply (Call In 1)
3 0.004064 10.0.2.15 =E2=86=92 192.168.7.46 CLEARCASE 130 V3 proc-=
27 Call
4 0.007742 192.168.7.46 =E2=86=92 10.0.2.15 CLEARCASE 266 V3 proc-=
27 Reply (Call In 3)
5 0.644470 10.0.2.15 =E2=86=92 192.168.7.46 CLEARCASE 210 V3 proc-=
61 Call
6 0.645062 192.168.7.46 =E2=86=92 10.0.2.15 CLEARCASE 78 V3 proc-6=
1 Reply (Call In 5)
7 0.650047 10.0.2.15 =E2=86=92 192.168.7.46 CLEARCASE 182 V3 proc-=
16 Call
8 0.650884 192.168.7.46 =E2=86=92 10.0.2.15 IPv4 1514 Fragmented I=
P protocol (proto=3DUDP 17, off=3D0, ID=3D2192)
9 0.859271 10.0.2.15 =E2=86=92 192.168.7.46 CLEARCASE 182 V3 proc-=
16 Call
10 0.859824 192.168.7.46 =E2=86=92 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 firs=
t time or the snaplen isn=E2=80=99t working. I know the data is traveling a=
cross the network=E2=80=A6
Brian
From: Dario Ciccarone (dciccaro)
Sent: Friday, April 19, 2019 1:24 PM
To: Brian Cowan; [email protected]
Subject: Re: Odd packet capture behavior with Jumbo Ethernet frames.
Did you capture the whole frame to begin with? Remember that both tcpdump a=
nd tshark=C2=A0 default to a 1500-byte snaplen. Use the =E2=80=9C-s=E2=80=
=9D option with appropriate Jumbo size (or 0) while=C2=A0 capturing.=C2=A0=
=20
https://www.wireshark.org/docs/man-pages/tshark.html
From: dev <[email protected]> on behalf of Brian Cowan <[email protected]=
m>
Date: Friday, April 19, 2019 at 12:07 PM
To: "[email protected]" <[email protected]>
Subject: Odd packet capture behavior with Jumbo Ethernet frames.
=C2=A0
Hello all, please forgive me if I don=E2=80=99t completely meet requirement=
s. Literally my first time posting here.
=C2=A0
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.
=C2=A0
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)
=C2=A0
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:
=C2=A0
>>> 11:30:04.306501 IP 10.134.49.78.clearcase > 10.134.57.194.54822: UDP, b=
ad length 4052 > 1472
=C2=A0
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.
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
=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
=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)
=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
=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, off=3D=
0, ID=3D01d0)
=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
=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)
=C2=A0
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
=C2=A0
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
=C2=A0
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
=C2=A0
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.
=C2=A0
Thanks,
=C2=A0
Brian
--_7750546D-EF1B-42D7-B166-DDF707B2229A_
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>When I remove the port filter, I see=
the data=E2=80=A6 OK, I am an idiot. NOW I see the stream getting fragment=
ed 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.=
<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNorm=
al>>C:\Program Files\Wireshark\tshark.exe' -s 16384 -i 3 port 371</p><p =
class=3DMsoNormal>Capturing on 'Ethernet'</p><p class=3DMsoNormal>=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.001282 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=3DMsoNormal>=C2=
=A0=C2=A0=C2=A0 3=C2=A0=C2=A0 0.004064=C2=A0=C2=A0=C2=A0 10.0.2.15 =E2=86=
=92 192.168.7.46 CLEARCASE 130 V3 proc-27 Call</p><p class=3DMsoNormal>=C2=
=A0=C2=A0=C2=A0 4=C2=A0=C2=A0 0.007742 192.168.7.46 =E2=86=92 10.0.2.15=C2=
=A0=C2=A0=C2=A0 CLEARCASE 266 V3 proc-27 Reply (Call In 3)</p><p class=3DMs=
oNormal>=C2=A0=C2=A0=C2=A0 5=C2=A0=C2=A0 0.644470=C2=A0=C2=A0=C2=A0 10.0.2.=
15 =E2=86=92 192.168.7.46 CLEARCASE 210 V3 proc-61 Call</p><p class=3DMsoNo=
rmal>=C2=A0=C2=A0=C2=A0 6=C2=A0=C2=A0 0.645062 192.168.7.46 =E2=86=92 10.0.=
2.15=C2=A0=C2=A0=C2=A0 CLEARCASE 78 V3 proc-61 Reply (Call In 5)</p><p clas=
s=3DMsoNormal>=C2=A0=C2=A0=C2=A0 7 =C2=A0=C2=A00.650047=C2=A0=C2=A0=C2=A0 1=
0.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 8=C2=A0=C2=A0 0.650884 192.168.7.46 =E2=86=
=92 10.0.2.15=C2=A0=C2=A0=C2=A0 IPv4 1514 Fragmented IP protocol (proto=3DU=
DP 17, off=3D0, ID=3D2192)</p><p class=3DMsoNormal>=C2=A0=C2=A0=C2=A0 9=C2=
=A0=C2=A0 0.859271=C2=A0=C2=A0=C2=A0 10.0.2.15 =E2=86=92 192.168.7.46 CLEAR=
CASE 182 V3 proc-16 Call</p><p class=3DMsoNormal>=C2=A0=C2=A0 10=C2=A0=C2=
=A0 0.859824 192.168.7.46 =E2=86=92 10.0.2.15=C2=A0=C2=A0=C2=A0 CLEARCASE 2=
94 V3 proc-16 Reply (Call In 9)</p><p class=3DMsoNormal><o:p> </o:p></=
p><p class=3DMsoNormal>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=E2=80=99t working. I know =
the data is traveling across the network=E2=80=A6</p><p class=3DMsoNormal><=
o:p> </o:p></p><p class=3DMsoNormal>Brian</p><p class=3DMsoNormal><o:p=
> </o:p></p><div style=3D'mso-element:para-border-div;border:none;bord=
er-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoNormal =
style=3D'border:none;padding:0in'><b>From: </b><a href=3D"mailto:dciccaro@c=
isco.com">Dario Ciccarone (dciccaro)</a><br><b>Sent: </b>Friday, April 19, =
2019 1:24 PM<br><b>To: </b><a href=3D"mailto:[email protected]">Brian Cowan=
</a>; <a href=3D"mailto:[email protected]">[email protected]</a><br><b>Subject: </b>R=
e: Odd packet capture behavior with Jumbo Ethernet frames.</p></div><p clas=
s=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>Did you capture the=
whole frame to begin with? Remember that both tcpdump and tshark def=
ault to a 1500-byte snaplen. Use the =E2=80=9C-s=E2=80=9D option with appro=
priate Jumbo size (or 0) while capturing. <o:p></o:p></p><p cla=
ss=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal><a href=3D"https:/=
/www.wireshark.org/docs/man-pages/tshark.html">https://www.wireshark.org/do=
cs/man-pages/tshark.html</a><o:p></o:p></p><p class=3DMsoNormal><o:p> =
</o:p></p><p class=3DMsoNormal><o:p> </o:p></p><div style=3D'border:no=
ne;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMso=
Normal><b><span style=3D'font-size:12.0pt;color:black'>From: </span></b><sp=
an style=3D'font-size:12.0pt;color:black'>dev <[email protected]> =
on behalf of Brian Cowan <[email protected]><br><b>Date: </b>Friday, =
April 19, 2019 at 12:07 PM<br><b>To: </b>"[email protected]" <dev@n=
map.org><br><b>Subject: </b>Odd packet capture behavior with Jumbo Ether=
net frames.<o:p></o:p></span></p></div><div><p class=3DMsoNormal><o:p> =
;</o:p></p></div><p class=3DMsoNormal> <o:p></o:p></p><p class=3DMsoNo=
rmal>Hello all, please forgive me if I don=E2=80=99t completely meet requir=
ements. Literally my first time posting here.<o:p></o:p></p><p class=3DMsoN=
ormal> <o:p></o:p></p><p class=3DMsoNormal>I am attempting a tshark/wi=
reshark 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=E2=80=99t necessarily provide full captures.<o:p></o:p></p><p clas=
s=3DMsoNormal> <o:p></o:p></p><p class=3DMsoNormal>What I am seeing is=
ethernet packets coming in, with UDP lengths more than the packet size. Be=
tter, all the data is actually in the packet. (helps that it=E2=80=99s a UD=
P 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 tr=
uncate the packet display, making it look as if the data is being incomplet=
ely transferred. When I use tcpdump to examine the packets, I see this in t=
he header:<o:p></o:p></p><p class=3DMsoNormal> <o:p></o:p></p><p class=
=3DMsoNormal>>>> 11:30:04.306501 IP 10.134.49.78.clearcase > 10=
.134.57.194.54822: UDP, bad length 4052 > 1472<o:p></o:p></p><p class=3D=
MsoNormal> <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>When I capture the=
packet, this is what tshark tells me:<o:p></o:p></p><p class=3DMsoNormal>P=
S C:\Users\brianc> & 'C:\Program Files\Wireshark\tshark.exe' -i 4 -w=
C:\Users\brianc\Desktop\test4.pcap port 371<o:p></o:p></p><p class=3DMsoNo=
rmal>Capturing on 'Ethernet'<o:p></o:p></p><p class=3DMsoNormal>6<o:p></o:p=
></p><p class=3DMsoNormal>PS C:\Users\brianc> & 'C:\Program Files\Wi=
reshark\tshark.exe' -r C:\Users\brianc\Desktop\test4.pcap<o:p></o:p></p><p =
class=3DMsoNormal> 1 0.000000 &nbs=
p; 10.0.2.15 =E2=86=92 192.168.7.46 CLEARCASE 134 V3 proc-1 Call<o:p></o:p>=
</p><p class=3DMsoNormal> 2 0.001098 192.168.=
7.46 =E2=86=92 10.0.2.15 CLEARCASE 78 V3 proc-1 Reply (Ca=
ll In 1)<o:p></o:p></p><p class=3DMsoNormal> 3  =
; 0.001516 10.0.2.15 =E2=86=92 192.168.7.46 CLEARCASE 182=
V3 proc-16 Call<o:p></o:p></p><p class=3DMsoNormal> 4&nb=
sp; 0.002004 192.168.7.46 =E2=86=92 10.0.2.15 IPv4 =
1514 Fragmented IP protocol (proto=3DUDP 17, off=3D0, ID=3D01d0)<o:p></o:p>=
</p><p class=3DMsoNormal> 5 0.247073 &nb=
sp; 10.0.2.15 =E2=86=92 192.168.7.46 CLEARCASE 182 V3 proc-16 Call<o:=
p></o:p></p><p class=3DMsoNormal> 6 0.247522 =
192.168.7.46 =E2=86=92 10.0.2.15 CLEARCASE 294 V3 proc-16=
Reply (Call In 5)<o:p></o:p></p><p class=3DMsoNormal> <o:p></o:p></p>=
<p class=3DMsoNormal>Tcpdump (Thanks WSL) shows me this for the same captur=
e:<o:p></o:p></p><p class=3DMsoNormal>11:57:09.956178 IP 10.0.2.15.53321 &g=
t; LP3-US-51628051.clearcase: UDP, length 92<o:p></o:p></p><p class=3DMsoNo=
rmal>11:57:09.957276 IP LP3-US-51628051.clearcase > 10.0.2.15.53321: UDP=
, length 36<o:p></o:p></p><p class=3DMsoNormal>11:57:09.957694 IP 10.0.2.15=
.53321 > LP3-US-51628051.clearcase: UDP, length 140<o:p></o:p></p><p cla=
ss=3DMsoNormal>11:57:09.958182 IP LP3-US-51628051.clearcase > 10.0.2.15.=
53321: UDP, bad length 4372 > 1472<o:p></o:p></p><p class=3DMsoNormal>11=
:57:10.203251 IP 10.0.2.15.53321 > LP3-US-51628051.clearcase: UDP, lengt=
h 140<o:p></o:p></p><p class=3DMsoNormal>11:57:10.203700 IP LP3-US-51628051=
.clearcase > 10.0.2.15.53321: UDP, length 252<o:p></o:p></p><p class=3DM=
soNormal> <o:p></o:p></p><p class=3DMsoNormal>What makes things more i=
nteresting 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 o=
n one VirtualBox NAT network but not another=E2=80=A6<o:p></o:p></p><p clas=
s=3DMsoNormal> <o:p></o:p></p><p class=3DMsoNormal>This incidentally a=
lso happens when capturing using Linux/tcpdump, so it=E2=80=99s possible th=
is is upstream behavior depending on how closely related npcap is to libpca=
p. <o:p></o:p></p><p class=3DMsoNormal> <o:p></o:p></p><p class=3DMsoN=
ormal>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 l=
east TELL me about the UDP packet size issue but it doesn=E2=80=99t.<o:p></=
o:p></p><p class=3DMsoNormal> <o:p></o:p></p><p class=3DMsoNormal>Than=
ks,<o:p></o:p></p><p class=3DMsoNormal> <o:p></o:p></p><p class=3DMsoN=
ormal>Brian<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p></div><=
/body></html>=
--_7750546D-EF1B-42D7-B166-DDF707B2229A_--
--===============0336475139777412383==
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/
--===============0336475139777412383==--