iPrint Printer fails to install with 1344, 1345 or Winsock 10060 error

There are many scenarios that can result in a 1344 Error. Below lists the causes with their associated resolutions:

Cause 1: CUPS Conflict
The iPrint installation should disable CUPS. If CUPS is running on an iPrint server, then there will be a conflict over port 631. This conflict can results in a 1344 error when installing iPrint printers to a workstation.

See /var/log/apache2/error_log. If the following error is found within the error_log, then the 1344 is most likely caused by this CUPS conflict problem:

SRVR_ERR_IDS_ERROR; Get ResourceData() returned 1F6 in ProcessGetInstallFilesReq()
IPP Operation error=541, operation=21

Resolution 1:
Type these commands:

Test install of an iPrint printer. If the install succeeds, then uninstall CUPS.

Cause 2: Proxy Server
The process of installing a printer requires that a printer driver be associated with the printer, and that the driver is able to be installed. The driver installation process is not obvious, and can cause the printer installation to fail if the configuration does not meet the requirements.

When the printer installation is begun, the Print Manager is consulted to confirm that a driver has been associated with the printer being installed. Once the driver is identified, iPrint first attempts to locate the driver on the workstation where the printer is being installed. If the driver exists, the printer is installed without further processing. If not, iPrint looks for the driver in the mod_ipp folder on the server where the Print Manager is located. If the driver is found there, the printer is installed using that driver. If the driver doesn't exist in the mod_ipp, iPrint looks in the Driver Store. If the driver is located in the Driver Store, it is copied to the mod_ipp on the server where the Print Manager is located. Then, iPrint installs the printer using the mod_ipp copy of the driver. Subsequent attempts to install the printer will use the copy of the driver in the mod_ipp folder, so the driver doesn't need to be copied from the Driver Store again. This keeps the drivers "close" to the users of the Print Manager where the printers are located.

A problem can arise if the server is using a Proxy. The Proxy controls access to the network, and unless the Driver Store is defined as an exception to the Proxy, the process of locating the driver in the Driver Store will fail, resulting in the 1344 error. This will happen even if the Driver Store and the Print Manager exist on the same server because, although nothing actually goes "on the wire" (through the network interface card), the Proxy will not allow the process to continue.

To resolve this problem, the Proxy must either be disabled, or be configured to allow an exception for the Driver Store.

Resolution 2:
Determine if a Proxy is enabled. 
a). Turn off the proxy:

YaST -> Network Services -> Proxy -> Uncheck the "Enable Proxy" option
unset http_proxy
rcapache2 restart

If you desire to continue using the proxy settings, follow these steps to add the Driver Store as an exception to the proxy configuration.

Example Syntax:

Example usage:

Within the /etc/opt/novell/iprint/conf/idsd.conf, change the IDSHostAddress value to the unique name defined in step a.

 

Example Usage:

YaST -> Network Services -> Proxy -> No Proxy Domains -> add the unique name to this list.  The list will look something like this:

Choose Finish to save these changes.

Cause 3: Permission/Ownership problem
If the ownerships and permissions are not exactly as shown below, then a 1344 or 1345 Error can occur.

mod_ipp drwxrwxr-x root www
mod_ipp/drivers drwxr-xr-x wwwrun www
mod_ipp/drivers/[OS_name] drwxr-xr-x wwwrun www
mod_ipp/drivers/[OS_name]/[Driver_file] -rw-r--r-- wwwrun www

Resolution 3:
Use the chmod and chown commands to set the directories and files to the correct permissions and ownerships.  

Novell has received reports that while the permissions and ownerships are correct, creating a new mod_ipp directory with the correct permissions and ownerships, followed by a server reboot, resolves the problem.

 

After reviewing the ownership and permissions to the mod_ipp directory, they look correct.  However, a few customer reports show that even though directory looks correct in every way, it still doesn't work.  While this scenario is not well understood, deleting and recreating the directory resolves this problem.

 

Move the mod_ipp directory to a different location on the server, for example, to /tmp.  Create a new mod_ipp directory in the /var/opt/novell/iprint location.  Assign the correct ownership and and permissions to the newly created mod_ipp directory. The following string of commands will do all of those things.

 

The use of the iprint server rpm dated April 22, 2008 has known corruption issues.  Due to the corruption, driver associations may become corrupt.

 

Check the rpm version from a terminal as root:

 

novell-iprint-server-6.0.20080422-0.2.1

 

Accept the new iPrint server code from the Channel.  The updated code will be 20081103 (30NOV2008) or later.

 

For information on the corruption issue, click here.

Note:  If none of these resolutions work, some have reported that restarting the server resolves the problem.

Workaround

To workaround the issue, manually copy the printer driver associated to the printer from the resdir to the mod_ipp repository.   The steps below illustrate this for Windows XP (driver_windows-nt-5.1_x86-32_en) for the HP LaserJet 8100 Series PCL 5e driver:

1.  Copy the resdir's resource.zip to the mod_ipp repository with modified name:


2.  Change the ownership of the copied file:


3.  Test the install of a printer that has the driver associated that was copied.