Hi,
Thanks for the response. I got to thinking about the same thing about maybe only accepting one session at a time and called the printer manufacturers support. We were both right, it will only handle one session at a time and will throw an error if you try to connect twice. I've escalated this up to make a code change on the server side to quit probing the printer and sending the job before the printer sends the ack to kill the probe session, or just quit probing the printer before the print job. Thanks for taking your time to check it out. Here is the kb article the printer support sent me.
LPD LPR printing
The mobile printer is a battery operated remote device designed to conserve energy while simultaneously optimizing print quality. It will not perform the same as a tabletop line printer with a high speed processor and large memory buffers, which are typically always turned on. It only processes one TCP connection at a time. If the server sends others while it is generating/printing a label the printer will reject the requests until it is free. This is normal acceptable behavior. It is up to the server and or sending application, not the printer, to retry and handle such normal error conditions appropriately. If using LPD, the spooler should be programmed to retry on a "printer busy" response. TCP printing is more robust as it handles the error conditions in a reliable manner, but it is still up to the application to understand how to deal with errors reported back by the protocol. All applications, especially those relying on LPD should check printer status prior to and after posting a print job.
On 3/26/07, Jack Jackson <jack@xxxxxxxxxxxxxxx> wrote:
At 10:24 AM 3/26/2007, Jamie Crawford wrote:
>Hello,
>I've got a application that probes a wireless printer to make sure it can
>communicate over tcp 6101. Once that it sees that it can communicate over
>that port, it will then send it's print job. But for some reason, the
>printer hangs up and won't accept any more connections for 60 seconds.
>Heres what the conversation looks like. Should the server just send a
>fin,ack to kill the session off? I figured you would first send a fin,
>and then get a fin,ack back from the printer?
>
>
>server 29515 -> printer 6101 syn
>printer 6101 -> server 29515 syn,ack
>server 29515 -> printer 6101 ack
>server 29515 -> printer 6101 fin,ack
>server 29517 -> printer 6101 syn
>printer 6101 -> server 29515 ack (TCP ZEROWINDOW)
>printer 6101 -> server 29517 rst,ack
>server 29517 -> printer 6101 syn
>printer 6101 -> server 29517 rst,ack
>server 29517 -> printer 6101 syn
>printer 6101 -> server 29517 rst,ack
>server 29517 -> printer 6101 syn
>printer 6101 -> server 29517 rst,ack
>server 29517 -> printer 6101 syn
>
>start over..same cycle....
Perhaps the print server won't let you start another connection when the
first connection hasn't been terminated.
When you send the second syn, the first connection has not been terminated
- the print server hasn't acked your fin (it does later) and hasn't sent
fin to terminate the other half of the conversation. I don't know why the
print server doesn't send fin. Maybe it never expects to get a connection
with no data or maybe the syn confuses it.
What happens if you don't send the second fin - does the print server
eventually close the first connection properly? If so, you could wait for
that to happen. Or you could try sending it a rst to force the connection
closed.
_______________________________________________
Wireshark-users mailing list
Wireshark-users@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-users
