[jcifs] Strange jetDirect printer behavior

Fri May 19 03:41:00 GMT 2006

Mike Davidson wrote:
> 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.   

By coincidence, I ran into exactly the same thing yesterday.  You are
correct that the JetDirect responds to name requests with the wrong
message.  The JetDirect, as you discovered, sends an NBSTAT.

I also saw that the JetDirect was sending these NBSTAT messages even
when the initial query was for a name that it didn't own.

Ugh.

More below...

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

My guess is that the Windows system (GC-EXCHANGE) is also sending a reply,
but the JetDirect printer is faster.  If you can monitor the exchange
with Ethereal, it'd be interesting to find out.

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

The transaction ID matches, so jCIFS correctly identifies that the message
from the JetDirect is in response the the query it sent.  The problem, as
you point out, is that it's a bogus response.

I can check this again tomorrow but I think that the JetDirect just sends
NBSTAT as a knee-jerk response to anything it receives on port 137.  I
will check to see how it responds to a direct name query.

Another thing that you might check, though...  If I remember correctly
the response is sent to port 137.  I use a testing tool I wrote a while
back that opens a high-numbered port and waits for responses there (similar
to nmblookup from Samba).

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

You would also want jCIFS to look for additional responses, and accept the
first good one.  If the name is a group name, of course, then the best bet
is to collect all of the responses.

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

I'm the theory guy.  Mike Allen is the practice guy and it looks as though
he's got this one on his list.

Chris -)-----

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