Control: tags -1 + wontfix

On 2024-01-29 15:27, kristofer.hansson@icomera.com wrote:

Package: kea-dhcp4-server
Version: 2.2.0-6

Hi, this version (and from what I believe all versions) of kea-dhcp4-server (and probably kea-dhcp6-server) handles vlan tagged traffic in a quite unintuitive way. When the server is set up in raw socket mode it will accept all
broadcasted DHCP requests regardless of VLAN tagging. It will then send a response untagged, again regardless of initial VLAN tag. See below for a packet
trace where this happens.

This has been reported to the ISC team quite some time ago here: https://gitlab.isc.org/isc-projects/kea/-/issues/1117.
A patch has been provided to the ISC team which they have not applied (I can't
say why): https://github.com/isc-projects/kea/pull/119.
The file that is patched has been more or less unchanged since the patch was created and should still apply (it did for me on 2.2.0-6).

This behavior was not present in isc-dhcp-server as they filtered out VLAN tagged broadcasts from what I can tell, so the behavior is changed between the
two DHCP server services.

As I see it there are two things that shouldn't happen here:
1. A DHCP server not explicitly configured to listen to VLAN traffic should not
   respond to that traffic.
2. If a DHCP server answers DHCP broadcasts on a VLAN tagged network it should
   respond on the same VLAN network.

My suggestion would be to include the patch (https://github.com/isc-projects/kea/pull/119)
to filter out any tagged traffic, as this is inline with how dhcpd from isc-dhcp-server worked.

Hello Kristofer and thanks for this bug report.

After looking at the state of the upstream bug and and the patches you
pointed to, and discussing the issue with the other Debian Kea maintainers,
our opinion is that we should not patch the Debian package to include the requested functionality. There are many reasons for this, in I think the
two most important ones are:

* The issue is not trivial, and there's the risk to introduce incomplete
or buggy code we can't commit to fix or maintain.

* If what ISC will ship at some point will be different from what Debian shipped, maybe in a stable release, we'll end up in a difficult to handle situation, with no clear or easy upgrade path for uses that ended up
relying on the Debian specific implementation.

I think the way forward here is asking upstream what the plans are, and
whether there are ways users interested in the feature can help landing
it.

Cheers,

Paride

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)