Ethereal-dev: RE: [ethereal-dev] SMB/Lanman problem

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Jeff Foster <jfoste@xxxxxxxxxxxx>
Date: Fri, 11 Aug 2000 07:21:28 -0500
I tried to look at this but can't because the attachment is invalid; it is
only 292 bytes. Please send it again and I will be happy to look at it.

Jeff Foster
jfoste@xxxxxxxxxxxx


-----Original Message-----
From: phil_t@xxxxxxxxxxxxx [mailto:phil_t@xxxxxxxxxxxxx]
Sent: Thursday, August 10, 2000 11:53 PM
To: ethereal-dev@xxxxxxxx
Subject: [ethereal-dev] SMB/Lanman problem


Could someone who knows a little about SMB and Lanman take a look at the
attached capture?  There's at least one problem with how these messages are
decoded/displayed, and possibly a couple more problems.

In capture packet 1:

1) If you select the "Send Buffer Len" under Lanman protocol, the "S" in
"Shopping Cart" (data) is highlighted as part of the buffer length field.

2) How we highlight portions of the hex data doesn't seem consistent with
how we highlight data from other protocols.  Select Netbios, SMB, then
Lanman, and notice how we're highlighting most of the rest of the packet?
I was expecting SMB to highlight just a portion, then SMB the next portion,
then Lanman's section, then data.

3) Select Lanman protocol. The data at the end of the packet isn't
highlighted or marked as such either under Lanman or as another field
(although the data is shown under SMB). I would think for completeness, that
the end of the packet (the data) should be shown as a field, instead of
appearing to drop the packet analysis in the middle of the packet.

In capture packet 2:

1) Expand the Lanman protocol. Select "PrintJobInfo Response". Nothing in
the packet is highlighted.  I'm guessing that we know this is the answer to
packet 1 because of the MID and/or other fields? If so, we might want to
note this somewhere on the display.

2) Select "Convert" - the last byte of the message is left without
explanation or highlighting. I think we should mark it as whatever it is:
padding/field/data.

Sorry I don't have any fixes for these items.  I looked around online a
little for some good documentation on these protocols, but didn't stumble
across anything...suggestions welcomed.

I've zipped the edited capture file and named it so that it should survive
the mail ride.

Richard - thanks for the user documentation (you're saving me from having to
write it for my boss).

Thanks,

Phil Techau

----------------------------------------------------------------
Get your free email from AltaVista at http://altavista.iname.com