Control: tags -1 + wontfix On 2024-01-29 15:27, kristofer.hans...@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
