Subject: lpd ethertap, one last data point
From: R Shapiro (reshapiro@mediaone.net)
Date: Thu Nov 02 2000 - 17:47:32 MST
I dug up my old copy of OTSessionWatcher do trace the MacOS side of
this problematic connection. Here's what it captured:
Send bind request (T_BIND_REQ = 101).
Bind to 192.168.1.2:721
Connection Indication Number = 2
Receive bind ack (T_BIND_ACK = 122).
Bind to 192.168.1.2:721
Connection Indication Number = 2
Send connection request (T_CONN_REQ = 102).
Connect to 24.218.57.230:515
Receive connection confirmation (T_CONN_CON = 123).
Connect from 24.218.57.230:515
Send data (14 bytes).
<00000000< Ç02Èepson-medres
Receive data (1 bytes).
>00000000> 00
Send data (14 bytes).
<0000000E< Ç02Èepson-medres
Receive data (1 bytes).
>00000001> 01
Receive orderly release indication (T_ORDREL_IND = 132).
Send orderly release request (T_ORDREL_REQ = 109).
So it really is sending the queue name twice, when it should be
sending the queue name in the first packet and the control-file name
in the second. I was almost hoping macos was sending the right data
and mol and/or ethertap was somehow clobbering the data. That, at
least, would be fixable within mol or ethertap. But it looks like the
macos lpr client itself (ie the lpr desktop printer) is confused. I
don't know if there's any hope of getting that kind of problem fixed,
especially since it only shows up in this one context :(
-- reshapiro@mediaone.net
This archive was generated by hypermail 2a24 : Thu Nov 02 2000 - 17:47:37 MST