Re: ReadPrinter fails for TCP/IP port, works for LPT1 and USB using pjlmon XP DDK sample

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Marc Reinig (Marco_at_newsgroups.nospam)
Date: 01/06/05 

Date: Thu, 6 Jan 2005 10:00:58 -0800

Firewall?

Marco
________________________
Marc Reinig
UCO/Lick Observatory
Laboratory for Adaptive Optics

"Starman" <starmannj@hotmail.com> wrote in message
news:1105027097.899990.77120@c13g2000cwb.googlegroups.com...
> Hi all,
> I have this problem which has been eluding me for weeks. The sample
> pjlmon project that comes with the XP DDK works perfectly for printers
> that are connected via LPT and USB, but fails when trying to read from
> a printer that's connected via TCP/IP. The printer port we're using is
> a Standard TCP/IP port, over port 9100 which creates a port named
> IP_10.32.56.23 which is fine.
>
> Here's the kicker - when I use WritePrinter to send the data down,
> WritePrinter works and returns back a successful value. Using the
> Ethereal packet sniffer, I find that we DO get the right data back from
> the printer, but for some reason it doesn't "bubble up" from the port
> to the language monitor, and ReadPrinter returns with a 0 meaning that
> no data was read back, and the buffer's empty. I don't know where the
> data's getting blocked. Is the port monitor blocking it from the
> language monitor?
>
> I've tried this with both the outdated versions of pjlmon and the
> newer updated one (InitializePrintMonitor and InitializePrintMonitor2).
> Doing some digging, I found that the port type you're using uses a
> different DLL for filling in the MONITOR/MONITOR2 structure. Using a
> debugger, I found that for TCP/IP, GetPrinterDataFromPort is NULL for
> TCP printers, and valid for LPT and USB. It seems to me that the
> tcpmon.dll DLL assumes that backchannel data will never come from a
> TCP/IP printer. If this is true, I'm going to have to work out my own
> solution since I can't depend on that DLL for reading data back. In
> fact, I already did that, but it bypasses ReadPrinter which I really
> don't feel comfortable doing.
>
> According to the MSDN documentation, using SendRecvBidiDataFromPort
> only works on Windows XP anyway, so that solution will not be an option
> since we have to support 9x->XP.
>
> So, what I want to know, if anyone can answer, are the answers to
> these questions:
>
> 1) Why do we not get backchannel data back from a printer with pjlmon
> (both old and new) using TCP/IP, but works with LPT and USB?
>
> 2) Will bidi communication work on server-based system such as CUPS and
> Samba? HP's bidi software wouldn't work with printers connected to
> these types of systems, but did work with direct TCP/IP connections.
> Thanks in advance.
> Mike
>

Relevant Pages

  • ReadPrinter fails for TCP/IP port, works for LPT1 and USB using pjlmon XP DDK sample
    ... a printer that's connected via TCP/IP. ... The printer port we're using is ... to the language monitor, and ReadPrinter returns with a 0 meaning that ... I've tried this with both the outdated versions of pjlmon and the ...
    (microsoft.public.development.device.drivers)
  • Re: Honeypot stats
    ... >> connections without authorization. ... > Well Larry, today's reality is TCP/IP. ... > opening a non-priv port, cannot affect the rest of the system any more ... With DECnet one knows that no normal user has created some path ...
    (comp.os.vms)
  • Re: Multiplexing serial data for multiple applications
    ... COM port between two running applications. ... TCPCom is primarily designed to expose a COM port to a TCP/IP port ... willaccept multiple client connections. ...
    (microsoft.public.pocketpc.developer)
  • Re: Need help with bandwidth management . . .
    ... also be a good time to separate the wired from the wireless parts of ... wired connections. ... QoS lan port settings, and I cannot get anything consistent. ... switch ports and limit the bandwidth per port (the settings are ...
    (alt.internet.wireless)
  • Re: z/OS using a guest virtual LAN under z/VM
    ... Making the DEVICE name the same as the TRLE name does *not* correspond to what I just posted on the IBMTCP-L list concerning the relationship between the TRLE statement and the DEVICE statement. ... The device name must be the PORT name of the LAN adapter defined in a TRLE for a QDIO connection. ... OSA port operating in either ATM native mode or in QDIO mode. ... If used by TCP/IP, this name must also be defined as the portname in the TCP/IP Profile DEVICE statement. ...
    (bit.listserv.ibm-main)