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

Discussion in 'Cisco' started by Perdition, Nov 14, 2005.

  1. Perdition

    Perdition Guest

    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
    Perdition, Nov 14, 2005
    #1
    1. Advertising

  2. Perdition

    Merv Guest

    You could try using a File Transfer Protocol FTP) utility; plenty of
    them available.
    Merv, Nov 14, 2005
    #2
    1. Advertising

  3. Perdition

    Perdition Guest

    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? :)
    Perdition, Nov 14, 2005
    #3
  4. Perdition

    Rex Johnson Guest

    "Perdition" <> wrote in message
    news:...
    >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
    >


    How about netcat?

    http://netcat.sourceforge.net/
    Rex Johnson, Nov 14, 2005
    #4
  5. Perdition

    Perdition Guest

    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?
    Perdition, Nov 14, 2005
    #5
  6. Perdition

    Andy Furnell Guest

    On 2005-11-14, Perdition <> wrote:
    > 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?
    >


    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
    <http://www.tinc-vpn.org> 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
    Andy Furnell, Nov 14, 2005
    #6
  7. Perdition

    Rex Johnson Guest

    "Perdition" <> wrote in message
    news:...
    > 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?
    >


    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?
    Rex Johnson, Nov 14, 2005
    #7
  8. Perdition

    Perdition Guest

    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
    Perdition, Nov 16, 2005
    #8
  9. In article <>,
    Perdition <> wrote:
    >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.


    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.
    --
    I am spammed, therefore I am.
    Walter Roberson, Nov 16, 2005
    #9
  10. Perdition

    Perdition Guest

    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.
    Perdition, Nov 16, 2005
    #10
  11. Perdition

    Jeff Pratt Guest

    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.


    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
    Jeff Pratt, Nov 16, 2005
    #11
  12. 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.]
    --
    "No one has the right to destroy another person's belief by
    demanding empirical evidence." -- Ann Landers
    Walter Roberson, Nov 16, 2005
    #12
  13. Perdition

    Perdition Guest

    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.
    Perdition, Nov 16, 2005
    #13
  14. 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
    :eek:f 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.
    --
    Chocolate is "more than a food but less than a drug" -- RJ Huxtable
    Walter Roberson, Nov 16, 2005
    #14
  15. Walter Roberson wrote:

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

    --
    Joop van der Velden -
    Het hele jaar door radiovlooienmarkt op:
    http://sharon.esrac.ele.tue.nl/verkopen/
    Joop van der Velden, Nov 17, 2005
    #15
  16. In article <>,
    Joop van der Velden <> wrote:
    :Walter Roberson wrote:

    :> 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
    :eek:r 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.
    --
    Is there any thing whereof it may be said, See, this is new? It hath
    been already of old time, which was before us. -- Ecclesiastes
    Walter Roberson, Nov 17, 2005
    #16
  17. Perdition

    Rex Johnson Guest

    "Perdition" <> wrote in message
    news:...
    > 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.
    >
    >


    If it's asynch data, then see this link:
    http://www.cisco.com/warp/public/700/14.pdf

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

    Regards,
    -rex
    Rex Johnson, Nov 19, 2005
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Abbyss

    win XP 32 bits on a 64 bits processor..

    Abbyss, Nov 12, 2003, in forum: Computer Support
    Replies:
    3
    Views:
    576
    Ralph Wade Phillips
    Nov 13, 2003
  2. Al Dykes
    Replies:
    3
    Views:
    1,142
    Tony Spadaro
    Dec 29, 2003
  3. Terry

    8 bits/ch vs 16 bits/ch in PS

    Terry, Jan 21, 2004, in forum: Digital Photography
    Replies:
    5
    Views:
    1,806
    Tony Spadaro
    Jan 21, 2004
  4. peggy83

    bits per pixel VS bits per channel

    peggy83, Oct 10, 2006, in forum: Digital Photography
    Replies:
    1
    Views:
    825
    Scott W
    Oct 10, 2006
  5. newasp.net
    Replies:
    1
    Views:
    1,598
    imransyed63
    Aug 21, 2008
Loading...

Share This Page