[jcifs] Strange jetDirect printer behavior

[Mike Davidson]

Thanks for the responses guys...its good to know I'm on the right track.

I've tested what amounts to about a 20 line code change to  
NameServiceClient.send() method and it appears to do the trick.   
Unfortunately I'm currently on a very back-level version of jCIFS  
(0.6.5) so I'm not sure how useful a patch file from my code changes  
would be.   Please note that I took a look at the  
NameServiceClient.java code in version 1.2.9 and the getByName()  
method is largely unchanged so I believe this issue still exists in  
the latest code.

My changes were pretty straight forward and I'd be interested in what  
you guys think.

Basically I changed the NameServiceClient.send() method such that it  
requires the recordType field of incoming responses to match the  
questionType field of the original request packet.  If the types do  
NOT match the response packet is ignored  and the send() method  
continues to wait for a good response (up to the configured timeout).

I tested this on our network and as Chris suggested after discarding  
the bad JetDirect printer packet the good response from the GC- 
Exchange system is received and parsed correctly.

I'd be happy to make these code changes available if you are  
interested in them (given they are against v0.6.5).  If so please let  
me know what the preferred mechansim is for doing that.  Barring that  
we are planning on moving to the latest and greatest version of jCIFS  
in the not too distant future and I could make these changes  
available to you then.

Thanks again,
Mike


On May 18, 2006, at 11:41 PM, Christopher R. Hertel wrote:

> 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,rDataLengt 
>> h=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
>