Several months ago, I was handed a sheet of paper with a strange error printed on it. One of our HP M602’s had spit it out, it seemed, while working on a real print job for one of our users. On further inspection, the printer had printed several identical pages with the same error, smiley face and all:
☺@EJL 1284.4
@EJL
@EJL
My first guess was a corrupted driver, so I re-installed the printer for the user who had reported the issue and waited for the error to come back.
It didn’t stop there. It wasn’t long before several users started reporting the error, all from different computers running different operating systems, and then the error pages started printing in the middle of the night when no one was using the printer.
We maintain a small fleet of HP M602’s and M605’s, but until this point the error had only been appearing on one of them. Updating the firmware on that printer didn’t help: instead, by the second week, all of our printers were randomly printing the @EJL 1284.4 pages.
Tracking Down the Issue
At this point, we inspected the print logs on the printers themselves and realized that every time an error page printed a “Guest print” event was added to the job log. Unfortunately, the M602/M605’s don’t log the source IP of the jobs they receive, but they do log the time and date when the job was processed. Now that we knew a network device was responsible for the mysterious print jobs, it was just a matter of finding the device on our network. After overcoming a minor setback caused by incorrect time and date settings on most of the printers, we were able to log traffic on the network and correlate it with the timing of the mysterious “Guest print” jobs to find the source IP of the offending device.
To figure out which computers were communicating with the printer, we shut down the printer and set up a Linux box in its place with its IP address. The, we gave the printer a new IP address, and configured the Linux box to forward all the traffic it received to the new IP address of the printer. Since the Linux box was now in a position to receive all traffic intended for the printer, a simple tcpdump session quickly revealed the source IP addresses of all the computers trying to send jobs to the printer. At this point, it was simply a matter of waiting for another error page to print, and the printer happily obliged.
Thanks, Epson (Fixing the Problem)
With the source IP address of the offending computer in hand, we tracked down the physical source of the rogue print jobs. It turned out to be a MacBook Pro, running a full Epson software/driver suite, that had joined our network at the same time that the error pages started printing. Some extensive Googling from the past week had led to the conclusion that “EJL” stood for “Epson Job Language”, so I formed a quick hypothesis that the Epson drivers were doing something that our HP printers weren’t very happy about. I uninstalled the Epson drivers from the MacBook, and sure enough, the @EJL 1284.4 pages stopped instantly.
Whatever the exact cause, the issue was clearly caused by a conflict between the Epson software suite and our HP network printers. If you encounter this error and you’re not on a large network like we are, it might be worth checking your computer for Epson software.
Epson, if you’re out there reading this, you owe me 3 reams of paper and a black toner cartridge for an HP M602.
A Little More About @EJL 1284.4
According to the Undocumented Printing Wiki’s page on Epson Job Language, the @EJL 1284.4 command:
takes the printer out of the Epson packet mode communication protocol (whatever that is) and enables IEEE 1284.4 communications mode
On top of this, the HP/Epson conflict has been well documented on HP’s support forums over the past year: