Driver unsuitable for installation errors - NDPS RPM

Client workstation is configured for NDPS Remote Printer Management (RPM).

When adding or installing printers from across the network (Broker and printers not local), then we get a "Driver unsuitable for installation" error on the workstation.

RPM on the local subnet works just fine.

The DPRPMLOG.TXT file shows Broker -926 errors (NWDP_OE_RM_FILE_OPEN_ERROR)

DPRPMLOG.TXT also shows RPC CAN'T RECEIVE -WSA - UKNOWN OR NEW ERROR 0)

It appears that the St. Bernard iPrism device is treating the NDPS RPM traffic, specifically the driver download portion, as peer to peer traffic. St. Bernard Software was contacted and they suggested that the customer create a filter exception with a source IP address of * and the destination network should encompass their entire internal network. If you internal network is from 10.1.1.x to 10.1.100.x, then the filter would look something like 10.0.0.0 to 10.1.100.FF or 10.1.100.255. Novell assumes that you know how to configure your iPrism device. If you do not know how to create such a configuration on your iPrism device, please contact St. Bernard Software's technical support for assistance.

If opening up your entire infrastructure is too much, you can open up the following TCP/IP ports that NDPS and iPrint use:

BROKER.NLM

TCP port 3014

NTFYSRVR.NLM (Event Notification Service or ENS for short)

TCP ports 3016 and 3017

REGSRVR.NLM (Service Registry Service or SRS for short)

TCP port 3018

RMANSRVR.NLM (Resource Management Service or RMS for short)

TCP port 3019

NDPSM.NLM (Novell Distributed Print Services Manager or NDPSM for short)

TCP port 3396

iPrint

TCP ports 631 and 443

In short, if you want to keep your NDPS and iPrint ports open, you will want to open ports 443, 631, 3014, 3016, 3017, 3018, 3019, and 3396.

TROUBLESHOOTING:

A LAN trace was taken of the workstation that was experiencing the problem from bootup. In reviewing the LAN trace, the following was discovered:

1.) The workstation was able to successfully negotiate a three way TCP handshake (SYN/SYN ACK/ACK) with the remote server with the Resource Management Service (RMS) service's port of 3019. Therefore we know that the remote RMS server was up and running.

2.) The client was successful in establishing a bind to the remote RMS service.

3.) The client will issue a "Get Resource File" request from the remote RMS service. This is a request made by the client to get the printer driver from the RMS. The client successfully receives a full packet of driver data from the remote server with the beginning of the driver. The client will make a subsequent request for the remainder of the driver and a TCP reset (RST) is being sent.

4.) The client will re-establish connection to the remote RMS. However, when the client attempts to do a "Get Resource File" request from the remote server, and immediate reset is sent. No data is ever received from the remote file server. Eventually the client will quit making attempts to connect to the remote RMS and a "Driver unsuitable for installation" error will be returned.

5.) When analyzing the traffic, the normal or proper data came from one MAC address. That MAC address coresponded to the customer's internal router. The hop count in the IP header was 128 minus the number of hops away the server was from the client. It was noticed that the reset came from a different MAC address than the router's MAC address and the hop count in the IP header was 64 instead of 128 minus hop count. Additionally the packet analyzing software decoded the MAC address of the reset as belonging to St. Bernard, meaning it is a MAC address that St. Bernard is registered to use.