
I have a printer that's being strange. Since the printer itself runs ipp, I'm trying to send it jobs directly with lp/lpstat/loptions/cancel &c, without talking to cupsd. I get some responses, but nothing very helpful. Are the cups client utilities supposed to be able to talk generic IPP, or do they assume the far end is cups? Since IPP is based on HTTP, I also tried just using netcat, but RFC2910 §13.1 seems to be sying that it has a bunch of byte-encoded stuff, rather than just VERB LOCATION PROTO/VERSION. Google and IRC haven't helped, so my next step I guess is to actually read the RFCs instead of just skimming them. $ ssh root@printserver grep DeviceURI /etc/cups/printers.conf DeviceURI ipp://mfd [....] $ ping -c1 mfd PING mfd.cyber.com.au (203.7.155.91) 56(84) bytes of data. 64 bytes from MFD.cyber.com.au (203.7.155.91): icmp_seq=1 ttl=254 time=0.723 ms --- mfd.cyber.com.au ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.723/0.723/0.723/0.000 ms This saves adding -h every time. Also I found that lpstat -t -h foo will STILL talk to the default printserver (not foo) for some of its queries -- WTF? $ cat ~/.cups/client.conf ServerName mfd $ lpstat -t scheduler is running no system default destination lpstat: server-error-operation-not-supported lpstat: server-error-operation-not-supported lpstat: server-error-operation-not-supported lpstat: server-error-operation-not-supported $ date | lp -d canthappen request id is canthappen-498 (0 file(s)) $ date | lp -d foo request id is foo-500 (0 file(s)) $ date | lp -d '' request id is -502 (0 file(s)) ...printer still hasn't printed anything. $ lpstat -t scheduler is running no system default destination lpstat: server-error-operation-not-supported lpstat: server-error-operation-not-supported lpstat: server-error-operation-not-supported lpstat: server-error-operation-not-supported MFD speaks PS (I think), so try that as well as text/plain. Doesn't help. $ date | a2ps -o- | lp -d '' # the mfd speaks PS (I think), so try that. [stdin (plain): 1 page on 1 sheet] [Total: 1 page on 1 sheet] sent to the standard output request id is -504 (0 file(s)) $ nc mfd ipp GET / HTTP/1.1 400 Bad Request Server: gSOAP/2.7 Content-Length: 0 Connection: close $ nc mfd ipp Print-Job 1 IPP/1.1 HTTP/1.1 400 Bad Request Server: gSOAP/2.7 Content-Length: 0 Connection: close $

Trent W. Buck <trentbuck@gmail.com> wrote:
I have a printer that's being strange. Since the printer itself runs ipp, I'm trying to send it jobs directly with lp/lpstat/loptions/cancel &c, without talking to cupsd.
I get some responses, but nothing very helpful.
Does Wireshark/Tshark give you any clues as to what's going wrong with the exchange between host and printer? Looking at some sample traffic might be enough to allow you to avoid reading (most of the) RFCs... Or perhaps not.

Jason White <jason@jasonjgw.net> writes:
Trent W. Buck <trentbuck@gmail.com> wrote:
I have a printer that's being strange. Since the printer itself runs ipp, I'm trying to send it jobs directly with lp/lpstat/loptions/cancel &c, without talking to cupsd.
I get some responses, but nothing very helpful.
Does Wireshark/Tshark give you any clues as to what's going wrong with the exchange between host and printer?
Looking at some sample traffic might be enough to allow you to avoid reading (most of the) RFCs... Or perhaps not.
Good idea. I have at least one working printer, so I can tshark that traffic to work out how to speak IPP.
participants (2)
-
Jason White
-
trentbuck@gmail.com