2016-08-26 10:14 GMT+02:00 Dario Lombardo <[email protected]>:
> It seems that it prevents the dissection of exported payloads if > proto_name is disaligned. Alexis is experiencing that during the testing of > udpdump. Maybe he can clarify where the problem is so we can work on it. > AFAIK, he's using aruba_erm as proto_name in udpdump, but this is changed > into "aruba_erm\x00\x00\x00" that is not matched by the dissectors table. > Alexis, did I get the point? > I'm using exported PDU with a protocol name that is not a multiple of 4 bytes everyday without any issue. I'm nor surprised that it does not work with "aruba_erm" as this dissector is not registered by name. Exported PDU can support dissectors registered by name, in a dissector table, or heuristic ones (see exported_pdu.h fiel for details). > On Fri, Aug 26, 2016 at 10:05 AM, Pascal Quantin <[email protected] > > wrote: > >> Hi Dario, >> >> 2016-08-26 10:02 GMT+02:00 Dario Lombardo <[email protected]>: >> >>> Hi, >>> I'm looking into the code of exported_pdu.c and specifically >>> into export_pdu_create_tags(). The first tag it creates is the tag with >>> proto_name. The piece of code that I don't understand is >>> >>> /* Start by computing size of protocol name as a tag */ >>> proto_str_len = (int)strlen(proto_name); >>> >>> /* Ensure that tag length is a multiple of 4 bytes */ >>> proto_tag_len = ((proto_str_len + 3) & 0xfffffffc); >>> >>> /* Add Tag + length */ >>> tag_buf_size += (proto_tag_len + 4); >>> >>> [...] >>> >>> exp_pdu_data->tlv_buffer = (guint8 *)g_malloc0(tag_buf_size); >>> >>> Basically, the buffer to store the proto_name tag must be multiple of 4 >>> bytes. This means that if I use "data", I have "data", but if I use "data1" >>> I have "data1\x00\x00\x00". What's the rationale behind this? Why is the >>> alignment to 4 bytes required? >>> >> >> This is inspired by the pcapng specification. You have a complete >> description of the TLV format used in epan/exported_pdu.h >> >> Pascal. >> >> >> ____________________________________________________________ >> _______________ >> Sent via: Wireshark-dev mailing list <[email protected]> >> Archives: https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> mailto:[email protected]?subject=unsubscr >> ibe >> > > > ____________________________________________________________ > _______________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject= > unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
