Subject: lpr and likely mol/ethertap bug
From: R Shapiro (reshapiro@mediaone.net)
Date: Wed Nov 01 2000 - 13:33:11 MST
After a look at rfc1179, I'm zero'ing in on the problem.
An lpr request sequence should start like this:
<02><queue name><lf>
This is what linux receives from macos/mol via ethertap. Then linux
sends back a single byte: 0 if the request is acceptable, anything
else if it isn't. In my case linux sends a 0: it's a valid request
from a validated host so the request continues.
Next, macos should send this:
<02><count><space><name><lf>
where <count> is the ascii representation of the size of the control
file and <name> is the name of the control file (always 'cfAxxx',
where the x's are digits). But in the ethertap case to the same box,
this is not what happens. Instead, the second packet, as received by
linux is once again:
<02><queue name><lf>
This sequence is not legal at this point on the protocol, so linux
rejects it, and the request fails.
I don't know what macos is actually sending, since I don't have packet
trace tool for macos. If it's sending <02><queue name><lf>, that's
some weird bug in the desktop printer. If it's sending the right
sequence but linux is receiving the wrong one, that's definitely an
ethertap bug, or a problem with the way mol is interacting with
ethertap.
Samuel, are you following all this? Is it possible to get a packet
trace from macos in mol to find out what macos thinks it's sending?
-- reshapiro@mediaone.net
This archive was generated by hypermail 2a24 : Wed Nov 01 2000 - 14:41:04 MST