- Subject: Re: SV: [Fwd: [Ethereal-dev] 3G Signaling patch]
- From: Rene Pilz <rene.pilz@xxxxxx>
- Date: Tue, 04 Oct 2005 16:02:24 +0200
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
|
