We’ve had pretty good experiences when using Brother printers and scanners in our Linux world – Brother is one of those companies that do not treat their Linux customers as second class. It was quite obvious we’d put Brother devices to the top of our list when shopping for new hardware.
So when we needed a printer/scanner combo for low-volume printing, some occasional scan jobs (but with automated document feed) and WLAN capabilities, we decided to try Brother’s DCP-J925DW device: It’s an ink jet printer with four separate ink tanks (CMYK), does even allow for the occasional printing of a CD/DVD label (right on the printable medium, without having to handle separate label stickers), comes with a scanner with ADF and is WLAN-capable.Unboxing the machine gave a generally positive impression, with each one notable plus and minus: The “CD tray”, required for label printing, has it’s own storage compartment right beneath the scanner lid, so that extra and rather seldomly used piece of plastic is stored away securely and still at hand when you need it. On the other hand, those typical tape strips attached to hold close the various lids and covers during transport, left nasty glue marks on the otherwise exceptionally nice surfaces of the unit. That’s something for Brother to work on.
The setup went smooth and easy: The MAC address of the “printer” was available via the device’s front panel, so we took care of a DNS name and a static IP address associated with that MAC address (making sure the DNS and DHCP servers knew about that and would hand out the proper address, and that the MAC address made it into the according WLAN cell’s access list). Entering the WLAN key into the printer was manageable, too, although the touch display is rather small. Oh, the printer spits out a configuration page automatically, even if you mis-configured and the printer couldn’t associate with the WLAN base station – I would have preferred that message to go to the front panel: Save the trees!
We already have a printer/scanner server set up, which is a SLES11SP3-based server VM at our central site. This server already has one or another Brother (and other manufacturer’s) device in its list and uses CUPS and SANE to give access to any requiring station within our network. So all we had to do was to install the current CUPS and SANE driver RPMs, as downloaded from Brother’s web site:
I won’t bore you with the details of the CUPS configuration (pretty standard) and will only mention the command to set up the scanner for future reference:
root@yourhost:~ # brsaneconfig4 -a name=printer19 model="DCP-J925DW" nodename=newprinter.company.com
Of course, you should replace the “name” parameter’s value with a name your users will recognize and enter the proper DNS name as the “nodename” value.
First print and scan tests were completed successfully. We only spotted a minor inconsistency, which may well have to do with SANE, rather than the Brother driver: Querying the list of available scanners gives a switched result for the brscan2 and brscan4 drivers:
ourserver:/etc/sane.d # scanimage -L device `brother4:net1;dev0' is a Brother printer19 DCP-J925DW device `brother2:net1;dev0' is a Brother MFC-5860CN printer05 ourserver:/etc/sane.d #
On the other hand, we later on noticed a severe problem when running more thorough scan tests: When accessing the scanner via saned (i.e. from our usual workstations), rather than via the DLL directly, we are unable to complete scans with a scan density above 200 dpi! So the above oddity may actually already point to some problem with the driver.
Update: Brother has provided us a working (beta) driver.
Symptoms
After some testing, we boiled it down to a difference between scanning via the DLL directly, versus using SANE’s net.dll to access “saned” on the scan server. Running various scans of a page via “scanimage” shows the following messages:
me@ourserver:~> time scanimage -d 'net:ourserver:brother4:net1;dev0' --resolution 1200 -v > /tmp/x.out scanimage: rounded value of br-x from 215.9 to 215.88 scanimage: rounded value of br-y from 355.6 to 355.567 scanimage: scanning image of size 9920x13889 pixels at 24 bits/pixel scanimage: acquiring RGB frame scanimage: min/max graylevel value = 255/0 scanimage: sane_read: Out of memory real 0m11.089s user 0m0.000s sys 0m0.008s me@ourserver:~> time scanimage -d 'net:ourserver:brother4:net1;dev0' --resolution 300 -v > /tmp/x.out scanimage: rounded value of br-x from 215.9 to 215.88 scanimage: rounded value of br-y from 355.6 to 355.567 scanimage: scanning image of size 2480x3472 pixels at 24 bits/pixel scanimage: acquiring RGB frame scanimage: min/max graylevel value = 0/255 scanimage: sane_read: Out of memory real 0m49.661s user 0m0.084s sys 0m0.144s me@ourserver:~> time scanimage -d 'net:ourserver:brother4:net1;dev0' --resolution 200 -v > /tmp/x.out scanimage: rounded value of br-x from 215.9 to 215.88 scanimage: rounded value of br-y from 355.6 to 355.567 scanimage: scanning image of size 1648x2314 pixels at 24 bits/pixel scanimage: acquiring RGB frame scanimage: min/max graylevel value = 0/255 scanimage: read 11440416 bytes in total real 0m27.561s user 0m0.036s sys 0m0.072s me@ourserver:~>
As you can see, those are scans with 1200, 300 and 200 dpi, all using the “net” interface to access the scanner via “saned”. Only the 200 dpi scan was successful, the others returned a strange “out of memory” error message. Be assured, memory constraints were not the cause.
In contrast, here’s the output from a 1200 dpi scan, run on the same machine, even the same shell process, but this time using the brother4 driver directly (not going through saned):
me@ourserver:~> time scanimage -d 'brother4:net1;dev0' --resolution 1200 -v > /tmp/x.out scanimage: rounded value of br-x from 215.9 to 215.88 scanimage: rounded value of br-y from 355.6 to 355.567 scanimage: scanning image of size 9920x13889 pixels at 24 bits/pixel scanimage: acquiring RGB frame scanimage: min/max graylevel value = 2/255 scanimage: read 413336640 bytes in total real 7m36.189s user 0m8.413s sys 0m1.772s me@ourserver:~>
Diagnosis
Now of course, this made me curious. While I had already contacted our local Brother support team, I guessed it’d do no harm to dig into this a bit deeper. I didn’t have the brscan4 source code at hand, so the best I could do was to analyze the network traffic between our scan server and the new DCP-J925DW. And indeed, there was a minor but essential difference.
The Brother driver communicates with the scanner on TCP port 54921. Right after session establishment, the scanner sends a short status notice to signal it is ready for communications (“+OK 200”, followed by CRLF).
The driver seems to send its commands to the scanner as
- “0x1b” as a “start of command” indicator
- one-byte command code, plus field delimited 0x0a
- optionally some fields, again each terminated by 0x0a
- a final “0x80”
and the scanner responds in some binary fashion.
In both the “brscan4 DLL via saned” and the “brscan4 DLL directly” tests, the driver opens a first session to send the command “0x51”, probably to determine the device status. On a second session, it sends a “0x49” command, requesting the scan resolution and color mode (“R=1200,1200” and “M=CGRAY” in our test case), receives a response from the scanner with jobs details and then requests the actual scan via the command “0x58” plus appropriate parameters.
In the “brscan4 DLL directly” run, the scanner now starts sending the scan result to the driver, which it obviously receives properly and hands it to the upper-layer application (in our case “scanimage”).
In the “brscan4 DLL via saned” run, the brscan4 continued by sending some obscure byte sequence (0x1b, 0x52), which does look like the start of some command (but lacks the terminating 0x0a and 0x80) – and the scanner responds by sending a single “0x83”, which I take to mean “there’s some error, aborting”. When debugging “saned” (i.e. by invoking it as “saned -d9”, where it will output various details to console), we then could see that saned is waiting for data from the driver, receives none and reports this as an “out of memory” condition to the client:
[saned] do_scan: start [saned] do_scan: trying to read 8188 bytes from scanner [saned] do_scan: read 0 bytes from scanner [saned] do_scan: status = `Out of memory'
Resolution
We have reported our findings to our local Brother support, but as it was just today, we have not had any response from their development staff. It may be a driver problem, it may as well be something within SANE – but since we’re successfully running a different Brother scanner via the same setup, but with another driver (brscan2 instead of brscan4), I wouldn’t be surprised to see it is some minor difficulty within the brscan4 driver.
Fortunately, there’s a work-around for those of us who cannot wait: All you have to do is install the brscan4 driver on the client system, too, thus accessing the scanner via network from your client machine directly.
If there’s no brscan4 package for your system, or your corporate network setup prohibits direct access to the scanner from your client, you’re out of luck though.
I ask you all to send a comment to this article if you hit the same problem – using a central scan server, plus network access for the clients via that server only, seems not to be that widely implemented; I have no idea how many people are affected by this. The SANE documentation calls this “the ultimate way to attach to a scanner”. I simply call it the right way.
4 Responses to Brother DCP-J925DW: Problems when scanning via SANE