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'
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
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@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
