[phil_t@xxxxxxxxxxxxx]

Jeff,

Attachment is okay, but is gzipped. On a Win98 system, I just now downloaded the file, changed the extension to .gz (didn't know WinZip was fussy about extensions) & was able to unzip the file, then read uncompressed file with Ethereal.  The file only has the two frames that I was concerned about.

Thanks,

Phil


 ---- you wrote: 
> 
> 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
> 


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