Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2023-09-26T14:30:24Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/2747unrecognized compiler flags2023-09-26T14:30:24ZAndrei Pavelandrei@isc.orgunrecognized compiler flagsCompiling Kea with the GNU compiler (`g++`) mentions an unrecognized flag because it's not compatible with said compiler:
```
cc1plus: note: unrecognized command-line option ‘-Wno-unused-private-field’ may have been intended to silence ...Compiling Kea with the GNU compiler (`g++`) mentions an unrecognized flag because it's not compatible with said compiler:
```
cc1plus: note: unrecognized command-line option ‘-Wno-unused-private-field’ may have been intended to silence earlier diagnostics
```
This flag is added in a Makefile. There are a few others like this.
Some include it inside the scope of `if USE_GXX`. I would instead remove these flags from Makefiles. Including a flag only for a library is arbitrary. If it should be included, it should either be for the entire repo, or not at all.
People who want to enable custom flags can use the `CXXFLAGS` environment variable which should be set before running `./configure`.
```
export CXXFLAGS="-Wno-unused-private-field"
./configure
```backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2736valid-lifetime and required client classes2023-01-26T14:25:43ZPeter Daviesvalid-lifetime and required client classesvalid-lifetime and required client classes:
When defining "valid-lifetime" in a client class the value takes precedence over
the global and subnet values. This does not happen when the class is defined as
"only-if-required" and...valid-lifetime and required client classes:
When defining "valid-lifetime" in a client class the value takes precedence over
the global and subnet values. This does not happen when the class is defined as
"only-if-required" and the subnet is defined with "required-client-classes"
The Kea Arm suggests that "option-data" in required classes take precedence but
no mention is made of "valid-lifetime"
Quote: Required evaluation can be used to express complex dependencies like subnet membership. It can also be used to reverse
the precedence; if option-data is set in a subnet, it takes precedence over option-data in a class. If option-data
is moved to a required class and required in the subnet, a class evaluated earlier may take precedence.
The following offers a lease time with the default value of "7200" and not "123"
for clients classifed as "Class-1"
```
{
"Dhcp4": {
"interfaces-config": { "interfaces": [ "vethserver" ] },
"control-socket": { "socket-type": "unix", "socket-name": "../sockets/kea4_command" },
"lease-database": { "type": "memfile", "name": "./kea-lease4.csv", "lfc-interval": 0, "persist": true },
"client-classes": [ {
"name": "Class-1", "test": "(pkt4.mac == 0x1e503193e1a6)", "only-if-required": true, "valid-lifetime": 123 }],
"subnet4": [ {
"subnet": "10.0.1.0/24", "id": 1,
"pools": [ { "pool": "10.0.1.5 - 10.0.1.254",
"require-client-classes": [ "Class-1" ] } ] }],
"dhcp-ddns": { "enable-updates": false },
"option-data": [ {
"name": "domain-name-servers", "code": 6, "data": "1.1.1.1" }, {
"name": "routers", "code": 3, "data": "10.0.1.1" } ],
"loggers": [ {
"name": "kea-dhcp4", "output_options": [ { "output": "./kea-dhcp4.log" } ],
"severity": "DEBUG", "debuglevel": 99 } ] }
}
```
[RT #21738](https://support.isc.org/Ticket/Display.html?id=21738)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2728the Dhcpv4Srv::appendRequestedOptions and Dhcpv4Srv::buildCfgOptionList exit ...2023-07-31T14:14:19ZRazvan Becheriuthe Dhcpv4Srv::appendRequestedOptions and Dhcpv4Srv::buildCfgOptionList exit early if subnet is nullwhile working at #1518 and using v6 as an 'inspiration' for the code I have discovered that v4 functions exit early if subnet is null.
Dhcpv4Srv::buildCfgOptionList is used to build the list of persistent options, so I think it should a...while working at #1518 and using v6 as an 'inspiration' for the code I have discovered that v4 functions exit early if subnet is null.
Dhcpv4Srv::buildCfgOptionList is used to build the list of persistent options, so I think it should also check if there are any hosts with persistent options or client classes with persistent options that need to be added to the response.
also the Dhcpv4Srv::appendRequestedOptions is skipping the list built by the first function if the subnet is null.
I think that this has an effect on the information message.
both functions are called by Dhcpv4Srv::processInform so I think that the information message should add persistent options (always-sent set to true), either global or in matching client classes or hosts(?).
thread ignored in #1518:
https://gitlab.isc.org/isc-projects/kea/-/merge_requests/1889#note_345697
using the early exit in v6 will cause following UT to fail:
```
[ RUN ] Dhcpv6SrvTest.prlPersistency
dhcp6_srv_unittest.cc:2868: Failure
Value of: response->getOption(D6O_SUBSCRIBER_ID)
Actual: false
Expected: true
[ FAILED ] Dhcpv6SrvTest.prlPersistency (4 ms)
[ RUN ] InfRequestTest.infRequestNoSubnets
infrequest_unittest.cc:300: Failure
Value of: nis
Actual: false
Expected: true
[ FAILED ] InfRequestTest.infRequestNoSubnets (2 ms)
[ FAILED ] 2 tests, listed below:
[ FAILED ] Dhcpv6SrvTest.prlPersistency
[ FAILED ] InfRequestTest.infRequestNoSubnets
```backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2721naming inconsistency between keactrl parameters and the servers acted upon2023-07-31T12:45:46ZAndrei Pavelandrei@isc.orgnaming inconsistency between keactrl parameters and the servers acted uponIt's unclear what parameter should be specified to, for example, start `kea-dhcp6`. The usage message is not clear on that:
```
$ keactrl
ERROR/keactrl: missing command
usage is keactrl command [-c keactrl-config-file] [-s server[,serve...It's unclear what parameter should be specified to, for example, start `kea-dhcp6`. The usage message is not clear on that:
```
$ keactrl
ERROR/keactrl: missing command
usage is keactrl command [-c keactrl-config-file] [-s server[,server,..]]
commands: start stop reload status version
```
They end up being different than the server names. Without the leading `kea-`, and with dashes turned to underscores:
```
$ keactrl version -s dhcp4,dhcp6,dhcp_ddns,ctrl_agent,netconf
keactrl: 2.3.4-git
kea-dhcp4: 2.3.4-git
kea-dhcp6: 2.3.4-git
kea-dhcp-ddns: 2.3.4-git
kea-ctrl-agent: 2.3.4-git
kea-netconf: 2.3.4-git
```
There is a mention of the parameters in `man keactrl`:
```
-s|--server server[,server,...]
Specifies a subset of the enabled servers to which the command should be issued. The list of servers should be separated by commas, with
no intervening spaces. Acceptable values are:
dhcp4 DHCPv4 server (kea-dhcp4).
dhcp6 DHCPv6 server (kea-dhcp6).
dhcp_ddns
DHCP DDNS server (kea-dhcp-ddns).
ctrl_agent
Control Agent (kea-ctrl-agent).
netconf
NETCONF agent (kea-netconf).
all All servers, including NETCONF if it was configured to be built. This is the default.
```
It would be nice to have the parameter names be the same as the server names to avoid ambiguity.
First reported here: https://lists.isc.org/pipermail/kea-users/2022-July/003497.htmlbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2703unit tests failure with mysql 5.7.39 and freebsd 12.2023-01-26T16:10:46ZWlodzimierz Wencelunit tests failure with mysql 5.7.39 and freebsd 12.unit test failures:
* https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/lastCompletedBuild/testReport/(root)/MySqlConfigBackendDHCPv6Test/run_tests___freebsd_12_1_amd64___freebsd_12_1_amd64_results___globalOptions6WithServerTagsTes...unit test failures:
* https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/lastCompletedBuild/testReport/(root)/MySqlConfigBackendDHCPv6Test/run_tests___freebsd_12_1_amd64___freebsd_12_1_amd64_results___globalOptions6WithServerTagsTest/
* https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/lastCompletedBuild/testReport/(root)/MySqlConfigBackendDHCPv6Test/run_tests___freebsd_12_1_amd64___freebsd_12_1_amd64_results___globalOptions6WithServerTagsTest/
* https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/lastCompletedBuild/testReport/(root)/MySqlConfigBackendDHCPv6Test/run_tests___freebsd_12_1_amd64___freebsd_12_1_amd64_results___unassignedSubnet6Test/
```
19:27:28 MySQL:
19:27:28 MYSQL_VERSION: 5.7.39
19:27:28 MYSQL_CPPFLAGS: -I/usr/local/include/mysql
19:27:28 MYSQL_LIBS: -L/usr/local/lib/mysql -lmysqlclient -lpthread -lm -lrt -lexecinfo -lssl -lcrypto -lssl -lcrypto
```
test report: https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/957/testReport/
Most of systems we are using at the build farm are using mysql version 8 or higher. Except centos 7 (5.5.68) and ubuntu 18.04 (5.7.39) but tests are not failing there.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2700HA Load-Balancing Network issue detection between Relay and Kea2023-01-26T15:22:15ZMathias AichingerHA Load-Balancing Network issue detection between Relay and KeaHi,
I have already tried to resolve this issue with the kea users community, but it seems not many are using HA Load Balancing.
I have the following problem.
Scenario:
Multiple DHCP-Relays at different sites with both KEA-Servers as DH...Hi,
I have already tried to resolve this issue with the kea users community, but it seems not many are using HA Load Balancing.
I have the following problem.
Scenario:
Multiple DHCP-Relays at different sites with both KEA-Servers as DHCP-Servers. Both servers are available and the load balancing shifts the requests between the two servers.
Incident: Because of a network issue Kea 1 is not available from the clients. The network connection between Kea 1 and Kea 2 still works, so no partner-down state.
Expected behaviour: Kea 2 sees the unacked clients of Kea 1 and sets Kea 1 in partner-down state and handles all requests.
Experienced behaviour: Kea 2 still reports HA_BUFFER4_RECEIVE_NOT_FOR_US and does not handle the requests. Unacked clients is not counted.
Is there a misunderstanding or configuration mistake on my side?
```
{
"library": "/usr/local/lib/kea//hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [
{
"this-server-name": "server2",
"mode": "load-balancing",
"heartbeat-delay": 10000,
"max-response-delay": 60000,
"max-ack-delay": 10000,
"max-unacked-clients": 1,
"delayed-updates-limit": 100,
"peers": [
{
"name": "server1",
"url": "http://192.168.248.1:8080/",
"role": "primary",
"auto-failover": true
},
{
"name": "server2",
"url": "http://192.168.248.2:8080/",
"role": "secondary",
"auto-failover": true
}
]
}
]
}
}
```
Thank you,
Mathiasbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2697if require-client-certs is false than cert-file and key-file should not be ne...2023-02-22T14:42:36Zjbbjarnasonif require-client-certs is false than cert-file and key-file should not be necessary---
name: Feature request
about: Suggest an idea for this project
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version? _No, I am running version `2.2.0-isc20220726061131`_
- A...---
name: Feature request
about: Suggest an idea for this project
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version? _No, I am running version `2.2.0-isc20220726061131`_
- Are you sure what you would like to do is not possible using some other mechanisms? _It is possible but wrong._
- Have you discussed your idea on kea-users or kea-dev mailing lists? _No_
**Is your feature request related to a problem? Please describe.**
If you configure `require-client-certs` as false in high availability hooks, you should not be required to declare `cert-file` and `key-file`
It is very important to describe what you would like to do and why?
Why? It doesn't make sense for remote Kea server to require client certificate from other Kea server when it is already configured as non-required.
**Describe the solution you'd like**
A clear and concise description of what you want to happen.
**Example config**
From high availability hook,
```json
"peers": [
{
"auto-failover": true,
"name": "kea-dhcpremote-2.kea-dhcpremote.default.svc.cluster.local.",
"role": "primary",
"url": "http://10.244.0.7:8000/"
},
{
"auto-failover": true,
"cert-file": "/certs/kea-client.crt",
"key-file": "/certs/kea-client.key",
"name": "kea-dhcpremote-1.kea-dhcpremote.default.svc.cluster.local.",
"require-client-certs": false,
"role": "standby",
"trust-anchor": "/certs/ca.crt",
"url": "https://10.244.0.5:8000/"
},
{
"auto-failover": true,
"name": "kea-dhcpremote-0.kea-dhcpremote.default.svc.cluster.local.",
"role": "backup",
"url": "http://10.244.0.10:8000/"
}
]
```
From the above config snippet, the `cert-file` and `key-file` should not be needed.
**Describe alternatives you've considered**
The alternative is to generate a bogus client certificate file and client key file and point to it, **Note** the files do not need to be the correct ones since it is not used.
**Additional context**
Add any other context about the feature request here.
**Funding its development**
Kea is run by ISC, which is a small non-profit organization without any government funding or any permanent sponsorship organizations. Are you able and willing to participate financially in the development costs? _No sorry_
**Participating in development**
Are you willing to participate in the feature development? ISC team always tries to make a feature as generic as possible, so it can be used in wide variety of situations. That means the proposed solution may be a bit different that you initially thought. Are you willing to take part in the design discussions? Are you willing to test an unreleased engineering code? _I would have to ask my employer_
**Contacting you**
How can ISC reach you to discuss this matter further? If you do not specify any means such as e-mail, jabber id or a telephone, we may send you a message on github with questions when we have them.
_jon.bjarni@menandmice.com_backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2695Regression: configure --with-sysrepo was changed to 4 different arguments.2023-01-19T14:59:24ZFrancis DupontRegression: configure --with-sysrepo was changed to 4 different arguments.The request is to be able to configure libyang and sysrepo with cpp using only one argument, either sysrepo to keep backward compatibility or a new one as --with-netconf (proposed by @andrei)The request is to be able to configure libyang and sysrepo with cpp using only one argument, either sysrepo to keep backward compatibility or a new one as --with-netconf (proposed by @andrei)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2670renew-timer and rebind-timer in client classes2023-03-03T11:49:51ZPeter Daviesrenew-timer and rebind-timer in client classesFor some users, it may be useful to be able to define "renew-timer" and "rebind-timer"
within client class definitions.
[RT #21543](https://support.isc.org/Ticket/Display.html?id=21543)For some users, it may be useful to be able to define "renew-timer" and "rebind-timer"
within client class definitions.
[RT #21543](https://support.isc.org/Ticket/Display.html?id=21543)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2637Regular expressions in Stork2023-04-06T12:02:30ZPeter DaviesRegular expressions in StorkTo enable the use of regular expression is Stork
see: https://gitlab.isc.org/isc-projects/stork/-/issues/901
It may be necessary to change the behaviour of leaseX-get-* commandsTo enable the use of regular expression is Stork
see: https://gitlab.isc.org/isc-projects/stork/-/issues/901
It may be necessary to change the behaviour of leaseX-get-* commandsbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2622`run_script` hook should contain all DHCP options2022-12-01T14:53:51Zvps-eric`run_script` hook should contain all DHCP optionsI propose that the `run_script` hook be expanded to include all (or more) options of the DHCPv4 packet. As it stands, [only option 82 is returned](https://gitlab.isc.org/isc-projects/kea/-/blob/master/src/hooks/dhcp/run_script/run_script...I propose that the `run_script` hook be expanded to include all (or more) options of the DHCPv4 packet. As it stands, [only option 82 is returned](https://gitlab.isc.org/isc-projects/kea/-/blob/master/src/hooks/dhcp/run_script/run_script.cc#L373-383):
```
RunScriptImpl::extractOption(vars,
pkt4->getOption(DHO_DHCP_AGENT_OPTIONS),
prefix, suffix);
RunScriptImpl::extractSubOption(vars,
pkt4->getOption(DHO_DHCP_AGENT_OPTIONS),
RAI_OPTION_AGENT_CIRCUIT_ID,
prefix, suffix);
RunScriptImpl::extractSubOption(vars,
pkt4->getOption(DHO_DHCP_AGENT_OPTIONS),
RAI_OPTION_REMOTE_ID,
prefix, suffix);
```
Not having looked in-depth, this seems like a place to add a loop over all the option constants, and additionally over each suboption (if applicable). This might be completely unrealistic, however.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2603add support for template-classes in CB2023-07-31T12:45:46ZRazvan Becheriuadd support for template-classes in CBNow that template classes are implemented, it would be good to extend the Config Backend support to cover them.Now that template classes are implemented, it would be good to extend the Config Backend support to cover them.backlogRazvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2597cache toText and hash_value of IOAddress instances2023-04-06T12:02:31ZFrancis Dupontcache toText and hash_value of IOAddress instancestoText and hash_value are expensive operations in particular for IPv6 addresses. The idea is to cache the result in these methods in IOAddress instances in mutable Optional new members.
Need some benchmark to see if the performance win ...toText and hash_value are expensive operations in particular for IPv6 addresses. The idea is to cache the result in these methods in IOAddress instances in mutable Optional new members.
Need some benchmark to see if the performance win is great enough to justify the complexity and the greater memory footprint.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2592partner-down state transition when max-unacked-clients reached2022-11-24T14:45:22ZMarcin Siodelskipartner-down state transition when max-unacked-clients reachedSuppose the server lost the connection with its partner. The server begins the failover procedure by checking whether or not the partner responds to the DHCP queries. The `max-unacked-clients` setting controls how many different clients ...Suppose the server lost the connection with its partner. The server begins the failover procedure by checking whether or not the partner responds to the DHCP queries. The `max-unacked-clients` setting controls how many different clients should retry getting the lease with the increased value of the `secs` field before the server considers partner dead. One would expect the server to make `partner-down` transition as soon as the number of unacked clients reaches the configured number. In fact, the state transitions are generally performed when the server completes a heartbeat or a lease update. It is possible that under heavy traffic there will be much larger number of unacked clients and the server still sits in the normal state (e.g. hot-standby), waiting for the heartbeat trigger. Assuming the heartbeat interval is reasonable, it should probably be fine. However, we may consider starting the transition as soon as the number of unacked clients reaches the configured maximum.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2574REST API using new BLQ lease query functions2023-04-06T12:02:31ZFrancis DupontREST API using new BLQ lease query functionsThe idea is to add REST API commands using the new #2571 lease query functions. The hook where to add them is to be discussed.The idea is to add REST API commands using the new #2571 lease query functions. The hook where to add them is to be discussed.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2565HA lease v6 updates use the default hwtype and hwaddr_source2023-07-31T13:51:18ZAndrei Pavelandrei@isc.orgHA lease v6 updates use the default hwtype and hwaddr_sourceNotice the discrepancy in the last two columns:
* `server1`:
```
address,duid,valid_lifetime,expire,subnet_id,pref_lifetime,lease_type,iaid,prefix_len,fqdn_fwd,fqdn_rev,hostname,hwaddr,state,user_context,hwtype,hwaddr_source
2001:db8:5...Notice the discrepancy in the last two columns:
* `server1`:
```
address,duid,valid_lifetime,expire,subnet_id,pref_lifetime,lease_type,iaid,prefix_len,fqdn_fwd,fqdn_rev,hostname,hwaddr,state,user_context,hwtype,hwaddr_source
2001:db8:50::11,00:03:00:01:01:03:0d:04:0b:01,4000,1663013972,1,3000,0,5946,128,0,0,,01:03:0d:04:0b:01,0,,1,0
2001:db8:50::12,00:03:00:01:01:04:0e:05:0c:02,4000,1663013972,1,3000,0,3512,128,0,0,,01:04:0e:05:0c:02,0,,1,0
2001:db8:50::d,00:03:00:01:01:05:0f:06:0d:03,4000,1663013972,1,3000,0,5918,128,0,0,,01:05:0f:06:0d:03,0,,1,2
2001:db8:50::e,00:03:00:01:01:06:10:07:0e:04,4000,1663013973,1,3000,0,4936,128,0,0,,01:06:10:07:0e:04,0,,1,2
```
* `server2`:
```
address,duid,valid_lifetime,expire,subnet_id,pref_lifetime,lease_type,iaid,prefix_len,fqdn_fwd,fqdn_rev,hostname,hwaddr,state,user_context,hwtype,hwaddr_source
2001:db8:50::11,00:03:00:01:01:03:0d:04:0b:01,4000,1663013972,1,3000,0,5946,128,0,0,,01:03:0d:04:0b:01,0,,1,2
2001:db8:50::12,00:03:00:01:01:04:0e:05:0c:02,4000,1663013972,1,3000,0,3512,128,0,0,,01:04:0e:05:0c:02,0,,1,2
2001:db8:50::d,00:03:00:01:01:05:0f:06:0d:03,4000,1663013972,1,3000,0,5918,128,0,0,,01:05:0f:06:0d:03,0,,1,0
2001:db8:50::e,00:03:00:01:01:06:10:07:0e:04,4000,1663013973,1,3000,0,4936,128,0,0,,01:06:10:07:0e:04,0,,1,0
```
The ones with `hwaddr_source = 0` are updated from the other peer. `hwtype = 1` is also likely a default that happens to match its source in the examples above.
It looks like `Lease6::toElement()` and `Lease6Parser::parse()` need the `hwtype` and `hwaddr_source` capabilities.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2563Refactor exceptions in libdhcp-cc library2023-04-06T12:02:31ZMarcin SiodelskiRefactor exceptions in libdhcp-cc libraryI have a use case related to #2408, where I intend to modify the control results returned by the ``lease_cmds`` hook library. The #2408 introduces the conflict status code returned when the new or updated lease is in conflict with the se...I have a use case related to #2408, where I intend to modify the control results returned by the ``lease_cmds`` hook library. The #2408 introduces the conflict status code returned when the new or updated lease is in conflict with the server's configuration. However, there is also another class of errors that could be distinguished - errors returned for bad arguments. Hook libraries make use of the Kea parsers that generally throw ``DhcpConfigError``. The ``lease_cmds`` hook can also throw ``BadValue`` or ``InvalidParameter``. They all can mean similar things. We could use ``DhcpConfigError`` everywhere, but its comment says it is to be removed in favor or the ``ConfigError`` exception. I also think that ``DhcpConfigError`` shouldn't be used for the commands that do not attempt to modify the configuration. There are tons of commands that only read the data but can still trigger the ``DhcpConfigError``. Overall, our use of the exceptions and the hierarchy makes it quite hard to differentiate between various error conditions.
In my opinion, we should have a ``BadCommandArguments`` type of exception returned by the DHCP parsers. The hook libraries like ``lease_cmds`` could also internally throw this error. Finally, when catching this exception, we could return a dedicated status code in the command response.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2540kea4 drops packet when server id option is included twice, but because of wro...2023-04-06T12:02:31ZWlodzimierz Wencelkea4 drops packet when server id option is included twice, but because of wrong reasonWe have pretty complicated test for fqdn sanitisation, we came across weird problem. When Kea gets v4 packet that include server id option twice - it's get dropped but Kea logs:
```
2022-08-19 02:35:41.529 DEBUG [kea-dhcp4.bad-packets/16...We have pretty complicated test for fqdn sanitisation, we came across weird problem. When Kea gets v4 packet that include server id option twice - it's get dropped but Kea logs:
```
2022-08-19 02:35:41.529 DEBUG [kea-dhcp4.bad-packets/169499.139645022918400] DHCP4_PACKET_DROP_0003 [hwtype=1 00:1f:d0:00:00:22], cid=[no info], tid=0x8c57ee, from interface enp0s9: it contains a foreign server identifier
```
interesting part is that value of server id is correct.
packet:
```
###[ Ethernet ]###
dst = ff:ff:ff:ff:ff:ff
src = 08:00:27:6d:ee:67
type = IPv4
###[ IP ]###
version = 4
ihl = None
tos = 0x0
len = None
id = 1
flags =
frag = 0
ttl = 64
proto = udp
chksum = None
src = 0.0.0.0
dst = 255.255.255.255
\options \
###[ UDP ]###
sport = bootpc
dport = bootps
len = None
chksum = None
###[ BOOTP ]###
op = BOOTREQUEST
htype = 1
hlen = 6
hops = 0
xid = 9197550
secs = 0
flags =
ciaddr = 0.0.0.0
yiaddr = 0.0.0.0
siaddr = 0.0.0.0
giaddr = 0.0.0.0
chaddr = b'\x00\x1f\xd0\x00\x00"'
sname = b''
file = b''
options = 'c\\x82Sc'
###[ DHCP options ]###
options = [message-type='request' server_id=192.168.50.252 server_id=192.168.50.252 requested_addr=192.168.50.11 client_FQDN='\x01\x00\x00client2.four.example.com.' end]
```backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2525Support multiple vendor options in flex_option hook2023-11-13T22:36:40ZFrancis DupontSupport multiple vendor options in flex_option hookCurrently the code assumes there is at most one instance of a vendor option and ignore vendor class options even it knows vendor IDs.Currently the code assumes there is at most one instance of a vendor option and ignore vendor class options even it knows vendor IDs.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2524Support multiple vendor options in expression evaluation2023-06-19T12:22:48ZFrancis DupontSupport multiple vendor options in expression evaluationCurrently expressions handle vendor IDs in the syntax but the code and unit tests are not prepared to have multiple vendor options (v4 124 and 125, v6 16 and 17) i.e. the first vendor option masks others.Currently expressions handle vendor IDs in the syntax but the code and unit tests are not prepared to have multiple vendor options (v4 124 and 125, v6 16 and 17) i.e. the first vendor option masks others.backlog