> To be honest, I have not heard of amd ( except for the competitor of intel
> ).
http://www.cs.columbia.edu/~ezk/am-utils/
(don't be confused by "BSD" in "the popular BSD Automounter"; it's used
on Linux, and also runs on various commercial UNIXes, I think).
> 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.
Probably not, given that
http://www.samba.org/samba/docs/man/nmblookup.1.html
seems to indicate that nmblookup only does NetBIOS name lookups, to
translate a NetBIOS name into an IP address, and doesn't do SMB
operations to see what shares a given SMB server is exporting.
It's probably LISa, not nmblookup, that's sending out the SMB requests
in question; all nmblookup is doing is presumably telling LISa what the
IP address of the server in question is.
I'd have to plow through the SMB documentation I have to see if it's
forbidden to send out a request with a given MID if you've already
gotten back a response to a request with that MID - as long as there
aren't multiple requests in-flight with the same MID, the client won't
need the MID to figure out which reply goes with which request, and I
don't think the server needs to care about the MID one way or the other,
except to send back in each reply the same MID as the one for the
request to which it's a reply. (The other fields aren't required to be
unique per request and, in fact, some of them aren't *supposed* to be
unique per request.)
In any case, even if you *aren't* supposed to do that, that doesn't mean
it's OK for Ethereal to misdissect it - one of the reasons for using a
network analyzer such as Ethereal is to disagnose network problems
caused by protocol violations, so network analyzers have to be able to
cope with packet captures that include protocol violations.
> Does your last paragraph mean that the patch you mentioned awhile ago should
> be ignored?
No.
There are two separate problems with Ethereal; the patch I sent out
fixes the first problem, i.e. misdissecting an "interim reply" to a
TRANSACTION request, but the duplicate MID issue is a separate problem,
which requires a separate fix in Ethereal.
The fix to the first problem happens to cover up the second problem in
that particular capture, as it means that Ethereal doesn't try to
dissect the second packet as a particular type of transaction, although
it probably really should call the "Lanman pipe" dissector with some
indication that it's an interim response, so that the Lanman pipe
dissector can at least say what kind of request it's an interim response
*to*.