Wireshark mailing list archives
Re: Questions about the design of a samsung-ipc protocol dissector
From: ss ws <sswsdev () gmail com>
Date: Tue, 22 Feb 2022 18:03:30 +0200
Hi Denis, Regarding your first question : AFAIK Wireshark does not allow representing different sub-packets in the packets list as of right now. This topic was already brought up on the dev list but no one implemented anything like that yet. I found myself writing several "multi payloads" dissectors like the one you describe and I can say the best thing you can do is write a compact description of each packet into the info column and separate the payloads: * Visually using commas * And logicaly using something called a 'fence'-- look for other dissectors calling 'col_set_fence' About the second issue: I'll let someone else answer but I remember vaugly that filters aren't exclusive so you might be able to just register both with the same filter string. An alternative I do remember is the trick used for "ip.addr" vs "ip.src" and "ip.dst" fields. Both "Source Address" and "Destination Address" have their own fields with unique filters but by also the dissector is adding a hidden field for each of them (the one with the ip.addr filter) so you can filter for both of those fields using the unified filter. I'd recommend reading that part in the IP dissector for inspiration. Best of luck, Shai On Tue, Feb 22, 2022, 17:30 Denis 'GNUtoo' Carikli < GNUtoo () cyberdimension org> wrote:
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 0x05And for responses we have:#define IPC_TYPE_INDI 0x01 #define IPC_TYPE_RESP 0x02 #define IPC_TYPE_NOTI 0x03Do 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
___________________________________________________________________________ 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)