Re: Dissect Sigtran capture files

Michael Tuexen wrote:
> Hi Jeff,
> see a question below.
> Best regards
> Michael
> 
> On May 24, 2006, at 6:19 AM, Jeff Morriss wrote:
> 
>>
>>
>> dirk Bruyland wrote:
>>> Hello Users,
>>> I need to analyse M3UA and MTP3 protocol messages (specific messages 
>>> , between 2 specific network elements) in ethereal SIGTRAN 
>>> (IP/Ethernet) capture logfiles.
>>> The ethereal display filter will only select large ( containing many 
>>> disparate MTP3 messages) ethernet frames.
>>> When I filter on "MTP3 msg xyz between node NE1 and NE2" (as 
>>> specified by M3UA DPC), I get selected frames containing indeed the 
>>> desired xyz  but also 95% other MTP3/M3UA/SCTP messages from all over 
>>> the place I am not really interested in.
>>> -Has anybody encountered this SIGTRAN difficulty before?
>>
>> I suppose you're talking about many M3UA/MTP3 messages that were 
>> bundled together into one SCTP packet?
>>
>> In that case, the problem you're seeing is probably due to the fact 
>> that display filters are applied to a *frame*, not to a particular, in 
>> this case, chunk inside an SCTP packet.
>>
>> This applies to which frames are selected to be presented to you so 
>> that if you have an SCTP packet with these M3UA messages inside it:
>>     - OPC=2730, DPC=3003
>>     - OPC=1001, DPC=2002
>>
>> then a filter like "m3ua.opc==2730 && m3ua.dpc==2002" will show you 
>> this frame even though none of the M3UA messages are from PC 2730 to 
>> PC 2002.
>>
>> It also applies to what you see: Ethereal has no mechanism to present 
>> only parts of a frame so you'll see the entire SCTP packet, no matter 
>> how many chunks were in it.
>>
>>> -Is it possible to dissect the capture file (get rid of the ethernet 
>>> frame structure) and produce a new cap file only containing 
>>> standalone elementary messages, so that the ethereal display filter 
>>> works and selects on these messages and not on the large frames ?
>>
>> Not that I know of, no.
>>
>> I'd love to find a solution to this problem, too, but I'm not sure how 
>> it could be done (though admittedly I haven't studied the problem very 
>> hard)...  (Of course one way is to disable chunk bundling as ETSI 
>> recommends though that won't always prevent SCTP from bundling.)
> ETSI does not recommend the disabling of bundling. Only bundling, which 
> adds additional delay
> (using a bundling timer, for example) should be disabled.

Ah, OK, I missed that point (in fact I never saw the ETSI spec--never 
had a need).

Thanks,
-Jeff