# Re: parallel port scanner support

Jon Knight (jon@net.lut.ac.uk)
Fri, 23 Oct 1998 09:29:21 +0100 (BST)

- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
- Next message: Dr. Andreas Bolsch: "Re: 6000SP: open of device /dev/dg0 failed, invalid argument"
- Previous message: Christian Bucher: "Re: Epson GT-300, scanimage results"

On Fri, 16 Oct 1998, Marco Foglia wrote:
> Is it possible to monitor the parallel port with a second computer to
> obtain information about the protocoll?
>
> I attached a second computer to the pass-through parallel port
> of the scanner.
>
> [ Sniffer] <----[Scanner]<---->[Win]
>
> While scanning under Win95 with one computer, the other was
> able to get "some" data form the parallel port. I am really not an
> expert in hardware. So i dont know whether this data ist usefull
> or not.

I would guess that it would depend to some extent on the scanner but I
would not expect to get much information from many scanners this way. My
reasoning is that the pass-through port of the scanner is intended to pass
parallel port comms *not* intended for the scanner along to other devices.
I would assume that if the comms are intended of the scanner, the scanner
would process them itself and not pass anything on to the pass-through
port. Similarly any protocol responses from the scanner to the PC would
probably not appear on the pass-through port.

I would think that it *might* be possible to do some sort of "man in the
middle" attack on the protocol by having a second sniffing PC placed
between the scanner and the Windows PC:

[scanner]<---->[sniffer]<---->[WinPC]

Quite how to do this is something I've been pondering myself. What I'd
really like is about 16 input lines on the sniffer PC (no need for any
output lines), which is stretching even two normal parallel ports. You
might be able to do some sort of neat tricks with ECP/EPP ports if the
scanner and the PC are talking using these but I'd guess it might get a
bit icky. Ideally you'd want 16 (or more!) input lines, with a hardware
buffer and the ability to clock in all 16 into the buffer any time one of
them changed (or at least sufficiently fast that you can watch any
protocol exchanges. Maybe if you could just decode the ECP or EPP
protocol to work out the direction of data travel you could get away with
10 inputs (8 bits of data, 1 bit for direction of travel and 1 for a
"clock" so that you know when you have valid data).

I wonder how the parallel port ZIP drive protocol was decoded? Any
suggestions folks?

Tatty bye,

Jim'll

#!/usr/bin/perl -- -Whois++-client-in-6-lines-of-Perl -Beat-that-Z39.50!
use IO::Socket;sub w{$f=shift;$a{$f}=1;($h,$p,$q)=split("/",$f);$s=
IO::Socket::INET->new(PeerAddr=>"$h:$p")||return;print $s "$q\r\n";while(<$s>)
{next if(/^%/);if(/^# SERVER-TO-ASK/){while(<$s>){$x=$1 if/Name: (.*)\r\n$/;$y
=$1 if/Port: (.*)\r\n$/;$f="$x/$y/$q";@j=(@j,$f)if(/^# END/&&!$a{$f})}}else{
print}}close($s)}@j=shift;while(@j){w(pop(@j))}# whois++.pl host/port/query

    --
    Source code, list archive, and docs: http://www.mostang.com/sane/
    To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com

- Next message: Dr. Andreas Bolsch: "Re: 6000SP: open of device /dev/dg0 failed, invalid argument"
- Previous message: Christian Bucher: "Re: Epson GT-300, scanimage results"