Connectivity details and troubleshooting
This file provides more detailed information about
setting up basic device connectivity,
including possible troubleshooting steps in case something goes wrong.
Additional information may be found in the separate documents pertaining to
the PTAL device name format,
ptal-init, and
ptal-mlcd.
General issues
Question: What connectivity diagnostic tools are available?
- The syslog file (/var/log/messages or possibly a different file
depending on your system) logs potentially useful messages from the kernel and
the hpoj daemons, such as ptal-mlcd.
- For Linux, the file /proc/bus/usb/devices provides somewhat
cryptic information about currently-connected USB devices. The
usbview utility
displays the same information in an easier-to-read fashion.
- The command "uname -a" displays the current kernel version.
- For Linux, the command "/sbin/lsmod" lists currently-loaded
kernel modules. This is especially useful for determining which USB
host-controller driver you're using and verifying that the necessary
kernel modules (such as lp.o or printer.o) are loaded.
- If "ptal-init setup" is successful,
then invoking the command "ptal-connect
[devname] -service PTAL-MLCD-DUMP"
dumps the state of ptal-mlcd (not
applicable for JetDirect-connected devices). While the information may not
mean much to you, it might be useful for developers if you need to report
a problem.
Question: My device has both a parallel and a USB port. Which one should
I use?
If you are connecting the device directly to your computer, you should
connect via USB if possible, because that will yield better performance.
Question: My device only has a parallel port, but my computer doesn't
have an available parallel port. Can I use a USB-to-parallel converter?
No. You might be able to print only, but not through the hpoj software.
Refer to the Post-installation steps
for setting the PATH environment variable. You can also manually specify
the path on the command line, for example, "/usr/local/sbin/ptal-init
setup".
Problem: I used "ptal-init setup"
to add a device and specified a different device
name suffix than the one proposed. I later specified this suffix when
asked for a device name but was told that
it was not a valid device name.
In the steps for setting up parallel- and USB-connected devices,
"ptal-init setup" proposes a default
device name to use and invites you to
specify a different device name suffix if
you'd like. In this case you don't need to specify the full
device name (with the mlc:par:
or mlc:usb: suffix). However, in all other cases you must
specify the full device name,
including the prefix.
No. "ptal-init setup" automatically
stops and re-starts the daemons as necessary.
Perhaps the necessary kernel modules are no longer loaded. For Linux,
run /sbin/lsmod to be sure. For Linux,
"ptal-init setup" attempts to load
the necessary kernel modules before starting a parallel-port or USB
device probe. However, "ptal-init start"
does not do this, so you will need to arrange for the necessary kernel
modules to be loaded some other way.
Problem: My device has both a USB and a parallel port. I connected
different computers to each port, but only one of the computers is able
to communicate with it.
Most HP peripherals with both parallel and USB ports don't support
connecting both at the same time. If you want to share the device,
you can either network it with an hpoj-supported HP JetDirect print server,
or share it out to the network from a single computer.
The HP OfficeJet D series is a notable exception, in that it can handle
connections over both the USB port and LIO interface, which accepts either
a parallel-port or a JetDirect cartridge.
Problem: I switched my device from parallel to USB (or vice-versa),
but now "ptal-init setup" can't
communicate with it.
Make sure you power-cycle the device after changing the connection type,
to get it into the right state to detect connections on the new port.
Also see the troubleshooting information for the specific connection type
(parallel, USB, or JetDirect) elsewhere in this document.
Parallel-port issues
Question: On which platforms are parallel connections supported?
Linux/i386, Linux/Alpha, and FreeBSD/i386 are known to work. Other
CPU architectures under Linux and FreeBSD may work if they provide a
similar access method to parallel-port hardware registers from user mode.
Other operating systems, such as NetBSD, OpenBSD, HP-UX, etc., will not
work, because they don't allow user-mode access to the parallel-port
hardware registers, and their kernel-mode drivers probably don't provide
the degree of control over parallel-port signalling that
ptal-mlcd requires.
Question: What version of Linux or FreeBSD do I need for parallel-port
support?
Since ptal-mlcd drives the parallel
port from user mode, any version of these kernels should work.
It doesn't matter if parallel-port support is compiled into the kernel or
not, or if it's dynamically or statically linked. If there is kernel
parallel-port support, then you should tell
"ptal-init setup" which kernel device
file corresponds to the parallel port in use, so that
ptal-mlcd can open it and prevent
other processes from interfering with its use of the parallel port.
On Linux 2.2 and 2.4 systems with kernel parallel-port support compiled and
linked in (either statically or loaded as modules),
"ptal-init setup" is usually
able to consult files under /proc to detect your parallel-port base
addresses. Otherwise, you may need to determine and supply this information
yourself. 0x378 is probably the most common base address for
motherboard-integrated parallel ports; 0x278 and 0x3BC are other
possibilities for integrated or ISA parallel ports. PCI add-in parallel
ports typically have very different base addresses. Be very careful about
entering this information, because probing incorrect I/O port addresses
could result in system instability and/or data loss.
Problem: After a parallel-connected device is power cycled or
disconnected/reconnected, an hpoj command reports a communication error.
ptal-mlcd currently doesn't always
detect when a parallel-connected device is disconnected or power
cycled when it's idle. Therefore, when the device is connected and
powered on again, you may experience a failure when you run an application
that tries to access the device. In most cases, if you retry the
operation it will succeed the second time.
Question: To what mode should my parallel-port be set?
Your parallel port should be set to preferably "ECP" mode, or "bidirectional"
(also known as "BPP" or "PS/2") at a minimum.
"Unidirectional" (also known as "SPP") and "EPP" may work, although more
slowly. Also, you may experience communication problems with certain models,
such as the OfficeJet Pro 1150C/117xC, R, and PSC 500 series, unless the
parallel port mode is set to either bidirectional or ECP.
ptal-mlcd issues a warning error
message at startup if it detects a unidirectional-only parallel port.
If it's not possible to set your parallel port to a better mode, then you can
add the "-porttype spp" switch to the
ptal-mlcd command line to get rid of
this error message, but as explained above, you may still experience
communication problems with certain models.
Problem: I experience parallel-port communication problems when
running certain other software.
Be careful not to load kernel modules that conflict with
ptal-mlcd's use of the parallel port.
Typical examples of conflicting kernel modules include the following:
- ieee12844 and ieee12844pp from previous versions
of the hpoj software (0.7 and earlier).
- vmppuser, which is part of VMWare and serves as a gateway
to the physical parallel port for the software (probably MS-Windows)
running under VMWare. If you must use vmppuser from time to time,
then at least be sure to run
"ptal-init stop" before loading it.
- Win4Lin may have a similar possibility as VMWare for causing problems.
- The parport_probe module provided with Linux 2.2.x kernels
also conflicts with ptal-mlcd when it
gets loaded. However, you can largely prevent problems by specifying the
correct -device switch to
ptal-mlcd, which causes this module
to get loaded and get its parallel-port access over with before it causes
a problem for ptal-mlcd.
- Drivers for other parallel-port devices, such as Zip drives, may
also conflict with ptal-mlcd.
Do not share the parallel port with other devices, not even "pass-through"
devices such as switchboxes.
Other user-mode applications which like
ptal-mlcd bypass the kernel to access
the parallel-port registers directly without performing similar kernel
device locking can also interfere with
ptal-mlcd's signalling.
USB issues
Question: On which platforms are USB connections supported?
Currently only Linux (not *BSD), and only certain versions (see the next
question).
Question: What version of the Linux kernel do I need for USB support?
That depends on what model you have.
At a minimum you need 2.2.19 or later, or 2.4.2 or later. Earlier kernel
versions had several bugs in the USB printer-class driver (printer.c)
related to bidirectional communcation, which
ptal-mlcd definitely requires.
For most models, 2.2.19+ or 2.4.2+ is sufficient. (Specifically, if
according to usbview
the device's first interface alternate setting has a class/subclass/protocol
ID of 7/1/3.)
However, for a few models, such as the PhotoSmart printers 1000/1100/12xx,
you need a minimum of 2.4.19 (actually 2.4.19-pre5 or the 2.4.18 kernel
shipped with RedHat 7.3) or 2.5.7. (Specifically, if according to
usbview the device's
first interface alternate setting has a class/subclass/protocol ID of 7/1/2.
Some enhancements were added into these kernel versions to provide
ptal-mlcd more control over the
USB printer-class device setup and interface alternate setting selection.)
Question: What should I do if my kernel has USB support but (according
to the previous question) printer.c won't work for my model?
If your kernel doesn't have USB support at all (for example, 2.2.17 or
earlier), then you must upgrade the kernel, but see the next question for
additional USB setup needed.
If your kernel otherwise has USB support, then the best option may be
to get the USB printer.c update from the hpoj
Download page.
That version of printer.c should work on any USB-capable 2.2 or
2.4 kernel version and contains the same hpoj-related enhancements from
2.4.19. Follow the installation instructions in its README file.
Question: How do I add USB support to an older Linux distribution?
First of all, you'll need to upgrade to the latest 2.2 or 2.4 kernel,
and you may also need to update the printer.c file.
The following kernel configuration options must be enabled:
- Support for USB (recommended as modules)
- Preliminary USB device filesystem
- Support for hot-pluggable USB devices
- USB controllers as appropriate for your system (UHCI, UHCI-alternate, OHCI)
- USB Printer support
- Any other device options you will need, such as hubs
The following kernel modules must be loaded (via /sbin/modprobe or
/sbin/insmod):
- usbcore
- One of usb-ohci, usb-uhci, or uhci,
as appropriate for your system
- printer
- hub (if you will be using USB hub(s))
- Any modules you will need for other USB devices
As an alternative to loading all needed drivers at startup, you can set up
a "hot-plug" script to do this dynamically. This procedure will not be
explained here, but you can get more information on the
Linux USB home page.
However, it is not recommended to use this mechanism to load the hpoj
daemons, such as ptal-mlcd.
Be sure to mount /proc/bus/usb (type usbdevfs), either
manually or at startup from /etc/fstab.
/proc/bus/usb/devices provides useful (although somewhat cryptic)
information about the devices attached to the bus. The
usbview
utility displays the same information in a more readable fashion.
If necessary, create the directory /dev/usb. In that directory,
issue the following commands to create nodes for USB printer-class devices:
mknod lp0 c 180 0
mknod lp1 c 180 1
# ^ ^ <-- Increment both of these numbers.
etc., as many as you need, but don't go past 15. Set the permission and
ownership as desired (for example, 0660 and root:daemon).
Problem: I have an SMP (Symmetric Multi-Processor) system, and I
experience kernel OOPSes or complete system lockups when using USB.
2.2 and earlier 2.4 versions have SMP-related bugs in the USB subsystem.
Try rebooting your system into UP (Uni-Processor) mode
(pass the nosmp option to the kernel). Try upgrading to the
latest stable kernel version.
Problem: My system locks up when I disconnect or power off the device.
This is a problem in earlier kernel versions, when
ptal-mlcd has an open connection to
the device. Running "ptal-init stop"
to kill ptal-mlcd before disconnecting
or powering off the device may prevent this problem from happening.
Apparently some fixes were made in 2.4.7 and later to address this issue.
You might be able to just upgrade printer.c (see above).
Problem: "ptal-init setup" can't
find my device, or it finds it but says it can't communicate with it.
Problem: I also have a non-hpoj USB printer, and sometimes
ptal-mlcd complains about not
being able to find its device.
Depending on what order USB printers are plugged in and/or powered on,
they could be assigned to different /dev/usb/lpX device
nodes at different times. ptal-mlcd
handles this, but if your print queue for the non-hpoj USB printer
references a particular device node, then you must update it accordingly
as its device node changes, to ensure that it doesn't inadvertently open
ptal-mlcd's device node instead.
JetDirect issues
Problem: ptal-devid can't retrieve
the device ID string.
There are several possible causes:
- There may be a network problem. Try pinging the JetDirect's
hostname or IP address and see if you get a response.
- There may be a device connectivity problem on the JetDirect's end. Try
printing a JetDirect configuration page (press and release the button on
the JetDirect).
- If the device was just plugged in or powered on, you may need to wait
approximately 15 seconds for full communication to be established.
- The hpoj software may not have been compiled with SNMP support. You
probably need both the packages ucd-snmp and ucd-snmp-devel
installed on your system. Check the output of the ./configure
script to see if it detected a compatible SNMP package.
- Some routers block SNMP and/or UDP traffic.
- The JetDirect's SNMP "community name" may have been set to something
other than public. Currently, libptal only supports the
default public community name, unless you hack ptal-hpjd.c
to change this assumption accordingly.
Problem: ptal-connect to the
ECHO service fails.
There are several possible causes:
- See the previous entry for general device connectivity issues.
- The device may not provide an echo service.
- Parallel-port JetDirects only support this operation for 1284.4-capable
(not MLC-only) models; 1284.4 support requires firmware x.08.xx or later.
The JetDirect configuration page (see above) shows the firmware version and
currently negotiated device communcation mode.
Problem: I can't do anything besides printing to the device.
Check the JetDirect configuration page and verify that the communication
mode is MLC or 1284.4. Note that some device models don't have full-feature
JetDirect support. See the hpoj
Supported devices page
for more information on which device models are networkable with which
JetDirect models.
Next steps
Use the Back button on your browser to return to the previous document,
or click here to return to the
index.