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.
