[Pascal Quantin <pascal.quantin@xxxxxxxxx>]

2016-08-26 10:14 GMT+02:00 Dario Lombardo <dario.lombardo.ml@xxxxxxxxx>:

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 <pascal.quantin@xxxxxxxxx> wrote:

Hi Dario,

2016-08-26 10:02 GMT+02:00 Dario Lombardo <dario.lombardo.ml@xxxxxxxxx>:

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

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@wireshark.org?subject=unsubscribe