[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