Hello,
#1)
There was an update to the 6LoWPAN patch from a while back
to add missing features, specifically “context-based” decompression.
In addition I’ve updated that patch to support the
latest version of the 6lowpan standard, hc-13. Note that hc-13 has gone to last
call and is unlikely to change the protocol format.
The patch is attached to https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5085
. I’ve tested this patch, and am also aware of a number of other people
testing the patch as well.
Would it be possible to get this committed to SVN and thus
closed?
#2)
There are several I-D’s which define new protocols. Two
important updates for 6lowpan people are 6lowpan-nd (neighbor discovery
extensions) and RPL (routing protocols).
6lowpan-nd is in working-group last-call and seems unlikely
to change, there is a patch to add support at https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5086
.
The I-D however requires the assignment of 3 ND option types
by the IANA, and is temporarily using 31/32/33 as the types as defined in the
I-D. Thus the patch has these hard-coded in just like the other ND options in
packet-ipv6.h. But according to http://www.iana.org/assignments/icmpv6-parameters
this already conflicts with another option.
How is this normally handled? Is it possible to get the code
committed despite not having official IANA assignments, and they are just
updated when they become official? Even if they were defined to zero, which isn’t
used, it would help as at least the code is present, and thus the final “patch”
is much smaller.
Regards,
-Colin