[jcifs] problem with NbtAddress.getAllByAddress()

Christopher R.Hertel crh at ubiqx.mn.org
Tue May 14 07:49:43 EST 2002


Sigh.

Look, I'm sure this all makes sense in your mind, but you are providing
this information without context.  I can break down your hex string, but
only because I'm steeped in NBT lore at this point.

Sigh...

\xa2\x48  Transaction ID
\x00\x00  Query request, with all flags false.
\x00\x01  QD_COUNT = 1
\x00\x00
\x00\x00
\x00\x00
\x20\x43\x4b\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41
\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x00
Name = "*\0\0\0\0\0\0\0\0\0\0\0\0\0\0", Suffix = '\0'
\x00\x21  Q_TYPE  = NBSTAT
\x00\x01  Q_CLASS = IN


Okay, the only potential differences I see are that jCIFS seems to be
generating a query with RD and B set.  These should be clear, to be
RFC-correct.  (Note: the RFCs have a typo that makes this unclear.  
RFC1002:4.2.17 shows the B flag in the NBSTAT query packet.  It should
show zero.)

I have my own testing tools, and I can send NBSTAT queries with these bits
turned on.  I have no trouble with W/95 and W/98 boxes.  I don't have XP
to test, however.

There is no reason that a system would pay attention to these bits,
*unless* (to speed things up) someone were to write code that simply reads
the entire two-byte flags field as a single short int.  This would be very
fast, particularly since you wouldn't need to covert to/from network byte
order.  Just read the two bytes.  Microsoft may have done something like
this in newer code.  Again, I cannot test this right now.

Chris -)-----

--
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




More information about the jcifs mailing list