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.
- ptal-mlcd can be told to increase
its log-message output by command-line options (-nolog (default),
-logwarn, and -log) and/or by commands on its "debug
console." The "local" debug console is available when
ptal-mlcd is manually started with
the -nofork option. The "remote" debug console is available
when started with the -remconsole option and accessed with a
command such as "ptal-connect
[devname] -service
PTAL-MLCD-CONSOLE". The console commands nolog,
logwarn, and log may be used to change the log-message
level. Log messages may be captured using the Unix script command
(invoked before ptal-connect) or
from syslog (possibly the file /var/log/messages), although some systems
may not be configured to save debug-level syslog messages.
- libptal applications may provide additional message output
(to standard error) if you set the environment variable "PTAL_DEBUG=1"
(warning messages) or "PTAL_DEBUG=2" (debug and warning messages).
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 may just need to log out
and back in again.) 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: prefix). 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, or a conflicting
kernel module (such as scanner.o) is now loaded that wasn't loaded
before. For Linux, run /sbin/lsmod to be sure. For Linux,
"ptal-init setup" and
"ptal-init start" attempt to load
some of the necessary kernel modules before probing or starting daemons
for a parallel-port or USB device (hpoj-0.90 didn't do this at
"ptal-init start" time). However,
this could break if the relevant kernel modules aren't named as expected
(lp.o and printer.o).
Problem: I get one or more error messages on the console (or text-mode
login screen) if I boot with the device disconnected or powered off.
When CUPS starts, it tries to probe the
system for available devices. When it gets to the ptal backend,
ptal-cups tries to probe all devices that have been registered
with "ptal-init setup". You will
see at least one (for USB) or more (for parallel) error messages for each
PTAL device that isn't connected and powered on. This is normal and
nothing to be concerned about.
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 and 7100 series are notable exceptions, in that they 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.
Problem: The basic device connectivity
tests segfault or give unresolved-symbol error messages.
You probably have (at least one piece of) an older hpoj version still
installed on your system. Refer to the Compiling
and installing the software document for information on completely
removing old hpoj versions from your system.
Some text editors create backup files by appending an extension such as
".bak" or a tilde ("~"), and some people manually do this
by appending an extension such as ".old" or ".original".
Since ptal-init and libptal
match device configuration files based on
the beginning of the name, this may result in duplicate devices such as
"mlc:usb:OfficeJet_G85~". To fix this, simply delete (or move to
a different directory) the offending files, and run
"ptal-init start" to verify that the
duplicate devices are eliminated.
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?
In order from most- to least-preferred:
- "ECP" -- Best performance due to hardware-assisted transfers in most cases.
- "Bidirectional", "BPP", or "PS/2" -- Lower performance due to software-only
signalling, but should still work with all models.
- "Unidirectional" or "SPP" -- Lowest performance due to transferring
back-channel data 4 bits at a time instead of 8, and may not work well with
some models (such as the OfficeJet Pro 1150C/117xC, R, and PSC 500 series).
- "EPP" (without ECP) -- hpoj devices don't use EPP signalling, and you
should avoid configuring your parallel port for EPP capabilities (with or
without ECP) if at all possible.
ptal-mlcd issues an informational
syslog message at startup to tell you what kind of parallel-port setting
(in the form of its -porttype command-line switch) it detected.
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.
Problem: I have trouble configuring or communicating with my LaserJet
1100 or 1100A.
Some people have reported difficulties specific to these models, especially
after leaving them powered on for a while. Try power-cycling the device to
get it back in a good state. It is recommended that you not leave these
particular models powered on all the time when you're not using them.
Problem: ptal-connect to the
ECHO service fails or doesn't work very well.
The ECHO service on the OfficeJet LX and 300 series doesn't work reliably.
Don't use it on those models.
USB issues
Question: On which platforms are USB connections supported?
Mainly Linux, as long as you have an appropriate kernel version (see below).
In theory, other operating systems such as *BSD may also work in conjunction
with libusb (see below).
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 many 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 some models, such as the PhotoSmart printers 1000/1100/12xx and
most newer OfficeJet- and PSC-branded products,
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
does not have an interface alternate setting with a class/subclass/protocol
ID of 7/1/3. 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.)
In addition, some models, such as those that support the LIDIL print language
instead of PCL, also require
libusb, or you won't
be able to connect to the print service through hpoj.
Refer to the hpoj
Supported devices page for more information.
Question: What is the difference between printer.c and
printer.o?
Technically, printer.c is the source code file and printer.o
is the binary/compiled/object-code file. However, to some extent they are
used interchangeably in the hpoj documentation.
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. Or you can upgrade your whole system to a
newer distribution that includes the necessary kernel support and setup.
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.
Important: If you already have the correct kernel version, then you
should not replace printer.c with the modified version mentioned
in the previous paragraph.
Question: How do I add USB support to an older Linux distribution
(or when recompiling my kernel)?
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
- USB Scanner support is not necessary for hpoj, and in fact certain
versions of that driver may conflict with certain hpoj models.
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 (of file-system 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).
Question: How do I get USB working on a non-Linux platform such as
FreeBSD?
First, make sure you install
libusb and the hpoj
./configure script detects it.
Next, make sure that there are no other drivers (such as for USB printer-class
devices) bound to the device. You may need to reconfigure/recompile your
kernel, unload module(s) (on FreeBSD, possibly with a command such as
"/sbin/kldunload ulpt"), or kill process(es).
At the time of this writing, there have been a number of failure reports
about this on FreeBSD and Mac OS X, and only one success report on FreeBSD
(in that case, FreeBSD-4.7, but your mileage may vary). If you need help
with this, ask on the
hpoj-devel
mailing list, but if all else fails you may end up needing to try this
on a later version of your operating system or
on a different operating system such as Linux.
Problem: I have an SMP (Symmetric Multi-Processor) system, and I
experience kernel OOPSes or complete system lockups when using USB.
Linux kernel 2.2 and 2.4 versions have SMP-related bugs in the USB subsystem,
at least in the printer-class driver (printer.o) when back-channel
data is transferred, which happens with hpoj but not with raw printing.
(One user suggested that these issues may have been resolved in the 2.5/2.6
kernel series, but this has not been verified.)
Verify that hpoj was built with
libusb support.
"ptal-init setup" should detect this
situation and enable a workaround (disable printer.o and only use
libusb), but this
wouldn't have happened if you originally ran it in non-SMP mode and are
now running in SMP mode.
To see if SMP is really the problem for you, try rebooting your system into
UP (Uni-Processor) mode (pass the nosmp option to the kernel).
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, it finds it but says it can't communicate with it, or I
experience I/O errors at a later time such as while
printing,
scanning, or
accessing photo-cards.
- See the top of this file for suggested diagnostic tools.
- Make sure your model is
supported.
It's possible that it's supported in the latest development code in
CVS or in a later stable version, in which case you will likely need
to upgrade hpoj.
- Does the device show up in /proc/bus/usb/devices or
usbview?
- Make sure your system is properly set up for USB support as described
above, including an appropriate kernel version and working printer.c
that supports your model. Depending on your system and device model, hpoj
may also need to be built with
libusb support.
- SMP-related kernel bugs (as described above) can sometimes result in
random data-loss errors or device-detection failures without completely
crashing your system.
- Make sure the necessary kernel modules (host-controller driver,
hub (if necessary), and printer) are loaded. In some
cases, you may need to arrange for the host-controller driver to be loaded
after all other USB-related kernel modules.
("ptal-init setup" and
"ptal-init start" now try to load
some but not necessarily all needed kernel modules.)
- Important: As you experiment with the following suggestions to
try to resolve the problem, try power cycling the device between each
step, especially if one of those steps involved patching or switching
host-controller drivers or trying to use the parallel port on the device.
Sometimes in the course of experimentation, invalid or partial data could
be sent to or received from the device and get things out of sync.
- Are you using the kernel supplied by or updated for RedHat 7.2,
or updated for RedHat 7.1, or any other distribution based on these RedHat
versions? (A common symptom is that the printer starts trying to print,
possibly a page with a single "smiley face" character, when
"ptal-init setup" probes the device.)
If so, then you need to edit /etc/modules.conf and add the line
"options printer proto_bias=3". Then issue the commands
"/sbin/rmmod printer" and "/sbin/modprobe printer"
to make the new setting take effect. (This may not help on some models.)
Installing the updated printer.c (see above) can also resolve this
problem, and may help for more models.
- What host-controller driver are you using?
- If it's usb-uhci or uhci, try switching to the other
one. usb-uhci (the default UHCI driver in most cases) has been
especially problematic for many users, who often get better results from
uhci (but see below).
In most cases, you need to edit /etc/modules.conf or
/etc/conf.modules and change the "alias usb-controller"
line, but some distributions such as Debian may have a different procedure.
After making the appropriate configuration file change, you must reboot
your system at a minimum, or possibly even completely power it off and
back on again, in order to get your USB host controller back into the
right state (a simple "/sbin/rmmod usb-uhci ; /sbin/modprobe uhci"
is probably not sufficient).
- If you're using uhci on a stock 2.4.18 kernel, you've
hit a known bug. The 2.4.18 kernels supplied with Mandrake 8.2 and
RedHat 7.3 contain the necessary fix. Other users may upgrade to a
later kernel version or the latest 2.4.19
prepatch, or apply a patch to fix this specific issue, available from
the hpoj Download
page.
- Note that if you're using usb-ohci, then switching to
usb-uhci or uhci will more than likely make things worse,
not better, because OHCI and UHCI are completely different hardware designs.
- Try "/sbin/rmmod scanner".
The Linux kernel USB scanner.o driver is not used by hpoj
but has been traditionally considered benign. However, recent kernel versions
have a bug where scanner.o conflicts with hpoj's access to certain
models (PSC 1210 on 2.4.22 and 2.6.0-test), by binding to some of the
device's USB interfaces that hpoj requires.
"ptal-init setup" tries to detect this
situation and blacklist/unload scanner.o, but this could get missed
if the detection doesn't happen correctly. (This bug has been reported to
the scanner.o maintainer.)
- Especially for non-Linux systems, check to see if another printer-class
driver (whether in the kernel or as a user-mode process) has already bound to
the device.
- Make sure the device and any hub(s) it's attached to are fully powered
on and all cables are securely plugged in.
- Try isolating the device on the bus. Unplug as many other USB
devices (including hubs) as possible, preferably leaving only the device
in question plugged into the "root hub" as reported by
usbview.
Low-quality (especially unpowered) USB hubs can sometimes be a source of
trouble.
- If your computer dual-boots with Windows, try setting up the device
there.
- If possible, try setting up the device on a different computer,
using either the same or a different operating system.
- Try a different USB cable; this is known to have helped at least
one person. Avoid USB extension cables.
- Check the Bugs and
TODO page for information on issues and possible fixes discovered after
the release of this version of the software.
- There may be an IRQ or other conflict on your PCI bus that affects
your USB card. (Diagnosing and correcting this is beyond the scope of this
document.)
- Report your problem to the
hpoj-devel
mailing list. Be sure to include a complete description of the problem,
including which model you're using and any relevant information provided
by the diagnostic tools listed at the top of this file, especially what
kernel modules are loaded.
- Unfortunately, some motherboards have defective USB chipsets.
If all else fails, try installing a PCI USB add-in card, but before making
a purchase, check the store's return policy in case this doesn't help.
- In particular, this has helped in several cases of OHCI chipsets
where ptal-mlcd reports an error
writing to the device.
- If the device also has a parallel port, another last resort might
be to set it up on parallel instead of USB. Be sure to power-cycle the
device when making this change, because some models don't have hot-swappable
I/O ports.
Problem: I also have a non-hpoj USB printer. Sometimes
ptal-mlcd complains about not
being able to find its device, or I have trouble printing to the
non-hpoj USB printer.
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 situation, 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.
Run "ptal-init setup" to check whether
somebody allowed it to take over the non-hpoj printer. In general, hpoj was
designed for use with most HP multi-function peripherals, and may not work
with single-function printers. In particular, there are issues with hpoj
in conjunction with various HP DeskJet models (especially 800 and 900
series).
As described above, if you have an SMP Linux system,
"ptal-init setup" may have blacklisted
the printer.o kernel module. This has the side effect of disabling
/dev/usb/lp*-style access to all USB printers. If this is a problem,
then you may need to switch back and forth between the two (sets of) devices
using the following steps:
To access hpoj device(s):
- Blacklist printer.o (see below).
- Run "/sbin/rmmod printer".
- Run "ptal-init start".
To access non-hpoj USB printer(s):
- Run "ptal-init stop".
- Un-blacklist printer.o (see below).
- Run "/sbin/modprobe printer".
Problem: I have a non-hpoj single-function USB scanner, and it quit
working after setting up an hpoj device.
As described above, the Linux kernel USB scanner.o driver conflicts
with hpoj's use of certain device models, and therefore
"ptal-init setup" must blacklist and
unload scanner.o. This may break access to USB single-function
scanners, requiring you to reconfigure them to use
libusb instead of
scanner.o. If that's not possible, then you may need to modify
the product ID table in scanner.h and recompile/reinstall
scanner.o to prevent it from binding to your hpoj device (which it
never should have done in the first place). Also, see below about un-doing
the blacklisting of scanner.o.
Question: How do I manually blacklist (prevent from automatically loading)
or un-blacklist a Linux kernel module such as printer.o or
scanner.o?
Assuming you want to blacklist printer.o:
- Add to /etc/modules.conf the line "alias printer
off".
- Add to /etc/hotplug/blacklist the line "printer".
- Run "/sbin/rmmod printer".
To un-do the blacklisting:
- Remove or comment out (prepend with "#") the lines that were
added to the above-mentioned two files.
- Run "/sbin/modprobe printer" if desired.
Problem: ptal-connect or
ptal-printd can't connect to the
print service on the device. Print jobs get stuck in the queue.
Chances are that hpoj (or more specifically,
ptal-mlcd) was not built for
libusb support.
Refer to the "Compiling and installing the
software document for more information. In particular, depending on
your distribution you may also need to have both libusb and
libusb-devel packages installed.
"ptal-init setup" checks for
libusb support and
warns you if it's missing. You can check for this yourself by referring
back to the ./configure script output (if it's still available)
or by running a command such as "ldd /usr/local/sbin/ptal-mlcd |
grep libusb".
Problem: Printing is extremely slow.
This is a known issue in a certain combination of circumstances:
- printer.o is not loaded (possibly because it was blacklisted due
to SMP, it was renamed to another name such as usblp.o (possibly the
case in the 2.6 kernel series), or you're running on a non-Linux platform),
and ptal-mlcd therefore uses
libusb for all of its I/O.
- ptal-mlcd accesses the device
in a "composite USB" mode, where "raw"
printing is done on a separate USB interface from other services.
The best way to fix this is probably to load printer.o (or whatever
it happens to be called on your system). Of course, this goes against the
usual advice of avoiding printer.o on SMP systems, but under the
circumstances it may be worth a try, in case the relevant SMP problems don't
hit in this mode of operation. Just be prepared to back it out if necessary.
Another possible fix is to disable "composite
USB" mode. This will not work on the PhotoSmart 145/245-series
products or on any product that uses LIDIL instead of PCL (run
"ptal-devid -cmd" and look for the
token LDL). To make this change, edit the device configuration
file (such as /etc/ptal/mlc:usb:psc_2500_series), add the line
"init.mlcd.append+=-nocomp", and run
"ptal-init start" to make it take
effect. After making this change, it would be a good idea to re-run the
basic device connectivity tests, especially
the part about testing print-service connectivity, to make sure this change
didn't break anything. (For the PhotoSmart 145 and 245, you can actually
get by without using hpoj at all, and instead use raw printing directly to
the device and a standard USB mass-storage-interface kernel driver.)
Problem: I get an I/O error or interrupted print job when inserting or
removing a photo card on the DeskJet 450.
This is an issue with the device, where it registers a USB disconnect and
reconnect (I'm not sure what it does over parallel) when a photo card is
inserted or removed. For this model, take care to insert or remove photo
cards only when the device is idle.
JetDirect issues
Problem: ptal-devid can't retrieve
the device ID string.
There are several possible causes:
- The JetDirect's IP address setting may have been lost or changed,
possibly if the JetDirect was cold-reset or if it was configured to get
a dynamic address with bootp or DHCP. In this case, you need to either
get a static IP address for the JetDirect, or re-run
"ptal-init setup" every time the
IP address changes.
- 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 and/or JetDirect was just plugged in or powered on, you may
need to wait 15-30 seconds for full device communication to be established
within the JetDirect firmware.
- 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 (or perhaps your machine's firewall setup) 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, except
that SNMP is not relevant here.
- 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 communication mode.
Problem: I can't do anything besides printing to the device, or
I can do everything except 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.
Miscellaneous issues
Problem: The device clock drifts over time and/or is wrong after a
power cycle.
This is a device-side issue.
Problem: I couldn't set the clock on my device.
Non-fax-capable models generally don't have a working clock.
If there's no way to set it from the front panel, then chances are it can't
be set from software either.
Problem: After setting the device's clock with
"ptal-hp clock -set, the clock gets
"stuck" and no longer advances.
This has been observed on some (but not necessarily all) PSC 2210 units.
The root cause is currently unknown. Try setting the clock from the
device's front-panel menu.
Problem: After being left on for a period of time, the device stops
answering incoming phone calls and/or receiving faxes.
This is a known firmware bug on the LaserJet 3200 series that may be resolved
with a firmware upgrade, possibly in the form of an add-in DIMM available by
contacting the appropriate "official" HP customer-support service (not the
hpoj project).
Next steps
Use the Back button on your browser to return to the previous document,
or click here to return to the
index.