[Alexis La Goutte <alexis.lagoutte@xxxxxxxxx>]

Hi Tomek,

On Wed, Jul 13, 2016 at 11:20 AM, Tomek Mrugalski <tomasz.mrugalski@xxxxxxxxx> wrote:

Hi!

Long time user, first time trying to extend the code and would like to
ask for a bit of guidance. I'm trying to extend DHCPv6 (packet-dhcpv6.c)
dissector to support RFC7598. Couple options in that RFC uses new option
format that stores IPv6 prefix as two fields:

1. prefix-len (1 octet, specifies length in bits)
2. prefix (minimum number of octets necessary to store the most
significant bits)

The prefix field can be of any length between 1 and 16.

This is the recommended way for new options (see RFC7227, Section 5.3),
so we will see more of this formatting in the future.

For specific example, see S46 DMR option here:
https://tools.ietf.org/html/rfc7598#section-4.3

How can I parse and display this in wireshark?

I'd like to display it as human readable prefix, e.g. 2001:db8::/32. I
could create a separate 16 bytes long buffer, then copy first
(prefix-len) bytes and pad them with zeros, but I don't know how to

Do you have look icmpv6.c dissector ? if i remember there is the same case

for add prefix (like /XX), you can use proto_item_append_text(ti, "/%u", prefix_len); for example

 

So far I came up with the following code: http://pastebin.com/wsFPF4Kp
(see lines 1987 to 1999). It sorta works, but displays prefix len as
separate field and part of the prefix as hex. Although that matches
on-wire format, that's not really user friendly way.

I've made the traffic capture available in case it is useful:
http://git.kea.isc.org/~tomek/lw4over6/dhcpv6-lw4over6-rfc7598.pcapng
See packet 6 or 8.

Can you push directly on Gerrit ( https://code.wireshark.org/review  (you can set WIP on commit log), it is more easy for review and try...

and push also the pcap on BugTracker ( https://bugs.wireshark.org )

Not sure if it changes anything, but I'm more than willing to contribute
the code once it's functional. Finally, there's a bunch
of DHCPv6 options that were published, but are not supported yet. Do you
prefer to get them all in one patch or should I split them up into
separate patches?

If it is options from the same RFC, you can push only a patch with all options.

Cheers,

Thanks in advance,
Tomek

 

___________________________________________________________________________
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@xxxxxxxxxxxxx?subject=unsubscribe