Comunicación de socket Python con servidor de impresión HP

Tengo un HP Laserjet 2550n con servidor de impresión integrado conectado a la red local en 192.168.1.100. Desafortunadamente, el software “caja de herramientas” del cliente que le indicó el estado del tóner, etc., solo se ejecuta en Windows XP. He usado Wireshark para escuchar la comunicación, usando una máquina XP antigua, y me gustaría escribir mi propio pequeño progtwig (prob under python) para recibir el xml con toda la información sobre la impresora. He logrado usar Putty con una conexión “RAW” al 192.168.1.100:9220 para repetir la comunicación a continuación y recibir el XML (no he adjuntado el XML completo, solo el principio).

Estoy luchando, sin embargo, por dónde empezar con python. He utilizado un cliente de socket simple para establecer una tubería, y socket.recv me envía la primera línea (220 JetDirect GGW …). Cuando socket.send (bytes (“TIME 600”, “UTF-8”)) y luego intente y reciba nuevamente, el shell interactivo se “congela”.

Realmente agradecería cualquier sugerencia sobre cómo obtener Python para tener la conversación como se muestra a continuación con el servidor de impresión. ¡Muchas gracias!

220 JetDirect GGW server (version 2.0) ready SERV HP-DC-WEB 250 96 HP-DC-WEB TIME 600 200 OK DEVI 255 MFG:Hewlett-Packard;CMD:PJL,PML,BIDI-ECP,MLC,PCL,POSTSCRIPT,PCLXL;MDL:hp color LaserJet 2550 series;CLS:PRINTER;DES:Hewlett-Packard color LaserJet 2550 series;MEM:MEM=57MB;1284.4DL:4d,4e,1;COMMENT:RES=600x2; OPEN 96 200 OK DATA 200 OK GET /hp/device/info_device_status.xml HTTP/1.1 HOST:localhost:5225 USER-AGENT:hp Proxy/2.5 CONTENT-LENGTH:0 HTTP/1.1 200 OK Server: Virata-EmWeb/R6_0_1 Transfer-Encoding: chunked Content-Type: text/xml Expires: Thu, 01 Jan 1970 00:00:00 GMT Cache-Control: no-cache Pragma: no-cache 0000013f ... 

Es muy difícil depurar tu código sin ver más de dos pequeños fragmentos, pero tengo una conjetura:

 socket.send(bytes("TIME 600","UTF-8")) 

No hay nueva línea allí. Y esto parece ser un protocolo basado en líneas. Por lo tanto, es de suponer que el servidor está esperando el rest de la línea, lo que nunca llega, y por lo tanto nunca devuelve nada en respuesta, y por lo tanto, su próxima recv solo se bloquea para siempre.

Vale la pena mencionar que el protocolo puede necesitar \r\n lugar de solo \n , especialmente si el dispositivo está tan centrado en Windows como parece.


Mientras tanto, los sockets son flujos de bytes, no flujos de mensajes ; send no está garantizado para enviar su mensaje completo; No se garantiza que recv reciba un mensaje completo del otro lado.

Para su aplicación simple, puede solucionar esto con bastante facilidad: use sendall lugar de send , y haga un bucle sobre recv hasta que tenga una línea completa, o, aún más simple, simplemente use makefile .