[bugzilla-daemon@xxxxxxxxxxxxx]

Bug ID	10827
Summary	STANAG 5066 SIS Dissector and ACP142/DMP
Product	Wireshark
Version	unspecified
Hardware	x86
OS	Linux (other)
Status	UNCONFIRMED
Severity	Enhancement
Priority	Low
Component	Dissection engine (libwireshark)
Assignee	bugzilla-admin@wireshark.org
Reporter	r.cristian.ramirez@gmail.com

Created attachment 13357 [details]
Acp 142 data over HF network

Build Information:
Version 1.99.2 (v1.99.2rc0-270-gf2224bc from master)
--
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.

---

      You are receiving this mail because:

• You are watching all bug changes.