Skip to content

RPL schema's fixed area is 5 octets where RFC 6554 gives 4, so a built header is wider than its own Hdr Ext Len #564

Description

@JarryShaw

RPL's fixed area is 5 octets where RFC 6554 gives 4, so the header it builds is one octet wider than its own Hdr Ext Len declares. Found while cross-reviewing #561, which unmasked it; filed separately because it is a third, independent defect sitting behind the two that PR addresses.

The mismatch

pcapkit/protocols/schema/internet/ipv6_route.py, the RPL schema, declares the fixed area as three whole-octet fields:

cmpr_i: 'int' = UInt8Field()      # 1 octet
cmpr_e: 'int' = UInt8Field()      # 1 octet
pad: 'PadInfo' = BitField(length=3, namespace={'pad_len': (0, 4), ...})   # 3 octets

That is 5 octets. RFC 6554 section 3 gives 4, and so does the ASCII diagram in IPv6_Route._read_data_type_rpl's own docstring in pcapkit/protocols/internet/ipv6_route.py:

| CmprI | CmprE |  Pad  |               Reserved                |

CmprI 4 bits, CmprE 4 bits, Pad 4 bits, Reserved 20 bits — 32 bits, one 4-octet word. cmpr_i and cmpr_e are nibbles, not octets.

So the module documents the correct layout in prose and implements a different one in the schema.

Consequence

The ipv6-route-type/RPL_Source_Route_Header roundtrip case builds a header that packs to 41 octets while its own Hdr Ext Len of 5 declares 48. Measured during #561's cross-review.

Why it is filed now

#561 fixes RPL.post_process, which used to raise on the pack path before anything downstream could be reached. With that gone, the next failure is the % 16 length guard at pcapkit/protocols/internet/ipv6_route.py:612 — itself a known, deliberately unfixed unit-confusion defect of the same shape #487 fixed for Source Route and Type 2. This octet-width defect sits behind that one, so ipv6-route-type/RPL_Source_Route_Header would remain red even if the % 16 guard were corrected today.

That ordering matters for whoever picks up the guard: fixing % 16 alone will not turn the case green, and without this issue to point at, the reason would not be obvious.

Scope note

Correcting the field widths changes what the schema packs and parses, so it is a wire-format change rather than a cosmetic one, and the Hdr Ext Len arithmetic and the % 16 guard should be reconciled in the same pass rather than separately — the guard cannot be validated against a header whose width is still wrong. Nothing here has been checked against a real RPL capture, which is the same caveat recorded against the guard itself.

Coverage

A test asserting the packed fixed area is 4 octets, and that a built header's length agrees with its declared Hdr Ext Len. Proven to fail without the fix, exit code read from a file.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions