Document format error prevents printing on Brother MFC-J6710CDW

Takiko ack210t at yahoo.com
Wed Nov 16 02:58:37 PST 2011


Hello,

I have a new Brother MFC-6710CDW and am trying to print from Fedora 15 using CUPS 1.4.8 (cups-1.4.8-5.fc15.x86_64). The driver was downloaded and installed as an RPM from Brother's web site. I seem to be able to configure the printer just fine via the CUPS interface, connecting to it via Ethernet using the JetDirect port. And indeed, the printer and CUPS seem to be communicating.

But I still can't print, not even the test page. When I click on that button, it appears to queue the job, but it disappears immediately thereafter. Nothing is ever printed, and no error appears in the CUPS error log. In fact, according to the access log, the print job completes successfully:

"POST / HTTP/1.1" 200 251 Create-Printer-Subscription successful-ok
"POST /printers/MFCJ6710CDW HTTP/1.1" 200 482 Print-Job successful-ok

The only clue I have so far about what might be going wrong is that, when I look at the ink levels, CUPS tells me that the printer has no ink left. This makes no sense since I just installed new cartridges AND a test page printed directly by the printer looks fine in all colors. Instead, what seems to be happening is that, when CUPS tries to query the printer to determine the ink levels (as by clicking on "Refresh") there is some miscommunication. What I get then is:

CUPS server error
There was an error during the CUPS operation: 'client-error-document-format-not-supported'.

Apparently if CUPS cannot determine the ink level, it assumes there is no ink, and my guess is that, when it thinks there is no ink in the printer, it doesn't send the job. Does that make sense?

There is some evidence from this in a tcpdump of the communication when I try to print a page. What I see is a successful TCP handshake on port 9100, then some SNMP exchange, and then the CUPS side (not the printer) closes the TCP session:

19:55:32.549770 IP 192.168.0.4.42108 > 192.168.0.2.jetdirect: Flags [S], seq 768996221, win 14600, options [mss 1460,sackOK,TS val 2284980 ecr 0,nop,wscale 6], length 0
19:55:32.550280 IP 192.168.0.2.jetdirect > 192.168.0.4.42108: Flags [S.], seq 141525392, ack 768996222, win 8688, options [mss 1460,nop,wscale 0,nop,nop,sackOK,nop,nop,TS val 2626450 ecr 2284980], length 0
19:55:32.550343 IP 192.168.0.4.42108 > 192.168.0.2.jetdirect: Flags [.], ack 1, win 229, options [nop,nop,TS val 2284981 ecr 2626450], length 0
19:55:32.560432 IP 192.168.0.4.43620 > 192.168.0.2.snmp:  GetRequest(28)  25.3.2.1.3.1
19:55:32.561530 IP 192.168.0.2.snmp > 192.168.0.4.43620:  GetResponse(48)  25.3.2.1.3.1="Brother MFC-J6710CDW"
19:55:32.562037 IP 192.168.0.4.43620 > 192.168.0.2.snmp:  GetNextRequest(27)  43.12.1.1.4
19:55:32.563048 IP 192.168.0.2.snmp > 192.168.0.4.43620:  GetResponse(34)  43.12.1.1.4.1.1="black"
19:55:32.563200 IP 192.168.0.4.43620 > 192.168.0.2.snmp:  GetNextRequest(29)  43.12.1.1.4.1.1
19:55:32.564196 IP 192.168.0.2.snmp > 192.168.0.4.43620:  GetResponse(35)  43.12.1.1.4.1.2="yellow"
19:55:32.564267 IP 192.168.0.4.43620 > 192.168.0.2.snmp:  GetNextRequest(29)  43.12.1.1.4.1.2
19:55:32.565356 IP 192.168.0.2.snmp > 192.168.0.4.43620:  GetResponse(33)  43.12.1.1.4.1.3="cyan"
19:55:32.565419 IP 192.168.0.4.43620 > 192.168.0.2.snmp:  GetNextRequest(29)  43.12.1.1.4.1.3
19:55:32.566545 IP 192.168.0.2.snmp > 192.168.0.4.43620:  GetResponse(36)  43.12.1.1.4.1.4="magenta"
19:55:32.567769 IP 192.168.0.4.43620 > 192.168.0.2.snmp:  GetNextRequest(29)  43.12.1.1.4.1.4
19:55:32.569054 IP 192.168.0.2.snmp > 192.168.0.4.43620:  GetResponse(30)  43.12.1.1.5.1.1=2
19:55:32.570177 IP 192.168.0.4.43620 > 192.168.0.2.snmp:  GetRequest(28)  25.3.5.1.2.1
19:55:32.571002 IP 192.168.0.2.snmp > 192.168.0.4.43620:  GetResponse(29)  25.3.5.1.2.1=00
19:55:32.571105 IP 192.168.0.4.43620 > 192.168.0.2.snmp:  GetRequest(29)  43.10.2.1.4.1.1
19:55:32.572010 IP 192.168.0.2.snmp > 192.168.0.4.43620:  GetResponse(30)  43.10.2.1.4.1.1=1
19:55:33.806574 IP 192.168.0.4.42108 > 192.168.0.2.jetdirect: Flags [F.], seq 1, ack 1, win 229, options [nop,nop,TS val 2286237 ecr 2626450], length 0
19:55:33.807036 IP 192.168.0.2.jetdirect > 192.168.0.4.42108: Flags [.], ack 2, win 8687, options [nop,nop,TS val 2627750 ecr 2286237], length 0
19:55:33.807766 IP 192.168.0.2.jetdirect > 192.168.0.4.42108: Flags [FP.], seq 1, ack 2, win 8687, options [nop,nop,TS val 2627750 ecr 2286237], length 0
19:55:33.807817 IP 192.168.0.4.42108 > 192.168.0.2.jetdirect: Flags [.], ack 2, win 229, options [nop,nop,TS val 2286238 ecr 2627750], length 0

Maybe the driver is unable to process whatever query CUPS uses to ask about the ink level?

Does anyone know of a solution, or a way around this? I consider modifying CUPS so that it assumes 100% ink levels if it can't determine the level, but a non-hack solution would obviously be better!

Thanks very much! And if any additional data would help, please just let me know.

Takiko





More information about the cups mailing list