converting a random string of bits into a TCP/IP packet

I have encrypted data which I would like to send over the net, but I don't know how to make the router interpret them into data, all it sees is an endless string of bits. I need a way, and I don't care how complex or expensive to make the router understand this code. if you know any product, hardware, interface or anything else that can add an IP packet format or any other third/second level protocol (HDLC,SDLC,DECNET..) from data, please help.

Thanks a bunch, you rock on many levels, all seven of them, Michael

Reply to
Perdition
Loading thread data ...

You could try using a File Transfer Protocol FTP) utility; plenty of them available.

Reply to
Merv

I don't see how an FTP utility is used between a router and a hardware based encrypter to pack the data into a packet so the router can route the information properly, can you elaborate please? :)

Reply to
Perdition

How about netcat?

formatting link

Reply to
Rex Johnson

I'm not sure this is the program for me, i have data and i bring it through a hardware encrypter so it is then transformed into a series of encrypted bytes, meaning it is entirely of the physical layer without any flags or what not to say when it begins or ends. I then need to have it packed into a third layer packet so that a router will know how to transport it. on some other network is another encrypter and if need be, a program to do the opposite of what was done on the original network. That means take the third layer information and decapsulate it entirely to raw data. Then the encryptor will use the same key in order to interpret the data. I didn't understand from the netcat website whether or not it can accept data through a port which doesn't have any discernable headers. It has to be data that is transported from one network to another, the window size will be the only thing to stop the flow between encapsulations. Any thoughts?

Reply to
Perdition

Let me get this straight.. You've got a hardware encrypter that takes a stream of data in on one network port, encrypts it, and spits it out on another port connected to your router? Something like tinc would (technically) do the job.. Sit it in between your encrpyter device and your router and configure it in 'hub' mode, where it will listen promiscuously on one interface, and to encapsulate anything it hears with an IP header for broadcasting to another tinc server. Once it hits the other end, the IP header will be stripped off and the underlying data spat back out to whatever's on the other side. The only thing I'm not sure about is whether it will blindly accept and retransmit frames with no valid MAC hdr/CRC..

If you're going to be going to such trouble, you would probably be better just implementing this as an IPSEC VPN and removing the hardware encrypters altogether, though? Seems that would be a much simpler solution..

Andy

Reply to
Andy Furnell

What is the "hardware" between this hardware encryptor and the router? What kind of hardware encryptor is it? Does it have an ethernet card? Or is that what your question is?

Reply to
Rex Johnson

a hardware encrypter is what certain militaries use to encrypt data. the output of a hardware encrypter is the data that it received from a host but the bits have been encrypted so that any encapsulation that took place has made the data undiscernable, including headers and such. to reverse the process the same key is used on the other side with another hardware encrypter. and so i need a program to take bits which have no discernable headers (because all the data is encrypted) and encapsulate it into a third layer protocol so that a router can route it properly. Assume price isn't a factor, although free software would definetly be a bonus ^_^ any thoughts?

DTE -> Encrypter -> Encapsulator to a third layer protocol -> router ->

modem

Reply to
Perdition

ttcp or netcat

For ttcp, on the source end use ttcp -t DESTINATIONHOST and on the destination end use ttcp -r

On the source end, where you have the bit stream, if the bit stream is obtained from a program, pipe that program into ttcp, or have that program popen() to ttcp and write the data to it; if the bit stream comes across as a device, then use redirect from the device .

On the other end do the reverse in order to get the data into the encryption device.

Reply to
Walter Roberson

netcat's website states: Netcat is a utility that is able to write and read data across TCP and UDP network connections. How would I use it so that it would read from one port a stream of bits which can't possibly be interpreted as having any headers or footers, and encapsulate it into a packet which will be sent to a different port? I remind you that the stream of bits don't include any flags and are entirely random. The bit stream does not arrive from a program, it arrives directly from the hardware encrypter. TTCP's website states that it's a program to benchmark tcp/udp performance between two systems but not how it could get a stream of non-encapsulated bits.

Reply to
Perdition

I think an important question here is "How does the hardware encrypter present the bitstream?" Serial? USB? Ethernet Frames? Hardware, settings, software, anything more you can tell us about how the bitstream is presented will be helpful.

Jeff

Reply to
Jeff Pratt

In article , Perdition wrote: :netcat's website states: Netcat is a utility that is able to write and :read data across TCP and UDP network connections. : How would I use it so that it would read from one port a stream of :bits which can't possibly be interpreted as having any headers or :footers, and encapsulate it into a packet which will be sent to a :different port? I remind you that the stream of bits don't include any :flags and are entirely random. The bit stream does not arrive from a :program, it arrives directly from the hardware encrypter. :TTCP's website states that it's a program to benchmark tcp/udp :performance between two systems but not how it could get a stream of :non-encapsulated bits.

You have two issues:

1) getting the encrypted stream from whatever form it is now into a form usable as input to a program. The method of doing this will depend upon your operating system and will depend on how the encrypter emits the traffic, which you have not been clear on.

You have hinted that the encryptor presents data to a "port", but if you mean "tcp or udp port" (i.e., network socket) then in order for that to happen the data would have to be arriving at the network port in some kind of tcp or udp frames, which contradicts your assertion that it is completely unframed. We are left to wonder whether by "port" you mean "serial port".

2) one the data is in a byte-stream form usable by a program, getting the data from one end to the other.

If it is a matter of connecting a tcp/udp port on one machine over to a tcp/udp port on a different machine, then 'ssh tunneling' would do the work for you... you would probably want to configure for the fastest (weakest) encryption for the tunnel as the data is already encrypted.

[to be continued.]
Reply to
Walter Roberson

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.The operating system will more than likely be Windows, any windows really.

Reply to
Perdition

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.

Reply to
Walter Roberson

What about start and stop bits? If the data is truly random, chances are there will me more than 8 zeros or ones in a row. You are assuming an existing encapsulation (async) while there seems to be not any encapsulation, just a serial stream of random data.

What i would do in this case:

- try to analyze the data with a serial protocol analyzer, to see if there is any encapsulation used: async, hdlc, whatever.

- if this really is not the case: make a piece of electronic gear that oversamples the datastream and create your own encapsulation format.

The easyist would be to create async data, but the bitrate would become twice or even more than the input datarate.

Reply to
Joop van der Velden

:> 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.

:What about start and stop bits?

I did say, "provided that the serial output of the encryptor can use one of the character framing mechanisms recognized by the OS"

:If the data is truly random, chances are there will me more than 8 zeros :or ones in a row. You are assuming an existing encapsulation (async) :while there seems to be not any encapsulation, just a serial stream of :random data.

The OP said "serial port", not "serial interface card".

I looked at the specs of a few serial interface cards for Windows (since the OP specified Windows), and all of them that I looked at support device-driver reading / writing in 8-bit byte groups no matter what the framing format.

Reply to
Walter Roberson

If it's asynch data, then see this link:

formatting link
If it's synchronous data, then maybe you can do something similar with a serial interface -- I'm not sure.

Regards,

-rex

Reply to
Rex Johnson

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.