Re: tool to interpret packets? and Qs about lineout!
- From: "Mark" <sober@xxxxxxxxxxxx>
- Date: Tue, 19 Jul 2005 22:52:29 GMT
"Frank da Cruz" <fdc@xxxxxxxxxxxx> wrote in message
news:slrnddqpdj.jfk.fdc@xxxxxxxxxxxxxxxxxxxxxxxxx
> On 2005-07-19, Mark <sober@xxxxxxxxxxxx> wrote:
> : "Jeffrey Altman" <jaltman2@xxxxxxxxxx> wrote in message
> : news:H7WBe.1111$Na6.495200@xxxxxxxxxxxxxxxxxxxxx
> :>> 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
.
- References:
- tool to interpret packets? and Qs about lineout!
- From: Mark
- Re: tool to interpret packets? and Qs about lineout!
- From: Jeffrey Altman
- Re: tool to interpret packets? and Qs about lineout!
- From: Frank da Cruz
- tool to interpret packets? and Qs about lineout!
- Prev by Date: Re: tool to interpret packets? and Qs about lineout!
- Next by Date: Redial on No Dialtone
- Previous by thread: Re: tool to interpret packets? and Qs about lineout!
- Next by thread: telnet to SCO
- Index(es):
Relevant Pages
|
|
