Ethereal-dev: Re: [Ethereal-dev] patch Frame Relay dissector to dissect GPRS Network Service p
On Wed, Sep 03, 2003 at 09:26:08AM +0200, jkor@xxxxxxxx wrote:
> 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.
The real bug was that, as there was a bitmask, the raw 2-octet address
field, not the DLCI, should have been passed to
"proto_tree_add_uint_format()".
The current CVS version of packet-fr.c, as per my mail, dissects the
address field one octet at a time, and then puts an item into the
protocol tree for the DLCI, so that no longer applies.
> 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.
Well, yes, but that applies to some other packets, too - there's no
guarantee that the FRF 3.2 scheme (the scheme that was incorrectly
referred to as "Q.933 Encapsulation" in the dissector until my recent
changes), or even the FRF 3.2 scheme or the Cisco HDLC scheme, is being
used; I've seen captures which aren't using those schemes, but also
aren't using the GPRS 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.
Really? It's not two network layers? It really sounds like two network
layers to me. Section 9 of 08.16 seems to be describing the network
service PDUs as starting with the PDU type, not with the frame relay
header....
(Also, clause 6.1.4.4 of 3GPP TS 08.16 version 8.0.1 says "ITU-T Revised
Q.933 [11] annex A or T1.617 [16] for PCS1900 procedures shall be
implemented at the BSS and the SGSN sides as recommended in FRF 1.1 [6]
clause 2.3." - does that mean some FR traffic will be Q.933, not GPRS
NS?)
Also, you might want to dissect the TLV information elements as such,
rather than hardwiring in the specified sequence of TLVs; you could
dissect the IEs of all the PDUs with a common loop that way.
