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

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

Date Index Thread Index Other Months All Mailing Lists
Date Prev Date Next Thread Prev Thread Next
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