Using a Scan To Network share (OfficeJet 9130)

IanSav wrote:
Hi Jarrah, I have still not found a solution for this issue, even though I have recently installed updated firmware for my OfficeJet 9130. I am curious to see what will happen with the newer SAMBA version in RAIDiator 4. Regards, Ian.

Hi Ian,

It looks like an incompatibility between the authentication protocol used by Samba 3.0.22 and the SMB implementation used by the printer. The authentication is actually succeeding, but then Samba is failing when it tries to lookup the user information. Samba returns NT_STATUS_ACCESS_DENIED which the printer assumes is an incorrect username or password.

I'm going to try building a later version of Samba with more debugging enabled to see if the problem has been fixed (I don't hold much hope that it is), or so I can at least find a work around for the problem.

Note that this has nothing really to do with the ReadyNAS, other than they're using the Samba software. If I can get it fixed in a later version of Samba, then it should be automatically picked up in a later firmware release.

Regards,
Greg

Hi Greg,

If you are able to verify the error and subsequently fix it with your SAMBA tests then please let us all know. Perhaps the fix may be compatible with Infrant's needs and can thus be implemented for all of us. The alternative could be that you can tell HP what they are doing wrong and then they can fix their firmware, again we all benefit.

Thanks for investigating this.

Regards,
Ian.

Update: I've tried this with the latest version of Samba (3.0.25a) with the same result. I think this indicates that the next ReadyNAS firmware update is not going to fix the problem.

Greg

Hi Greg,

jarrah wrote:
Update: I've tried this with the latest version of Samba (3.0.25a) with the same result. I think this indicates that the next ReadyNAS firmware update is not going to fix the problem.Greg

Bugga! :P

Did the logs show anything interesting?

Regards,
Ian.

Does this also happen in Share security mode, or with guest access enabled on the share? I know HP uses Samba in a lot of their products, so there's a good chance that the scanner is actually using Samba too, but maybe in a strange way.

Hi Skywalker,

Skywalker wrote:
Does this also happen in Share security mode, or with guest access enabled on the share? I know HP uses Samba in a lot of their products, so there's a good chance that the scanner is actually using Samba too, but maybe in a strange way.

In my case I am using User security mode. I have tried with Guest access enabled and disabled. It makes no difference. The printer always reports a username/password error.

Regards,
Ian.

IanSav wrote:
In my case I am using User security mode. I have tried with Guest access enabled and disabled. It makes no difference. The printer always reports a username/password error.

I still wonder how it would behave in full share security mode, since that uses a different authentication model. But changing security modes isn't something you really want to do on a live system. Anyone else try this with the NAS in Share security mode?

Ok, I've found a workaround to the problem. It will required an additional option to be added to one of the share configuration pages (the 'Advanced Options' seem most appropriate). The option would add/remove the following line to the [global] section of the smb.conf file on the ReadyNAS:

use spnego = no

Note that this may affect performance and/or access to shares by other CIFS clients. That's why it needs to be an advanced option.

A discussion of the issue follows.

The problem appears to be either a bug in Samba's session setup protocol or in the printer's implementation of the SMB protocol. It's possible that this will be fixed in Samba 4.0, but not certain. I'll post something to the samba-technical list to see if I can get clarification. In any case, until Samba 4.0 is released I think the only solution is the one described above.

Session setup for user authentication using SPNEGO goes something like this (client is the printer, server is the ReadyNAS Samba server):

1. Client sends a NEGOTIATE to server.

2. Server sends a NEGOTIATE to client specifying available options.

3. Client sends a SESSION_SETUP_ANDX to server to request authentication.

4. Server sends a SESSION_SETUP_ANDX with challenge and a status requesting more data is required (STATUS_MORE_PROCESSING_REQUIRED).

5. Client sends SESSION_SETUP_ANDX with challenge response and username.

6. Server sends a SESSION SETUP_ANDX with authenticated vuid.

7. Client sends a TREE_CONNECT_ANDX using authenticated vuid.

The vuid is then used for any subsequent communication between the client and server. Think of the vuid as a session key that identifies authenticated communication between the client and server.

The problem accurs because the Samba server actually allocates a temporary vuid in step 4 that is different from the vuid supplied to the client in step 6, and includes this in it's message to the client. The printer then uses this temporary vuid rather than the real vuid in step 7. Because the authentication actually succeeded, a message to this effect is logged on the server, which is what we're seeing. However the server then terminates the connection at step 7 when the incorrect vuid is supplied.

The 'use spnego = no' option tells the server to use an older authentication protocol that avoids the two stage process shown above. This avoids the temporary vuid allocation and so the correct vuid is used by the printer.

Greg

Hey Greg,

Where are you based? I have tried to get HP in Australia to help with this and they weren't interested. Perhaps you can try your local HP support team and see if they can get this looked at for us.

Is there any chance you can feed this back to HP and get them to implement the fix in a firmware patch. That way there is no need to play around with RAIDiator and everyone who still has this series of OfficeJet can also enjoy the fix. The fact that you have the details of what is going wrong may inspire HP to sort out this issue once and for all.

Thanks for investigating this.

Regards,
Ian.

I'm in the US, but I doubt if HP here will be any more interested. The last firmware update for this printer was nearly two years ago, and this is probably a Samba problem anyway. I'll see what the Samba people say. If we don't get any traction with them, then maybe we can try pursuing it with HP.

Greg