Greetings,
Kernel version is 2.5.7-pre2 if that matters.
I was reading lkml with a forgotten tcpdump running, when my son turned
on his windows box, blessing me with the usual msjunk. Is the attached
just a tcpdump bug? I had already read that message, and didn't really
expect to see it again.. not in my tcpdump log anyway :)
-Mike
On 18 March 2002 15:20, Mike Galbraith wrote:
> Greetings,
>
> Kernel version is 2.5.7-pre2 if that matters.
>
> I was reading lkml with a forgotten tcpdump running, when my son turned
> on his windows box, blessing me with the usual msjunk. Is the attached
> just a tcpdump bug? I had already read that message, and didn't really
> expect to see it again.. not in my tcpdump log anyway :)
8-( We need SMB experts here...
I presume your box is a Linux one.
Is this packet went from your box to win box?
What was running on your box? Samba?
Did you use smbfs?
16:42:49.412862 10.0.0.101.netbios-dgm > 10.255.255.255.netbios-dgm:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
bcast from your box to NetBIOS port?
>>> NBT UDP PACKET(138) Res=0x1102 ID=0x54 IP=10.0.0.101 Port=138 Length=193
Res2=0x0
SourceName=T1H6I3 NameType=0x00 (Workstation)
^^^^^^ your hostname?
DestName=
SMB PACKET: SMBunknown (REQUEST)
SMB Command = 0x43
Error class = 0x46
Error code = 20550
Flags1 = 0x45
Flags2 = 0x4E
Tree ID = 17990
Proc ID = 18000
UID = 16720
MID = 16707
Word Count = 66
SMBError = ERROR: Unknown error (70,20550)
--
vda
On Tue, 19 Mar 2002, Denis Vlasenko wrote:
> On 18 March 2002 15:20, Mike Galbraith wrote:
> > Greetings,
> >
> > Kernel version is 2.5.7-pre2 if that matters.
> >
> > I was reading lkml with a forgotten tcpdump running, when my son turned
> > on his windows box, blessing me with the usual msjunk. Is the attached
> > just a tcpdump bug? I had already read that message, and didn't really
> > expect to see it again.. not in my tcpdump log anyway :)
>
> 8-( We need SMB experts here...
> I presume your box is a Linux one.
Yes.
> Is this packet went from your box to win box?
No, it looks to me like tcpdump just gets uncleared pages, makes a
booboo while processing ms packet and spits out old page content.
(security doesn't matter to me, but I figured maybe it shouldn't be
doing that.. worth sending a note just in case)
> What was running on your box? Samba?
> Did you use smbfs?
No samba here. (configured in, but I never found a round-tuit)
>
> 16:42:49.412862 10.0.0.101.netbios-dgm > 10.255.255.255.netbios-dgm:
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> bcast from your box to NetBIOS port?
> >>> NBT UDP PACKET(138) Res=0x1102 ID=0x54 IP=10.0.0.101 Port=138 Length=193
> Res2=0x0
> SourceName=T1H6I3 NameType=0x00 (Workstation)
> ^^^^^^ your hostname?
No, that's my son's winbox.
> DestName=
> SMB PACKET: SMBunknown (REQUEST)
> SMB Command = 0x43
> Error class = 0x46
> Error code = 20550
> Flags1 = 0x45
> Flags2 = 0x4E
> Tree ID = 17990
> Proc ID = 18000
> UID = 16720
> MID = 16707
> Word Count = 66
> SMBError = ERROR: Unknown error (70,20550)
> --
> vda
-Mike
Sorry, I lost track of attributions. Need more coffee,
> > 16:42:49.412862 10.0.0.101.netbios-dgm > 10.255.255.255.netbios-dgm:
> > >>> NBT UDP PACKET(138) Res=0x1102 ID=0x54 IP=10.0.0.101 Port=138 Length=193
> > Res2=0x0
> > SourceName=T1H6I3 NameType=0x00 (Workstation)
> > DestName=
> > SMB PACKET: SMBunknown (REQUEST)
> > SMB Command = 0x43
> > Error class = 0x46
> > Error code = 20550
> > Flags1 = 0x45
> > Flags2 = 0x4E
> > Tree ID = 17990
> > Proc ID = 18000
> > UID = 16720
> > MID = 16707
> > Word Count = 66
> > SMBError = ERROR: Unknown error (70,20550)
This looks like standard SMB garbage. It probably repeats on a regular
basis. From what I remember, I think it is a Windows box browsing
the network trying to discover other SMB boxes, finding a 'master
browser', and other such stuff.
I see it all the time when there are Windows machines about, and I'm
running tcpdump.
I imagine that someone who knows better, such as the Samba guys, would be
able to tell you exactly whats going on, and maybe some other interesting
tidbits of information.
(I hate SMB ... its really chatty ...)
--
-- John E. Jasen ([email protected])
-- User Error #2361: Please insert coffee and try again.
On Tue, 19 Mar 2002, John Jasen wrote:
> Sorry, I lost track of attributions. Need more coffee,
>
>
> > > 16:42:49.412862 10.0.0.101.netbios-dgm > 10.255.255.255.netbios-dgm:
> > > >>> NBT UDP PACKET(138) Res=0x1102 ID=0x54 IP=10.0.0.101 Port=138 Length=193
> > > Res2=0x0
> > > SourceName=T1H6I3 NameType=0x00 (Workstation)
> > > DestName=
> > > SMB PACKET: SMBunknown (REQUEST)
> > > SMB Command = 0x43
> > > Error class = 0x46
> > > Error code = 20550
> > > Flags1 = 0x45
> > > Flags2 = 0x4E
> > > Tree ID = 17990
> > > Proc ID = 18000
> > > UID = 16720
> > > MID = 16707
> > > Word Count = 66
> > > SMBError = ERROR: Unknown error (70,20550)
>
> This looks like standard SMB garbage. It probably repeats on a regular
> basis. From what I remember, I think it is a Windows box browsing
> the network trying to discover other SMB boxes, finding a 'master
> browser', and other such stuff.
Yeah, this part is normal loking junk. The abby-normal looking
bit got snipped :)
-Mike
On Tue, Mar 19, 2002 at 09:20:25AM -0500, John Jasen wrote:
> > > 16:42:49.412862 10.0.0.101.netbios-dgm > 10.255.255.255.netbios-dgm:
> > > >>> NBT UDP PACKET(138) Res=0x1102 ID=0x54 IP=10.0.0.101 Port=138 Length=193
> > > Res2=0x0
> > > SourceName=T1H6I3 NameType=0x00 (Workstation)
> > > DestName=
> > > SMB PACKET: SMBunknown (REQUEST)
> > > SMB Command = 0x43
> > > Error class = 0x46
> > > Error code = 20550
> > > Flags1 = 0x45
> > > Flags2 = 0x4E
> > > Tree ID = 17990
> > > Proc ID = 18000
> > > UID = 16720
> > > MID = 16707
> > > Word Count = 66
> > > SMBError = ERROR: Unknown error (70,20550)
>
> This looks like standard SMB garbage. It probably repeats on a regular
> basis. From what I remember, I think it is a Windows box browsing
> the network trying to discover other SMB boxes, finding a 'master
> browser', and other such stuff.
>
> I see it all the time when there are Windows machines about, and I'm
> running tcpdump.
>
> I imagine that someone who knows better, such as the Samba guys, would be
> able to tell you exactly whats going on, and maybe some other interesting
> tidbits of information.
>
> (I hate SMB ... its really chatty ...)
That's not the problem part of the tcpdump output. The problem is that part
of an email previously read on the linux box (with no samba runing. (also,
no smbfs MikeG?)) showed up in the tcpdump output...
On Tue, 19 Mar 2002, Mike Fedyk wrote:
> On Tue, Mar 19, 2002 at 09:20:25AM -0500, John Jasen wrote:
> > > > 16:42:49.412862 10.0.0.101.netbios-dgm > 10.255.255.255.netbios-dgm:
> > > > >>> NBT UDP PACKET(138) Res=0x1102 ID=0x54 IP=10.0.0.101 Port=138 Length=193
> > > > Res2=0x0
> > > > SourceName=T1H6I3 NameType=0x00 (Workstation)
> > > > DestName=
> > > > SMB PACKET: SMBunknown (REQUEST)
> > > > SMB Command = 0x43
> > > > Error class = 0x46
> > > > Error code = 20550
> > > > Flags1 = 0x45
> > > > Flags2 = 0x4E
> > > > Tree ID = 17990
> > > > Proc ID = 18000
> > > > UID = 16720
> > > > MID = 16707
> > > > Word Count = 66
> > > > SMBError = ERROR: Unknown error (70,20550)
> >
> > This looks like standard SMB garbage. It probably repeats on a regular
> > basis. From what I remember, I think it is a Windows box browsing
> > the network trying to discover other SMB boxes, finding a 'master
> > browser', and other such stuff.
> >
> > I see it all the time when there are Windows machines about, and I'm
> > running tcpdump.
> >
> > I imagine that someone who knows better, such as the Samba guys, would be
> > able to tell you exactly whats going on, and maybe some other interesting
> > tidbits of information.
> >
> > (I hate SMB ... its really chatty ...)
>
> That's not the problem part of the tcpdump output. The problem is that part
> of an email previously read on the linux box (with no samba runing. (also,
> no smbfs MikeG?)) showed up in the tcpdump output...
Yes. That's exactly what worried me. (no clue as to security issues)
-Mike
On Tue, Mar 19, 2002 at 07:56:27PM +0100, Mike Galbraith wrote:
> On Tue, 19 Mar 2002, Mike Fedyk wrote:
> > That's not the problem part of the tcpdump output. The problem is that part
> > of an email previously read on the linux box (with no samba runing. (also,
> > no smbfs MikeG?)) showed up in the tcpdump output...
>
> Yes. That's exactly what worried me. (no clue as to security issues)
What computer is 10.0.0.101?
On Mar 19, 2002 10:11 -0800, Mike Fedyk wrote:
> That's not the problem part of the tcpdump output. The problem is that part
> of an email previously read on the linux box (with no samba runing. (also,
> no smbfs MikeG?)) showed up in the tcpdump output...
I haven't been following the whole thread, but it is _possible_ that the
email data was written to the end of a data block which was later re-used
for a file exported via SMB. Depending on how the SMB code works, is it
possible that it is sending a whole block of data to the client and/or
not zeroing out new blocks?
Of course (not having looked at the original tcpdump output), is it
possible that the email was captured by tcpdump because it arrived on
the host via the network?
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
On Tue, Mar 19, 2002 at 08:47:34AM -0700, Andreas Dilger wrote:
> On Mar 19, 2002 10:11 -0800, Mike Fedyk wrote:
> > That's not the problem part of the tcpdump output. The problem is that part
> > of an email previously read on the linux box (with no samba runing. (also,
> > no smbfs MikeG?)) showed up in the tcpdump output...
>
> I haven't been following the whole thread, but it is _possible_ that the
> email data was written to the end of a data block which was later re-used
> for a file exported via SMB. Depending on how the SMB code works, is it
> possible that it is sending a whole block of data to the client and/or
> not zeroing out new blocks?
>
> Of course (not having looked at the original tcpdump output), is it
> possible that the email was captured by tcpdump because it arrived on
> the host via the network?
>
I'm still waiting to find out what computer 10.0.0.101 is for MikeG...
But, he's not running samba or smbfs, and the email was encoded within a smb
packet...
On Tue, 19 Mar 2002, Andreas Dilger wrote:
> On Mar 19, 2002 10:11 -0800, Mike Fedyk wrote:
> > That's not the problem part of the tcpdump output. The problem is that part
> > of an email previously read on the linux box (with no samba runing. (also,
> > no smbfs MikeG?)) showed up in the tcpdump output...
>
The data sent/received on the network is precious. You will not have
any 'extra' data on its end except for possibly a single byte if the
data didn't have an even length. Note that these things are checksummed
and also CRCed in the hardware.
If you got part of somebody's email, I think you should look at
the `tcpdump` source. It may be the culprit...
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.
On Tue, 19 Mar 2002, Andreas Dilger wrote:
> On Mar 19, 2002 10:11 -0800, Mike Fedyk wrote:
> > That's not the problem part of the tcpdump output. The problem is that part
> > of an email previously read on the linux box (with no samba runing. (also,
> > no smbfs MikeG?)) showed up in the tcpdump output...
>
> I haven't been following the whole thread, but it is _possible_ that the
> email data was written to the end of a data block which was later re-used
> for a file exported via SMB. Depending on how the SMB code works, is it
> possible that it is sending a whole block of data to the client and/or
> not zeroing out new blocks?
There was no SMB involved on the box that errors and as I understand it
the email never touched the windows box involved. I think this is just
tcpdump misbehaving.
I'm guessing that Mike ran tcpdump with no -s parameter. The tcpdump
decoder (for SMB and probably others) doesn't seem to look at how much
data is valid when it decodes. At least I believe that I have seen it
do that before and/or when playing with some decode to ascii patch.
The SMB part that is decoded is ridiculous. word count of 66 (10-15 yes,
lots of those but 66?). The Flags do not match what any server I know of
returns.
Further, when there is a smb error return normally the rest of the packet
is empty. And the (known) error classes are 0, 1, 2, 3, not 0x46. Some of
the "parameter words" (smb_vwv) looks suspicously like ascii data.
Like you say, if the tcpdump was running while the email was received on
Mike's box it is possible that it had that data in some buffer. When it
later got this message (in another buffer) and tried to decode it, it
decoded the length the message said it had and simply spewed out random
bytes from memory.
Someone that feels like doing some hex to ascii conversion can find work
here:
http://www.lib.uaa.alaska.edu/linux-kernel/archive/2002-Week-11/att-x_
/Urban
> The data sent/received on the network is precious. You will not have
> any 'extra' data on its end except for possibly a single byte if the
> data didn't have an even length. Note that these things are checksummed
> and also CRCed in the hardware.
Wrong for ethernet. Ethernet has a minimum frame size
Alan
Alan Cox wrote:
>>The data sent/received on the network is precious. You will not have
>>any 'extra' data on its end except for possibly a single byte if the
You will have padding if the ethernet packet is less than 60 bytes and
if necessary it will be more than a single byte. I am not sure what is
the value of the paddin bythes though. May be zero..
Petko
On Tue, 19 Mar 2002, Mike Fedyk wrote:
> On Tue, Mar 19, 2002 at 07:56:27PM +0100, Mike Galbraith wrote:
> > On Tue, 19 Mar 2002, Mike Fedyk wrote:
> > > That's not the problem part of the tcpdump output. The problem is that part
> > > of an email previously read on the linux box (with no samba runing. (also,
> > > no smbfs MikeG?)) showed up in the tcpdump output...
> >
> > Yes. That's exactly what worried me. (no clue as to security issues)
>
> What computer is 10.0.0.101?
My son's win98 box. I'm ~positive that the message did _not_ propagate
to my son's box and come back via net.. local data exposed probably via
page return.
-Mike
On Tue, 19 Mar 2002, Urban Widmark wrote:
> I'm guessing that Mike ran tcpdump with no -s parameter. The tcpdump
Correct.
> Like you say, if the tcpdump was running while the email was received on
> Mike's box it is possible that it had that data in some buffer. When it
> later got this message (in another buffer) and tried to decode it, it
> decoded the length the message said it had and simply spewed out random
> bytes from memory.
Hmm. There were other 'packets' containing binary data and ascii which I'm
pretty sure was not part of any network traffic.
I'll repeat this, and post a follow-up if I see anything which is definitely
not received data. For now, I'll assume that it's a harmless tcpdump booboo.
Thanks,
-Mike