Wireshark mailing list archives
Questions about the design of a samsung-ipc protocol dissector
From: Denis 'GNUtoo' Carikli <GNUtoo () cyberdimension org>
Date: Tue, 22 Feb 2022 16:30:14 +0100
Hi, I'm currently writing a dissector[1][2] for the samsung-ipc protocol. While there is still a lot of things to fix and/or check before being able to submitting it for inclusion in Wireshark, I've two questions related to the general design of that dissector. To capture packets I run tshark and the usbmon driver on GNU/Linux on a Galaxy SIII (GT-I9300). And to generate the packets I used a modified version[3] of a free software implementation of the samsung-ipc protocol[4]. The first issue I have is that a single USB packet has often multiples samsung-ipc packets inside. While this isn't an issue for the tree view, I've no idea how to represent that in the Info column. Ideally I'd like to have one row per samsung-ipc packet and add information such as the FMT command (like PWR_PHONE_PWR_UP, CALL_OUTGOING, etc) inside the Info column. Without that understanding what is going on would be painful as users would have to use the tree view for each packet. With the right information in the Info column it's for instance trivial to generate text file with tshark and use meld or diff to compare different captures to get an overview of what is going on. Is there any dissector that already has a row per sub-packet? Is Wireshark capable of doing that? If not what workaround people typically use instead? The second issue I have is that we have this header for one of the packet types (the FMT packet type):
struct ipc_fmt_header { unsigned short length; unsigned char mseq; unsigned char aseq; unsigned char group; unsigned char index; unsigned char type; } __attribute__((__packed__));
And there the issue is that the type field is to be interpreted differently if it's a request or a response. For requests we have:
#define IPC_TYPE_EXEC 0x01 #define IPC_TYPE_GET 0x02 #define IPC_TYPE_SET 0x03 #define IPC_TYPE_CFRM 0x04 #define IPC_TYPE_EVENT 0x05
And for responses we have:
#define IPC_TYPE_INDI 0x01 #define IPC_TYPE_RESP 0x02 #define IPC_TYPE_NOTI 0x03
Do we really need to represent that field as samsung-ipc.fmt.response.type and samsung-ipc.fmt.request.type in the filter? Or is there a way where we could define it as samsung-ipc.fmt.type in the filter and somehow use a different value_string to interpret the data when it's a request or response ? References: ----------- [1]https://git.replicant.us/contrib/GNUtoo/tools/wireshark/tree/epan/dissectors/packet-samsung-ipc.c?id=93899f1f2170742f96ddf8255bf14ea97dd28b03 [2]https://git.replicant.us/contrib/GNUtoo/tools/wireshark/tree/epan/dissectors/packet-samsung-ipc.h?id=93899f1f2170742f96ddf8255bf14ea97dd28b03 [3]The modifications were to make it work on top of GNU/Linux on that device. I also used not-yet mainline modem drivers. [4]https://git.replicant.us/replicant/hardware_replicant_libsamsung-ipc Denis. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Questions about the design of a samsung-ipc protocol dissector Denis 'GNUtoo' Carikli (Feb 22)
- Re: Questions about the design of a samsung-ipc protocol dissector ss ws (Feb 22)
- Re: Questions about the design of a samsung-ipc protocol dissector Denis 'GNUtoo' Carikli (Feb 28)
- Re: Questions about the design of a samsung-ipc protocol dissector ss ws (Feb 22)