[jcifs] SMB Signing Sequence Counters

[Christopher R. Hertel]

Just a general note.  At the CIFS conference Tridge was telling me that
sequence number incrementation does not always follow logical rules.  He had
details, but we were in a swimming pool and I couldn't write them down.  I
will bug him about the quirks when we get to that point.

Things to look for:  Oplock breaks and other out-of-sequence packets may
behave oddly.

Chris -)-----
...who realizes that what he wrote above isn't particularly helpful.

Michael B Allen wrote:
> 
> Eric wrote:
> > It also gets strange since multiple threads can be throwing stuff
> > at us (that's why I put separate sequence counters for signing and
> > verifying; I had a single counter, but it all fell apart under
> > multithreading because I would get i.e. 2 consecutive requests and
> > lose sequence).
> 
> What would the sequence numbers be for the below 3 SMBs? From looking at
> your code it looks like it should be something like the following:
> 
> send: SMB1 sign 0
> send: SMB2 sign 2
> send: SMB3 sign 4
> recv: SMB3 vrfy 5
> recv: SMB1 vrfy 1
> recv: SMB2 vrfy 3
> 
> Is the verify sequence number of the response always 1 more than the
> sequence number used to sign it's request (as shown above)?
> 
> If so, would it make more sense to put the verify sequence value in the
> ServerMessageBlock class (i.e. keep the state with the object it
> represents)?
> 
> We don't need the signingLock. If my reasoning is correct we can have one
> signSequence counter and set a verifySequence in the response object. Then
> we do all signing/verifying from within the snd_buf/rcv_buf locks. We can
> initialize things as necessary from within this lock as well. That will
> give us the concurrency we need and considering snd_buf and rcv_buf are
> static it prevents their contents from changing during signing/verifying
> (which I think might be a problem with the current code).
> 
> Mike
> 
> PS: java.util.Random is much faster. I also moved it to where
> clientChallenge was actually required. BTW, I failed to mention yesterday
> that there were serveral other threads in the monitor dump that looked
> like they were trying to generate some kind of seed value. I also wonder
> if Java 1.3 has the JCE providers that Java 1.4 has.
> 
> --
> A program should be written to  model the concepts of the task it
> performs rather than the physical world or a process because this
> maximizes the  potential for it  to be applied  to tasks that are
> conceptually similar and, more  important, to tasks that have not
> yet been conceived.

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org