Comment # 4
on bug 9643
from Anders Broman
(In reply to comment #2)
> Hi Pascal,
>
> Thanks for your reply. I did not spot that option before.
> However, I am unsure of what the implications of setting
> that option might be for a large capture where multiple
> network nodes are being traced (with different application
> context versions).
Regardless that might be very hard to do something about.
>
> The idea behind my change is that opcode 46 (mo-ForwardSm)
> was only introduced in MAP phase 3 and does not exist in previous
> phases.
>
> So if the application context is absent, and opcode 46 is
> used perhaps then we can decode as a MO-FSM-V3.
> (As opcode 46 is only associated with V3).
The way the code is made it looks like that is not true(or the code is wrong?).
case 46: /*mo-forwardSM(v3) or ForwardSM(v1/v2)*/
if (application_context_version == 3)
offset=dissect_gsm_map_sm_MO_ForwardSM_Arg(FALSE, tvb, offset, actx,
tree, -1);
else {
offset=dissect_gsm_old_ForwardSM_Arg(FALSE, tvb, offset, actx, tree, -1);
}
break;
>
> If application context is present but set to 1 or 2 ,
> and opcode = 46, then I guess this is an error according
> to the specifications (and a FSM decode should
> not be attempted ??)
See above
>
> [ As an aside, when the dialogue/portion is absent,
> could wireshark used TCAP OTID/DTID to glean the
> application context from a previous packet ?? - I am
> not too sure if this feasible/realistic]
At least in ANSI TCAP where this is done(I think) that has proved problematic
and not covering all cases.
>
> Regarding "If version 3 is widely used and v1/v2 are obsolete,".
>
> From what I have seen, V3 is certainly most popular but I guess there is
> legacy v1 infrastructure and I have (or am about to) log some V1 related
> decoding bugs.
As time goes by I guess V3 will be more common so I think changing the
preference to V3 is a good idea.
Blame 3GPP for not making the protocol backwards compatible...
Regards
Anders
You are receiving this mail because:
- You are watching all bug changes.