Le 2 janv. 2015 02:49, "Ricardo Cristian Ramirez" <r.cristian.ramirez@xxxxxxxxx> a écrit :
>
> Hi,
>
> I have been analyzing Acp 142 (P_Mul) data over IP network and
> everything was fine. However, I couldn't analyze Acp 142 data over HF
> network (STANAG 5066).
>
> S'5066 SIS dissector displays the data section (UPDU) succesfully but
> this UPDU contains transport layer header of S'5066 network when the
> S'5066 client is TMMHS client (so that it cannot be dissected by Acp
> 142). The name of the discussed transport layer is RCOP/UDOP and
> details are given in STANAG 5066 Ed. 2 ANNEX F.8 and F.9. Header bytes
> can be seen as the first six bytes of data section in the attachment
> before.cap (00 0X 00 00 20 00).
>
> S'5066 provides HF subnetwork serivce to different type of clients.
> Specification describes a transport layer for some clients like Acp
> 142 and DMP but not for all of them. Since RCOP/UDOP header definition
> are given in S'5066 specification, consuming these header bytes in
> S'5066 SIS dissector may be appropriate. The attachment s5066sis.diff
> suggests below changes:
>
> - When the client type is TMMHS, RCOP or UDOP client (sapid == 2, 6
> and 7), add a tree item after the pdu type tree item and display
> transport layer content
> - If the incoming SIS primitive doesn't contain a UPDU (e.g.
> BIND_ACCEPTED), don't add tree item
> - Specify an application identifier and register it to the dissector
> table ("s5066sis.ctl.appid"). This identifier is used to call related
> dissector (Acp 142 or DMP). This make sense because there are
> different application identifiers for Acp 142 (0x2000 TMI-1) and DMP
> (0x2003 TMI-4).
> - If there is not a defined application for the incoming data, call
> data handle dissector as usual
> - After the above changes, P_Mul tells that it accepts data when the
> application identifier is 0x2000.
> dissector_add_uint ("s5066sis.ctl.appid", 0x2000, p_mul_handle);
> - And in DMP (by the way, I didn't tested DMP):
> dissector_add_uint ("s5066sis.ctl.appid", 0x2003, dmp_handle);
>
> The view of the tree is like in atachment after.png
>
> I'm not a wireshark expert but these changes solved my problem. If
> there is a better solution, please direct me the right way.
>
> Note: Sometimes, discussed changes causes malformed data assertion for
> P_Mul dissector from the statement "DISSECTOR_ASSERT (pkg_data);",
> just before the return statement in the register_p_mul_id() function.
> When I looked the calls of this function, there is a null check
> everytime it is called. Hence, I removed the assertion and it seems
> that everytihng is normal.
>
> Thanks.
>
Hi Ricardo,
Thanks for your patch. The best way to go forward is to fill a bug on bugs.wireshark.org and upload your patch to Gerrit (as explained in the developer guide: https://www.wireshark.org/docs/wsdg_html_chunked/ChSrcContribute.html#ChSrcSend). Then your changes will be reviewed and discussed before being merged once everything is OK.
Regards,
Pascal.
