Sorry, I badly explained what I had ment.
DLCI 16 means decimal 16 after decoding from
Frame Relay header. I only changed mask parameter
from FRELAY_DLCI to 0x0 in registration of
fr.dlci field. I sent test capture with several
packets with high DLCI numbers ( above 100),
because they are FR-NS coded they will appear
as “Malformed packet” in ethereal without FR-NS
support. But it is possible to test filtering on
DLCI number.
The GPRS Network service uses only 2 bytes
header from frame relay and than it adds own
fields. There is no field in FR packet on which
one could be decided, that it is frame relay with
Network service. The structure of FR-NS packet
is : 2bytes FR header, 1 byte information element
code , 0 or more bytes ,it depends on type of
information element, payload or next layer
protocol (BSSGP). The Frame Relay with Network
service make one network protocol layer. I
utilized experience with network analyzers like
Tektronix or Radcom which use similar approach to
frame relay encapsulation of Gb line.Due to I
added protocol preference to frame relay
dissector.
Regards Josef
----- Původní zpráva -----
Od: Guy Harris <guy@xxxxxxxxxxxx>
Datum: úterý, 2. září 2003 v 11:02 odp.
Předmět: Re: [Ethereal-dev] patch Frame Relay
dissector to dissect GPRS Network Service protocol
>
> On Thursday, August 28, 2003, at 5:02 AM,
> jkor@xxxxxxxx wrote:
>
> > I am sending patch for packet-fr.c file to
> support> decoding "Network Service" defined
> in ETSI 8.16
> > specification for GPRS Gb line. Patch is
> made to
> > nightly snapshot
> > from 2003-08-27. The patch also solve the
> > unpossibility to filter on bigger DLCI
> than 16.
>
> Bigger than 16 (i.e., bigger than 4 bits),
> or bigger than 16 bits
> (i.e., 3-octet or 4-octet address)? If
> "bigger than 16", are you
> saying that having fr.dlci being a bitfield
> doesn't work when you try
> to filter on it?
>
> In any case, I've checked in a change to
> handle 3-octet and 4-octet
> addresses; it also puts the DLCI field in
> not as a bitfield but as a
> regular field, as it dissects each octet
> separately, and assembles the
> DLCI from the pieces of it.
>
> > Patch adds protocol preference which
> choose mode
> > of protocol encapsulation next layers.
>
> So is the GPRS Network Service just another
> form of Frame Relay
> payload? If so, then nothing needs to
> change in the dissector to
> handle it other than the code to handle the
> payload - none of the stuff
> to process the address field, or the
> columns, needs to change.
>
> Also, if it's a protocol running atop Frame
> Relay, it should be treated
> as such - given its own "packet-XXX.c" file,
> and its own protocol tree,
> and its own column settings, and the like.
>
>