In article , Perdition wrote: :by port i mean serial port :) the encrypter simply receives data from a :serial port on one end, operates a certain algorithm with a key to :encrypt all the data, and through another serial port it emits a stream :of data towards the router. of course the router can't route this :information since it's unintelligable. That is where the encapsulation :after the encryption must come in.
Serial port makes it easy:
transmitting side: do something to configure the serial port to the right attributes ttcp -t REMOTEHOST < PORTNAME
Receiving side: do something to configure the serial port to the right attributes ttcp -r > PORTNAME
For example on unix,
(stty 38400 raw; ttcp -t 123.45.67.89) < /dev/ttyd6 #transmitting (stty 38400 raw; ttcp -r) > /dev/ttyd3 #receiving
To emphasize: this will not care in the least that the data is not framed, provided that the serial output of the encryptor can use one of the character framing mechanisms recognized by the OS, preferably
8 bits no parity for maximum data transfer rate.
:The operating system will more than :likely be Windows, any windows really.
This sort of thing is usually easier to set up with Unix, but it should be possible with Windows.
To re-emphasize: ttcp (and netcat) can read an arbitrary stream of bytes and package them up into packets and send them to the other end where they get unpackaged and delivered. They don't *care* where the data came from, and they will pack as much data in per packet as will fit (or as was configured.)
NB: if you use ttcp or netcat, then because the framing information is lost, you will run into difficulties. For example, a post-tunneled TCP SYN packet should be replied to by the far end with a SYN ACK packet, but unless there is a consistant stream of other traffic or the encryptor knows enough to mix in empty frames so as to have a consistant output rate, then the buffering to collect the serial data into maximum- sized packets could significantly delay the SYN ACK response. You would, for example, see this kind of effect if the line was otherwise idle and you tried pinging the other end.