Wireshark · Ethereal-dev: Re: SV: [Fwd: [Ethereal-dev] 3G Signaling patch]

[Rene Pilz <rene.pilz@xxxxxx>]

There is no/rarely used Q.2931 protocol. The stack is as follows:
ATM
SSCOP
SSCF-NNI
MTP3b
SCCP
RANAP
GSM A/F DTAP

So your prososal does not work in my case.

I would propose this algorithm:
a) if aal5 len < 14 bytes then dissect as sscop
b) if aal5 len >= 14 bytes and the fist byte is 0x81 or 0x83 then dissect as sscop

As I have seen until now, there should be no MAC address collision with this solution.

Is it fine for you?
Should I also consider Q.2931 as you proposed?

/rene

On Tue, 2005-10-04 at 02:00 -0700, Guy Harris wrote:
> Guy Harris wrote:
>
> > Unfortunately, having atm_guess_lane_type() check for 802.3 frames by 
> > checking the type/length field as if it's a length field, and set the 
> > traffic type to something other than LANE if it doesn't look like an 
> > 802.3 frame, means that
> > 
> >     1) Ethernet frames with a type field don't get recognized as LANE 
> > frames
>
> A heuristic that checks for packets that look like signalling packets 
> might work better - if the signalling is Q.2931, then checking for 09 xx 
>   xx xx xx {Q.2931 message type} might work.  (There don't appear to be 
> a lot of known Ethernet types in the 0x09xx range.)  The byte after the 
> protocol discriminator is the call reference length, so the heuristics 
> might also check for small values in the second byte.
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev

-- 
Dipl-Ing (FH) MSc. C.E René Pilz
ftw. Telekommunications Research Center Vienna http://www.ftw.at
Tech Gate Vienna, Donaucitystraße 1, A-1220 Wien
Mobile: +43 664 8269871 Office: +43 1 5052830-13  Fax: +43 1 5052830-99