Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DHCPv4 V-I Vendor Class with multiple ENs overwrites the EN values #328

Open
rmarioe opened this issue Jun 5, 2024 · 4 comments
Open

DHCPv4 V-I Vendor Class with multiple ENs overwrites the EN values #328

rmarioe opened this issue Jun 5, 2024 · 4 comments

Comments

@rmarioe
Copy link

rmarioe commented Jun 5, 2024

Hi,

I see when defining the vendclass two times with different EN, the first one is overwritten and the second one is actually part of the data.
In the manual I see:

[vendclass] en data
Add the DHCPv6 Vendor Indetifying Vendor Class with the IANA assigned Enterprise Number en with the data. This option can be set more than once to add more data, but the behaviour, as per RFC 3925 is undefined if the Enterprise Number differs.

However the RFC states:

This option contains information corresponding to one or more
Enterprise Numbers. Multiple instances of this option may be present
and MUST be concatenated in accordance with [RFC 3396]. An
Enterprise Number SHOULD only occur once among all instances of this
option. Behavior is undefined if an Enterprise Number occurs
multiple times. The information for each Enterprise Number is
treated independently, regardless or whether it occurs in an option
with other Enterprise Numbers or in a separate option.

Does this not mean that having multiple enterprise numbers that differ should be supported but repeating an already seen enterprise number is undefined?

@rsmarples
Copy link
Member

This isn't very well done I have to confess I probably haven't implemented this very well.
Currently you cannot specify different EN values, only the first one is used.

@rmario1
Copy link

rmario1 commented Oct 30, 2024

One more thing is the formatting as per https://mailarchive.ietf.org/arch/msg/dhcwg/B4fNsvUR0EHxcrKDsKCf7lBrc3s/ where each instance the vendor-class-data needs to have a length. Since the packet sent does not include it (but includes the total length) the packets are seen as malformed.
Should we track this as two issues even though one commit could fix both of them?

@rsmarples
Copy link
Member

One commit can fix two issues, sure.

@rsmarples
Copy link
Member

This will be fixed in #383 with a new option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants