Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2023-06-19T10:40:00Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/2856mysql v4 backend slowing down while using random and flq allocator2023-06-19T10:40:00ZWlodzimierz Wencelmysql v4 backend slowing down while using random and flq allocatorIt looks like Kea performance is hugely impacted when random or flq allocator is used. Screen of the charts that show performance degradation are attached. Results are generated using code from isc-projects/kea#2843
![Screenshot_2023-05...It looks like Kea performance is hugely impacted when random or flq allocator is used. Screen of the charts that show performance degradation are attached. Results are generated using code from isc-projects/kea#2843
![Screenshot_2023-05-11_at_13.56.08](/uploads/8fd6f88e0cd8078c130c11b224ea749c/Screenshot_2023-05-11_at_13.56.08.png)
![Screenshot_2023-05-11_at_13.56.38](/uploads/7a82938d13b13dec1b7c80388f3b4b1c/Screenshot_2023-05-11_at_13.56.38.png)
Issue is not observed in v6 random allocator:
![Screenshot_2023-05-11_at_14.01.09](/uploads/39181cd28e2e1fad03c70e2319a88fc1/Screenshot_2023-05-11_at_14.01.09.png)
[full internal report](https://jenkins.aws.isc.org/view/Kea-manual/job/kea-manual/job/performance/94/artifact/qa-dhcp/kea/performance-jenkins/report.html) (it's heavy, please wait patiently for it to load)
to check all allocator related tests please go to tab `Resource Consumption`, allocators tests starts at Scenario 7.
Mysql related scenarios:
* v4: 10, 11, 12, 19, 20, 21, 28, 29, 30
* v6: 39, 40, 45, 46, 51, 52
(number of tests will be reduced for regular monthly runs)
Additionally I should mention that in previous runs (master) I observed issues with iterative allocator in v4 mysql as well. Looked like kea stops assigning leases after assigning ~6mln leases, but I couldn't reproduce it on isc-projects/kea#2843 (I will repeat those tests on master overnight)
![Screenshot_2023-05-11_at_14.11.01](/uploads/6da24ed37a758e3e86653a31a2b2fbb1/Screenshot_2023-05-11_at_14.11.01.png)next-stable-2.6Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2850KEA fails to start due to lease file corrupted by an invalid IPv4 address2023-05-18T13:50:29ZThriusKEA fails to start due to lease file corrupted by an invalid IPv4 address---
name: Bug report
about: kea-dhcp4 -v 1.8.2
---
**Describe the bug** The KEA DHCP server that provides DHCP for our network couldn't be started (after being stopped) because the lease file was corrupted.
After some digging we found t...---
name: Bug report
about: kea-dhcp4 -v 1.8.2
---
**Describe the bug** The KEA DHCP server that provides DHCP for our network couldn't be started (after being stopped) because the lease file was corrupted.
After some digging we found the issue: The lease file contained an invalid IPv4 address. The KEA DHCP service wouldn't start because of an error: `Failed to convert string to address '10.20010.200.0.35': Invalid arg.` This IP address almost seems to have been written to the .csv possibly when another entry was being added due to the IPv4 format here as 10.200 are the first two octets in this IP range and duplicated in the invalid entry.
**To Reproduce**
Steps to reproduce the behavior:
1. Unsure how to add a client with an IPv4 that is invalid such as noted and have it saved into the KEA .csv entries. Possibly hand edit a .csv entry to mimic this invalid IPv4 address entry.
2. stop the kea service
3. start the kea service
4. look at the logging. In this case /var/log/syslog: `May 03 15:09:22 dhcp1 kea-dhcp4[2998]: 2023-05-03 15:09:22.853 ERROR [kea-dhcp4.dhcpsrv/2998.140331595758656] DHCPSRV_MEMFILE_LEASE_LOAD_ROW_ERROR discarding row 10401053, error: Failed to convert string to address '10.20010.200.0.35': Invalid arg`
4. Check the status of kea-dhcp4-server.service such as: `systemctl status isc-kea-dhcp4-server`
5. Note that the kea-dhcp4-server.service failed to start
**Expected behavior** Invalid IPv4 address entries are logged as such but does not cause the kea-dhcp4-server.service to fail starting. Ignore the invalid entry and continue loading the kea-dhcp4-server.service.
**Environment:**
- Kea version: 1.82
- OS: Ubuntu 18.04.6 LTS
**Additional Information** Example invalid IP address:
`10.20010.200.0.35`
[Kea_syslog.txt](/uploads/c2cf74d254d0afc7e0a925cb9f7fb9ee/Kea_syslog.txt)outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2849Follow-up from "Resolve "DHCP4_LEASE_REUSE count report in statistic-get-all ...2023-05-11T14:21:42ZAndrei Pavelandrei@isc.orgFollow-up from "Resolve "DHCP4_LEASE_REUSE count report in statistic-get-all and similar statistics API calls""The following discussion from !1983 should be addressed:
- [ ] @andrei started a [discussion](https://gitlab.isc.org/isc-projects/kea/-/merge_requests/1983#note_369982): (+4 comments)
> I noticed that v4 reuses leases for fake all...The following discussion from !1983 should be addressed:
- [ ] @andrei started a [discussion](https://gitlab.isc.org/isc-projects/kea/-/merge_requests/1983#note_369982): (+4 comments)
> I noticed that v4 reuses leases for fake allocations too, while v6 doesn't. While the net effect is the same for both fake allocation and lease reuse which is that the lease is not updated in persistent storage, this disparity becomes obvious when looking at the statistics - the v4 statistics have double the value of v6 statistics, which can be confusing. I'd open an issue about it after this one gets reviewed, but I can also fix it in the current issue. It should be just a matter of moving if statements around.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2844Kea fails to log useful information about option 822023-05-18T14:43:40ZRobin ChristKea fails to log useful information about option 82I was trying to debug some issues and spent a lot of time trying to figure out why my DHCP relay on an L3 switch was not inserting option82 correctly. Turns out: It does, but kea does not log it properly.
This is the debug log:
```
pr 2...I was trying to debug some issues and spent a lot of time trying to figure out why my DHCP relay on an L3 switch was not inserting option82 correctly. Turns out: It does, but kea does not log it properly.
This is the debug log:
```
pr 25 02:19:07 pve kea-dhcp4[44191]: DEBUG DHCP4_QUERY_DATA [hwtype=1 8c:16:45:d8:b5:b4], cid=[no info], tid=0x37048b4a, packet details: local_address=10.2.1.1:67, remote_address=10.2.0.3:67, msg_type=DHCPREQUEST (3), transid=0x37048b4a,
Apr 25 02:19:07 pve kea-dhcp4[44191]: options:
Apr 25 02:19:07 pve kea-dhcp4[44191]: type=012, len=018: "robin-ThinkPad-P52" (string)
Apr 25 02:19:07 pve kea-dhcp4[44191]: type=050, len=004: 10.21.1.0 (ipv4-address)
Apr 25 02:19:07 pve kea-dhcp4[44191]: type=053, len=001: 3 (uint8)
Apr 25 02:19:07 pve kea-dhcp4[44191]: type=054, len=004: 10.2.1.1 (ipv4-address)
Apr 25 02:19:07 pve kea-dhcp4[44191]: type=055, len=013: 1(uint8) 28(uint8) 2(uint8) 3(uint8) 15(uint8) 6(uint8) 119(uint8) 12(uint8) 44(uint8) 47(uint8) 26(uint8) 121(uint8) 42(uint8)
Apr 25 02:19:07 pve kea-dhcp4[44191]: type=082, len=006:,
Apr 25 02:19:07 pve kea-dhcp4[44191]: options:
Apr 25 02:19:07 pve kea-dhcp4[44191]: type=001, len=004: 6b:75:72:7a
```
As we can see, nothing is logged for Option 82, just `len 006` (which is easy to miss)
This is the actual contents, captured with Wireshark:
```
Frame 43: 346 bytes on wire (2768 bits), 346 bytes captured (2768 bits)
Ethernet II, Src: Mellanox_46:1d:78 (f4:52:14:46:1d:78), Dst: Mellanox_87:28:22 (24:8a:07:87:28:22)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 2
Internet Protocol Version 4, Src: 10.2.0.2, Dst: 10.2.1.1
User Datagram Protocol, Src Port: 67, Dst Port: 67
Dynamic Host Configuration Protocol (Discover)
Message type: Boot Request (1)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 1
Transaction ID: 0x454ea131
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
Client IP address: 0.0.0.0
Your (client) IP address: 0.0.0.0
Next server IP address: 0.0.0.0
Relay agent IP address: 10.21.0.2
Client MAC address: LCFCHeFe_d8:b5:b4 (8c:16:45:d8:b5:b4)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Discover)
Option: (50) Requested IP Address (10.21.1.0)
Option: (12) Host Name
Option: (55) Parameter Request List
Option: (82) Agent Information Option
Length: 6
Option 82 Suboption: (1) Agent Circuit ID
Length: 4
Agent Circuit ID: 6b75727a
Option: (255) End
Padding: 00000000000000
```
Binary contents of the option 82 field:
```
0000 52 06 01 04 6b 75 72 7a R...kurz
```
(expected value is `kurz`)
As we can see, there is a circuit it, but kea does not log it. I believe this is a bug and should be fixed.
**Environment:**
- Kea version is 2.2.0
- Proxmox 7.4next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2829Factor v4 BLQ unit tests2023-07-07T12:36:42ZFrancis DupontFactor v4 BLQ unit testsSQL unit tests for SQL backends can share a lot of code with memfile as they were copied from...
This creates a generic set of tests in testutils and then derive the tests for each of the backends.SQL unit tests for SQL backends can share a lot of code with memfile as they were copied from...
This creates a generic set of tests in testutils and then derive the tests for each of the backends.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2828Document or fix database conflicts between v4 hosts and v6 hosts2023-04-20T13:38:11ZAndrei Pavelandrei@isc.orgDocument or fix database conflicts between v4 hosts and v6 hostsSay there are a kea-dhcp4 server and a kea-dhcp6 server with both their `hosts-databases` set to the same database.
If an administrator wants to reserve v4 resources and v6 resources for the same client identified by a common identifier...Say there are a kea-dhcp4 server and a kea-dhcp6 server with both their `hosts-databases` set to the same database.
If an administrator wants to reserve v4 resources and v6 resources for the same client identified by a common identifier type, say hardware address, the host schema goes out if its way to allow this, having separate `dhcp4_subnet_id` and `dhcp6_subnet_id` columns, separate `dhcp4_options` and `dhcp6_options` tables, and so on.
However, the response to the second of the two `reservation-add` commands that are issued for each server, is `Database duplicate entry error`.
What's worse is that the administrator might assume that there is already a reservation with that identifier in the database, but if you follow up with a `reservation-get-all` to check it out, it doesn't show up, because it only shows hosts from the server version that is queried and the duplicate is for the other server version.
I'm suggesting that this needs to be either documented in the ARM, or fixed which is not difficult and is doable, and backwards-compatible, by including `dhcp4_subnet_id` and `dhcp6_subnet_id` as part of the primary key in the `hosts` table.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2825Deprecate extended JSON in favor for compliant JSON comments2023-04-20T12:55:56ZCarsten StrotmannDeprecate extended JSON in favor for compliant JSON comments---
name: Deprecate extended JSON in favor for compliant JSON comments/includes
Kea DHCP uses an extended JSON format with comments and includes that deviates from "standard" JSON (RFC 8259).
While it is nice to have comments and incl...---
name: Deprecate extended JSON in favor for compliant JSON comments/includes
Kea DHCP uses an extended JSON format with comments and includes that deviates from "standard" JSON (RFC 8259).
While it is nice to have comments and includes in the configuration file, the current implementation is not compliant with the JSON specs and breaks other tools JSON parser.
For non-trivial Kea DHCP configuration files, it is highly recommended to use a text editor with JSON support (VS Code, VIM, Emacs, BBEdit etc) or a JSON editor. However, the current "extensions" break the JSON support in these tools/editors so that they cannot be used. The loss of these tools is hurting more than the extra functions implemented in the extended JSON format.
I propose that the current extension are being deprecated and replaced with comments and includes that are valid according to the JSON RFC, so that non-Kea tools can be used when working with Kea configuration files.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2824Optimizations in the allocator selection: copy the existing state2023-04-13T13:49:14ZMarcin SiodelskiOptimizations in the allocator selection: copy the existing stateThe random and flq allocators maintain their states. It is particularly long for the FLQ allocator to populate its initial state. It can take from milliseconds to minutes. When a subnet is reconfigured without changing the allocator and ...The random and flq allocators maintain their states. It is particularly long for the FLQ allocator to populate its initial state. It can take from milliseconds to minutes. When a subnet is reconfigured without changing the allocator and the subnet pools, we could perhaps avoid re-building the allocator state but keeping the existing state aside, and then copying the pointer to the allocation state to the new subnet instance. In that case we'd only have the overhead during the startup, renumbering and an allocator change. In all other cases, the reconfiguration would be smooth.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2820Optionally log transaction ID with log messages2024-03-27T12:55:48ZDarren AnkneyOptionally log transaction ID with log messagesIt could be useful to have a `%` parameter available for the pattern in the loggers section to add the transaction id to each message logged. It's already logged on some messages but not all.
Example:
```
2023-03-30 20:26:27.518 DEBUG ...It could be useful to have a `%` parameter available for the pattern in the loggers section to add the transaction id to each message logged. It's already logged on some messages but not all.
Example:
```
2023-03-30 20:26:27.518 DEBUG [kea-dhcp4.hosts/283769.281473780088704] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id 1 and IPv4 address 192.168.115.202
```
vs.
```
2023-03-30 20:26:27.518 DEBUG [kea-dhcp4.alloc-engine/283769.281473780088704] ALLOC_ENGINE_V4_REQUEST_ALLOC_REQUESTED [hwtype=1 00:0c:01:02:03:06], cid=[01:00:0c:01:02:03:06], tid=0x3: trying to allocate requested address 192.168.115.202
```
Having a way to log it consistently before the start of the message would be helpful when trying to find all of the messages that occurred with a particular exchange. It could even be useful to match these up to packets in a pcap.
[RT21953](https://support.isc.org/Ticket/Display.html?id=21953)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/2819Add max TTL time to D22024-03-27T12:49:15ZDarren AnkneyAdd max TTL time to D2With the addition of being able to set the DDNS TTL with `ddns-ttl-percent` to some percentage of lease time, it might be a good idea to add a maximum possible TTL to the `kea-ddns` configuration. This should be an absolute time limit. ...With the addition of being able to set the DDNS TTL with `ddns-ttl-percent` to some percentage of lease time, it might be a good idea to add a maximum possible TTL to the `kea-ddns` configuration. This should be an absolute time limit. For example, `3600` for one hour maximum TTL length. In this example, if Kea sent something higher than this, D2 would truncate the TTL to `3600`. If the proposed setting is not present in D2 then there should be no change from current behavior which, I believe, is no limit to the length of the TTL.
[RT21610](https://support.isc.org/Ticket/Display.html?id=21610)next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/2818Read YAML configuration file2023-04-13T13:47:19ZVicky Riskvicky@isc.orgRead YAML configuration fileIn today's webinar on configuring custom options, a participant asked whether we could enable configuration in YAML instead of JSON. Carsten revealed that he uses a YAML <-> JSON translator so he can work in YAML but still feed Kea JSON....In today's webinar on configuring custom options, a participant asked whether we could enable configuration in YAML instead of JSON. Carsten revealed that he uses a YAML <-> JSON translator so he can work in YAML but still feed Kea JSON. It was suggested that maybe we could make Kea recognize whether the configuration file is in YAML or JSON, and in case of YAML, run this translator first. It seems like there might be a useful usability improvement in here somewhere.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2816The default delegated-len should be /642023-05-18T13:35:45ZTomek MrugalskiThe default delegated-len should be /64There's a substantial discussion happening at IETF (6man and v6ops WGs), related to [draft-collink-v6ops-ent64pd](https://datatracker.ietf.org/doc/draft-collink-v6ops-ent64pd/) and [draft-collink-6man-pio-pflag-00](https://datatracker.ie...There's a substantial discussion happening at IETF (6man and v6ops WGs), related to [draft-collink-v6ops-ent64pd](https://datatracker.ietf.org/doc/draft-collink-v6ops-ent64pd/) and [draft-collink-6man-pio-pflag-00](https://datatracker.ietf.org/doc/draft-collink-6man-pio-pflag/).
The leading perspective is that the recommended prefix length for delegation should be /64. This is pretty major change of opinion for Google and Android. We should make sure Kea is ready for those new deployments.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2812rfc7078: address selection policy v6 options2023-04-13T13:41:55ZTomek Mrugalskirfc7078: address selection policy v6 optionsWe need to implement address selection policies options defined in RFC7078. These are not likely to be popular options yet, but people doing experiments with multi-homing would love to see them supported. If/when multi-homing takes off, ...We need to implement address selection policies options defined in RFC7078. These are not likely to be popular options yet, but people doing experiments with multi-homing would love to see them supported. If/when multi-homing takes off, it would be better if Kea was part of the solution.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2806Generate config-test snippets that are different than running config ang chec...2023-04-13T13:41:26ZRazvan BecheriuGenerate config-test snippets that are different than running config ang check if running config-test has an effect on running serverAfter enhancing the config rollback in #2722, #1671, #2799 there might be other parsers that have an effect on running config beside MT settings. If this is the case it must be fixed, and proper UT to check this must be added.After enhancing the config rollback in #2722, #1671, #2799 there might be other parsers that have an effect on running config beside MT settings. If this is the case it must be fixed, and proper UT to check this must be added.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2802Implement `bundle` command2023-04-11T11:07:55ZTomek MrugalskiImplement `bundle` commandThe idea for this API call came from @marcin. Here's the discussion: https://pad.isc.org/p/stork-cb-migration#L64
The overall long term goal is to have a command that could include multiple other commands and run them one after another ...The idea for this API call came from @marcin. Here's the discussion: https://pad.isc.org/p/stork-cb-migration#L64
The overall long term goal is to have a command that could include multiple other commands and run them one after another as one change-set. Couple scenarios where this might be useful:
- changing subnet and all host reservations in it
- deleting subnet and all leases associated
- reservation migration from config file to database
This mechanism, if implemented correctly, will be very powerful.
One important feature of this new command is the ability to rollback changes if configurable number of errors is reached. It's important to acknowledge that full rollback in generic case is not possible, so this rollback should be limited to DB operations _for now_. We hope to expand the rollback in the future to maybe cover some other commands, but it will never be possible to rollback everything.
Since there are many ways how this could be implemented, I think the first step would be come up with a mini-design. Couple paragraphs in the ticket or on wiki should do the trick.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2800Client classes are case insensitive in the leaseX_stat_by_client_class MySQL ...2023-04-20T13:29:20ZAndrei Pavelandrei@isc.orgClient classes are case insensitive in the leaseX_stat_by_client_class MySQL tableReplication steps:
1. Start `kea-dhcp4` with two classes having the same name, but with different capitalization, with limits hook library loaded, and a MySQL lease backend, like in the following example. Add to the configuration whatev...Replication steps:
1. Start `kea-dhcp4` with two classes having the same name, but with different capitalization, with limits hook library loaded, and a MySQL lease backend, like in the following example. Add to the configuration whatever else is needed for dealing with DHCP traffic like `interfaces-config` and `subnet4`.
```json
{
"Dhcp4": {
"client-classes": [
{
"name": "myclass",
"test": "member('ALL')"
},
{
"name": "MYCLASS",
"test": "member('ALL')"
}
],
"hooks-libraries": [
{
"library": "/opt/kea/lib/kea/hooks/libdhcp_limits.so"
}
],
"lease-database": {
"host": "127.0.0.1",
"name": "keatest",
"password": "keatest",
"type": "mysql",
"user": "keatest"
}
}
}
```
2. Send any number of DORAs. Each of the two client classes has to be assigned at least to one DORA.
3. Get all rows from `lease4_stat_by_client_class`. Notice that one of the classes is missing, and the other one is present with more leases than `ALL` which should not be possible. The problem is that both classes are registered under only one of them.
```sh
$ mysql --user=root --password=keatest --database=keatest --execute='SELECT * FROM lease4_stat_by_client_class;'
+--------------+--------+
| client_class | leases |
+--------------+--------+
| ALL | 29 |
| myclass | 58 |
| UNKNOWN | 29 |
+--------------+--------+
```
4. Get the user context from `lease4`. See that both classes are properly added to the user context.
```sh
$ mysql --user=root --password=keatest --database=keatest -e 'SELECT DISTINCT user_context FROM lease4;'
+-----------------------------------------------------------------------------+
| user_context |
+-----------------------------------------------------------------------------+
| { "ISC": { "client-classes": [ "ALL", "myclass", "MYCLASS", "UNKNOWN" ] } } |
+-----------------------------------------------------------------------------+
```
Replicates for `kea-dhcp6` too.
Does not replicate on a PostgreSQL lease backend, meaning there are separate entries for each class e.g. `myclass` and `MYCLASS`. This is the expected behavior.
Used this version to replicate: `Server version: 10.11.2-MariaDB-1:10.11.2+maria~ubu2204 mariadb.org binary distribution`outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2796"naive" (dhcpd, microsoft style) conflict resolution (immediately reassign le...2023-10-23T14:58:37Zuedvt359"naive" (dhcpd, microsoft style) conflict resolution (immediately reassign lease to reserved host)When resolving conflicts between active leases and host reservations, Kea relies on the client with the active lease to cooperate. When lease times are long, and the client with the active lease goes offline, the host with the reservatio...When resolving conflicts between active leases and host reservations, Kea relies on the client with the active lease to cooperate. When lease times are long, and the client with the active lease goes offline, the host with the reservation must wait for the lease to expire fully before it will be assigned to it.
This is a feature request for what the documentation calls the "naive approach" of just re-assigning IPs, at least for out-of-pool reservations.
I posted this to the Kea-Users mailing list in January, and got a bunch of replies, indicating that this feature would be appreciated by other users, too: https://lists.isc.org/pipermail/kea-users/2023-January/003847.html
Picture the following situation:
Initially:
- Leases are valid for a long time (11 days, per customer requirement)
- There is a host reservation for \<mac1\> and \<ip1\>
- The device with \<mac1\> got a lease for \<ip1\>
Now, the hardware is replaced and the reservation is updated, so the new device gets the same IP:
- remove reservation for \<mac1\> and \<ip1\>
- add reservation for \<mac2\> and \<ip1\>
- the old device is unplugged, and therefore cannot release its lease
- the new device is plugged in and requests a lease
Now, Kea looks for the host reservation for \<mac2\> and notices that
\<ip1\> is still leased to \<mac1\>, so it refuses to reassign this IP.
I read through section 8.3.2 of the documentation, and the conflict
resolution protocol used seems to not handle our case here (where the
old device doesn't release its lease). It expects the old device with
\<mac1\> to renew its lease, before responding with DHCPNAK and
reallocating \<ip1\> to \<mac2\>.
The documentation describes that "A naive approach would to be
immediately remove the existing lease for Host A and create a new one
for Host B" -- this would be exactly what we want, and what our
previous setup did.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2791Manage exported shared library symbols visibility2023-04-06T13:46:58ZAthos RibeiroManage exported shared library symbols visibilityHello,
I am wondering if there are any plans on improving the state of the exported symbols when building the kea shared libraries.
This could ease distributing kea and the maintenance of third party software which may be linked those ...Hello,
I am wondering if there are any plans on improving the state of the exported symbols when building the kea shared libraries.
This could ease distributing kea and the maintenance of third party software which may be linked those kea shared libraries. Moreover, the shared libraries would contain a lean, clearer exposed interface.
Currently, there are no mechanisms to manage those symbols visibility. A couple alternatives would be to either
- decorate everything intended to be public with a macro that is expanded to `__attribute__((__visibility__("default")))`, and start building those shared objects with `-fvisibility=hidden`; or
- ship a version script [1] with the package to set the scope for the shared object symbols.
[1] https://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_25.html#SEC25outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2787A client class reservation in FreeRADIUS only applies to the first exchange i...2024-03-25T15:05:41ZAndrei Pavelandrei@isc.orgA client class reservation in FreeRADIUS only applies to the first exchange if there is also an address reservation for the same hostIf you have both an address reservation and a client class reservation in RADIUS, like so:
```
00:03:00:01:08:00:27:b0:c1:42 Cleartext-password := "08:00:27:b0:c1:42"
Framed-IP-Address = "192.168.52.52",
Framed-IPv6-Ad...If you have both an address reservation and a client class reservation in RADIUS, like so:
```
00:03:00:01:08:00:27:b0:c1:42 Cleartext-password := "08:00:27:b0:c1:42"
Framed-IP-Address = "192.168.52.52",
Framed-IPv6-Address = "2001:db8:50::52",
Framed-Pool = "gold",
Framed-IPv6-Pool = "gold"
```
The client class is only assigned to the packet from the first exchange, but not to the packet from the second exchange, like so:
```
DEBUG [kea-dhcp6.packets] DHCP6_QUERY_DATA duid=[00:03:00:01:08:00:27:b0:c1:42], tid=0xf9cf5f, packet details: localAddr=[ff02::1:2]:0 remoteAddr=[fe80::3442:f5d2:3c93:374c]:546
msgtype=1(SOLICIT), transid=0xf9cf5f
--
DEBUG [kea-dhcp6.dhcp6] DHCP6_CLASS_ASSIGNED duid=[00:03:00:01:08:00:27:b0:c1:42], tid=0xf9cf5f: client packet has been assigned to the following class(es): ALL, gold, KNOWN
--
DEBUG [kea-dhcp6.packets] DHCP6_RESPONSE_DATA responding with packet type 2 data is localAddr=[ff02::1:2]:547 remoteAddr=[fe80::3442:f5d2:3c93:374c]:546
msgtype=2(ADVERTISE), transid=0xf9cf5f
--
DEBUG [kea-dhcp6.packets] DHCP6_QUERY_DATA duid=[00:03:00:01:08:00:27:b0:c1:42], tid=0xf9cf5f, packet details: localAddr=[ff02::1:2]:0 remoteAddr=[fe80::3442:f5d2:3c93:374c]:546
msgtype=3(REQUEST), transid=0xf9cf5f
--
DEBUG [kea-dhcp6.dhcp6] DHCP6_CLASS_ASSIGNED duid=[00:03:00:01:08:00:27:b0:c1:42], tid=0xf9cf5f: client packet has been assigned to the following class(es): ALL, KNOWN
--
DEBUG [kea-dhcp6.packets] DHCP6_RESPONSE_DATA responding with packet type 7 data is localAddr=[ff02::1:2]:547 remoteAddr=[fe80::3442:f5d2:3c93:374c]:546
msgtype=7(REPLY), transid=0xf9cf5f
```
If the client class would have also been assigned in the second exchange, it could have potentially resulted in a different lease, depending on Kea configuration.
This behavior is exhibited with v4 too.
See https://gitlab.isc.org/isc-projects/kea/-/issues/2761#note_357250 for slightly more details.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2778HA service UT sporadically fail on macOS2024-02-29T06:55:54ZRazvan BecheriuHA service UT sporadically fail on macOS```
[ RUN ] HAServiceTest.sendUpdatesControlResultErrorMultiThreading
ha_service_unittest.cc:1378: Failure
Expected equality of these values:
2
factory3_->getResponseCreator()->getReceivedRequests().size()
Which is: 1
ha_ser...```
[ RUN ] HAServiceTest.sendUpdatesControlResultErrorMultiThreading
ha_service_unittest.cc:1378: Failure
Expected equality of these values:
2
factory3_->getResponseCreator()->getReceivedRequests().size()
Which is: 1
ha_service_unittest.cc:1384: Failure
Value of: update_request3
Actual: false
Expected: true
[ FAILED ] HAServiceTest.sendUpdatesControlResultErrorMultiThreading (2 ms)
```
```
[ RUN ] HAServiceTest.sendSuccessfulUpdates6MultiThreading
ha_service_unittest.cc:1542: Failure
Expected equality of these values:
1
factory3_->getResponseCreator()->getReceivedRequests().size()
Which is: 0
ha_service_unittest.cc:1549: Failure
Value of: update_request3
Actual: false
Expected: true
[ FAILED ] HAServiceTest.sendSuccessfulUpdates6MultiThreading (2 ms)
```
```
[ RUN ] HAServiceTest.sendSuccessfulUpdatesMultiThreading
ha_service_unittest.cc:1120: Failure
Expected equality of these values:
2
factory3_->getResponseCreator()->getReceivedRequests().size()
Which is: 1
ha_service_unittest.cc:1126: Failure
Value of: update_request3
Actual: false
Expected: true
[ FAILED ] HAServiceTest.sendSuccessfulUpdatesMultiThreading (2 ms)
```
It seems that all are caused by checks on the backup server.
It might be realted to the stop condition on the IO service (wait for requests, not for replies)
```
// Actually perform the lease updates.
ASSERT_NO_THROW(runIOService(TEST_TIMEOUT, [this]() {
// Finish running IO service when there are no more pending requests.
return (service_->pendingRequestSize() == 0);
}));
```next-stable-2.6