Hi,
Would it be possible to send me a capture file with this problem?
I would help.
I have an idea of what could cause this, it could either be
1, dissect_smb() not cleaning up properly the dummy structure used for
response packets which have no matching request.
Not likely.
2, or it could also happen when we have a a sequence of two different SMB
commands
the first one using extra_info to store a FID and the second command using
extra_info to store
a t2i pointer.
If both commands use identical MID,PID, etc and the first reply and the
second request are dropped by
the network, then we would have incorrect matching like this.
It could however be something else, a serious bug, which is why I would
still like to see a capture to verify that this is
the bug.
To make sure 2, does not crash ethereal I think we should enhance the
request-reply matching functions to also check
cmd to be equal.
This would require the matching function to become a bit intelligent since
we dont just want to check
if(request->cmd == reply->cmd)
but also handle Cancel commands, which can match (reply->cmd==ANY)
or [NT]Trans[2]Secondary which should also match the initial non-trans
command.
I will code up a patch that changes the cmd matching in such a way later
today to fix 2,
Marcin, is is possible for you in that case to apply that patch to the
source code and test if it fixes the problem?
----- Original Message -----
From: "Guy Harris"
To: "Marcin Gryszkalis"
Cc: "ethereal-dev"
Sent: Tuesday, February 19, 2002 6:31 PM
Subject: Re: [Ethereal-dev] packet-smb.c:11327 - si->info_level =
t2i->info_level
> On Tue, Feb 19, 2002 at 08:26:10AM +0100, Marcin Gryszkalis wrote:
> > > What are the values of "si" and "t2i"?
> >
> > (gdb) print si
> > $4 = (smb_info_t *) 0xbfbfe79c
> > (gdb) print t2i
> > $5 = (smb_transact2_info_t *) 0x800a
> > (gdb) print *si
> > $6 = {cmd = 50, unicode = 1, request = 0, unidir = 0, info_level = -1,
> > info_count = -1, sip = 0xe7df048,
> > ct = 0xe7a99a4}
> > (gdb) print *t2i
> > Cannot access memory at address 0x800a.
>
> That's probably a file ID. The "extra_info" field of an
> "smb_saved_info_t" structure is usually a pointer to a
> SMB-message-type-specific data structure, but sometimes it's used to
> hold a numerical file ID instead.
>
> It looks as if a file ID was put there, but the code is assuming that
> it's not a file ID.
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev