[jcifs] Strange jetDirect printer behavior

[Mike Davidson]

We use jCIFS strictly for IP address to NetBIOS (& vice versa) name 
resolution. We have a JetDirect printer which (I believe) is behaving badly 
and appears to be confusing jCIFS.   

Let's assume for sake of illustration the following network elements:

192.168.180.25 - IP address of management appliance where jCIFS code lives
192.168.180.30 - IP address of Windows system with NetBIOS name GC-EXCHANGE
192.168.180.78 - IP address of JetDIRECT printer with NetBIOS name NPIC5A694

Here's what appears to be happening:

1) management appliance (via jCIFS) broadcasts name lookup for GC-EXCHANGE 
using NbtAddress.getByName() method.  The outgoing packet has a questionType 
field of 0x0020 (NB).
2) a response packet is received but it is from the JetDirect printer
(192.168.180.78) instead of 192.168.180.30.  The incoming packet has a
recordType field of 0x0021 (NBSTAT not NB as I would expect).
3) The jCIFS code appears to go ahead and process/parse the incoming packet as
if it was of the correct type (NB) and the end result is an NbtAddress object
with an incorrect IP address.  This will make more sense when looking on the
content of the jCIFS log files below.

Here's the outgoing request packet:
-----------------------------------------------------------------
May 18 16:55:35.040 - nbt name service packet sent
NameQueryRequest[nameTrnId=13,isResponse=false,opCode=QUERY,
isAuthAnswer=false,isTruncated=false,isRecurAvailable=false,
isRecurDesired=false,isBroadcast=true,resultCode=0,questionCount=1,
answerCount=0,authorityCount=0,additionalCount=0,
questionName=GC-EXCHANGE<00>,questionType=0x0020,questionClass=IN,
recordName=null,recordType=0x0000,recordClass=0x0000,ttl=0,rDataLength=0]

May 18 16:55:35.041 - datagram packet sent to: 255.255.255.255
00000: 00 0D 00 10 00 01 00 00 00 00 00 00 20 45 48 45  |............ EHE|
00010: 44 43 4E 45 46 46 49 45 44 45 49 45 42 45 4F 45  |DCNEFFIEDEIEBEOE|
00020: 48 45 46 43 41 43 41 43 41 43 41 41 41 00 00 20  |HEFCACACACAAA.. |
00030: 00 01
-----------------------------------------------------------------

And here is the incoming response packet from the JetDirect printer:
-----------------------------------------------------------------
May 18 16:55:35.046 - nbt name service debugging
 new data read from socket
May 18 16:55:35.047 - datagram packet received from: 192.168.180.78
00000: 00 0D 84 00 00 00 00 01 00 00 00 00 20 45 48 45  |............ EHE|
00010: 44 43 4E 45 46 46 49 45 44 45 49 45 42 45 4F 45  |DCNEFFIEDEIEBEOE|
00020: 48 45 46 43 41 43 41 43 41 43 41 41 41 00 00 21  |HEFCACACACAAA..!|
00030: 00 01 00 00 00 00 00 41 01 4E 50 49 43 35 41 36  |.......A.NPIC5A6|
00040: 39 34 20 20 20 20 20 20 00 04 00 00 11 0A C5 A6  |94      ......Ŧ|
00050: 94 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00070: 00 00 00 00 00 00 00 00 00                       |.........       |

May 18 16:55:35.047 - nbt name service packet received
NameQueryResponse[nameTrnId=13,isResponse=true,opCode=QUERY,
isAuthAnswer=true,isTruncated=false,isRecurAvailable=false,
isRecurDesired=false,isBroadcast=false,resultCode=0,questionCount=0,
answerCount=1,authorityCount=0,additionalCount=0,questionName=null,
questionType=0x0000,questionClass=IN,recordName=GC-EXCHANGE<00>,
recordType=0x0021,recordClass=IN,ttl=0,rDataLength=65,
addrEntry=GC-EXCHANGE<00>/80.73.67.53]
-----------------------------------------------------------------

The resulting NbtAddress object has an IP address of 80.73.67.53!!!  Based 
on RFC 1002, jCIFS appears to be parsing the response packet which is of 
type NBSTAT as if it was an NB packet and incorrectly interpreting the 
"PIC5" portion of the printer's name as the IP address of 'WINXP1'.  

To see this simply convert the IP address 80.73.67.53 to hex which is 
50 49 43 35 and then convert the hex to ASCII which gives you "PIC5" from 
NPIC5A649.

There would seem to be two problems here.  The first is that the JetDIRECT
printer should not be responding to these broadcast queries and the second
is that jCIFS is not recognizing the fact that it is NOT getting the type
of response it expects and proceeds to parse the response as if it has.

So my question is this...to address the jCIFS portion of the issue I'm 
proposing that the NameServiceClient.getByName() method be modified so 
that only responses which have a recordType of 0x0020 (NB) be accepted 
and parsed. Is this reasonable?

Does this make sense or am I way off base here?  Has anyone else ever run 
into something similar this issue?  Any help will be greatly appreciated.

Thanks,
Mike