Another day, another customer with issues with the closed-source firmware of one of their devices, even if this time it’s not as bad as the one who got angry yesterday when I dared suggest I would have liked to see the device’s firmware to see if I could isolate the bug.

This time the device is a RIP server for Xerox printers, developed by EFI (no, not the one Matthew Garrett is fighting with). In particular, it’s the server that comes with a DocuColor 250 “copier” a very old customer of mine has recently acquired.

This copier, which is actually a much higher end multi-function printer, is replacing, for my customer, the previous DocuPrint 700 copier, which also has an EFI RIP server. The 700 is actually the more recent one, but that’s my customer’s choice to go with an older version, and thus I have no say in the matter.

As you can probably guess, both devices come with a scanner (otherwise they wouldn’t be called copiers), and both scan to so-called “mailboxes”, which are on-RIP storage areas with predefined configuration values. One of the most important things to keep in mind with these mailboxes, though, is that they can be set to transfer the scanned files to a different storage area through the network. On the DP700 RIP, I was able to set it up to use CIFS to send the data on a shared folder on their backup server – after they updated to OS X Lion, since Apple replaced Samba with a SMB2-only server – but the same trick wouldn’t work with the DC250, since that version, much older, does not support CIFS at all.

Instead, to push files out, this version only supports FTP, which is generally nice and easy: just set it up on the same server, to access the same shared directory, and you’re done.. or not? Turns out that the release notes for the RIP firmware state explicitly this:

Scan to FTP not supported for all FTP servers

Scan to FTP is not supported for all FTP servers. If an FTP server does not reply to a NLST command with a 4xx or 5xx response, scan to FTP from the Fiery does not work correctly. The WS_FTP server is known to have this issue.

While these three lines are all the documentation you can find about the topic, a quick sniffing around gave me a good idea of what the problem is. When writing the files to the FTP server, the RIP software is trying to find a unique name to use; instead of using the current date/time to generate one, it tries over and over until it finds a free one. The problem is that to do so, it expects the NLST (short listing) command to return an error if there is no file matching the name… which is not what RFC959 (the specifications of FTP) tells you to do. VSFTPd does it exactly like WS_FTP is said to do above: it will return a success message.. and an empty list.

Again, this is the kind of problems that I would like to be able to fix, but since this is a closed-source, proprietary firmware, it’s out of the question that I’d be able to (besides, the developers know the problem exists already, as they wrote it down, yet there is no fix available). Combine this with the obnoxious experience of “local” developers who pretend to be holy and get angry I dare to think I’m as good as them, and you can probably guess why I’m a Free Software developer.