Subject: Re: 'verify' is not diagnostic (thread: lpr desktop printers)
From: R Shapiro (reshapiro@mediaone.net)
Date: Wed Nov 01 2000 - 08:54:56 MST
I'm assuming from the non-response that no one has ever actually
succeeded using an macos lpr desktop printer to a lpd server running
in linux on the same box. Please correct me if I'm wrong.
This is such an elegant solution to the lack of usb-printer support in
mol that I'd really like to get it going. So even though no one may
be listening anymore, I'm going to proceed with some public debugging
:)
The problem is that linux reports a protocol error, and now I think I
see why. Here's a packet-by-packet description, from a packet trace
collected in linux:
> 07:28:36.745046 < 192.168.1.2.721 > [linux_addr].printer: S 2618147389:2618147389(0) win 32768 <mss 1460,wscale 0,nop> (DF)
This is the SYN from macos (request for connection).
> 07:28:36.745046 > [linux_addr].printer > 192.168.1.2.721: S 1433166786:1433166786(0) ack 2618147390 win 32120 <mss 1460,nop,wscale 0 > (DF)
This is the corresponding SYN ACK from linux (connection accepted).
> 07:28:36.745046 < 192.168.1.2.721 > [linux_addr].printer: P 1:15(14) ack 1 win 32768 (DF)
This is the lpr request from macos. I don't know why this appears in
the trace before the final ACK in the tcp 3-way handshake - possibly
an artifact of tcpdump. This may have something to do with the
protocol error a little later on.
> 07:28:36.745046 > [linux_addr].printer > 192.168.1.2.721: . 1:1(0) ack 15 win 32120 (DF)
This is the final ACK from linux in the tcp 3-way handshake
(connection ready to go).
> 07:28:36.745046 > [linux_addr].printer > 192.168.1.2.721: P 1:2(1) ack 15 win 32120 (DF)
This is the linux lpd server responding to the lpr request from two
packets up. The response is "ok, go ahead". Things should be from
this point, but they're not.
> 07:28:36.755050 < 192.168.1.2.721 > [linux_addr].printer: P 15:29(14) ack 2 win 32768 (DF)
This is a repeat of the lpr request from macos -- that's the protocol
error. Macos should have already gotten an "ok" ack from the first
request, so it should now be sending the data. Instead it repeats the
request, which is not what the protocol calls for.
> 07:28:36.755050 > [linux_addr].printer > 192.168.1.2.721: P 2:3(1) ack 29 win 32120 (DF)
This is the puzzled linux lpd server responding to the repeated
request. The response can be paraphrased as "hunh?", which macos
(properly) takes to mean "not accepted".
> 07:28:36.755050 > [linux_addr].printer > 192.168.1.2.721: F 3:3(0) ack 29 win 32120 (DF)
This is the FIN from macos, shutting down the connection since it
thinks it failed.
The final three packets are the rest of the shutdown (omitted).
So it really is a protocol error.
The question is, why is macos repeating the request after it already
got a positive ack the first time? It's not a tcp retransmission (the
seq# is different) so it didn't miss ack.
Could it be a clock problem? The clock has been off in mol since
daylight time ended (I have to keep resetting it manually). Note that
the clock values aren't moving at all
The packet trace above is taken in linux. To really see what's wrong,
I need also need a trace of the packets in macos. Are there tools for
this?
-- reshapiro@mediaone.net
This archive was generated by hypermail 2a24 : Wed Nov 01 2000 - 10:02:54 MST