Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2022-11-02T15:08:43Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/39shared-network option takes precedence before option defined in client class2022-11-02T15:08:43ZGhost Usershared-network option takes precedence before option defined in client classWhen kea6 is configured with shared-network that contain option, and subnet (within that shared-network) which has assigned class with the same option defined - Kea ignores option defined in class.
Example configuration:
```
{
"Dhcp...When kea6 is configured with shared-network that contain option, and subnet (within that shared-network) which has assigned class with the same option defined - Kea ignores option defined in class.
Example configuration:
```
{
"Dhcp6":
{
"renew-timer":1000,
"rebind-timer":2000,
"preferred-lifetime":3000,
"valid-lifetime":4000,
"client-classes":[
{
"name":"Client_Class_1",
"test":"substring(option[1].hex,8,2)==0xf2f1",
"option-data":[
{
"csv-format":true,
"code":23,
"data":"2001:db8::888",
"name":"dns-servers",
"space":"dhcp6"
}
]
}
],
"interfaces-config":
{
"interfaces":["eth2"]
},
"lease-database":
{
"type":"memfile"
},
"shared-networks":[
{
"name":"name-abc",
"interface":"eth2",
"option-data":[
{
"csv-format":true,
"code":23,
"data":"2001:db8::1",
"name":"dns-servers",
"space":"dhcp6"
}
],
"subnet6":[
{
"subnet":"2001:db8:a::/64",
"client-class":"Client_Class_1",
"pools":[
{
"pool":"2001:db8:a::1-2001:db8:a::10"
}
]
}
]
}
]
}
}
```
Packet is evaluated correctly, option 23 has value that is configured on shared-network level, not what is in the class.
```
DEBUG [kea-dhcp6.eval/18704] EVAL_DEBUG_EQUAL Popping 0xF2F1 and 0xF2F1 pushing result 'true'
INFO [kea-dhcp6.dhcp6/18704] EVAL_RESULT Expression Client_Class_1 evaluated to 1
```
but message is created incorreclty:
```
DHCP6_RESPONSE_DATA responding with packet type 2 data is localAddr=[ff02::1:2]:547 remoteAddr=[fe80::800:27ff:fe00:1]:546
msgtype=2(ADVERTISE), transid=0xeda107
type=00001, len=00010: 00:03:00:01:66:55:44:33:f2:f1
type=00002, len=00014: 00:01:00:01:21:81:be:d4:08:00:27:19:b8:2a
type=00003(IA_NA), len=00040: iaid=39866, t1=1000, t2=2000,
options:
type=00005(IAADDR), len=00024: address=2001:db8:a::1, preferred-lft=3000, valid-lft=4000
type=00023, len=00016: 2001:db8::1
```
Entire logs and network capture attached.
Number of subnets within shared-network, or number of shared-networks makes no difference - bug occur.
When client has reservation with option X it correctly overrides option configured on shared-network level.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/37revamp subnet sanity checks2022-11-02T15:08:41ZGhost Userrevamp subnet sanity checksOn one side decides what should be checked:
- interface in shared network
- "same subnet" (cf #5423)
- malformed prefix
etc
And apply this to documentation and code in:
- plain subnet configuration
- in shared network subnet config...On one side decides what should be checked:
- interface in shared network
- "same subnet" (cf #5423)
- malformed prefix
etc
And apply this to documentation and code in:
- plain subnet configuration
- in shared network subnet configuration
- subnet REST API
Should be done after #5423 (definition of "same subnet") and client-class in pools.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/41Kea should be able to print performance metrics2023-01-09T12:25:26ZGhost UserKea should be able to print performance metricsWhen debugging an issue, it became clear that finding out how long it takes Kea to process a packet and actually send a response is difficult. It requires matching different log entries, which sometimes is very problematic if there are m...When debugging an issue, it became clear that finding out how long it takes Kea to process a packet and actually send a response is difficult. It requires matching different log entries, which sometimes is very problematic if there are multiple packets sent from a client.
We should develop a way to measure how long it takes to process a packet. The easiest way will be to use a stopwatch (see src/lib/util/stopwatch.h). I think we should remember the timestamp somewhere in Pkt4 (and possibly Pkt6) very early when the packet is received (perhaps in Pkt4 constructor?) and then print the interval value once the response packet is being sent out.
I think it would be useful to have separate logger for this, maybe call it performance or perf? If the concept proves to be useful, we may soon extend it to print out more detailed information about different stages (it took X ms to find host reservation, Y ms to select a lease, Z ms to do DNS update etc).backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/46Please add circuit-ID to result of get lease-42022-11-02T15:08:42ZGhost UserPlease add circuit-ID to result of get lease-4We want to identify leases with circuit ID, how can we get the circuit ID with the lease4-get?
I want to search for a lease with the circuit ID with lease-get.
Vennlig hilsen / Best regards
Frode SætreWe want to identify leases with circuit ID, how can we get the circuit ID with the lease4-get?
I want to search for a lease with the circuit ID with lease-get.
Vennlig hilsen / Best regards
Frode Sætrebackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/77memfile: add a command to force writing in-memory DB to file2022-11-02T15:08:43ZGhost Usermemfile: add a command to force writing in-memory DB to filememfile keeps leases in memory and writes changes to disk. If the leasefile is lost for whatever reason, it may be useful to tell Kea to write is entire lease file to disk.memfile keeps leases in memory and writes changes to disk. If the leasefile is lost for whatever reason, it may be useful to tell Kea to write is entire lease file to disk.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/60Add automatic rate adjustment to perfdhcp2022-11-02T15:08:41ZGhost UserAdd automatic rate adjustment to perfdhcpTo facilitate performance measurements, it would be helpful if perfdhcp had an automatic rate adjustment feature.
With this, perfdhcp would start sending packets a specified initial rate, then periodically adjust the rate upwards or dow...To facilitate performance measurements, it would be helpful if perfdhcp had an automatic rate adjustment feature.
With this, perfdhcp would start sending packets a specified initial rate, then periodically adjust the rate upwards or downwards automatically until it reached the maximum rate at which the fraction of packets lost was no higher than a given value.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/133Discussion about ordering in configurations.2022-11-02T15:08:43ZFrancis DupontDiscussion about ordering in configurations.It concerns mainly subnets and client classes but most of this is generic, e.g. can be applied to shared networks:
- memory representation must use a multi index container with a sequenced or random access index to implement the order, ...It concerns mainly subnets and client classes but most of this is generic, e.g. can be applied to shared networks:
- memory representation must use a multi index container with a sequenced or random access index to implement the order, in particular we must to not add previous or next field to objects themselves.
- database representation must use previous and next columns in rows to implement a double linked list. First and last rows have a reserved previous or next value (e.g. id 0 for subnets).
- command hooks must add a before or after to insert command (vs always nsert at the end) and an easy way to get the order itself, e.g. the order list of entries used as index (subnet id, client class name, ...).
- optionally (i.e. not in 1.5) we can add a relocate command.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/22stringop-truncation warnings2022-11-02T15:08:41ZFrancis Dupontstringop-truncation warningsG++ 8 has a new warning stringop truncation which is emitted when strncat or strncpy (only the second in kea) fails to terminate (i.e. append a null character) its result.
There are on Fedora 28 spurious warnings on local/unix socket ad...G++ 8 has a new warning stringop truncation which is emitted when strncat or strncpy (only the second in kea) fails to terminate (i.e. append a null character) its result.
There are on Fedora 28 spurious warnings on local/unix socket address or ifname because they are filled using strncpy.
I have a mixed feeling about this: IMHO the issue is not in Kea but in the system header files which should add a ```nonstring``` attribute but did not, so no action is a possible answer to this...backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/38Updating DNS entry on host reservation changing2022-11-02T15:08:42ZGhost UserUpdating DNS entry on host reservation changingI sent this questions to kea-users@lists.isc.org two days ago, but nothing happens and I can't see my message in thread list. So, I decided to create a new ticket.
My previous message:
I'm trying to bond Kea with BIND. When a new lease ...I sent this questions to kea-users@lists.isc.org two days ago, but nothing happens and I can't see my message in thread list. So, I decided to create a new ticket.
My previous message:
I'm trying to bond Kea with BIND. When a new lease is created or expired it works well. In this cases I get correct records in "forward" and "reverse" DNS zones. But, when I'm changing an IP-address in host reservation entry in MySQL database, a new address is allocated to the customer and new correct entries appear in DNS. However, an old entry for previous IP-address still remains in "reverse" DNS zone. Thus, now I have a "ghost" entry in my DNS.
I would manually remove the lease BEFORE changing the reservation entry. I guess it should work. But maybe there is a routine solution for this issue?backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/44make database config parsing more flexible2022-11-02T15:08:41ZGhost Usermake database config parsing more flexibleCf. #5528 comments (look for "line 125").Cf. #5528 comments (look for "line 125").backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/47Update network/subnet hooks to handle new classification fields2022-11-02T15:08:43ZGhost UserUpdate network/subnet hooks to handle new classification fields[#5374](https://oldkea.isc.org/ticket/5374) was merged but introduced new features which require an update of hooks managing shared networks and subnets.[#5374](https://oldkea.isc.org/ticket/5374) was merged but introduced new features which require an update of hooks managing shared networks and subnets.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/51Impossible to use a Chromecast with kea DHCP2022-11-02T15:08:41ZGhost UserImpossible to use a Chromecast with kea DHCPHello,
since few month I use kea dhcp server, it works properly with all my devices but I have a big problem with my Chromecast, it doesn't work att all with your DHCP server. I already contacted Chromecast Support team. I don't know if ...Hello,
since few month I use kea dhcp server, it works properly with all my devices but I have a big problem with my Chromecast, it doesn't work att all with your DHCP server. I already contacted Chromecast Support team. I don't know if I am the only one with this problem.
Before I decided to use Kea I was using my ISP's dhcp server but it was too limited and verry bugfull.
I hope you will be able to find a way to fix this, I didn't gave you any logs or config files because I don't know what you really need but I really need it working and I'll give you any file you need, your DHCP server is VERRY nice !
Cordiallybackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/52kea-dhcp4 can't offer ip reserved.2022-11-02T15:08:43ZGhost Userkea-dhcp4 can't offer ip reserved.subnet : 192.168.0.0/24
reservation1 : mac(aa:aa:aa:aa:aa:aa) ip(192.168.0.11)
reservation2 : mac(bb:bb:bb:bb:bb:bb) ip(192.168.0.12)
reservation1 has router option(3) 192.168.0.3
reservation2 has no options.
I used mysql for hosts res...subnet : 192.168.0.0/24
reservation1 : mac(aa:aa:aa:aa:aa:aa) ip(192.168.0.11)
reservation2 : mac(bb:bb:bb:bb:bb:bb) ip(192.168.0.12)
reservation1 has router option(3) 192.168.0.3
reservation2 has no options.
I used mysql for hosts reservation.
kea-dhcp4 responses to reservation1 but fail to response to reservation2 somtimes.
The Failure log is 'preparing on-wire-format of the packet to be sent failed DHCPv4 Option4AddrLst 3 is too big.At most 255 bytes are supported.'
In packets debug log, kea-dhcp4 try to response to reserve2 with router option(value is 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 ....... maybe 2048~4096byte)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/54Reconfigure with an unusable lease back end, leaves the server in a non-worki...2022-11-02T15:08:41ZGhost UserReconfigure with an unusable lease back end, leaves the server in a non-working state (no rollback)A running kea-dhcpX server can be rendered non-functional by issuing a reconfigure (either by command or signal) with a configuration containing
a flawed lease back end specifications or to back end which cannot be reached.
After succes...A running kea-dhcpX server can be rendered non-functional by issuing a reconfigure (either by command or signal) with a configuration containing
a flawed lease back end specifications or to back end which cannot be reached.
After successfully parsing the configuration, the server attempts to connect to the new lease back end. This causes the LeaseMgrFactory to close the existing instance and subsequently fails to open a new one. The server will emit a log message that states reconfiguration has failed and at this point it will no longer process client packets.
A simple scenario:
1. start server with memfile lease back end
2. verify server hands out leases
3. change configuration to MySQL back end with an invalid database or user name
4. issue reconfig command
5. verify server does not see or acknowledge packets
The basic issue is the LeaseMgrFactory only permits one instance to exist. There is no "Staged" instance and we do not restore the one we closed. We probably don't handle host back ends any differently.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/72Radius option definitions2023-06-19T11:01:38ZGhost UserRadius option definitionsThe RadiusDesign calls for an optional mechanism that will query the Radius server about specific client. Typically this functionality has been done by a relay, which then inserted Radius options into DHCP message before forwarding it to...The RadiusDesign calls for an optional mechanism that will query the Radius server about specific client. Typically this functionality has been done by a relay, which then inserted Radius options into DHCP message before forwarding it to the server.
Kea should be able to understand such options. See RFC4014 (v4) and RFC7037 (v6) for details. Kea should be able to represent radius attributes as sub-options, so general mechanisms, like client classification could be used.
This ticket calls for option definitions only. No special handling logic should be implemented.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/76Update leases on 'dashboard server' without running HA2022-11-02T15:08:41ZGhost UserUpdate leases on 'dashboard server' without running HAOne of our GSOC students is working on a Kea dashboard, based on the GLASS project, a dashboard for ISC DHCP. The dashboard requires access to a local lease file so it can continuously or frequently update stats about pool utilization, e...One of our GSOC students is working on a Kea dashboard, based on the GLASS project, a dashboard for ISC DHCP. The dashboard requires access to a local lease file so it can continuously or frequently update stats about pool utilization, etc. It seems like the ideal way to do this is to push lease file updates to the dashboard server.
It seems we can use the 'backup server' feature of HA, but without the HA support. So, we would want a mode that doesn't check for a valid HA configuration and an HA partner. Also, we would want this feature to not require the premium HA package.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/106CB: Update Developer's Guide for Configuration Backend2022-11-02T15:08:42ZMarcin SiodelskiCB: Update Developer's Guide for Configuration BackendThis ticket covers updates to the Developer's Guide after the implementation of the Kea Config Backend.This ticket covers updates to the Developer's Guide after the implementation of the Kea Config Backend.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/110pool order2022-11-02T15:08:41ZFrancis Dupontpool orderConfiguration order of subnets and client classes is critical. Pools are ordered too but IMHO cases where it matters are uncommon, in fact it will be an issue only for config backend unit tests. I suggest to NOT address this issue (1.x l...Configuration order of subnets and client classes is critical. Pools are ordered too but IMHO cases where it matters are uncommon, in fact it will be an issue only for config backend unit tests. I suggest to NOT address this issue (1.x low for instance?).backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/114Timeouts specified in inconsistent units2022-11-02T15:08:43ZTomek MrugalskiTimeouts specified in inconsistent unitsAccording to our documentation, timeouts for MySQL and PostgreSQL are specified in seconds, while the same values for CQL are in milliseconds.
I think it's better to use milliseconds. The use case for this is that in HA scenarios, somet...According to our documentation, timeouts for MySQL and PostgreSQL are specified in seconds, while the same values for CQL are in milliseconds.
I think it's better to use milliseconds. The use case for this is that in HA scenarios, sometimes waiting for a second is too much and sub-second precision may be needed. Milliseconds is also the units used in HA.
The immediate reason why this popped up is NETCONF model definition.
However, our current documentation probably should be improved as well. We currently have the parameters explained several times, once for each backend.
Parameters affected: connect-timeout, reconnect-wait-time, request-timeout. There may be others I missed.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/139lease times stored in localtime in Postgres (DST issue?)2022-11-02T15:08:42ZRay Bellislease times stored in localtime in Postgres (DST issue?)I've observed that lease expiry times appear to be stored in local time in the Postgres database (and perhaps in others?) rather than in UTC.
This might cause unexpected removal of leases from the database at the changeover to or from DST.I've observed that lease expiry times appear to be stored in local time in the Postgres database (and perhaps in others?) rather than in UTC.
This might cause unexpected removal of leases from the database at the changeover to or from DST.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/159Kea daemonization2022-11-02T15:08:41ZAdam OsuchowskiKea daemonizationThere are some best practices on how unix daemons should behave. Some of these are not met on Kea. You can read little old but still up-to-date howto document for general overview how to linux daemons should work: http://www.netzmafia.de...There are some best practices on how unix daemons should behave. Some of these are not met on Kea. You can read little old but still up-to-date howto document for general overview how to linux daemons should work: http://www.netzmafia.de/skripten/unix/linux-daemon-howto.html
In particular:
- Kea should put its daemons into background, not stay foreground
- daemons should unbind their stdin, stdout and stderr from current streams (i.e. terminal) and bind them to /dev/null or alternatively stdout and stderr may be binded to log file
- daemons should release their controlling terminal (setsid) because they don't communicate with users this way
- daemons should change current working directory to root (/) not to lock any possible mount points
- daemons should ignore all signals which is not significant to it (i.e. SIGPIPE)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/200Remove obsolete and duplicate exceptions2022-11-02T15:08:41ZTomek MrugalskiRemove obsolete and duplicate exceptionsThere are currently 179 different types of exceptions Kea can throw. See $439 for details. We should review then and remove duplicates. For example we have 6 different ParserError exception, 4 ConfigError exceptions, 7 Type exceptions, 4...There are currently 179 different types of exceptions Kea can throw. See $439 for details. We should review then and remove duplicates. For example we have 6 different ParserError exception, 4 ConfigError exceptions, 7 Type exceptions, 4 socket errors. I'm sure there are many other duplicates.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/108Need to quote some keys for yang.2022-11-02T15:08:43ZFrancis DupontNeed to quote some keys for yang.The Kea6 reservations.json example file use ```'somevalue'``` as the identifier of a (flex-id) host reservation. Yang uses the same character ```'``` for list keys so it conflicts.
The solution should be to convert the identifier in hexa...The Kea6 reservations.json example file use ```'somevalue'``` as the identifier of a (flex-id) host reservation. Yang uses the same character ```'``` for list keys so it conflicts.
The solution should be to convert the identifier in hexadecimal so:
- check the textual and hexadecimal forms can be used together / safely.
- check presence of problematic characters in a string used as a list key
- create an adaptor to quote or convert strings used as list key.
Nothing hard but low priority as this is clearly a corner case.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/191Allow IPv6 multicast to be disabled2022-11-02T15:08:43ZGhost UserAllow IPv6 multicast to be disabled---
name: Feature request
about: Allow IPv6 multicast to be disabled
---
Currently for kea-dhcp6 on FreeBSD, a socket is opened and bound to `*:547` for multicast joining, regardless of how `interfaces-config/interface` is configured. ...---
name: Feature request
about: Allow IPv6 multicast to be disabled
---
Currently for kea-dhcp6 on FreeBSD, a socket is opened and bound to `*:547` for multicast joining, regardless of how `interfaces-config/interface` is configured. I wish to use port 547 on another interface for health checking, but can't. Since I only use external unicast relays, I don't need the multicast functionality of kea-dhcp6, so it would be nice if there was an option to disable this.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/193Server level option data is sent instead of subnet level option data2022-11-02T15:08:41ZKevan BrownServer level option data is sent instead of subnet level option data**Describe the bug**
Given a DHCP4 configuration where a client option is defined at the server level, and also at the subnet level, the client is receiving the option data from the server level first, and then after forcing the client t...**Describe the bug**
Given a DHCP4 configuration where a client option is defined at the server level, and also at the subnet level, the client is receiving the option data from the server level first, and then after forcing the client to renew, it receives the value from the subnet level.
**To Reproduce**
1) Kea DHCP4
2) Boot a Windows 10 client
3) Client receives domain-name-servers option data defined at the server level
4) Run ipconfig /renew Ethernet on the client and now it receives the correct domain-name-servers option data defined at the subnet level
5) Reboot the client and it now has the server level domain-name-servers option data again.
**Expected behavior**
The Kea DHCP4 server should send the option data defined at the subnet level to which the host reservation is mapped.
**Environment:**
- Kea version:
* 1.4.0-P1
* tarball
* linked with:
* log4cplus 1.1.2
* OpenSSL 1.1.0f 25 May 2017
* database:
* PostgreSQL backend 4.0, library 90610
* Memfile backend 2.0
- OS: Debian Stretch (Raspbian)
- Which features were compiled in (in particular which backends): "--with-pgsql --enable-shell"
- If/which hooks where loaded in: libdhcp_lease_cmds.so
**Additional Information**
- The intent here is to define common option data at level that reduces redundancy, while overriding it at the subnet level when required.
- Configuration excerpt:
```
"option-data": [
{
"name": "domain-name",
"code": 15,
"data": "mydomain.com"
},
{
"name": "domain-name-servers",
"code": 6,
"data": "172.20.0.1"
},
{
"name": "ntp-servers",
"code": 42,
"data": "172.20.0.1"
}
],
"hooks-libraries": [
{
// Lease hooks library for Kea Anterius
"library": "/usr/local/lib/hooks/libdhcp_lease_cmds.so"
}
],
"shared-networks": [
{
"name": "Home",
"subnet4": [
{
// Networking Devices
"subnet": "172.20.0.0/24",
"id": 1,
"pools": [ { "pool": "172.20.0.3 - 172.20.0.8" } ],
"option-data": [
{
"name": "routers",
"code": 3,
"data": "172.20.0.1"
}
]
},
{
// Host Management
"subnet": "172.20.1.0/24",
"id": 2,
"pools": [
{ "pool": "172.20.1.2 - 172.20.1.4" },
{ "pool": "172.20.1.6/32" }
],
"option-data": [
{
"name": "routers",
"code": 3,
"data": "172.20.1.1"
}
]
},
{
// Non-Domain Servers
"subnet": "172.20.3.0/24",
"id": 4,
"pools": [ { "pool": "172.20.3.4 - 172.20.3.4" } ],
"option-data": [
{
"name": "routers",
"code": 3,
"data": "172.20.3.1"
}
]
},
{
// Known Clients
"subnet": "172.20.4.0/24",
"id": 5,
"pools": [ { "pool": "172.20.4.2 - 172.20.4.5" } ],
"option-data": [
{
"name": "routers",
"code": 3,
"data": "172.20.4.1"
},
{
"name": "domain-name-servers",
"code": 6,
"data": "172.20.2.3,172.20.2.4,172.21.0.10,172.20.2.5,172.20.0.1"
}
]
},
```
**Describe the solution you'd like**
A fix for the options data hierarchy behavior in the product.
**Describe alternatives you've considered**
The only other alternative I have is to remove the common options data and repeat it, over and over, for each of the subnets that use it.
**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.
- Emailbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/196Improve netconf performance: keep the control socket connection open2022-11-02T15:08:43ZTomek MrugalskiImprove netconf performance: keep the control socket connection openIn 1.5 the kea-netconf agent opens up a new connection every time there is a new config to be set. This means that if you're changing the configuration frequently, there are many connections set up and torn down. It would be better to ha...In 1.5 the kea-netconf agent opens up a new connection every time there is a new config to be set. This means that if you're changing the configuration frequently, there are many connections set up and torn down. It would be better to have persistent connection (or the option to enable it).
This is out of scope for 1.5, though. Looks like a potential optimization in 1.6.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/307queue by list of packets rather than one by one2022-11-02T15:08:44ZThomas Markwalderqueue by list of packets rather than one by oneI have created a branch which greatly simplifies the PacketQueue<> interface to provide implementations with much more latitude. Lower level functions, such as push, peek, and pop were moved down into PacketQueueRing<> (the default impl...I have created a branch which greatly simplifies the PacketQueue<> interface to provide implementations with much more latitude. Lower level functions, such as push, peek, and pop were moved down into PacketQueueRing<> (the default implementation base). It also replaces queuing a single packet, to queuing a list of packets. The latter change should reduce thread contention by enabling the receiving thread to read all ready packets and pass them into the queue in one call. Lastly, I split out the PacketQueueRing<> from dhcp/packet_queue.h into its own header, dhcp/packet_queue_ring.hbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/199Integrate DHCPv6 reconfigure message feature2022-11-02T15:08:42ZMayyaSunilIntegrate DHCPv6 reconfigure message featureReconfiguration feature was implemented partially as a part of GSoC 2018 project. This issue is to track the integration of the remaining feature into kea repo.Reconfiguration feature was implemented partially as a part of GSoC 2018 project. This issue is to track the integration of the remaining feature into kea repo.backlogMarcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/217scoped D2 client config2022-11-02T15:08:43ZFrancis Dupontscoped D2 client configReading Dan's ISC DHCP config it seems the really useful scoped D2 client config extension is to be able to enable or disable D2 (using enable-updates) in some specific scopes (e.g. a subnet or a class).
Perhaps there is another issue a...Reading Dan's ISC DHCP config it seems the really useful scoped D2 client config extension is to be able to enable or disable D2 (using enable-updates) in some specific scopes (e.g. a subnet or a class).
Perhaps there is another issue about this but if we do the minimum it should be this.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/218ISC DHCP server config option stash-agent-options2023-07-12T16:34:35ZFrancis DupontISC DHCP server config option stash-agent-optionsThe stash-agent-options statement
>>>
**stash-agent-options flag;**
If the stash-agent-options parameter is true for a given client,
the server will record the relay agent information options sent
during the client's initial DHCPREQUEST...The stash-agent-options statement
>>>
**stash-agent-options flag;**
If the stash-agent-options parameter is true for a given client,
the server will record the relay agent information options sent
during the client's initial DHCPREQUEST message when the client
was in the SELECTING state and behave as if those options are
included in all subsequent DHCPREQUEST messages sent in the RENEWING
state. This works around a problem with relay agent information
options, which is that they usually not appear in DHCPREQUEST
messages sent by the client in the RENEWING state, because such
messages are unicast directly to the server and not sent through a
relay agent.
>>>
It is a real issue (for DHCPv4, in DHCPv6 the server controls the use of unicast (i.e. direct communication) by the client) but I have no idea how (or whether) it is handled by Kea...backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/220ISC DHCP authoritative for v62023-07-13T18:26:24ZFrancis DupontISC DHCP authoritative for v6Cut and paste from dhcp.conf.5:
>>>
The authoritative statement
**authoritative;**
**not authoritative;**
The DHCP server will normally assume that the configuration information
about a given network segment is not known to be correct...Cut and paste from dhcp.conf.5:
>>>
The authoritative statement
**authoritative;**
**not authoritative;**
The DHCP server will normally assume that the configuration information
about a given network segment is not known to be correct and is
not authoritative. This is so that if a naive user installs a DHCP
server not fully understanding how to configure it, it does not send
spurious DHCPNAK messages to clients that have obtained addresses
from a legitimate DHCP server on the network.
Network administrators setting up authoritative DHCP servers for
their networks should always write authoritative; at the top of their
configuration file to indicate that the DHCP server should send DHCP-
NAK messages to misconfigured clients. If this is not done, clients
will be unable to get a correct IP address after changing subnets
until their old lease has expired, which could take quite a long
time.
Usually, writing authoritative; at the top level of the file should
be sufficient. However, if a DHCP server is to be set up so that it
is aware of some networks for which it is authoritative and some networks
for which it is not, it may be more appropriate to declare
authority on a per-network-segment basis.
Note that the most specific scope for which the concept of authority
makes any sense is the physical network segment - either a shared-
network statement or a subnet statement that is not contained within
a shared-network statement. It is not meaningful to specify that the
server is authoritative for some subnets within a shared network, but
not authoritative for others, nor is it meaningful to specify that
the server is authoritative for some host declarations and not others.
>>>
UPDATE: We have this (authoritative statement) implemented in Kea DHCPv4, but not in Kea DHCPv6.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/221Kea vs ISC DHCP timers2022-11-02T15:08:43ZFrancis DupontKea vs ISC DHCP timersISC DHCP uses 3 values (max, min and default) values for lease-time (valid-lifetime) in Kea).
These 3 values are in the Kea code (aka the triplet class) but are not reflected in config. (note I don't say a solution is better but they are...ISC DHCP uses 3 values (max, min and default) values for lease-time (valid-lifetime) in Kea).
These 3 values are in the Kea code (aka the triplet class) but are not reflected in config. (note I don't say a solution is better but they are different). As the valid-lifetime is a mandatory config parameter this means Kea is rigid (same comment).
For other timers ISC DHCP has preferred-lifetime but derives t1 and t2 (aka renew and rebind timers) from the valid one using standard formula. ISC DHCP follows more the client query, i.e., it uses configured values including computed values only as default and bounds.
This is not a call to change something: it is just a summary for documentation and some infos in the case a customer requests more flexibility.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/222Pool log threshold2023-07-17T18:30:49ZFrancis DupontPool log thresholdIdea from ISC DHCP, cf dhcpd.8:
>>>
The log-threshold-high and log-threshold-low statements
**log-threshold-high** percentage;
**log-threshold-low** percentage;
The log-threshold-low and log-threshold-high statements are used to
contr...Idea from ISC DHCP, cf dhcpd.8:
>>>
The log-threshold-high and log-threshold-low statements
**log-threshold-high** percentage;
**log-threshold-low** percentage;
The log-threshold-low and log-threshold-high statements are used to
control when a message is output about pool usage. The value for
both of them is the percentage of the pool in use. If the high
threshold is 0 or has not been specified, no messages will be pro-
duced. If a high threshold is given, a message is output once the
pool usage passes that level. After that, no more messages will be
output until the pool usage falls below the low threshold. If the
low threshold is not given, it default to a value of zero.
A special case occurs when the low threshold is set to be higer than
the high threshold. In this case, a message will be generated each
time a lease is acknowledged when the pool usage is above the high
threshold.
Note that threshold logging will be automatically disabled for shared
subnets whose total number of addresses is larger than (264)-1. The
server will emit a log statement at startup when threshold logging is
disabled as shown below:
"Threshold logging disabled for shared subnet of ranges:
<addresses>"
This is likely to have no practical runtime effect as CPUs are
unlikely to support a server actually reaching such a large number of
leases.
>>>
From this I like the idea to have a hook library which performs a simple
action (log is an example) when a threshold is crossed in a reasonably
sized pool.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/223ISC DHCP server config option min-secs2023-07-17T18:34:24ZFrancis DupontISC DHCP server config option min-secs>>>
The min-secs statement
**min-secs** seconds;
Seconds should be the minimum number of seconds since a client began
trying to acquire a new lease before the DHCP server will respond to
its request. The number of seconds is based on w...>>>
The min-secs statement
**min-secs** seconds;
Seconds should be the minimum number of seconds since a client began
trying to acquire a new lease before the DHCP server will respond to
its request. The number of seconds is based on what the client
reports, and the maximum value that the client can report is 255 sec-
onds. Generally, setting this to one will result in the DHCP server
not responding to the client's first request, but always responding
to its second request.
This can be used to set up a secondary DHCP server which never offers
an address to a client until the primary server has been given a
chance to do so. If the primary server is down, the client will bind
to the secondary server, but otherwise clients should always bind to
the primary. Note that this does not, by itself, permit a primary
server and a secondary server to share a pool of dynamically-allocat-
able addresses.
>>>
Simple idea and easy to implement using Kea pkt4::getSecs.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/224ISC DHCP server config option limited-broadcast-address2022-11-02T15:08:43ZFrancis DupontISC DHCP server config option limited-broadcast-addressThere is no manual entry for this. The idea is to get some control on the broadcast address used to send responses to on-link clients. A priori not a bad idea. BTW the limited broadcast address is 255.255.255.255 and is not forwarded by ...There is no manual entry for this. The idea is to get some control on the broadcast address used to send responses to on-link clients. A priori not a bad idea. BTW the limited broadcast address is 255.255.255.255 and is not forwarded by routers (so the name) but the ISC DHCP option takes an IPv4 address (vs a boolean).backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/226ISC DHCP server config option adaptive-lease-time-threshold2022-11-02T15:08:42ZFrancis DupontISC DHCP server config option adaptive-lease-time-threshold>>>
The adaptive-lease-time-threshold statement
**adaptive-lease-time-threshold** percentage;
When the number of allocated leases within a pool rises above the
percentage given in this statement, the DHCP server decreases the
lease len...>>>
The adaptive-lease-time-threshold statement
**adaptive-lease-time-threshold** percentage;
When the number of allocated leases within a pool rises above the
percentage given in this statement, the DHCP server decreases the
lease length for new clients within this pool to min-lease-time sec-
onds. Clients renewing an already valid (long) leases get at least
the remaining time from the current lease. Since the leases expire
faster, the server may either recover more quickly or avoid pool
exhaustion entirely. Once the number of allocated leases drop below
the threshold, the server reverts back to normal lease times. Valid
percentages are between 1 and 99.
>>>
A good idea for a lease allocation hook library.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/227ISC DHCP server config option limit-addrs/prefs-per-ia2023-07-17T18:40:44ZFrancis DupontISC DHCP server config option limit-addrs/prefs-per-ia>>>
The limit-addrs-per-ia statement
**limit-addrs-per-ia** number;
By default, the DHCPv6 server will limit clients to one IAADDR per IA
option, meaning one address. If you wish to permit clients to hang
onto multiple addresses at a t...>>>
The limit-addrs-per-ia statement
**limit-addrs-per-ia** number;
By default, the DHCPv6 server will limit clients to one IAADDR per IA
option, meaning one address. If you wish to permit clients to hang
onto multiple addresses at a time, configure a larger number here.
Note that there is no present method to configure the server to
forcibly configure the client with one IP address per each subnet on
a shared network. This is left to future work.
>>>
There is another **limit-prefs-per-ia** option for prefixes. It seems a good idea even if its main/obvious use case is not supported (by ISC DHCP).backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/231ISC DHCP host declaration are global2023-07-13T18:30:36ZFrancis DupontISC DHCP host declaration are globalISC DHCP host declarations are always global, Kea reservations are by default per subnet.
Kea 1.5 introduced global host reservations.ISC DHCP host declarations are always global, Kea reservations are by default per subnet.
Kea 1.5 introduced global host reservations.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/232Kea supports only Ethernet hardware type2022-11-02T15:08:43ZFrancis DupontKea supports only Ethernet hardware typeISC DHCP supports some other (real) hardware as FDDI... IMHO it should be allowed to use a number for the hardware type in >= 1.6.ISC DHCP supports some other (real) hardware as FDDI... IMHO it should be allowed to use a number for the hardware type in >= 1.6.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/233ISC DCHP host reservation "group <name>" parameter2022-11-02T15:08:44ZFrancis DupontISC DCHP host reservation "group <name>" parameterIt is not documented at all but in host reservations one can specify a group by name.
I believe it is a second way (first is inclusion of the host reservation declaration in the scope of the group) to apply a group to a host. If it is t...It is not documented at all but in host reservations one can specify a group by name.
I believe it is a second way (first is inclusion of the host reservation declaration in the scope of the group) to apply a group to a host. If it is the case the corresponding Kea feature is to declare a class without a matching expression with all the parameters (e.g. option-data) of the group and to specify the host reservation belongs to the class, so basically swapping the group keyword for class.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/234ISC DHCP log executable statement2023-07-13T18:33:07ZFrancis DupontISC DHCP log executable statementAccording to ISC DHCP dhcp-eval(5):
>>>
log (priority, data-expr)
Logging statements may be used to send information to the standard
logging channels. A logging statement includes an optional priority
...According to ISC DHCP dhcp-eval(5):
>>>
log (priority, data-expr)
Logging statements may be used to send information to the standard
logging channels. A logging statement includes an optional priority
(fatal, error, info, or debug), and a data expression.
Logging statements take only a single data expression argument, so if
you want to output multiple data values, you will need to use the
concat operator to concatenate them.
>>>
It is an interesting feature which was discussed before (cf #4124).
To implement it in the ISC DHCP style we need 3 parameters:
- a boolean expression
- a priority
- a string expression to log
It does not seem so hard to do...backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/235ISC DHCP "class-like" if statements2023-07-17T18:49:15ZFrancis DupontISC DHCP "class-like" if statementsThis ticket is about how to convert this ISC DHCP config style:
```
subnet 10.208.0.0 netmask 255.255.128.0 {
option subnet-mask 255.255.128.0 ;
if substring (option vendor-class-identifier,0,4) = "MSFT"{
...This ticket is about how to convert this ISC DHCP config style:
```
subnet 10.208.0.0 netmask 255.255.128.0 {
option subnet-mask 255.255.128.0 ;
if substring (option vendor-class-identifier,0,4) = "MSFT"{
option routers 10.208.0.1 ;
option domain-name-servers 10.237.3.4, 10.237.3.5 ;
}
if substring (option vendor-class-identifier,0,2) = "RG"{
option classless-routes = 0F:0A:EC:0A:D0:00:01 ;
}
pool {
deny members of "MotoVIP";
range 10.208.64.1 10.208.127.254;
}
}
```
(old discussion)
The 2 if (and the "MotoVIIP" class uses an test expression which can be easily converted into a match if defining a class. The domain-name-servers option shares the same value but not the routers or the classless-routes so it is not possible to set all these parameters in class definitions.
As there is no subnet related class selector (for two reasons: classes are globally defined and classes are used to select subnets so can't depend on them) the idea should to split the subnet into class-dependent subnets. It works well for the subnet selection and parameter setting but not for the pool: range conflicts are detected when they occur inside a subnet, not yet (cf Trac 2346) between subnets but clearly do *not* work.
So IMHO it is a good place for shared networks (cf Kea 5273)... (implemented since this comment)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/236ISC DHCP and Kea shared-networks are not the same2023-07-13T18:42:08ZFrancis DupontISC DHCP and Kea shared-networks are not the sameThis ticket documents differences between ISC DHCP and Kea shared-networks:
- in ISC DHCP any subnet is a member of a shared-network, e.g. the config parser creates an anonymous one when it finds a "plain" subnet
- in ISC DHCP localizat...This ticket documents differences between ISC DHCP and Kea shared-networks:
- in ISC DHCP any subnet is a member of a shared-network, e.g. the config parser creates an anonymous one when it finds a "plain" subnet
- in ISC DHCP localization aka subnet selection in fact selects a shared-network. In Kea the selected subnet has some kind of priority over its siblings in the shared-network
- Kea shared-networks come with a performance penalty for resources to access at the shared-network level vs the selected subnet
To be reference by the MA for shared-networks with more than one subnet (with one subnet the shared-network is removed).backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/237ISC DHCP per class lease limit2023-07-13T18:35:36ZFrancis DupontISC DHCP per class lease limitQuote from ISC DHCP 1dhcpd.conf.5`
>>>
PER-CLASS LIMITS ON DYNAMIC ADDRESS ALLOCATION
You may specify a limit to the number of clients in a class that can be
assigned leases. The effect of this will be to make it difficul...Quote from ISC DHCP 1dhcpd.conf.5`
>>>
PER-CLASS LIMITS ON DYNAMIC ADDRESS ALLOCATION
You may specify a limit to the number of clients in a class that can be
assigned leases. The effect of this will be to make it difficult for a
new client in a class to get an address. Once a class with such a
limit has reached its limit, the only way a new client in that class
can get a lease is for an existing client to relinquish its lease,
either by letting it expire, or by sending a DHCPRELEASE packet.
Classes with lease limits are specified as follows:
class "limited-1" {
lease limit 4;
}
This will produce a class in which a maximum of four members may hold a
lease at one time.
>>>
Often associated with cloned classes. Requested by a customer but a priori not easy to implement.
Note that in Kea lease assignment is done before calling setReservedClientClasses.
Support tickets: [support#18293](https://support.isc.org/Ticket/Display.html?id=18293), [support#17523](https://support.isc.org/Ticket/Display.html?id=17523), [support#19968](https://support.isc.org/Ticket/Display.html?id=19968)
Being implemented in Kea.ISC DHCP Migrationhttps://gitlab.isc.org/isc-projects/kea/-/issues/238ISC DHCP server config option one-lease-per-client2023-07-13T18:45:31ZFrancis DupontISC DHCP server config option one-lease-per-client>>>
The one-lease-per-client statement
one-lease-per-client flag;
If this flag is enabled, whenever a client sends a DHCPREQUEST for a
particular lease, the server will automatically free any other leases
the client holds. This presume...>>>
The one-lease-per-client statement
one-lease-per-client flag;
If this flag is enabled, whenever a client sends a DHCPREQUEST for a
particular lease, the server will automatically free any other leases
the client holds. This presumes that when the client sends a DHCPRE-
QUEST, it has forgotten any lease not mentioned in the DHCPREQUEST -
i.e., the client has only a single network interface and it does not
remember leases it's holding on networks to which it is not currently
attached. Neither of these assumptions are guaranteed or provable,
so we urge caution in the use of this statement.
>>>
Dubious utility: put here only for documentation purpose.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/239ISC DHCP server config booting keyword2023-07-17T18:59:35ZFrancis DupontISC DHCP server config booting keyword>>>
The booting keyword
**allow booting;**
**deny booting;**
**ignore booting;**
The booting flag is used to tell dhcpd whether or not to respond to
queries from a particular client. This keyword only has meaning when
it appears in a...>>>
The booting keyword
**allow booting;**
**deny booting;**
**ignore booting;**
The booting flag is used to tell dhcpd whether or not to respond to
queries from a particular client. This keyword only has meaning when
it appears in a host declaration. By default, booting is allowed, but
if it is disabled for a particular client, then that client will not be
able to get an address from the DHCP server.
>>>
It looks like an indirect way to add a reservation without address. The only action should be to check Kea supports this case?backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/240ISC DHCP server config option get-lease-hostnames2022-11-02T15:08:44ZFrancis DupontISC DHCP server config option get-lease-hostnames>>>
The get-lease-hostnames statement
**get-lease-hostnames** flag;
The get-lease-hostnames statement is used to tell dhcpd whether or
not to look up the domain name corresponding to the IP address of
each address in the lease pool and...>>>
The get-lease-hostnames statement
**get-lease-hostnames** flag;
The get-lease-hostnames statement is used to tell dhcpd whether or
not to look up the domain name corresponding to the IP address of
each address in the lease pool and use that address for the DHCP
hostname option. If flag is true, then this lookup is done for all
addresses in the current scope. By default, or if flag is false, no
lookups are done.
>>>
The idea is to perform a reverse DNS lookup to find the corresponding hostname in place of the provisioning system or the client... For documentation purpose only.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/241ISC DHCP server config option always-broadcast2022-11-02T15:08:44ZFrancis DupontISC DHCP server config option always-broadcast>>>
The always-broadcast statement
**always-broadcast** flag;
The DHCP and BOOTP protocols both require DHCP and BOOTP clients to
set the broadcast bit in the flags field of the BOOTP message header.
Unfortunately, some DHCP and BOOTP ...>>>
The always-broadcast statement
**always-broadcast** flag;
The DHCP and BOOTP protocols both require DHCP and BOOTP clients to
set the broadcast bit in the flags field of the BOOTP message header.
Unfortunately, some DHCP and BOOTP clients do not do this, and there-
fore may not receive responses from the DHCP server. The DHCP server
can be made to always broadcast its responses to clients by setting
this flag to 'on' for the relevant scope; relevant scopes would be
inside a conditional statement, as a parameter for a class, or as a
parameter for a host declaration. To avoid creating excess broadcast
traffic on your network, we recommend that you restrict the use of
this option to as few clients as possible. For example, the
Microsoft DHCP client is known not to have this problem, as are the
OpenTransport and ISC DHCP clients.
>>>
Dubious idea in particular if there is no broken client requiring this hack. For documentation purpose only.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/242ISC DHCP server config option server-id-check2023-07-17T19:04:26ZFrancis DupontISC DHCP server config option server-id-check>>>
The server-id-check statement
**server-id-check** flag;
The server-id-check statement is used to control whether or not a
server, participating in failover, verifies that the value of the
dhcp-server-identifier option in received D...>>>
The server-id-check statement
**server-id-check** flag;
The server-id-check statement is used to control whether or not a
server, participating in failover, verifies that the value of the
dhcp-server-identifier option in received DHCP REQUESTs match the
server's id before processing the request. Server id checking is
disabled by default. Setting this flag enables id checking and
thereafter the server will only process requests that match. Note
the flag setting should be consistent between failover partners.
Unless overridden by use of the server-identifier statement, the
value the server uses as its id will be the first IP address asso-
ciated with the physical network interface on which the request
arrived.
In order to reduce runtime overhead the server only checks for a
server id option in the global and subnet scopes. Complicated
configurations may result in different server ids for this check
and when the server id for a reply packet is determined, which
would prohibit the server from responding.
The primary use for this option is when a client broadcasts a
request but requires that the response come from a specific
failover peer. An example of this would be when a client reboots
while its lease is still active - in this case both servers will
normally respond. Most of the time the client won't check the
server id and can use either of the responses. However if the
client does check the server id it may reject the response if it
came from the wrong peer. If the timing is such that the "wrong"
peer responds first most of the time the client may not get an
address for some time.
Care should be taken before enabling this option.
>>>
Dubious idea: for documentation purpose only.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/243duplicate in ISC DHCP configuration2023-07-17T19:08:12ZFrancis Dupontduplicate in ISC DHCP configurationISC DHCP support a lot of duplications in config file, e.g. from Dan's sample:
- multiple class definitions (note the ISC DHCP parser merges definitions with the same class name so the MA does the same as it shares this code)
- multiple...ISC DHCP support a lot of duplications in config file, e.g. from Dan's sample:
- multiple class definitions (note the ISC DHCP parser merges definitions with the same class name so the MA does the same as it shares this code)
- multiple option definitions
- multiple host (aka reservation) definitions sharing the same address
The last two are IMHO errors so I commented them out. In conclusion the problem is more on the ISC DHCP side and to accept less duplication in Kea is both right and should be spread.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/244ISC DHCP server hostname (vs IPv4 address) in option data2022-11-02T15:08:44ZFrancis DupontISC DHCP server hostname (vs IPv4 address) in option dataWhen it parses an IPv4 address the ISC DHCP parser accepts a DNS hostname which it resolves dynamically (i.e. when the value is used, not when it is parsed) into an address or a list of addresses.
This feature seems convenient at the fi...When it parses an IPv4 address the ISC DHCP parser accepts a DNS hostname which it resolves dynamically (i.e. when the value is used, not when it is parsed) into an address or a list of addresses.
This feature seems convenient at the first view but in fact is not, in particular for option values.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/245ISC DHCP users specify interfaces on the command line2022-11-02T15:08:42ZFrancis DupontISC DHCP users specify interfaces on the command lineThere is a real risk when converting an ISC DHCP server config to Kea to end with a config without interfaces. Note to add a wildcard interface does not really help...
As it is a difference in models there is nothing which can be done o...There is a real risk when converting an ISC DHCP server config to Kea to end with a config without interfaces. Note to add a wildcard interface does not really help...
As it is a difference in models there is nothing which can be done other to be aware.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/246ISC DHCP supports an ASCII or binary option type2022-11-02T15:08:44ZFrancis DupontISC DHCP supports an ASCII or binary option typeISC DHCP has two "string" types:
- t - ASCII text
- X - either an ASCII string or binary data. On
input, the option can be specified either as a quoted string or as
a colon-separated hex list.
Kea has string and binary, t matches strin...ISC DHCP has two "string" types:
- t - ASCII text
- X - either an ASCII string or binary data. On
input, the option can be specified either as a quoted string or as
a colon-separated hex list.
Kea has string and binary, t matches string but X can be either string or binary.
Now only one standard option has a trailing X so the implementation converts X to string (option-def) and when building data (option-data) converts full binary input to binary with csv-format to false. For trailing X add a comment saying that the last type should be changed to binary.
Unfortunately mostly for documentation purpose.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/247ISC DHCP expression2022-11-02T15:08:44ZFrancis DupontISC DHCP expressionISC DHCP supports "expressions" of 3 types: boolean, data (string) and numeric (integer).
They can be used for matching classes, set option values, etc.
Unfortunately this system is not fully consistent, for instance if you'd like to se...ISC DHCP supports "expressions" of 3 types: boolean, data (string) and numeric (integer).
They can be used for matching classes, set option values, etc.
Unfortunately this system is not fully consistent, for instance if you'd like to set an option to true:
```
option ip-forwarding = true;
```
This does not work because true is not a keyword and is parsed as a variable reference. As it is not set at runtime it will be evaluated as null so false...
If you try a constant true expression (aka tautology):
```
option ip-forwarding = 'foo' = 'foo';
```
In this case you specify a boolean expression when the system wants a data expression so refused this attempt at parsing time.
Note it is worse for integers, in:
```
option default-ip-ttl = 12;
```
the 12 is in hexadecimal so in fact is 18... If you want a decimal value you need a context where a number is expected.
Cf KB references:
https://kb.isc.org/article/AA-00334/56/Do-the-list-of-parameters-in-the-dhcp-parameter-request-list-need-to-be-in-hex.html
and about inconsistencies in output/display:
https://kb.isc.org/article/AA-01039/56/Formatting-MAC-addresses-in-dhcpd-or-why-does-binary-to-ascii-strip-leading-zeroes.htmlbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/249No shared-network pools2022-11-02T15:08:44ZFrancis DupontNo shared-network poolsIn Kea a pool must belongs to a subnet so pools at shared-network level as in ISC DHCP are no allowed.In Kea a pool must belongs to a subnet so pools at shared-network level as in ISC DHCP are no allowed.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/250enforce an option in response2023-07-17T19:16:24ZFrancis Dupontenforce an option in responseISC DHCP configs use this trick (from Dan's samples):
```
option wpad code 252 = text;
....
# Windows doesn't put WPAD on its PRL, but does consume it.
option dhcp-parameter-request-list =
concat(...ISC DHCP configs use this trick (from Dan's samples):
```
option wpad code 252 = text;
....
# Windows doesn't put WPAD on its PRL, but does consume it.
option dhcp-parameter-request-list =
concat(option dhcp-parameter-request-list, fc);
```
The dhcp-parameter-request-list (aka PRL) option in received packets is patched to add the code fc (252) so responses will include it.
This feature was ported to Kea as the **always-send** option-data flag.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/251if hook is defined in config twice then all operations are made 2 times2023-07-31T13:52:07ZMichal Nowikowskiif hook is defined in config twice then all operations are made 2 timesif in config there is:
```
{
"library": "/usr/local/lib/hooks/libdhcp_class_cmds.so"
}, {
"library": "/usr/local/lib/hooks/libdhcp_class_cmds.so"
}
```
then operations like 'class-add' are performed 2 times.
In case of 'class-add...if in config there is:
```
{
"library": "/usr/local/lib/hooks/libdhcp_class_cmds.so"
}, {
"library": "/usr/local/lib/hooks/libdhcp_class_cmds.so"
}
```
then operations like 'class-add' are performed 2 times.
In case of 'class-add' the second one fails as there is already given class present.
UPDATE: See the discussion below. This is uncommon, but valid. However, Kea should print a warning if the same hook is loaded more than once.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/255kea-netconf (and other servers/agents) creating incorrectly named pid file2022-11-02T15:08:42ZWlodzimierz Wencelkea-netconf (and other servers/agents) creating incorrectly named pid filefile name is ```kea-netconf.kea-netconf.pid``` instead of ```kea-netconf.pid```
```
wlodek@debian9-64-2:~/installed$ cat git/var/kea/kea-netconf.kea-netconf.pid
16207
wlodek@debian9-64-2:~/installed$ ps -aux | grep kea
root 16206 0...file name is ```kea-netconf.kea-netconf.pid``` instead of ```kea-netconf.pid```
```
wlodek@debian9-64-2:~/installed$ cat git/var/kea/kea-netconf.kea-netconf.pid
16207
wlodek@debian9-64-2:~/installed$ ps -aux | grep kea
root 16206 0.0 0.2 47612 3216 pts/0 S+ 07:10 0:00 sudo git/sbin/kea-netconf -c kea-netconf.conf -d
root 16207 0.0 0.5 158128 9332 pts/0 S+ 07:10 0:00 git/sbin/kea-netconf -c kea-netconf.conf -d
wlodek 16341 0.0 0.0 11112 940 pts/1 S+ 07:11 0:00 grep kea
```backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/257Improve doxygen for IfaceMgr2022-11-02T15:08:44ZThomas MarkwalderImprove doxygen for IfaceMgrThe class commentary for IfaceMgr is extremely terse and needs to be expanded.The class commentary for IfaceMgr is extremely terse and needs to be expanded.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/265ISC DHCP eui-64 based allocation2022-11-02T15:08:42ZFrancis DupontISC DHCP eui-64 based allocationQuoting dhcpd.conf.5 about the optionAL EUI-64 feature:
>>>
use-eui-64 flag;
The use-eui-64 flag, if enabled, instructs the server to con-
struct an address using the client's EUI-64 DUID (...Quoting dhcpd.conf.5 about the optionAL EUI-64 feature:
>>>
use-eui-64 flag;
The use-eui-64 flag, if enabled, instructs the server to con-
struct an address using the client's EUI-64 DUID (Type 3, HW
Type EUI-64), rather than creating an address using the dynamic
algorithm. This means that a given DUID will always generate
the same address for a given pool and further that the address
is guaranteed to be unique to that DUID. The IPv6 address will
be calculated from the EUI-64 link layer address, conforming to
RFC 2373, unless there is a host declaration for the client-id.
The range6 statement for EUI-64 must define full /64 bit ranges.
Invalid ranges will be flagged during configuration parsing as
errors. See the following example:
subnet6 fc00:e4::/64 {
use-eui-64 true;
range6 fc00:e4::/64;
}
The statement may be specified down to the pool level, allowing
a mixture of dynamic and EUI-64 based pools.
During lease file parsing, any leases which map to an EUI-64
pool, that have a non-EUI-64 DUID or for which the lease address
is not the EUI-64 address for that DUID in that pool, will be
discarded.
If a host declaration exists for the DUID, the server grants the
address (fixed-prefix6, fixed-address6) according to the host
declaration, regardless of the DUID type of the client (even for
EUI-64 DUIDs).
If a client request's an EUI-64 lease for a given network, and
the resultant address conflicts with a fixed address reserva-
tion, the server will send the client a "no addresses available"
response.
Any client with a non-conforming DUID (not type 3 or not hw type
EUI-64) that is not linked to a host declaration, which requests
an address from an EUI-64 enabled pool will be ignored and the
event will be logged.
Any client with a non-conforming DUID (not type 3 or not hw type
EUI-64) that is not linked to a host declaration, which requests
an address from an EUI-64 enabled pool will be ignored and the
event will be logged.
Pools that are configured for EUI-64 will be skipped for dynamic
allocation. If there are no pools in the shared network from
which to allocate, the client will get back a no addresses
available status.
On an EUI-64 enabled pool, any client with a DUID 3, HW Type
EUI-64, requesting a solicit/renew and including IA_NA that do
not match the EUI-64 policy, they will be treated as though they
are "outside" the subnet for a given client message:
Solicit - Server will advertise with EUI-64 ia suboption,
but with rapid
commit off
Request - Server will send "an address not on link status",
and no ia
suboption Renew/Rebind - Server will send the requested
address ia
suboption with lifetimes of 0, plus an EUI-64 ia
Whether or not EUI-64 based leases are written out to the lease
database may be controlled by persist-eui-64-leases statement.
>>>
Added to ISC DHCP as an optional feature on customer request. Can be ported to Kea.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/266ISC DHCP release on roam flag2022-11-02T15:08:42ZFrancis DupontISC DHCP release on roam flag>>>
release-on-roam flag;
When enabled and the dhcpd server detects that a DHCPv6 client
(IAID+DUID) has roamed to a new network, it will release the
pre-existing leases on t...>>>
release-on-roam flag;
When enabled and the dhcpd server detects that a DHCPv6 client
(IAID+DUID) has roamed to a new network, it will release the
pre-existing leases on the old network and emit a log statement
similiar to the following:
"Client: <id> roamed to new network, releasing lease:
<address>"
The server will carry out all of the same steps that would nor-
mally occur when a client explicitly releases a lease. When
release-on-roam is disabled (the default) the server makes such
leases unavailable until they expire or the server is restarted.
Clients that need leases in multiple networks must supply a
unique IAID in each IA. This parameter may only be specified at
the global level.
>>>
Make sense for a moving client which for some reasons does not release its address at the previous location. Can be implemented in Kea if there is an easy and fast way to get leases by IAID+DUID only.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/269client_encoding in PostgreSQL connection2022-11-02T15:08:44ZGhost Userclient_encoding in PostgreSQL connection---
name: client_encoding in PostgreSQL connection
about: Make connection's client_encoding configurable
---
**Related problem**
Sometimes it is impossible to execute lease{4,6}_{update,insert} SQLs in configuration with PostgreSQL dat...---
name: client_encoding in PostgreSQL connection
about: Make connection's client_encoding configurable
---
**Related problem**
Sometimes it is impossible to execute lease{4,6}_{update,insert} SQLs in configuration with PostgreSQL database created with default UTF8 encoding and default server's encoding set to UTF8. This is because some DHCP clients are not fully compatible with RFC1035 and are using 8-bit ASCII codes in hostname options. This, in case, results in errors like '2018-11-12 23:36:44.762 ERROR [kea-dhcp4.alloc-engine/30224] ALLOC_ENGINE_V4_ALLOC_ERROR [hwtype=1 a0:f3:c1:9d:33:d5], cid=[01:a0:f3:c1:9d:33:d5], tid=0x55527316: error during attempt to allocate an IPv4 address: Statement exec failed: for: update_lease4, status: 7sqlstate:[ 22021], reason: ERROR: invalid byte sequence for encoding "UTF8": 0xc0 0x90'
**Solution**
One possible solution is to change "client_encoding" connection parameter to "latin1" value. This eliminates problem of PostgreSQL's parsing such problematic string as UTF8 string and makes it possible to store hostname value "as is".
To make this connection parameter configurable, I've added configuration parameter "client-encoding" visible in LEASE_DATABASE, HOSTS_DATABASE and CONFIG_DATABASE scopes.
I've attached the patch against today's master branch of repo.
I can also make a pull request, if you need it
Also, I can backport this patch to 1.4.0 and 1.5.0 version, because it fixes some possible problems
[client_encoding_master.patch](/uploads/db18cf7ffa25ca65bbfaa1a825cf73ca/client_encoding_master.patch)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/272selecting listening port by -p in dhcp4 does not work2022-11-02T15:08:42ZMichal Nowikowskiselecting listening port by -p in dhcp4 does not workbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/290Arguments/parameters for hooks and commands are not checked2023-02-25T19:27:17ZFrancis DupontArguments/parameters for hooks and commands are not checkedChild of #229 for all hooks.Child of #229 for all hooks.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/301Report a hook DSO version when it is loaded2022-11-02T15:08:41ZThomas MarkwalderReport a hook DSO version when it is loadedIt would be useful, if Hook DSO versions were emitted when they are loaded, or if they were included in response to the version report command.It would be useful, if Hook DSO versions were emitted when they are loaded, or if they were included in response to the version report command.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/304poc: replace autotools with meson2022-11-02T15:08:40ZMichal Nowikowskipoc: replace autotools with mesonbacklogMichal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/311Subnet selection via client class failing when using shared network2022-11-02T15:25:01ZHreidar JoelssonSubnet selection via client class failing when using shared networkHi, I have been working on a hook for KEA which purpose is to dictate from which subnet a client should get an IP lease from. My early assumptions about KEA led me to build my code around making a selection using the subnet4_select callo...Hi, I have been working on a hook for KEA which purpose is to dictate from which subnet a client should get an IP lease from. My early assumptions about KEA led me to build my code around making a selection using the subnet4_select callout but I quickly got stuck with my work as there is a mechanism in KEA that overwrites your choice if the device has already had a lease from another subnet in the same shared network. I have been told that I shouldn't be using shared network if I like to use subnet4_select callout but I do need to use this feature as the services we provide on our network can have multiple logical IP subnets on the same physical link. So I edited my code so it is using client class instead. In pkt4_receive I'm using a policy, from an external source, which tells my code if the query should be marked with the "restricted" or the "unrestricted" class. The problem now is that KEA only allows devices marked with the "restricted" class to get a lease but logs out a "DHCP4_SUBNET_SELECTION_FAILED" log message for the other class. I can't understand why this is happening because there is no real difference between these two subnet configurations in KEA. The only thing that is different is how the physical link on the Cisco switch is configured.
I'm currently using KEA 1.4.0-P1
Physical link config:
```
interface BVI101
description GR-TEST
mtu 9216
vrf GR-TEST
ipv4 address 10.206.0.3 255.255.252.0
ipv4 address 192.168.30.3 255.255.255.0 secondary
arp timeout 300
ipv4 unreachables disable
```
Partial KEA config:
```
{
"Dhcp4": {
"client-classes": [
{
"name": "restricted"
},
{
"name": "unrestricted"
}
],
"shared-networks": [
{
"match-client-id": true,
"name": "GR-Internet-AG06",
"option-data": [ ],
"reservation-mode": "all",
"subnet4": [
{
"id": 1,
"match-client-id": true,
"next-server": "0.0.0.0",
"option-data": [
{
"always-send": false,
"code": 3,
"csv-format": true,
"data": "10.206.0.1",
"name": "routers",
"space": "dhcp4"
}
],
"pools": [
{
"option-data": [ ],
"pool": "10.206.0.4-10.206.3.254"
}
],
"rebind-timer": 300,
"renew-timer": 150,
"subnet": "10.206.0.0/22",
"valid-lifetime": 600,
"client-class": "restricted"
},
{
"id": 2,
"match-client-id": true,
"next-server": "0.0.0.0",
"option-data": [
{
"always-send": false,
"code": 3,
"csv-format": true,
"data": "192.168.30.1",
"name": "routers",
"space": "dhcp4"
}
],
"pools": [
{
"option-data": [ ],
"pool": "192.168.30.4-192.168.30.248"
}
],
"rebind-timer": 300,
"renew-timer": 150,
"subnet": "192.168.30.0/24",
"valid-lifetime": 600,
"client-class": "unrestricted"
}
]
}
]
...
}
}
```
I'm adding the class in the pkt4_receive callout like so:
```
query->addClass(ClientClass("restricted"));
// or
query->addClass(ClientClass("unrestricted"));
```
kea-dhcp4.log when query is markt with "restricted" class:
```
2018-12-04 14:05:11.220 DEBUG [kea-dhcp4.packets/1] DHCP4_PACKET_RECEIVED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: DHCPDISCOVER (type 1) received from 10.206.0.2 to 192.168.15.80 on interface ens33
2018-12-04 14:05:11.220 DEBUG [kea-dhcp4.packets/1] DHCP4_QUERY_DATA [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b, packet details: local_address=192.168.15.80:67, remote_address=10.206.0.2:67, msg_type=DHCPDISCOVER (1), transid=0x848b28b,
options:
type=050, len=004: 192.168.30.4 (ipv4-address)
type=053, len=001: 1 (uint8)
type=055, len=024: 1(uint8) 2(uint8) 3(uint8) 4(uint8) 5(uint8) 6(uint8) 7(uint8) 8(uint8) 9(uint8) 15(uint8) 17(uint8) 28(uint8) 42(uint8) 43(uint8) 44(uint8) 66(uint8) 67(uint8) 120(uint8) 121(uint8) 77(uint8) 250(uint8) 58(uint8) 59(uint8) 212(uint8)
type=060, len=027: "uDHCP HG659V100R001C279B010" (string)
type=061, len=007: 01:50:a7:2b:ea:cc:e3
type=077, len=002: 01:68
type=082, len=018:,
options:
type=001, len=006: 00:04:00:65:06:0b
type=002, len=008: 00:06:cc:ef:48:1e:a0:40
type=116, len=001: 1 (uint8)
2018-12-04 14:05:11.220 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_BEGIN begin all callouts for hook pkt4_receive
2018-12-04 14:05:11.226 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook pkt4_receive that has address 0x7f8a31587723 (callout duration: 5.385 ms)
2018-12-04 14:05:11.226 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_COMPLETE completed callouts for hook pkt4_receive (total callouts duration: 5.385 ms)
2018-12-04 14:05:11.226 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.206.0.0/22 for packet received by matching address 10.206.0.2
2018-12-04 14:05:11.226 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_BEGIN begin all callouts for hook subnet4_select
2018-12-04 14:05:11.226 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook subnet4_select that has address 0x7f8a31588fbd (callout duration: 0.335 ms)
2018-12-04 14:05:11.227 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_COMPLETE completed callouts for hook subnet4_select (total callouts duration: 0.335 ms)
2018-12-04 14:05:11.227 DEBUG [kea-dhcp4.packets/1] DHCP4_SUBNET_SELECTED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: the subnet with ID 9060101 was selected for client assignments
2018-12-04 14:05:11.227 DEBUG [kea-dhcp4.packets/1] DHCP4_SUBNET_DATA [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: the selected subnet details: 10.206.0.0/22
2018-12-04 14:05:11.227 DEBUG [kea-dhcp4.dhcp4/1] DHCP4_CLASS_ASSIGNED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: client packet has been assigned to the following class(es): UNKNOWN
2018-12-04 14:05:11.227 DEBUG [kea-dhcp4.dhcp4/1] DHCP4_CLASS_ASSIGNED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: client packet has been assigned to the following class(es): ALL, VENDOR_CLASS_uDHCP HG659V100R001C279B010, restricted, UNKNOWN
2018-12-04 14:05:11.227 DEBUG [kea-dhcp4.ddns/1] DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: processing client's Hostname option
2018-12-04 14:05:11.227 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_MEMFILE_GET_CLIENTID obtaining IPv4 leases for client ID 01:50:a7:2b:ea:cc:e3
2018-12-04 14:05:11.228 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_MEMFILE_GET_HWADDR obtaining IPv4 leases for hardware address hwtype=1 50:a7:2b:ea:cc:e3
2018-12-04 14:05:11.228 DEBUG [kea-dhcp4.alloc-engine/1] ALLOC_ENGINE_V4_OFFER_NEW_LEASE allocation engine will try to offer new lease to the client [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b
2018-12-04 14:05:11.228 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.206.0.5
2018-12-04 14:05:11.228 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_BEGIN begin all callouts for hook lease4_select
2018-12-04 14:05:11.228 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook lease4_select that has address 0x7f8a3158939d (callout duration: 0.387 ms)
2018-12-04 14:05:11.229 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_COMPLETE completed callouts for hook lease4_select (total callouts duration: 0.387 ms)
2018-12-04 14:05:11.229 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.206.0.5
2018-12-04 14:05:11.229 INFO [kea-dhcp4.leases/1] DHCP4_LEASE_ADVERT [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: lease 10.206.0.5 will be advertised
2018-12-04 14:05:11.229 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_BEGIN begin all callouts for hook pkt4_send
2018-12-04 14:05:11.229 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook pkt4_send that has address 0x7f8a31588987 (callout duration: 0.346 ms)
2018-12-04 14:05:11.230 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_COMPLETE completed callouts for hook pkt4_send (total callouts duration: 0.346 ms)
2018-12-04 14:05:11.230 DEBUG [kea-dhcp4.options/1] DHCP4_PACKET_PACK [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: preparing on-wire format of the packet to be sent
2018-12-04 14:05:11.230 DEBUG [kea-dhcp4.packets/1] DHCP4_PACKET_SEND [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: trying to send packet DHCPOFFER (type 2) from 192.168.15.80:67 to 10.206.0.2:67 on interface ens33
2018-12-04 14:05:11.230 DEBUG [kea-dhcp4.packets/1] DHCP4_RESPONSE_DATA [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: responding with packet DHCPOFFER (type 2), packet details: local_address=192.168.15.80:67, remote_address=10.206.0.2:67, msg_type=DHCPOFFER (2), transid=0x848b28b,
options:
type=001, len=004: 4294966272 (uint32)
type=003, len=004: 10.206.0.1
type=006, len=008: 192.168.0.1 192.168.0.33
type=015, len=013: "gagnaveita.is" (string)
type=051, len=004: 60 (uint32)
type=053, len=001: 2 (uint8)
type=054, len=004: 192.168.15.80
type=061, len=007: 01:50:a7:2b:ea:cc:e3
type=082, len=018:,
options:
type=001, len=006: 00:04:00:65:06:0b
type=002, len=008: 00:06:cc:ef:48:1e:a0:40
2018-12-04 14:05:11.231 DEBUG [kea-dhcp4.packets/1] DHCP4_BUFFER_RECEIVED received buffer from 10.206.0.2:67 to 192.168.15.80:67 over interface ens33
2018-12-04 14:05:11.231 DEBUG [kea-dhcp4.options/1] DHCP4_BUFFER_UNPACK parsing buffer received from 10.206.0.2 to 192.168.15.80 over interface ens33
2018-12-04 14:05:11.231 DEBUG [kea-dhcp4.packets/1] DHCP4_PACKET_RECEIVED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: DHCPREQUEST (type 3) received from 10.206.0.2 to 192.168.15.80 on interface ens33
2018-12-04 14:05:11.231 DEBUG [kea-dhcp4.packets/1] DHCP4_QUERY_DATA [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b, packet details: local_address=192.168.15.80:67, remote_address=10.206.0.2:67, msg_type=DHCPREQUEST (3), transid=0x848b28b,
options:
type=050, len=004: 10.206.0.4 (ipv4-address)
type=053, len=001: 3 (uint8)
type=054, len=004: 192.168.15.80 (ipv4-address)
type=055, len=024: 1(uint8) 2(uint8) 3(uint8) 4(uint8) 5(uint8) 6(uint8) 7(uint8) 8(uint8) 9(uint8) 15(uint8) 17(uint8) 28(uint8) 42(uint8) 43(uint8) 44(uint8) 66(uint8) 67(uint8) 120(uint8) 121(uint8) 77(uint8) 250(uint8) 58(uint8) 59(uint8) 212(uint8)
type=060, len=027: "uDHCP HG659V100R001C279B010" (string)
type=061, len=007: 01:50:a7:2b:ea:cc:e3
type=082, len=018:,
options:
type=001, len=006: 00:04:00:65:06:0b
type=002, len=008: 00:06:cc:ef:48:1e:a0:40
2018-12-04 14:05:11.231 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_BEGIN begin all callouts for hook pkt4_receive
2018-12-04 14:05:11.236 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook pkt4_receive that has address 0x7f8a31587723 (callout duration: 4.628 ms)
2018-12-04 14:05:11.236 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_COMPLETE completed callouts for hook pkt4_receive (total callouts duration: 4.628 ms)
2018-12-04 14:05:11.236 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.206.0.0/22 for packet received by matching address 10.206.0.2
2018-12-04 14:05:11.236 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_BEGIN begin all callouts for hook subnet4_select
2018-12-04 14:05:11.237 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook subnet4_select that has address 0x7f8a31588fbd (callout duration: 0.307 ms)
2018-12-04 14:05:11.237 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_COMPLETE completed callouts for hook subnet4_select (total callouts duration: 0.307 ms)
2018-12-04 14:05:11.237 DEBUG [kea-dhcp4.packets/1] DHCP4_SUBNET_SELECTED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: the subnet with ID 9060101 was selected for client assignments
2018-12-04 14:05:11.237 DEBUG [kea-dhcp4.packets/1] DHCP4_SUBNET_DATA [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: the selected subnet details: 10.206.0.0/22
2018-12-04 14:05:11.237 DEBUG [kea-dhcp4.dhcp4/1] DHCP4_CLASS_ASSIGNED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: client packet has been assigned to the following class(es): UNKNOWN
2018-12-04 14:05:11.237 DEBUG [kea-dhcp4.dhcp4/1] DHCP4_CLASS_ASSIGNED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: client packet has been assigned to the following class(es): ALL, VENDOR_CLASS_uDHCP HG659V100R001C279B010, restricted, UNKNOWN
2018-12-04 14:05:11.237 DEBUG [kea-dhcp4.ddns/1] DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: processing client's Hostname option
2018-12-04 14:05:11.238 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_MEMFILE_GET_CLIENTID obtaining IPv4 leases for client ID 01:50:a7:2b:ea:cc:e3
2018-12-04 14:05:11.238 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_MEMFILE_GET_HWADDR obtaining IPv4 leases for hardware address hwtype=1 50:a7:2b:ea:cc:e3
2018-12-04 14:05:11.238 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.206.0.4
2018-12-04 14:05:11.238 DEBUG [kea-dhcp4.alloc-engine/1] ALLOC_ENGINE_V4_REQUEST_ALLOC_REQUESTED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: trying to allocate requested address 10.206.0.4
2018-12-04 14:05:11.238 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.206.0.4
2018-12-04 14:05:11.238 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_BEGIN begin all callouts for hook lease4_select
2018-12-04 14:05:11.239 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook lease4_select that has address 0x7f8a3158939d (callout duration: 0.441 ms)
2018-12-04 14:05:11.239 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_COMPLETE completed callouts for hook lease4_select (total callouts duration: 0.441 ms)
2018-12-04 14:05:11.239 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_MEMFILE_ADD_ADDR4 adding IPv4 lease with address 10.206.0.4
2018-12-04 14:05:11.239 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.206.0.4
2018-12-04 14:05:11.239 INFO [kea-dhcp4.leases/1] DHCP4_LEASE_ALLOC [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: lease 10.206.0.4 has been allocated
2018-12-04 14:05:11.239 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_BEGIN begin all callouts for hook leases4_committed
2018-12-04 14:05:11.255 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook leases4_committed that has address 0x7f8a3158a0a3 (callout duration: 15.466 ms)
2018-12-04 14:05:11.255 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_COMPLETE completed callouts for hook leases4_committed (total callouts duration: 15.466 ms)
2018-12-04 14:05:11.255 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_BEGIN begin all callouts for hook pkt4_send
2018-12-04 14:05:11.255 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook pkt4_send that has address 0x7f8a31588987 (callout duration: 0.298 ms)
2018-12-04 14:05:11.256 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_COMPLETE completed callouts for hook pkt4_send (total callouts duration: 0.298 ms)
2018-12-04 14:05:11.257 DEBUG [kea-dhcp4.options/1] DHCP4_PACKET_PACK [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: preparing on-wire format of the packet to be sent
2018-12-04 14:05:11.257 DEBUG [kea-dhcp4.packets/1] DHCP4_PACKET_SEND [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: trying to send packet DHCPACK (type 5) from 192.168.15.80:67 to 10.206.0.2:67 on interface ens33
2018-12-04 14:05:11.257 DEBUG [kea-dhcp4.packets/1] DHCP4_RESPONSE_DATA [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x848b28b: responding with packet DHCPACK (type 5), packet details: local_address=192.168.15.80:67, remote_address=10.206.0.2:67, msg_type=DHCPACK (5), transid=0x848b28b,
options:
type=001, len=004: 4294966272 (uint32)
type=003, len=004: 10.206.0.1
type=006, len=008: 192.168.0.1 192.168.0.33
type=015, len=013: "gagnaveita.is" (string)
type=051, len=004: 60 (uint32)
type=053, len=001: 5 (uint8)
type=054, len=004: 192.168.15.80
type=061, len=007: 01:50:a7:2b:ea:cc:e3
type=082, len=018:,
options:
type=001, len=006: 00:04:00:65:06:0b
type=002, len=008: 00:06:cc:ef:48:1e:a0:40
```
kea-dhcp4.log when query is markt with "unrestricted" class:
```
2018-12-04 14:11:27.327 DEBUG [kea-dhcp4.packets/1] DHCP4_BUFFER_RECEIVED received buffer from 10.206.0.3:67 to 192.168.15.80:67 over interface ens33
2018-12-04 14:11:27.327 DEBUG [kea-dhcp4.options/1] DHCP4_BUFFER_UNPACK parsing buffer received from 10.206.0.3 to 192.168.15.80 over interface ens33
2018-12-04 14:11:27.328 DEBUG [kea-dhcp4.packets/1] DHCP4_PACKET_RECEIVED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x5b0501ef: DHCPDISCOVER (type 1) received from 10.206.0.3 to 192.168.15.80 on interface ens33
2018-12-04 14:11:27.329 DEBUG [kea-dhcp4.packets/1] DHCP4_QUERY_DATA [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x5b0501ef, packet details: local_address=192.168.15.80:67, remote_address=10.206.0.3:67, msg_type=DHCPDISCOVER (1), transid=0x5b0501ef,
options:
type=050, len=004: 192.168.30.4 (ipv4-address)
type=053, len=001: 1 (uint8)
type=055, len=024: 1(uint8) 2(uint8) 3(uint8) 4(uint8) 5(uint8) 6(uint8) 7(uint8) 8(uint8) 9(uint8) 15(uint8) 17(uint8) 28(uint8) 42(uint8) 43(uint8) 44(uint8) 66(uint8) 67(uint8) 120(uint8) 121(uint8) 77(uint8) 250(uint8) 58(uint8) 59(uint8) 212(uint8)
type=060, len=027: "uDHCP HG659V100R001C279B010" (string)
type=061, len=007: 01:50:a7:2b:ea:cc:e3
type=077, len=002: 01:68
type=082, len=018:,
options:
type=001, len=006: 00:04:00:65:06:0b
type=002, len=008: 00:06:cc:ef:48:1e:a0:40
type=116, len=001: 1 (uint8)
2018-12-04 14:11:27.329 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_BEGIN begin all callouts for hook pkt4_receive
2018-12-04 14:11:27.349 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook pkt4_receive that has address 0x7ff7b76a8723 (callout duration: 20.561 ms)
2018-12-04 14:11:27.350 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_COMPLETE completed callouts for hook pkt4_receive (total callouts duration: 20.561 ms)
2018-12-04 14:11:27.350 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_BEGIN begin all callouts for hook subnet4_select
2018-12-04 14:11:27.351 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUT_CALLED hooks library with index 1 has called a callout on hook subnet4_select that has address 0x7ff7b76a9fbd (callout duration: 1.099 ms)
2018-12-04 14:11:27.351 DEBUG [kea-dhcp4.callouts/1] HOOKS_CALLOUTS_COMPLETE completed callouts for hook subnet4_select (total callouts duration: 1.099 ms)
2018-12-04 14:11:27.352 DEBUG [kea-dhcp4.packets/1] DHCP4_SUBNET_SELECTION_FAILED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x5b0501ef: failed to select subnet for the client
2018-12-04 14:11:27.352 DEBUG [kea-dhcp4.dhcp4/1] DHCP4_CLASS_ASSIGNED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x5b0501ef: client packet has been assigned to the following class(es): UNKNOWN
2018-12-04 14:11:27.353 DEBUG [kea-dhcp4.dhcp4/1] DHCP4_CLASS_ASSIGNED [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x5b0501ef: client packet has been assigned to the following class(es): ALL, VENDOR_CLASS_uDHCP HG659V100R001C279B010, unrestricted, UNKNOWN
2018-12-04 14:11:27.353 DEBUG [kea-dhcp4.ddns/1] DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x5b0501ef: processing client's Hostname option
2018-12-04 14:11:27.353 ERROR [kea-dhcp4.bad-packets/1] DHCP4_PACKET_NAK_0001 [hwtype=1 50:a7:2b:ea:cc:e3], cid=[01:50:a7:2b:ea:cc:e3], tid=0x5b0501ef: failed to select a subnet for incoming packet, src 10.206.0.3, type DHCPDISCOVER
```
I hope someone can shed light on this issue as it seems that I'm getting out of options using KEA as a soulution for my problem.
best regards, Hreidar.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/316Update DHCPv6 server to fully support RFC7550 (obsoleted by RFC 8415)2022-11-02T15:08:41ZMarcin SiodelskiUpdate DHCPv6 server to fully support RFC7550 (obsoleted by RFC 8415)While addressing https://gitlab.isc.org/isc-projects/kea/issues/288 I realized that DHCPv6 server logic follows rather simplified approach when it comes to Renew/Rebind processing. The following is the todo comment inserted as part of th...While addressing https://gitlab.isc.org/isc-projects/kea/issues/288 I realized that DHCPv6 server logic follows rather simplified approach when it comes to Renew/Rebind processing. The following is the todo comment inserted as part of the #288:
We should consider unification of the server behavior for address assignment and prefix delegation with respect to Rebind message processing. The RFC 8415, section 18.3.5 doesn't really differentiate between IA_NA and IA_PD in how they should be processed by the server. The intention of the spec is as follows:
- If the server finds a lease but addresses and/or prefixes are not
appropriate anymore, it sends them with zero lifetimes.
- If the server doesn't find a lease the server checks if the addresses
and/or prefixes the client sends are appropriate and sends them back
with zero lifetimes if they aren't.
- The server may choose to not respond at all, if it cannot determine
whether the addresses and/or prefixes are appropriate and it doesn't
allocate any other addresses and/or prefixes.
- If the server cannot find the leases included in the Rebind, the
server may either allocate the leases or simply return NoBinding.
The extendIA_PD function drops the Rebind message if it cannot find the client entry (as a result of not finding a subnet for the client), the extendIA_NA function sends NoBinding status code in that case. Perhaps we should introduce an "Authoritative" configuration flag which, if enabled, would cause the server to always respond, either indicating that the address/prefix is inappropriate (with zero lifetimes) or that there is no binding (NoBinding status code) for both addresses and prefixes. When the "Authoritative" flag is disabled the server would drop the Rebind for which there is neither subnet selected nor client entry found (as it could be handled by another DHCP server). If nothing else we could consider unifying the behavior of extendIA_NA and extendIA_PD with respect to Rebind processing.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/322Time of issue of ip address (permanent IP assignment)2022-11-02T15:08:43ZVicky Riskvicky@isc.orgTime of issue of ip address (permanent IP assignment)<Originally reported on Github as issue \# 90 by PBA4 on July 2, 2018.>
It is not possible to issue a permanent ip address to the user. In the RFC, it is said that the leases-time can be set to -1, thereby reserving the IP address of th...<Originally reported on Github as issue \# 90 by PBA4 on July 2, 2018.>
It is not possible to issue a permanent ip address to the user. In the RFC, it is said that the leases-time can be set to -1, thereby reserving the IP address of the user by the user, but this does not work and kea talks about the error. I store ip addresses in the mysql. How can I make the addresses reserved after the issue?backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/323Warning message "the interface x is down" is incomplete. (GH#95)2023-03-03T08:52:38ZVicky Riskvicky@isc.orgWarning message "the interface x is down" is incomplete. (GH#95)<This was first reported as Github issue #95, by brubbel, on July 19, 2018>
(Note: This was tested on Kea 1.1.0, but I see that this issue is still present in the latest 1.4.0 version.)
At startup, Kea may produce the following warning ...<This was first reported as Github issue #95, by brubbel, on July 19, 2018>
(Note: This was tested on Kea 1.1.0, but I see that this issue is still present in the latest 1.4.0 version.)
At startup, Kea may produce the following warning message:
DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface x is down or has no usable IPv4 addresses configured
I checked interface x of course, but it was [UP] and had an IPv4 address assigned.
It turns out (from reading the source) that Kea expects interface x also being in the [RUNNING] state.
I suggest to change the warning message into "has no usable IPv4 address or is missing flags [UP] and/or [RUNNING]."
As a related question: why does isc-dhcp allow and kea-dhcp does not allow starting a server on an interface without the IFF_RUNNING flag set?
In any case, kea 1.1.0 does not work when the interface is not [RUNNING] when it was started, even when it becomes [RUNNING] afterwards. When the state goes from running->not running->running: all ok.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/325Implement RDM mechanism (Github#85)2022-11-02T15:08:41ZVicky Riskvicky@isc.orgImplement RDM mechanism (Github#85)<Originally opened by Tomek Mrugalski on Github as issue #85>
The RFC8415 defines Replay Detection Mechanism. We need to have this implemented in Kea.
We'll go with the simplest model possible. The RDM will be a global 64bits counter (...<Originally opened by Tomek Mrugalski on Github as issue #85>
The RFC8415 defines Replay Detection Mechanism. We need to have this implemented in Kea.
We'll go with the simplest model possible. The RDM will be a global 64bits counter (the same value for all subnets and all clients. This value must be retained between server restarts.backlog2020-02-29https://gitlab.isc.org/isc-projects/kea/-/issues/328Using a model which is installed but unknown.2022-11-02T15:08:42ZFrancis DupontUsing a model which is installed but unknown.This issue is about the third case in this method called with the model for a managed server entry:
```
bool
NetconfAgent::checkModule(const string& module_name) const {
if (module_name.empty()) {
return (true);
}
auto modul...This issue is about the third case in this method called with the model for a managed server entry:
```
bool
NetconfAgent::checkModule(const string& module_name) const {
if (module_name.empty()) {
return (true);
}
auto module = modules_.find(module_name);
if (module == modules_.end()) {
LOG_ERROR(netconf_logger, NETCONF_MODULE_MISSING_ERR)
.arg(module_name);
return (false);
}
auto modrev = YANG_REVISIONS.find(module_name);
if (modrev == YANG_REVISIONS.end()) {
// Can't check revision?!
// It can happen only with a module which is not in
// YANG_REVISIONS but installed so likely on purpose.
return (true);
}
if (modrev->second != module->second) {
LOG_ERROR(netconf_logger, NETCONF_MODULE_REVISION_ERR)
.arg(module_name)
.arg(modrev->second)
.arg(module->second);
return (false);
}
return (true);
}
```
Tomek requested a warning, I added the comment after ```Can't check revision?!``` and answered:
No warning. In fact it means the module is installed but is not in yang revisions so either it is on purpose and the check was simply disabled, or it is a real error and the translator will raise a better error.
I am creating an issue in the case a better option could be found.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/329Add a verbose flag to developer YANG module check scripts.2022-11-02T15:08:43ZFrancis DupontAdd a verbose flag to developer YANG module check scripts.Add a verbose flag to `src/share/yang/modules/utils/check-{hashes, revisions}.sh`.
cf #204Add a verbose flag to `src/share/yang/modules/utils/check-{hashes, revisions}.sh`.
cf #204backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/330keactrl should better handle disabled services2022-11-02T15:24:12ZTomek Mrugalskikeactrl should better handle disabled servicesThis is a follow-up coming form #186 review.
There's a section in keactrl.conf that has flags for each daemon:
```
# Start DHCPv4 server?
dhcp4=yes
# Start DHCPv6 server?
dhcp6=yes
# Start DHCP DDNS server?
dhcp_ddns=no
# Start Contr...This is a follow-up coming form #186 review.
There's a section in keactrl.conf that has flags for each daemon:
```
# Start DHCPv4 server?
dhcp4=yes
# Start DHCPv6 server?
dhcp6=yes
# Start DHCP DDNS server?
dhcp_ddns=no
# Start Control Agent?
ctrl_agent=yes
# Start Netconf?
netconf=no
```
When a service is set to false, there's no way to start it using keactrl. For example:
```
root@billabong:/opt186# sbin/keactrl start -s netconf
root@billabong:/opt186# sbin/keactrl stop -s netconf
INFO/keactrl: kea-netconf isn't running.
```
Note the start command. It quits silently without starting the netconf service.
IMHO the flags should govern whether the service is started when ALL services are started (keactrl start). There should always be a way to start the service manually.
If you strongly disagree with this, at the very least keactrl should print out why it didn't even try to start the service.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/331kea-netconf should print out control channel being opened2022-11-02T15:08:42ZTomek Mrugalskikea-netconf should print out control channel being openedWhile reviewing !163 I've tried to start kea-netconf without dhcp4 or dhcp6 running. The error message I got was confusing. It was clear that some file is missing, but it was never said which file:
```
2018-12-10 19:40:24.202 INFO [kea...While reviewing !163 I've tried to start kea-netconf without dhcp4 or dhcp6 running. The error message I got was confusing. It was clear that some file is missing, but it was never said which file:
```
2018-12-10 19:40:24.202 INFO [kea-netconf.netconf/29469] NETCONF_STARTED Netconf (version 1.5.0-beta2-git) started
2018-12-10 19:40:24.203 INFO [kea-netconf.netconf/29469] NETCONF_GET_CONFIG_STARTED getting configuration from dhcp4 server
2018-12-10 19:40:24.203 ERROR [kea-netconf.netconf/29469] NETCONF_GET_CONFIG_FAILED getting configuration from dhcp4 server failed: config-get command failed with communication error: No such file or directory
2018-12-10 19:40:24.203 INFO [kea-netconf.netconf/29469] NETCONF_GET_CONFIG_STARTED getting configuration from dhcp6 server
2018-12-10 19:40:24.203 ERROR [kea-netconf.netconf/29469] NETCONF_GET_CONFIG_FAILED getting configuration from dhcp6 server failed: config-get command failed with communication error: No such file or directory
2018-12-10 19:40:24.203 INFO [kea-netconf.netconf/29469] NETCONF_SET_CONFIG_STARTED setting configuration to dhcp4 server
2018-12-10 19:40:24.217 DEBUG [kea-netconf.netconf/29469] NETCONF_SET_CONFIG set configuration to dhcp4 server: {
"Dhcp4": { }
}
2018-12-10 19:40:24.217 ERROR [kea-netconf.netconf/29469] NETCONF_SET_CONFIG_FAILED setting configuration to dhcp4 server failed: config-set command failed with communication error: No such file or directory
2018-12-10 19:40:24.217 INFO [kea-netconf.netconf/29469] NETCONF_SUBSCRIBE_CONFIG subscribing configuration changes for dhcp4 server with kea-dhcp4-server module
2018-12-10 19:40:24.229 INFO [kea-netconf.netconf/29469] NETCONF_SET_CONFIG_STARTED setting configuration to dhcp6 server
2018-12-10 19:40:24.243 DEBUG [kea-netconf.netconf/29469] NETCONF_SET_CONFIG set configuration to dhcp6 server: {
"Dhcp6": { }
}
2018-12-10 19:40:24.243 ERROR [kea-netconf.netconf/29469] NETCONF_SET_CONFIG_FAILED setting configuration to dhcp6 server failed: config-set command failed with communication error: No such file or directory
```
IMHO the netconf daemon should print out unix socket path/http URL on info level. This would be on par with what dhcp4/6 does, it prints the unix socket path when opening control channel:
```
COMMAND_ACCEPTOR_START Starting to accept connections via unix domain socket bound to /tmp/kea-dhcp4-ctrl.sock
```backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/332strip down version of unpack2022-11-02T15:08:42ZFrancis Dupontstrip down version of unpackIn some cases we need only the message type and not to decode all options, for instance for advanced receiver queueing or for perfdhcp.
So the idea is to have a fast clone of unpack which digs into a received query to get the message ty...In some cases we need only the message type and not to decode all options, for instance for advanced receiver queueing or for perfdhcp.
So the idea is to have a fast clone of unpack which digs into a received query to get the message type and perhaps for DHCPv6 the rapid commit option.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/333parser libraries for servers (for netconf)2022-11-02T15:24:02ZFrancis Dupontparser libraries for servers (for netconf)Build in DHCPv4 and DHCPv6 (at least) Makefiles a convenience library with the parser so a tool which just needs to parse a DHCPv4 (or DHCPv6) configuration including comments and includes can link with this library and calls a parse* me...Build in DHCPv4 and DHCPv6 (at least) Makefiles a convenience library with the parser so a tool which just needs to parse a DHCPv4 (or DHCPv6) configuration including comments and includes can link with this library and calls a parse* method to get a syntactic correct Element.
I have an use for this in netconf to port and improve a to-yang tool which translates such config to YANG and loads it to sysrepo datastore. IMHO config backend should use this too.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/334Revamped the require-client-classes idea.2022-11-02T15:08:42ZFrancis DupontRevamped the require-client-classes idea.Obviously the require-client-classes feature lacks adoption. My idea is to replace it with a simpler feature which is almost as powerful but more uniform.
Currently we have for host reservations "client-classes" which adds each class of...Obviously the require-client-classes feature lacks adoption. My idea is to replace it with a simpler feature which is almost as powerful but more uniform.
Currently we have for host reservations "client-classes" which adds each class of the list to queries matching the reservation. I propose to rename it to "add-client-classes" to avoid confusion with guards and to apply it to scopes where require-client-classes where defined.
The "only-if-required" flag must be changed too: perhaps the original idea of a late evaluation flag should be considered again?backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/335Removed the simplified notation (doc cleanup)2022-11-02T15:08:42ZFrancis DupontRemoved the simplified notation (doc cleanup)At the end of the config.xml file. Looks like an old BIND 10 stuff.At the end of the config.xml file. Looks like an old BIND 10 stuff.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/336Perfdhcp: Implement burst-size2022-11-02T15:22:52ZTomek MrugalskiPerfdhcp: Implement burst-sizeBefore #283 there was an aggresivity parameter that controlled how many packets are sent at once. After #283 changes it was no longer used.
There may be scenarios where bursty traffic is useful. We should add a parameter called burst-size.Before #283 there was an aggresivity parameter that controlled how many packets are sent at once. After #283 changes it was no longer used.
There may be scenarios where bursty traffic is useful. We should add a parameter called burst-size.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/348Small experiment improving congestion control locks2023-03-15T11:43:45ZFrancis DupontSmall experiment improving congestion control locksI propose a small experiment to see if this trivial (and recognized as correct) change makes a noticeable difference. I leave to QA the win threshold which requires inclusion in 1.5 or 1.6.
The change is here and in the attachment too.
...I propose a small experiment to see if this trivial (and recognized as correct) change makes a noticeable difference. I leave to QA the win threshold which requires inclusion in 1.5 or 1.6.
The change is here and in the attachment too.
```
diff --git a/src/lib/dhcp/packet_queue_ring.h b/src/lib/dhcp/packet_queue_ring.h
index 315e2a0375..bcaa496747 100644
--- a/src/lib/dhcp/packet_queue_ring.h
+++ b/src/lib/dhcp/packet_queue_ring.h
@@ -123,12 +123,12 @@ public:
/// @return A pointer to dequeued packet, or an empty pointer
/// if the queue is empty.
virtual PacketTypePtr popPacket(const QueueEnd& from = QueueEnd::FRONT) {
- isc::util::thread::Mutex::Locker lock(mutex_);
PacketTypePtr packet;
if (queue_.empty()) {
return (packet);
}
+ isc::util::thread::Mutex::Locker lock(mutex_);
if (from == QueueEnd::FRONT) {
packet = queue_.front();
queue_.pop_front();
```
[better-lock.diff](/uploads/0f3a20502c39e13e033d0818fd20b25c/better-lock.diff)outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/349Restricting timestamps in Kea backends to max supported values2022-11-02T15:08:42ZMarcin SiodelskiRestricting timestamps in Kea backends to max supported valuesThe following chapter of the Kea User's Guide `Limitations Related to the use of SQL Databases` claims that we restricted timestamps to 32 bit value past the epoch. I don't see us restricting this anywhere. Maybe we should revise which d...The following chapter of the Kea User's Guide `Limitations Related to the use of SQL Databases` claims that we restricted timestamps to 32 bit value past the epoch. I don't see us restricting this anywhere. Maybe we should revise which databases have which limitation and explicitly report an error upon an attempt to add higher timestamps.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/350Ability to send DHCPv6 Reconfigure message2023-09-21T10:10:36ZTomek MrugalskiAbility to send DHCPv6 Reconfigure messageThis is a migration of [issue #84](https://github.com/isc-projects/kea/issues/84) from github.
The goal of this ticket is to implement capability to send reconfigure message. This at the very least requires implementing a "reconfig-send...This is a migration of [issue #84](https://github.com/isc-projects/kea/issues/84) from github.
The goal of this ticket is to implement capability to send reconfigure message. This at the very least requires implementing a "reconfig-send" command, and the actual ability to retrieve lease from db and then send reconfigure message with authentication option.
Here's [one request for it](https://lists.isc.org/pipermail/kea-users/2020-October/002910.html).backlog2020-02-29https://gitlab.isc.org/isc-projects/kea/-/issues/355Postgres unit-tests fail in weird way if postgres timezone is set incorrectly2022-11-02T15:08:42ZTomek MrugalskiPostgres unit-tests fail in weird way if postgres timezone is set incorrectlyI live in Poland (CET, GMT+1), but I was visiting London (GMT) and installed Postgres. It had this in postgresql.conf:
```
datestyle = 'iso, mdy'
timezone = 'GB'
```
However, my system timezone (as set in mac os control panel) was CET....I live in Poland (CET, GMT+1), but I was visiting London (GMT) and installed Postgres. It had this in postgresql.conf:
```
datestyle = 'iso, mdy'
timezone = 'GB'
```
However, my system timezone (as set in mac os control panel) was CET.
This caused weird error in unit-tests:
```
[ RUN ] PgSqlBasicsTest.timeStampTest
NOTICE: table "basics" does not exist, skipping
pgsql_exchange_unittest.cc:896: Failure
Expected: fetched_time
Which is: 1544791527
To be equal to: times[row]
Which is: 1544787927
row: 0
pgsql_exchange_unittest.cc:896: Failure
Expected: fetched_time
Which is: 2147487247
To be equal to: times[row]
Which is: 2147483647
row: 1
pgsql_exchange_unittest.cc:896: Failure
Expected: fetched_time
Which is: 4294970895
To be equal to: times[row]
Which is: 4294967295
row: 2
pgsql_exchange_unittest.cc:896: Failure
Expected: fetched_time
Which is: 1544877927
To be equal to: times[row]
Which is: 1544874327
row: 3
[ FAILED ] PgSqlBasicsTest.timeStampTest (40 ms)
```.
Yes, this was a weird configuration, but Kea should have done both conversions using the same timezone.
At the very least we should print a warning about checking timezone configuration if the values are off by multiplicity of 3600 seconds.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/358Rename flex_id unit-tests (CalloutTest => FlexIdTest)2022-11-02T15:08:41ZTomek MrugalskiRename flex_id unit-tests (CalloutTest => FlexIdTest)Just a minor readability improvement. We should rename the tests name to better reflect that it's testing FlexID.Just a minor readability improvement. We should rename the tests name to better reflect that it's testing FlexID.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/382Propagate lease updates between HA peers2022-11-02T15:08:41ZMarcin SiodelskiPropagate lease updates between HA peersHigh Availability setup includes at least two servers paired to provide reliable service. We have the lease_cmds hooks library which is utilized by the HA hooks library to send lease updates between the peers. Sometimes, though, an admin...High Availability setup includes at least two servers paired to provide reliable service. We have the lease_cmds hooks library which is utilized by the HA hooks library to send lease updates between the peers. Sometimes, though, an administrator may want to update lease information via the control channel, e.g. remove stale lease. Currently, he'd need to send appropriate command to all HA peers that (potentially) share the lease information. It is useful to be able to send the command to only one of the HA peers and let it propagate it down to other servers. For that, the HA peer would need to somehow identify that the command has been sent by the administrator rather than the HA peer, otherwise it would trigger circular updates.
The details how to implement it are TBD.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/383Add CA support to netconf.2022-11-02T15:22:00ZFrancis DupontAdd CA support to netconf.Finish the model and write translators.
More urgent that the similar ticket for D2 because it gives for free a test for kea-netconf over HTTP.Finish the model and write translators.
More urgent that the similar ticket for D2 because it gives for free a test for kea-netconf over HTTP.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/384Add D2 support to netconf.2022-11-02T15:22:26ZFrancis DupontAdd D2 support to netconf.Finish the model and write translators.Finish the model and write translators.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/390doubled log message on debug level during HA sync2022-11-02T15:08:44ZWlodzimierz Wenceldoubled log message on debug level during HA syncduring HA sync testing I found little quirk `DHCPSRV_MEMFILE_GET_ADDR6` message is logged twice:
```
2019-01-07 06:44:39.966 DEBUG [kea-dhcp6.dhcpsrv/10887] DHCPSRV_MEMFILE_GET_ADDR6 obtaining IPv6 lease for address 2001:db8:1::b7 and le...during HA sync testing I found little quirk `DHCPSRV_MEMFILE_GET_ADDR6` message is logged twice:
```
2019-01-07 06:44:39.966 DEBUG [kea-dhcp6.dhcpsrv/10887] DHCPSRV_MEMFILE_GET_ADDR6 obtaining IPv6 lease for address 2001:db8:1::b7 and lease type IA_NA
2019-01-07 06:44:39.966 DEBUG [kea-dhcp6.dhcpsrv/10887] DHCPSRV_MEMFILE_ADD_ADDR6 adding IPv6 lease with address 2001:db8:1::b7
2019-01-07 06:44:39.966 DEBUG [kea-dhcp6.dhcpsrv/10887] DHCPSRV_MEMFILE_GET_ADDR6 obtaining IPv6 lease for address 2001:db8:1::b7 and lease type IA_NA
```backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/152Add a rebuild-test target for CA, D2 and NETCONF2022-11-02T15:08:43ZFrancis DupontAdd a rebuild-test target for CA, D2 and NETCONFand of course Netconf. Currently a rebuild-test target is available only for DHCPv4 and DHCPv6: it should be adapted to anything using a flex/bison JSON syntax.and of course Netconf. Currently a rebuild-test target is available only for DHCPv4 and DHCPv6: it should be adapted to anything using a flex/bison JSON syntax.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/414Use new lease user contexts in RADIUS accounting2024-03-21T16:21:16ZFrancis DupontUse new lease user contexts in RADIUS accountingMigrated from https://oldkea.isc.org/ticket/5658
Current code has many potential problems and was scheduled to use use contexts from the beginning but it was postponed because user contexts in leases were implemented later:
- save/load...Migrated from https://oldkea.isc.org/ticket/5658
Current code has many potential problems and was scheduled to use use contexts from the beginning but it was postponed because user contexts in leases were implemented later:
- save/load to a CSV file is implemented but never tested.
- eraseCreateTimestamp() is called only when a STOP event is sent so the timestamp stays in memory without more control
+ obviously using an user-context is the right way: extent following the lease one, save in stable storage, etc.
If memory leak on RADIUS accounting experiments are not conclusive this should be tried.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/420Decrease CPU workload for low traffic condition in perfdhcp2022-11-02T15:10:19ZTomek MrugalskiDecrease CPU workload for low traffic condition in perfdhcp#283 implemented support for optional threaded support in perfdhcp. The code behaves better when generating high volume traffic on multi-core systems. However, it does not handle well situations where there is only one core and little tr...#283 implemented support for optional threaded support in perfdhcp. The code behaves better when generating high volume traffic on multi-core systems. However, it does not handle well situations where there is only one core and little traffic is needed.
During discussions on !135 and related it became apparent that the approach to slip for 1 us is not the right solution. The code should behave adaptively and calculate time to the next action rather than check it a million times per second.
Related MR: !165backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/435A design for "backends in hooks"2022-04-21T10:39:03ZTomek MrugalskiA design for "backends in hooks"We had a discussion about Kea packaging in 1.6 (see meeting notes 2019-01-24). The conclusion was that we want to prepare for Kea packaging better. In particular, the database backends should be moved to hooks that are loaded dynamically...We had a discussion about Kea packaging in 1.6 (see meeting notes 2019-01-24). The conclusion was that we want to prepare for Kea packaging better. In particular, the database backends should be moved to hooks that are loaded dynamically, rather than included during compilation time.
The overall intention is to have a directory where hooks could be loaded from. This is similar to Apache modules. They have 2 directories: mods-available and mods-enabled. The first one contains a list of modules (hooks). The second one has symlinks to those modules (hooks) that will be loaded. This approach is super easy to understand and use. Also, very extensible, because you can package backends and other hooks in independent RPM or DEB packages.
It's different than what we do now and several things have to be changed before we get there:
1. When Kea parses configuration, it has to know what lease-database and hosts-database backends are supported. Right now it's hardcoded* (but see below). We'd need to load the hooks first and they would register available backends, then we'd process rest of the configuration.
1. RADIUS is implemented as a hook and it does provide hosts backend. Before doing anything, please investigate how it registers "radius" hosts-backend type. This is not exactly a ready to use solution (because you can't configure "radius" backend in the config yet), but they underlying implementation of backend type registration is good.
1. we need to develop a code that would load all the hooks from a directory
Things to consider:
1. name the directory properly (people complained that the hooks have incorrect name libdhcp- and also are placed in incorrect directory)
2. perhaps we could have hooks that are loaded always (call them permanent hooks maybe?). Those would be put in the hooks-enabled directory and would be loaded at kea startup and not unloaded during reconfiguration? This would be most useful for parameter-less hooks (such a config backends)
3. apache allows having a separate config file for each module. IMHO this is a bit too much, but maybe it's something to look at after all?
The goal of this ticket is to write a design. It should conclude with w written design and a list of tickets needed to implement it.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/445add support for mongo db2019-02-07T17:00:17ZGhost Useradd support for mongo db---
name: mongodb
about: add mongodb support to kea dhcp server
---
**Some initial questions**
- could not find this request anywhere in issues or on the web
- sure, there are other databases support; but that's not the point
**Is you...---
name: mongodb
about: add mongodb support to kea dhcp server
---
**Some initial questions**
- could not find this request anywhere in issues or on the web
- sure, there are other databases support; but that's not the point
**Is your feature request related to a problem? Please describe.**
- Reduction of the numbers of databases on the client's systems
**Describe the solution you'd like**
- allow kea administrators to configure mongodb in kea
**Describe alternatives you've considered**
- Not really.
**Additional context**
- No.
**Funding its development**
- Sure to some very small degree.
**Participating in development**
- design discussions and testing
**Contacting you**
- Private messages to my gitlab.isc.org registered email address are fine.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/449Create AuditRevision object to carry supplementary information for audit entries2020-09-10T15:49:35ZMarcin SiodelskiCreate AuditRevision object to carry supplementary information for audit entriesThe CB database includes `dhcp4_audit_revision` table which holds general information about the changes applied in the database. Currently it holds a timestamp and the log message. The timestamp is and will remain being generated automat...The CB database includes `dhcp4_audit_revision` table which holds general information about the changes applied in the database. Currently it holds a timestamp and the log message. The timestamp is and will remain being generated automatically. The log message is also generated automatically at the moment but the idea is to be able to specify the log message in the command. Some examples can be found here:
https://gitlab.isc.org/isc-projects/kea/wikis/designs/configuration-in-db-design#configuration-management
In the future we may store more information in the revision table. For example: name of the user who applied a change, IP address from which the command has been sent etc. This information must be encapsulated in a new object, e.g. AuditRevision and passed via the CB API to the commands that modify the information in the database, i.e. set and del commands.
Even though we could postpone this change to later Kea release, it may be actually better to add it now to keep the API stable in next releases.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/450Populate log messages from the cb_cmds to the database2020-09-10T15:50:03ZMarcin SiodelskiPopulate log messages from the cb_cmds to the databaseAssuming that we do #449, we then have to extend the cb_cmds hooks library to actually use the log messages conveyed in the control commands to the database through the AuditRevision objects.Assuming that we do #449, we then have to extend the cb_cmds hooks library to actually use the log messages conveyed in the control commands to the database through the AuditRevision objects.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/472Documentation about congestion recovery2020-09-10T15:52:00ZFrancis DupontDocumentation about congestion recoveryTwo points:
- make clearer that the congestion recovery is not congestion avoidance (or any variant in terms which can suggest it) in the documentation
- findings about the impact on performance of the congestion recovery.Two points:
- make clearer that the congestion recovery is not congestion avoidance (or any variant in terms which can suggest it) in the documentation
- findings about the impact on performance of the congestion recovery.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/475extend kea-admin with option to install/update yang models2021-06-18T09:35:04ZWlodzimierz Wencelextend kea-admin with option to install/update yang modelskea-admin is capable to handle mysql/pgsql/cql when it comes to leases and HR. And right now work on config backend will extend it for configuration storage. We should also extend it to handle yang models.kea-admin is capable to handle mysql/pgsql/cql when it comes to leases and HR. And right now work on config backend will extend it for configuration storage. We should also extend it to handle yang models.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/479HA peer should drop leases not present on the partner during sync2022-11-02T15:10:19ZMarcin SiodelskiHA peer should drop leases not present on the partner during syncLet's suppose there are two HA peers A and B. The peer B dies. While the peer B is offline, the admin sends `lease4-del` command to the A. The peer B starts up and synchronizes its lease database with A. It correctly adds new leases and ...Let's suppose there are two HA peers A and B. The peer B dies. While the peer B is offline, the admin sends `lease4-del` command to the A. The peer B starts up and synchronizes its lease database with A. It correctly adds new leases and updates existing leases based on the list received from A. However, it doesn't remove the lease deleted on A while it was offline. The server admin would need to send `lease4-del` command to B to remove the lease.
In order to address this problem we have to fetch all leases from the B's backend and iterate over them to see if they are also present on A. In order to do so, we will have to keep the local copy of leases received from A. For Memfile, MySQL and Postgres we could do it more efficiently by comparing ranges of leases as they are ordered by IP addresses. After comparing a range of leases we could simply drop the local copy of the lease ranges. However, this won't work for Cassandra which returns leases out of order. In the Cassandra case we will have to collect all leases returned by the peer.backlogMarcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/482perfdhcp avalanche: more research needed for selecting proper periods for che...2022-11-02T15:10:19ZMichal Nowikowskiperfdhcp avalanche: more research needed for selecting proper periods for checking resending packetsCurrently this is 200ms. It was choosen based on experiments.
The whole scenario times were more less the lowest between 50ms and 200ms.
This issue reflects review comment: https://gitlab.isc.org/isc-projects/kea/merge_requests/237#note...Currently this is 200ms. It was choosen based on experiments.
The whole scenario times were more less the lowest between 50ms and 200ms.
This issue reflects review comment: https://gitlab.isc.org/isc-projects/kea/merge_requests/237#note_45247
This time is located in avalanche_scen.cc file, in run() method.backlog