tool to interpret packets? and Qs about lineout! - Protocols

This is a discussion on tool to interpret packets? and Qs about lineout! - Protocols ; Hello gurus, I have a couple of kermit questions and hope I chose the right group to ask in... Are there any utilities available (for FreeBSD or dos/windows) which can be fed raw packet data and interpret the commands that ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: tool to interpret packets? and Qs about lineout!

  1. tool to interpret packets? and Qs about lineout!

    Hello gurus,
    I have a couple of kermit questions and hope I chose the right group to ask
    in...

    Are there any utilities available (for FreeBSD or dos/windows) which can be
    fed raw packet data and interpret the commands that were issued?
    What I'd like to see is the command issued to generate a packet such as:
    [soh]0 Iz @-Y1~@ 5T7[cr]
    (and many, many others)

    If I were to use the 'lineout' command to output my own 'packet' (i.e.,
    header/length/seq/type/data/cksum) would it be interpretted
    properly on the other side and be handled accordingly? (assume a properly
    formatted packet with a valid command type and data segment)

    Thanks in advance,
    Mark



  2. Re: tool to interpret packets? and Qs about lineout!

    Mark wrote:

    > Hello gurus,
    > I have a couple of kermit questions and hope I chose the right group to ask
    > in...
    >
    > Are there any utilities available (for FreeBSD or dos/windows) which can be
    > fed raw packet data and interpret the commands that were issued?
    > What I'd like to see is the command issued to generate a packet such as:
    > [soh]0 Iz @-Y1~@ 5T7[cr]
    > (and many, many others)
    >
    > If I were to use the 'lineout' command to output my own 'packet' (i.e.,
    > header/length/seq/type/data/cksum) would it be interpretted
    > properly on the other side and be handled accordingly? (assume a properly
    > formatted packet with a valid command type and data segment)
    >
    > Thanks in advance,
    > Mark


    I am unaware of any external Kermit packet trace debugging tools.
    If you are using C-Kermit, you can log debug to obtain everything
    C-Kermit knows about the packet processing.


    --
    -----------------
    This e-mail account is not read on a regular basis.
    Please send private responses to jaltman at mit dot edu

  3. Re: tool to interpret packets? and Qs about lineout!

    "Jeffrey Altman" wrote in message
    news:H7WBe.1111$Na6.495200@twister.nyc.rr.com...
    > Mark wrote:
    >
    >> Hello gurus,
    >> I have a couple of kermit questions and hope I chose the right group to
    >> ask
    >> in...
    >>
    >> Are there any utilities available (for FreeBSD or dos/windows) which can
    >> be
    >> fed raw packet data and interpret the commands that were issued?
    >> What I'd like to see is the command issued to generate a packet such as:
    >> [soh]0 Iz @-Y1~@ 5T7[cr]
    >> (and many, many others)

    >
    > I am unaware of any external Kermit packet trace debugging tools.
    > If you are using C-Kermit, you can log debug to obtain everything
    > C-Kermit knows about the packet processing.


    I will be using c-kermit for a client but the commands I'm currently
    trying to interpret are embedded in utilities which establish a
    serial connection to a closed system (for purpose of data retrieval).
    Unfortunately, the source is not available and the utilities run on
    the wrong OS... therefore I currently have to run the utilities on 1 OS
    to retrieve data, but then transfer data to another server for processing.
    I'd like to use c-kermit on the processing machine to script the entire
    process so that it may be automated and bypass the need for the
    utilities completely.

    With a data-scope I'm able to see the packets going back and forth,
    which is why I asked a second question about the lineout command
    (unaswered question follows):
    >> If I were to use the 'lineout' command to output my own 'packet' (i.e.,
    >> header/length/seq/type/data/cksum) would it be interpretted
    >> properly on the other side and be handled accordingly? (assume a properly
    >> formatted packet with a valid command type and data segment)



    If the answer to that question is yes, the next question is:
    how can the lineout command be used to transfer (packet data) commands
    from a disk file?

    Thanks for the quick response previously :-)
    Mark



  4. Re: tool to interpret packets? and Qs about lineout!

    On 2005-07-19, Mark wrote:
    : "Jeffrey Altman" wrote in message
    : news:H7WBe.1111$Na6.495200@twister.nyc.rr.com...
    :>> Are there any utilities available (for FreeBSD or dos/windows) which can
    :>> be fed raw packet data and interpret the commands that were issued?
    :>> What I'd like to see is the command issued to generate a packet such as:
    :>> [soh]0 Iz @-Y1~@ 5T7[cr]
    :>> (and many, many others)
    :
    You should be able to find a copy of the original Kermit book:

    http://www.columbia.edu/kermit/manuals.html#ktb

    (which went out of print a couple years ago) in a library. It contains
    a specification of the protocol and packet formats. There have been some
    changes since then, but nothing to invalidate what's in the book, at least
    not as far as packet format and types are concerned.

    I'm not sure what you mean by "commands". If a command such as "send *.zip"
    was given, it could result in hundreds, thousands, or millions of packets,
    of various types.

    : I will be using c-kermit for a client but the commands I'm currently
    : trying to interpret are embedded in utilities which establish a
    : serial connection to a closed system (for purpose of data retrieval).
    : Unfortunately, the source is not available and the utilities run on
    : the wrong OS... therefore I currently have to run the utilities on 1 OS
    : to retrieve data, but then transfer data to another server for processing.
    : I'd like to use c-kermit on the processing machine to script the entire
    : process so that it may be automated and bypass the need for the
    : utilities completely.
    :
    You should be able to do that.

    : With a data-scope I'm able to see the packets going back and forth,
    : which is why I asked a second question about the lineout command
    : (unaswered question follows):
    :>> If I were to use the 'lineout' command to output my own 'packet' (i.e.,
    :>> header/length/seq/type/data/cksum) would it be interpretted
    :>> properly on the other side and be handled accordingly? (assume a properly
    :>> formatted packet with a valid command type and data segment)
    :
    Yes, it is possible to implement the Kermit protocol itself in a Kermit
    script, but I'm not aware of anyone actually having done it. You can see a
    trivial example (not the whole protocol, but the use of INPUT and OUTPUT
    commands to receive and send a few packets) here:

    http://www.columbia.edu/kermit/ckscripts.html#protocol

    And something similar, a complete implementation of TAP, the alpha pager
    protocol which uses packets similar to Kermit's, here:

    http://www.columbia.edu/kermit/ckscripts.html#page

    : If the answer to that question is yes, the next question is:
    : how can the lineout command be used to transfer (packet data) commands
    : from a disk file?
    :
    Use FOPEN to open the disk file, FREAD to read data from it into variables,
    use LINEOUT to send the contents of the variables. Brief example:

    fopen /read \%c foo.bar
    if fail blah blah
    ...
    fread \%c line
    if fail blah blah
    lineout \m(line)
    ...
    fclose \%c

    But if this is Kermit protocol then you can't just send the data bare, you
    have to encapsulate it in a packet and "encode" it according to the
    negotiated options. Ditto for incoming data.

    I don't understand enough about your setup to comment further. But if the
    black box is executing Kermit protocol in a standard enough way that you
    can communicate with it with C-Kermit, then the task might be simpler than
    it appears at the moment.

    - Frank

  5. Re: tool to interpret packets? and Qs about lineout!


    "Frank da Cruz" wrote in message
    news:slrnddqpdj.jfk.fdc@sesame.cc.columbia.edu...
    > On 2005-07-19, Mark wrote:
    > : "Jeffrey Altman" wrote in message
    > : news:H7WBe.1111$Na6.495200@twister.nyc.rr.com...
    > :>> Are there any utilities available (for FreeBSD or dos/windows) which
    > can
    > :>> be fed raw packet data and interpret the commands that were issued?
    > :>> What I'd like to see is the command issued to generate a packet such
    > as:
    > :>> [soh]0 Iz @-Y1~@ 5T7[cr]
    > :>> (and many, many others)
    > :
    > You should be able to find a copy of the original Kermit book:
    >
    > http://www.columbia.edu/kermit/manuals.html#ktb
    >
    > (which went out of print a couple years ago) in a library. It contains
    > a specification of the protocol and packet formats. There have been some
    > changes since then, but nothing to invalidate what's in the book, at least
    > not as far as packet format and types are concerned.


    Ordered it from Amazon last week... just waiting for it to show up :-)

    > I'm not sure what you mean by "commands". If a command such as "send
    > *.zip"
    > was given, it could result in hundreds, thousands, or millions of packets,
    > of various types.

    Referring to an input command which 'could' have been issued to
    generate a particular request... specifically:
    [soh]0 Iz @-Y1~@ 5T7[cr]

    The 'packet type' byte (in this example, 'l' 0x6c) refers to a specific
    instruction,
    but I haven't been able to determine what 'l' means... unfortunately, I'm
    not
    sure if it will be documented in the protocol specification either! It's
    possible
    that the developers of the system I'm working with had added their own
    authentication (kludge) routine as it initiates a sequence of requests from
    the server (and responses from client) which end with a request for the
    utility's version and release numbers.

    > : I will be using c-kermit for a client but the commands I'm currently
    > : trying to interpret are embedded in utilities which establish a
    > : serial connection to a closed system (for purpose of data retrieval).
    > : Unfortunately, the source is not available and the utilities run on
    > : the wrong OS... therefore I currently have to run the utilities on 1 OS
    > : to retrieve data, but then transfer data to another server for
    > processing.
    > : I'd like to use c-kermit on the processing machine to script the entire
    > : process so that it may be automated and bypass the need for the
    > : utilities completely.
    > :
    > You should be able to do that.
    >
    > : With a data-scope I'm able to see the packets going back and forth,
    > : which is why I asked a second question about the lineout command
    > : (unaswered question follows):
    > :>> If I were to use the 'lineout' command to output my own 'packet'
    > (i.e.,
    > :>> header/length/seq/type/data/cksum) would it be interpretted
    > :>> properly on the other side and be handled accordingly? (assume a
    > properly
    > :>> formatted packet with a valid command type and data segment)
    > :
    > Yes, it is possible to implement the Kermit protocol itself in a Kermit
    > script, but I'm not aware of anyone actually having done it. You can see
    > a
    > trivial example (not the whole protocol, but the use of INPUT and OUTPUT
    > commands to receive and send a few packets) here:
    >
    > http://www.columbia.edu/kermit/ckscripts.html#protocol
    >
    > And something similar, a complete implementation of TAP, the alpha pager
    > protocol which uses packets similar to Kermit's, here:
    >
    > http://www.columbia.edu/kermit/ckscripts.html#page


    Thanks for the references.

    > : If the answer to that question is yes, the next question is:
    > : how can the lineout command be used to transfer (packet data) commands
    > : from a disk file?
    > :
    > Use FOPEN to open the disk file, FREAD to read data from it into
    > variables,
    > use LINEOUT to send the contents of the variables. Brief example:
    >
    > fopen /read \%c foo.bar
    > if fail blah blah
    > ...
    > fread \%c line
    > if fail blah blah
    > lineout \m(line)
    > ...
    > fclose \%c


    Thanks for the example.

    > But if this is Kermit protocol then you can't just send the data bare, you
    > have to encapsulate it in a packet and "encode" it according to the
    > negotiated options. Ditto for incoming data.


    I was thinking about storing the raw packet data in disk files, and then
    sequentially sending each packet as a seperate lineout command to
    see if I could trick the server into thinking my script was the cmdline
    utility.

    > I don't understand enough about your setup to comment further. But if the
    > black box is executing Kermit protocol in a standard enough way that you
    > can communicate with it with C-Kermit, then the task might be simpler than
    > it appears at the moment.


    Many commands have been disabled on the server-side, but I am able to log
    into the server with c-kermit and issue a few generic requests. On the
    other hand,
    I'm pretty certain that I am not dealing with a 'vanilla' kermit server on
    the other side
    and some of the requests I'll have to make are probably the result of
    modifications
    they had made on the server to support them!
    Doesn't matter to me how it happens as long as I can get my data out :-)

    Thanks for the quick response,
    Mark



+ Reply to Thread