Subject: Re: 'verify' is not diagnostic (thread: lpr desktop printers)
From: R Shapiro (reshapiro@mediaone.net)
Date: Wed Nov 01 2000 - 12:02:20 MST
Continuing...
R Shapiro writes:
> > 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
I'm told that my understanding of the 3-way handshake was wrong.
There's nothing mysterious about this lpr request packet appearing at
this point in the conversation.
> > 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).
See above. This is not part of the handshake, it's just an ordinary
ack to the request above.
>
> > 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 ok from
> this point, but they're not.
This is also an ack to the first request. The difference between this
one and the one before is that this one has one payload byte, a zero
which indicates a successful lpr request, whereas the previous packet
is a pure ack, with no payload.
After this comes the repeated lpr request from MacOS, and the
"screwdup protocol/rejected request" reply from linux.
Does anyone on this list understand enough about tcp and lpr to see
why MacOS is repeating the request? I think what we have here may be
a general macos-linuxppc compatibility problem that has nothing
specifically to do with mol or ethertap or anything else at that
level.
-- reshapiro@mediaone.net
This archive was generated by hypermail 2a24 : Wed Nov 01 2000 - 13:10:11 MST