Title: RE: [Ethereal-users] bug with LANMAN NetShareEnum Reponse decoding
To be honest, I have not heard of amd ( except for the competitor of intel ).
lisa actually nmblookup of samba. It assumes nmblookup is in your PATH. I'll check what version of samba I have and see if there are later versions that fixes the problem you mentioned with tid, uid, mid, pid, etc.
Does your last paragraph mean that the patch you mentioned awhile ago should be ignored?
John
-----Original Message-----
From: Guy Harris
To: Jesus M. Salvo Jr.
Cc: ethereal-dev@xxxxxxxxxxxx
Sent: 3/16/01 8:34 PM
Subject: Re: [Ethereal-users] bug with LANMAN NetShareEnum Reponse decoding
On Thu, Mar 15, 2001 at 06:10:26PM +1100, Jesus M. Salvo Jr. wrote:
> I am actually trying out lisa that comes with KDE 2.1, so that with
> konqueror, you can see all the hosts and available shares ( ala
windows
> network neighborhood ).
#include "complaint that what people *should* be doing is extending AMD,
\
or something such as that, to handle SMB as well as NFS, so that
you can see all the hosts and available shares by CDing to
"/net" or something such as that, as well as through a file
manager" :-)
(Well, maybe having the file manager know about that stuff explicitly
has some advantages, as it lets it put up icons that indicate that
something is a file server or an exported/shared directory from the file
server. I have the impression there's a fancy plugin mechanism - or
maybe more than one such mechanism - in Windows for remote file systems,
for that purpose.)
> * Click from frame 3 to frame 2 makes ethereal think frame 2 is
> NetServerEnum2 when it is actually a NetShareEnum function.
Grumble. The underlying problem here appears to be that the SMB client
in lisa isn't assigning a different MID to the two requests it sends out
- the NetShareEnum request has the same TID, PID, UID, and MID as the
NetShareEnum2 request, and, currently, the SMB dissector assumes that
won't happen, so that, for any SMB response, you can find the matching
request by looking for the request, from the same conversation, with the
same MID.
The only way to fix this would probably be to, when dissecting a
TRANSACTION reply:
if there's a "struct smb_request_val" attached to the frame, use
that;
otherwise, look up in the hash table for the matching request's
"struct smb_request_val", and, if found, attach it to the frame,
and then *remove* it from the hash table, so that the *next*
request in that conversation using that MID will get a new
"struct smb_request_val".