On 6/6/05, Guy Harris <gharris@xxxxxxxxx> wrote:
> LEGO wrote:
>
> > I need ideas on how to handle the .stk files (ethereal won't use
> > them, I hate the very same Idea behind these files). These as you
> > might know describe the protocol stack used by each source.
> >
> > I haven't been able to infer if or how the encapsulation used for each
> > source is written to the file.
>
> I.e., you don't know the format of the .stk files yet?
No, anyway, I think we should avoid them tout cour.
For ethereal dissection the only useful thing in there is the base
encapsulation which I think we better handle with some sort of map.
I'm thinking in using a "hints" file a file that could look like:
umts_iu_ranap_alcap.stk MTP3/SSCOP
umts_mc_h248_ranap.stk MTP3/SSCOP
gprs_gn_gtp.stk RFC1483
gprs_gi_radius.stk ETHERNET
ss7_isup.stk MTP2
atm_uni.stk UNI_SSCOP
atm_pnnis.stk PNNI_SSCOP
....
That's preety much all that we need from it.
Even with the k12xx, If what you have to do is just decoding they are
interexchangeable. On the other hand, If you need the k12 as a traffic
generator, these files contain the FSM and the actions to perform when
a certain message gets in in a certain state. That is (and it's going
to be for some time) beyond ethereal's scope.
> > I temporarily worked arround this issue by using the USER0-15
> > encapsulations, these are handled by the DLT_USER00-15 "dissectors" I
> > checked in yesterday, in whose preferences one can set which
> > protocol(s) is(are) carried by each encapsulation.
> >
> > By now each .stk file used by the file is mapped to an USER encap
> > starting from USER0 in the order they appear in the file.
>
> So is there more than one .stk file per .rf5 file?
Yes, In some cases there are more, most often every souce uses a single one.
> And are the .stk files written by users, by the K12xx, or by Tektronix
> (with a fixed set of .stk files)?
Both,
If you need it just for decoding any given one (as far as it hgas your
stack) is fine.
If you need it for plain traffic generation you might one to use one of theirs.
If what you want is to trigger some error condition in the equipment
most probably you'll have to create your own.
> > The current implementation handle timestamps using 64bit integers. I
> > want to do it without 64 bit arithmetic as not every plattform
> > supports it.
>
> Ethereal - including Wiretap - now require support for int64 and uint64,
> so you can just use those. *Printing* them requires some work, but look
> for PRIu64 in packet-rsvp.c for an example of how to handle that.
I don't need to print them I just need to extract seconds and
microseconds from a 64bit encoded timestamp, so I'm done with it.
Luis
