[comp.dcom.modems] Inside info on Telebit spoofing?!?

root@zswamp.uucp (Geoffrey Welsh) (04/19/91)

   Does anyone know what the data stream fed to the line looks like after a 
Telebit has gone into spoofing mode?

   I could imagine a Trailblazer stripping all the framing and providing the 
ACKs, and then sending the data into the PEP or MNP as if the host had simply 
done a binary dump to the serial port.  The receiving modem would take the 
raw data after the PEP/MNP processing and send it via UUCP-g to the receiving 
computer.

   This might not be the most elegant or safest approach, but it would mean 
easy inter-manufacturer compatibility.  Data should remain safe, since MNP or 
LAP-M would be entrusted with delivering the binary data verbatim, and each 
modem could take care of the protocol spoofing with its own home machine.

   This might also make it *theoretically* possible to tell machine A to send 
using Kermit and machine B to receive using XMODEM, since the data stream in 
between would be raw and spoofing would be a local issue only.

   Don't ask me how the modem is supposed to recognize the protocol if both 
ends don't interact enough to indicate a transfer reliably, this is just an 
uneducated dream. <grin>
 

--  
UUCP:     watmath!xenitec!zswamp!root | 602-66 Mooregate Crescent
Internet: root@zswamp.fidonet.org     | Kitchener, Ontario
FidoNet:  SYSOP, 1:221/171            | N2M 5E6 CANADA
Data:     (519) 742-8939              | (519) 741-9553
The mile is traversed not by a single leap, but by a procession of coherent 
steps; those who insist on making the trip in a single element will be
failing long after you and I have discovered new worlds. -- me

gandrews@netcom.COM (Greg Andrews) (04/20/91)

In article <7229.280E4283@zswamp.uucp> root@zswamp.uucp (Geoffrey Welsh) writes:
>
>   I could imagine a Trailblazer stripping all the framing and providing the 
>ACKs, and then sending the data into the PEP or MNP as if the host had simply 
>done a binary dump to the serial port.  The receiving modem would take the 
>raw data after the PEP/MNP processing and send it via UUCP-g to the receiving 
>computer.
>

Why bother?  It would be another order of magnitude more work to have to
strip out the protocol stuff and re-generate it at the receiving end.  Heck, 
the computer has done all the hard work already.  Just check the basic stuff
like the packet is not out of sequence and the checksum compares okay and
ack it.  The receiver's modem only has to feed the packet to the computer 
and get the ack.

The fact that the sender's modem provides the ack locally and the receiver's
modem absorbs the ack locally (and the sender's modem ensures that its buffer
stays full) is what makes spoofing work across a PEP connection.


-- 
.------------------------------------------------------------------------.
|  Greg Andrews   |       UUCP: {apple,amdahl,claris}!netcom!gandrews    |
|                 |   Internet: gandrews@netcom.COM                      |
`------------------------------------------------------------------------'

tech@mich-ns.UUCP (Mich. Network Sys. TECH SUPPORT) (04/25/91)

In article <7229.280E4283@zswamp.uucp> root@zswamp.uucp (Geoffrey Welsh) writes:
"
"   Does anyone know what the data stream fed to the line looks like after a 
"Telebit has gone into spoofing mode?
"

Basically, what spoofing does is eliminate the need for the ACK to 
traverse the phone line. The sending modem receives data from the 
DTE and pumps it out to the phone line as fast as it can and sends an
ACK back to the DTE without having to receive one from the remote end.

The remote (receiving) modem tosses out all ACK's that its DTE sends it
in response to an incoming packet. This reduces the latency involved in 
whereby the sending system has to wait for an ACK from the remote for 
a packet just sent before sending another one. All of Telebit's features
(Spoofing and PEP) are designed to optimize a link over a normal phone 
line. PEP utilizes as much of the bandwidth as possible, given the line 
quality and can dynamically change its utilization based on changing line
conditions. Spoofing eliminates the latency involved with the "send-wait"
mentality of most protocols. 
 
As for error correction: Thats done at a lower level by PEP's CRC-16.

"   I could imagine a Trailblazer stripping all the framing and providing the 
"ACKs, and then sending the data into the PEP or MNP as if the host had simply 
"done a binary dump to the serial port.  The receiving modem would take the 
"raw data after the PEP/MNP processing and send it via UUCP-g to the receiving 
"computer.
"
"   This might not be the most elegant or safest approach, but it would mean 
"easy inter-manufacturer compatibility.  Data should remain safe, since MNP or 
"LAP-M would be entrusted with delivering the binary data verbatim, and each 
"modem could take care of the protocol spoofing with its own home machine.
"

Thats it. Error correction protocols eliminate the need for ACK/NAK. Telebit
takes advantage of this.


"   This might also make it *theoretically* possible to tell machine A to send 
"using Kermit and machine B to receive using XMODEM, since the data stream in 
"between would be raw and spoofing would be a local issue only.
"
"   Don't ask me how the modem is supposed to recognize the protocol if both 
"ends don't interact enough to indicate a transfer reliably, this is just an 
"uneducated dream. <grin>
" 

Protocol spoofing is enabled on either end by the setting of certain S-
registers. The modems can also detect which method the other modem is 
using and will use that as well if it is enabled locally.

-- 
Michigan Network Systems        Technical Support Division
1-800-736-5984                  BBS: +1 313 343 0800 
      TELEBIT  DIGIBOARD   WESTERN DIGITAL  3COM   SCO   INTERACTIVE UNIX
                         MICROPOLIS    ADAPTEC