Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bionet!ames!sgi!vjs@rhyolite.wpd.sgi.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.dcom.modems
Subject: Re: Telebits and uucp g-protocol
Summary: spoofing is sometimes bad
Message-ID: <35933@sgi.SGI.COM>
Date: 17 Jun 89 00:54:21 GMT
References: <335@nixtor.UUCP> <13751@ncoast.ORG> <783@omen.UUCP>
Sender: daemon@sgi.SGI.COM
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 28

In article <783@omen.UUCP>, caf@omen.UUCP (Chuck Forsberg WA7KGX) writes:
> ...
> Almost, but not quite, transparently.  Enabling protocol spoofing for a
> protocol typically interferes with the correct operation of other
> protocols, so the spoofing is not quite "transparent".
> ...
> Chuck Forsberg WA7KGX          ...!tektronix!reed!omen!caf 
> Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
>   Omen Technology Inc    "The High Reliability Software"
> 17505-V NW Sauvie IS RD   Portland OR 97231   503-621-3406
> TeleGodzilla:621-3746 FAX:621-3735 CIS:70007,2304 Genie:CAF

Quite so.  I have a Compressed-SL/TCP/IP-with-cksums protocol (uhh, kludge)
which distills TCP/IP to <framing><user-data><1-byte-of-TCP><cksum><framing>.
With UUCP enabled, a pair of TB+'s on a test wire would continually
retrain and loose the connection, and never pass any data TCP/IP data.
I presume they thought the binary compress-SLIP swill looked like UUCP
handshakes, and went out to lunch when it did not make sense.

I kind of wish there had been a warning in the manuals.  It took me
too much time to figure out that there was nothing wrong with the
modems or the wire.

Of course, if you're doing UUCP-g, TB+'s are currently unbeatable.

Vernon Schryver
Silicon Graphics
vjs@sgi.com