Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-21T14:50:56Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3275Kea DB allows to store too short identifier in the lease table2024-03-21T14:50:56ZSlawek FigielKea DB allows to store too short identifier in the lease tableWhile performing some experiments in Stork, I found that the Kea database accepts identifiers that are too short (less than 3 bytes) in the `lease6` table. It causes the error to be thrown when the identifier is processed. I noticed it b...While performing some experiments in Stork, I found that the Kea database accepts identifiers that are too short (less than 3 bytes) in the `lease6` table. It causes the error to be thrown when the identifier is processed. I noticed it blocks fetching this lease by API. I don't know if it has any other internal consequences.
Steps to reproduce:
1. Setup Kea 2.3.8 or above with PostgreSQL.
2. Configure lease database.
3. Insert a lease with too short DUID (e.g., `00`)
```
INSERT INTO lease6(address, duid, valid_lifetime, expire, subnet_id, pref_lifetime, lease_type, iaid, prefix_len, hwtype, hwaddr_source, state) VALUES('3001:db8:1::2', DECODE('00', 'hex'), 3600, NOW() + interval '1' MONTH, 1, 1800, 0, 1, 128, 0, 0, 1);
```
4. Send the `lease-get` command with the specified address (i.e., `3001:db8:1::2`).
5. Observe the error:
```
stork-agent-kea6-1 | INFO COMMAND_RECEIVED Received command 'lease6-get'
stork-agent-kea6-1 | INFO CTRL_AGENT_COMMAND_RECEIVED command lease6-get received from remote address 127.0.0.1
stork-agent-kea6-1 | INFO COMMAND_RECEIVED Received command 'lease6-get'
stork-agent-kea6-1 | ERROR LEASE_CMDS_GET6_FAILED lease6-get command failed (parameters: { "ip-address": "3001:db8:1::2", "type": "IA_NA" }, reason: Could not convert data to Lease6, reason: identifier is too short (1), at least 3 is required)
stork-agent-kea6-1 | ERROR HOOKS_CALLOUT_ERROR error returned by callout on hook $lease6_get registered by library with index 1 (callout address 0x7f12e8310e90) (callout duration 0.593 ms)
stork-agent-kea6-1 | INFO CTRL_AGENT_COMMAND_FORWARDED command lease6-get successfully forwarded to the service dhcp6 from remote address 127.0.0.1
```backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3273Upgrade schema on startup2024-03-14T14:36:20ZAndrei Pavelandrei@isc.orgUpgrade schema on startupKea could have a boolean database-level configuration knob with a default of false that, when enabled, makes the schema be upgraded on startup.
Should be straightforward to do following the work on automatic database init in issue 3025.Kea could have a boolean database-level configuration knob with a default of false that, when enabled, makes the schema be upgraded on startup.
Should be straightforward to do following the work on automatic database init in issue 3025.next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3189Follow-up on #3019: limits are incompatbile with retry-on-startup2024-03-28T14:56:49ZAndrei Pavelandrei@isc.orgFollow-up on #3019: limits are incompatbile with retry-on-startupThe limits library needs the lease manager initialized in dhcpX_srv_configured in order to check for JSON support and to do some recounting. When `retry-on-startup` is configured for the lease database, and a retry is triggered, the leas...The limits library needs the lease manager initialized in dhcpX_srv_configured in order to check for JSON support and to do some recounting. When `retry-on-startup` is configured for the lease database, and a retry is triggered, the lease manager is not yet available, so an exception is thrown and the reconfiguration aborts, instead of actually retrying.
We should make limits compatible with retry-on-startup. Through some lazy recounting mechanism. @razvan's idea was a callback in `LeaseMgrFactory` that gets called on instantiation.kea2.6.0https://gitlab.isc.org/isc-projects/kea/-/issues/3160Too many nullable fields in DB schema?2023-11-23T14:48:53ZDavid KraeutmannToo many nullable fields in DB schema?I'm writing an admin tool for the Kea DB and noticed that a lot of fields in lease4/lease6 are nullable even when they shouldn't be. This adds a lot of handling overhead.
For example, in lease4, most of the columns are nullable, but onl...I'm writing an admin tool for the Kea DB and noticed that a lot of fields in lease4/lease6 are nullable even when they shouldn't be. This adds a lot of handling overhead.
For example, in lease4, most of the columns are nullable, but only relay_id and remote_id are actually possibly set to NULL in the Kea code.
What is the design decision behind that?backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3137Audit revision conflicts between IPv4 and IPv6 due to shared session variable2023-11-23T14:37:03ZMaurice MakaayAudit revision conflicts between IPv4 and IPv6 due to shared session variable**Describe the bug**
For creating audit revisions, separate paths exists for DHCP4 and DHCP6 auditing. The paths are not fully separated though. The two implementations make use of some shared session variables, amongst which `audit_rev...**Describe the bug**
For creating audit revisions, separate paths exists for DHCP4 and DHCP6 auditing. The paths are not fully separated though. The two implementations make use of some shared session variables, amongst which `audit_revision_id`. These session variables tightly couple the two paths, which can lead to conflicts.
**To Reproduce**
Here's an example scenario for a conflict:
```
kea=# SELECT createAuditRevisionDHCP4(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 1
kea=# SELECT createAuditRevisionDHCP6(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 1
kea=# SELECT createAuditRevisionDHCP4(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 2
kea=# INSERT INTO dhcp4_client_class (name) VALUES ('something'); -- uses audit_revision_id = 2, ok
kea=# INSERT INTO dhcp6_client_class (name) VALUES ('something'); -- uses audit_revision_id = 2, fail
```
Because the global revision id now points at 2, but only `dhcp6_audit` with id 1 exists, we get:
```
ERROR: insert or update on table "dhcp6_audit" violates foreign key constraint "fk_dhcp6_audit_revision"
DETAIL: Key (revision_id)=(2) is not present in table "dhcp6_audit_revision".
CONTEXT: SQL statement "INSERT INTO dhcp6_audit (object_type, object_id, modification_type, revision_id)
VALUES (object_type_val, object_id_val,
(SELECT id FROM modification WHERE modification_type = modification_type_val),
audit_revision_id)"
PL/pgSQL function createauditentrydhcp6(character varying,bigint,character varying) line 11 at SQL statement
SQL statement "SELECT createAuditEntryDHCP6('dhcp6_client_class', NEW.id, 'create')"
PL/pgSQL function func_dhcp6_client_class_ains() line 4 at PERFORM
```
In this case, the INSERT breaks, because the DHCP6 audit record points to a non-existent `dhcp6_audit_revision` id.
Another scenario is possible, where coincidentally the incorrect revision id does exist. In that case, the audit will be assigned to an old revision in the audit trail, changing history. An example scenario for this one:
```
kea=# SELECT createAuditRevisionDHCP4(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 1
kea=# INSERT INTO dhcp4_client_class (name) VALUES ('one'); -- uses audit_revision_id = 1, ok
kea=# SELECT createAuditRevisionDHCP4(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 2
kea=# INSERT INTO dhcp4_client_class (name) VALUES ('two'); -- uses audit_revision_id = 2, ok
kea=# SELECT createAuditRevisionDHCP6(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 1
kea=# INSERT INTO dhcp6_client_class (name) VALUES ('something'); -- uses audit_revision_id = 1, ok
kea=# INSERT INTO dhcp4_client_class (name) VALUES ('three'); -- uses audit_revision_id = 1, fail
```
**Expected behavior**
The audit revisions should be independent and use their own specific session variables, instead of shared ones.
When running the first scenario from the reproduction scenario:
- It must not fail
- The DHCP6 change must be logged in `dhcp6_audit` with `revision_id` = 1
- The DHCP4 change must be logged in `dhcp4_audit` with `revision_id` = 2
When running the second scenario:
- DHCP4 client class 'one' must be related to `dhcp4_audit' with `revision_id` = 1
- DHCP4 client class 'two' must be related to `dhcp4_audit' with `revision_id` = 2
- DHCP4 client class 'three' must be related to `dhcp4_audit' with `revision_id` = 2
- DHCP6 client class 'something' must be related to `dhcp6_audit' with `revision_id` = 1
**Environment:**
- Kea version: 2.5.3 and before
- Affects both MySQL and PostgreSQL
**Work-around**
To prevent issues with the current database schema, make sure that DHCP4 and DHCP6 updates are separated in the query sequence:
- create DHCP4 audit revision
- perform all DHCP4 updates
- create DHCP6 audit revision
- perform all DHCP6 updates
**Contacting you**
You can reach me at account-gitlab-isc@makaay.nloutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/3025Database initialization if empty db detected.2024-03-01T18:42:14ZMarcin GodzinaDatabase initialization if empty db detected.When setting up the quick docker Kea environment, I encountered a problem with an inconvenient step of manually preparing the database to work with Kea.
The docker environment discourages manual involvement in running containers.
Most o...When setting up the quick docker Kea environment, I encountered a problem with an inconvenient step of manually preparing the database to work with Kea.
The docker environment discourages manual involvement in running containers.
Most other systems I used set up a database automatically when an empty system is detected.
Examples: Nextcloud, Wordpress, nginx, tomcat, mosquito, homeassistant and many more.
This feature would be handy, but not required.kea2.5.6Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/3019Add retries and delay for initial lease db connection on Kea start2024-01-16T16:38:12ZMarcin GodzinaAdd retries and delay for initial lease db connection on Kea startWhen Kea starts and can not connect to lease db, it makes 4 tries in total in rapid succession. (under 5 seconds)
If we have a slowly starting db engine, Kea may exit prematurely.
Existing parameters like `"max-reconnect-tries"`, `"conn...When Kea starts and can not connect to lease db, it makes 4 tries in total in rapid succession. (under 5 seconds)
If we have a slowly starting db engine, Kea may exit prematurely.
Existing parameters like `"max-reconnect-tries"`, `"connect-timeout"`, and `"reconnect-wait-time"` work only when the db connection is **LOST** after the initial startup and connection check.kea2.5.5Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2957dhcpdb_create.pgsql erroneously creates dhcp4_server_modification_ts index on...2024-03-22T13:05:49ZJohn W. O'Briendhcpdb_create.pgsql erroneously creates dhcp4_server_modification_ts index on dhcp6_server table---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
dhcpdb_create.pgsql erroneously creates the dhcp4_server_modification_ts index on the dhcp6_server table
**To Reproduce**
Steps to reproduce the b...---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
dhcpdb_create.pgsql erroneously creates the dhcp4_server_modification_ts index on the dhcp6_server table
**To Reproduce**
Steps to reproduce the behavior:
1. Initialize a PostgreSQL database using dhcpdb_create.pgsql
2. Inspect the dhcp4_server_modification_ts index
3. See that it is associated with the dhcp6_server table
**Expected behavior**
A clear and concise description of what you expected to happen:
The dhcp4_server_modification_ts index should be associated with the dhcp4_server table.
**Environment:**
- Kea version: 2.2.0
- OS: FreeBSD 13.2-RELEASE amd64
- Compiled with pgsql backend
- Loaded hooks: pgsql_cb
**Additional Information**
```
kea=> \di dhcp4_server_modification_ts
List of relations
Schema | Name | Type | Owner | Table
--------+------------------------------+-------+-------+--------------
public | dhcp4_server_modification_ts | index | kea | dhcp6_server
(1 row)
```
This appears to have been introduced as a [copy/paste error in version 7.0 of the schema](https://gitlab.isc.org/isc-projects/kea/-/blob/Kea-2.3.8/src/share/database/scripts/pgsql/dhcpdb_create.pgsql#L1398). I could identify no correspond bug in the MySQL schema.
**Contacting you**
* SMS/Signal: (available upon request)
* GitHub/GitLab: neirbowj
* Mastodon: [@neirbowj@mastodon.online](https://mastodon.online/@neirbowj)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/2931Host commands fetching hosts by IP address from the backends return partial data2023-07-17T13:58:20ZMarcin SiodelskiHost commands fetching hosts by IP address from the backends return partial dataSuppose you have a host reservation that includes IPv6 addresses, prefixes and DHCP options. Now, if you send a command to fetch the host reservation by one of the IPv6 addresses, you'll get the host reservation with this IPv6 address (l...Suppose you have a host reservation that includes IPv6 addresses, prefixes and DHCP options. Now, if you send a command to fetch the host reservation by one of the IPv6 addresses, you'll get the host reservation with this IPv6 address (lacking other IPv6 addresses), without the prefixes and probably with only one of the options.
The reason for it is the invalid query that performs a simple inner join and filters by the IPv6 address. The other addresses and prefixes are ignored (filtered out) because they don't match the specified address. It seems that the correct query should run a sub-query selecting the host-id and then the main query that filters the host by this id.
The original issue was described here: https://gitlab.isc.org/isc-projects/kea/-/issues/2881#note_380311kea2.4.0Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2909Migrate DB V6 address string column to inet or binary types2023-07-17T13:58:20ZThomas MarkwalderMigrate DB V6 address string column to inet or binary typeskea2.4.0Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/2903PgSqlExtendedInfoTest.initLease6 fails sporadically2023-06-21T15:09:03ZThomas MarkwalderPgSqlExtendedInfoTest.initLease6 fails sporadicallyThis UT fails every so often because it assumes the leases fetched by PgSqlLeaseMgr::getLeases6() are ordered by address (primary key), however the query SQL does not specify an order clause:
```
// GET_LEASE6
{ 0, { OID_NONE },...This UT fails every so often because it assumes the leases fetched by PgSqlLeaseMgr::getLeases6() are ordered by address (primary key), however the query SQL does not specify an order clause:
```
// GET_LEASE6
{ 0, { OID_NONE },
"get_lease6",
"SELECT address, duid, valid_lifetime, "
"extract(epoch from expire)::bigint, subnet_id, pref_lifetime, "
"lease_type, iaid, prefix_len, fqdn_fwd, fqdn_rev, hostname, "
"hwaddr, hwtype, hwaddr_source, "
"state, user_context, pool_id "
"FROM lease6" }
```
It just so happens that Postgresql returns them ordered by address most of the time, but it isn't guaranteed.
Same is true for the corresponding MySQL query, they should both have "order by address".kea2.4.0Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2762Lease user context processing can be made more consistent2023-03-09T14:47:03ZFrancis DupontLease user context processing can be made more consistentFor instance it is possible to add using directly the API a lease user context which is not a map: with SQL backends to try to retrieve the lease throws including in a returning collection method without giving the address of the lease...For instance it is possible to add using directly the API a lease user context which is not a map: with SQL backends to try to retrieve the lease throws including in a returning collection method without giving the address of the lease...next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2688MariaDB Connector Time Out Issue:2023-07-31T11:35:19ZPeter DaviesMariaDB Connector Time Out Issue:MariaDB Connector Time Out Issue:
In a setup with two DHCP servers connected to a MariaDB Galera cluster replicating
the data between the nodes, a read call occasionally hangs; it is unclear why.
The servers connect to a database...MariaDB Connector Time Out Issue:
In a setup with two DHCP servers connected to a MariaDB Galera cluster replicating
the data between the nodes, a read call occasionally hangs; it is unclear why.
The servers connect to a database via a local ha_proxy. The ha_proxy can switch
the database connection to another database instance when it detects a database
failure. The ha_proxy configuration for each node includes the
`on-marked-down shutdown-sessions` clause. It should terminate the connection
from the Kea server upon database failure. In theory, the Kea server should be
able to reconnect to another database instance (via the same proxy) because it
is configured with max-reconnect-tries=2 and reconnect-wait-time=1000.
One of Kea's threads may hang during reading from the database after updating
lease information. This will pause the execution of periodic tasks and the
processing of DHCP requests. If, however, Kea is configured with HA and the
"dedicated-listener" Kea will reply to heartbeats commands from its partner.
As a result, the partner will believe the server is operational.
```
if (!timeout)
timeout= -1;
do {
rc= poll(&p_fd, 1, timeout);
} while (rc == -1 && errno == EINTR);
```
The libc poll() function blocks the call when the timeout is negative. In other
words, if the application using the MariaDB connector (Kea in this case) doesn't
set the read timeout for the connection, the read from the database may never
return, causing the hang in the application. The function may return upon the
TCP connection timeout; this may take a relatively time.
It has not been possible to provoke a hang, on cutover to a different database;
the outcome is either a correct switchover or a shutdown. Shutdowns appear to
occur when the database switchover takes longer than 2 seconds. One should consider
bumping up the max-reconnect-tries or the reconnect-wait-time (or both) if the
termination frequently occurs instead of the switchover.
Using `iptables` to block the traffic from the "ha_proxy" to the database while
the server was running and allocating leases can cause Kea to hang.
Kea needs an additional configuration knob (or knobs) to configure the database
read timeouts. Currently, it is always to 0. The possible limitations are that
these timeouts are only valid for some MySQL versions (but versions not supporting
it are pretty old), and only for TCP connections (not UNIX domain socket connections).
This means we may need some additional logic to validate if this setting applies.kea2.3.4Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2499don't extend dhcpdb_create scripts any more2024-03-27T13:32:29ZWlodzimierz Wenceldon't extend dhcpdb_create scripts any moreWe should stop to make two paths of database creation. It leads to mistakes more work during releases additional jobs to check differences. So rather to develop scripts like `dhcpdb_create.mysql` (`dhcpdb_create.pgsql`) and upgrade scrip...We should stop to make two paths of database creation. It leads to mistakes more work during releases additional jobs to check differences. So rather to develop scripts like `dhcpdb_create.mysql` (`dhcpdb_create.pgsql`) and upgrade scripts (eg. upgrade_009_to_010.sh.in) separately we should develop just upgrade scripts which will be executed by dhcpdb_create.sh script.
It's ugly to do it this late in a process but it will make our life much easier in the future.
- [ ] as part of the refactor process, please make sure there's a VERY good reason why there's .in version that needs to be expanded during configure.next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/2479Documentation - upgrading Kea servers with a common DB backend2023-07-31T13:34:54ZPeter DaviesDocumentation - upgrading Kea servers with a common DB backend**Documentation - upgrading Kea servers with a common DB backend**
Kea implementations where servers do not share common databases Kea may be upgraded individually.
In this way the down time of dhcp services may be limited.
Some u...**Documentation - upgrading Kea servers with a common DB backend**
Kea implementations where servers do not share common databases Kea may be upgraded individually.
In this way the down time of dhcp services may be limited.
Some users employ a common database backend for leases and/or configuration data.
As Kea software upgrades normally increment database schema versions, individual upgrades may have unfortunate side effects.
We would like advice regarding this type of upgrade added to:
4.3.2.2 Upgrading a MySQL Database From an Earlier Version of Kea
4.3.3.3 Upgrading a PostgreSQL Database From an Earlier Version of Keanext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2345Kea 2.0.0 Fails to Allocate Leases2022-11-02T15:10:41ZALOK KUMAR SINGHKea 2.0.0 Fails to Allocate LeasesWe are using Kea 2.0.0 version with backend database postgresql and observer an issue where lease not getting allocated/extended and producing below error message.
Note: Kea and Postgresql database is installed on same VM and has timez...We are using Kea 2.0.0 version with backend database postgresql and observer an issue where lease not getting allocated/extended and producing below error message.
Note: Kea and Postgresql database is installed on same VM and has timezone EST set, also database timezone is set to EST but still this issue is happening, though this was running perfect from last 3 months after an upgrade from 1.5.0P1 to 2.0.0
```
2022-03-07 01:48:13.030 DEBUG [kea-dhcp4.dhcp4/1541.140278882691264] DHCP4_CLASS_ASSIGNED [hwtype=1 9c:ad:97:16:83:2f], cid=[01:9c:ad:97:16:83:2f], tid=0x23d07203: client packet has been assigned to the following class(es): UNKNOWN
2022-03-07 01:48:13.030 DEBUG [kea-dhcp4.dhcp4/1541.140278882691264] DHCP4_CLASS_ASSIGNED [hwtype=1 9c:ad:97:16:83:2f], cid=[01:9c:ad:97:16:83:2f], tid=0x23d07203: client packet has been assigned to the following class(es): ALL, HA_codcmdndh001, VENDOR_CLASS_MSFT 5.0, UNKNOWN
2022-03-07 01:48:13.030 DEBUG [kea-dhcp4.ddns/1541.140278882691264] DHCP4_CLIENT_FQDN_PROCESS [hwtype=1 9c:ad:97:16:83:2f], cid=[01:9c:ad:97:16:83:2f], tid=0x23d07203: processing Client FQDN option
2022-03-07 01:48:13.030 DEBUG [kea-dhcp4.ddns/1541.140278882691264] DHCP4_CLIENT_FQDN_DATA [hwtype=1 9c:ad:97:16:83:2f], cid=[01:9c:ad:97:16:83:2f], tid=0x23d07203: Client sent FQDN option: type=81 (CLIENT_FQDN), flags: (N=0, E=0, O=0, S=0), domain-name='compy' (partial)
2022-03-07 01:48:13.030 DEBUG [kea-dhcp4.ddns/1541.140278882691264] DHCP4_RESPONSE_FQDN_DATA [hwtype=1 9c:ad:97:16:83:2f], cid=[01:9c:ad:97:16:83:2f], tid=0x23d07203: including FQDN option in the server's response: type=81 (CLIENT_FQDN), flags: (N=1, E=0, O=0, S=0), domain-name='compy.' (full)
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.dhcpsrv/1541.140278882691264] DHCPSRV_PGSQL_GET_CLIENTID obtaining IPv4 leases for client ID 01:9c:ad:97:16:83:2f
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.hosts/1541.140278882691264] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id 2 and IPv4 address 10.52.67.126
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.hosts/1541.140278882691264] HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4 address 10.52.67.126
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.hosts/1541.140278882691264] HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 10.52.67.126, found 0 host(s)
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.hosts/1541.140278882691264] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet id 2 and address 10.52.67.126
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.dhcpsrv/1541.140278882691264] DHCPSRV_PGSQL_GET_ADDR4 obtaining IPv4 lease for address 10.52.67.126
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.alloc-engine/1541.140278882691264] ALLOC_ENGINE_V4_REQUEST_EXTEND_LEASE [hwtype=1 9c:ad:97:16:83:2f], cid=[01:9c:ad:97:16:83:2f], tid=0x23d07203: extending lifetime of the lease for address 10.52.67.126
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.dhcpsrv/1541.140278882691264] DHCPSRV_PGSQL_UPDATE_ADDR4 updating IPv4 lease for address 10.52.67.126
2022-03-07 01:48:13.031 ERROR [kea-dhcp4.alloc-engine/1541.140278882691264] ALLOC_ENGINE_V4_ALLOC_ERROR [hwtype=1 9c:ad:97:16:83:2f], cid=[01:9c:ad:97:16:83:2f], tid=0x23d07203: error during attempt to allocate an IPv4 address: unable to update lease for address 10.52.67.126 as it does not exist
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.bad-packets/1541.140278882691264] DHCP4_PACKET_NAK_0004 [hwtype=1 9c:ad:97:16:83:2f], cid=[01:9c:ad:97:16:83:2f], tid=0x23d07203: failed to grant a lease, client sent ciaddr 0.0.0.0, requested-ip-address 10.52.67.126
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.callouts/1541.140278882691264] HOOKS_CALLOUTS_BEGIN begin all callouts for hook leases4_committed
```
[6mar.pcap](/uploads/819df2d10bd7335b39dae233f837379e/6mar.pcap)[kea-dhcp4.log.10](/uploads/64ac95d818035cf59d7ba2f75604e770/kea-dhcp4.log.10)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2331Kea-Admin db-upgrade fails if using different Port for pgsql2023-07-05T10:39:19ZAlex GastKea-Admin db-upgrade fails if using different Port for pgsql---
name: Kea-Admin db-upgrade fails if using different Port for pgsql
about: Kea-Admin should respect supplied Port (-P) Parameter for doing db-upgrade
---
**Bug Description**
When doing the `db-upgrade` with `kea-admin` using a pgs...---
name: Kea-Admin db-upgrade fails if using different Port for pgsql
about: Kea-Admin should respect supplied Port (-P) Parameter for doing db-upgrade
---
**Bug Description**
When doing the `db-upgrade` with `kea-admin` using a pgsql-Backend with a port different than 5432 the update fails.
The `-P` Parameter is used and verified before but does not work in the real upgrade process.
Starting the PostgreSQL Database on the default-port and omitting the Port-Parameter the update works well.
Example:
```
kea-admin db-upgrade pgsql -h localhost -P 5435 -u kea -p "<my-fancy-password>" -n kea
Database version reported before upgrade: 8.0
Processing /usr/share/kea/scripts/pgsql/upgrade_001.0_to_002.0.sh file...
This script upgrades 1.0 to 2.0. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_002.0_to_003.0.sh file...
This script upgrades 2.0 to 3.0. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_003.0_to_003.1.sh file...
This script upgrades 3.0 to 3.1. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_003.1_to_003.2.sh file...
This script upgrades 3.1 to 3.2. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_003.2_to_003.3.sh file...
This script upgrades 3.2 to 3.3. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_003.3_to_004.0.sh file...
This script upgrades 3.3 to 4.0. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_004.0_to_005.0.sh file...
This script upgrades 4.0 to 5.0. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_005.0_to_005.1.sh file...
This script upgrades 5.0 to 5.1. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_005.1_to_006.0.sh file...
This script upgrades 5.1 to 6.0. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_006.0_to_006.1.sh file...
This script upgrades 6.0 to 6.1. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_006.1_to_006.2.sh file...
This script upgrades 6.1 to 6.2. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_006.2_to_007.0.sh file...
This script upgrades 6.2 to 7.0. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_007_to_008.sh file...
This script upgrades 7.0 to 8.0. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_008_to_009.sh file...
psql: error: could not connect to server: Connection refused
Is the server running on host "localhost" (::1) and accepting
TCP/IP connections on port 5432?
could not connect to server: Connection refused
Is the server running on host "localhost" (127.0.0.1) and accepting
TCP/IP connections on port 5432?
```
**To Reproduce**
Steps to reproduce the behavior:
1. Use Kea with Lease-Backend on pgsql configured with a Port other than 5432
2. Do a software-upgrade (in my case via APT-Packages) [rem. might be another bug that the APT does not upgrade the db-schema itself]
3. Kea reports a wrong Schema-Version at startup.
4. Execute `kea-admin db-upgrade pgsql -h localhost -P 5435 -u kea -p "<my-fancy-password>" -n kea`
5. See that it detects the actual Schema-Version and then in the last step ends with "Connection refused" at Port 5432.
6. Run the PostgreSQL-Software at Port 5432
7. Use the above `kea-admin`-Command with the same `-P` Parameter
8. See that it can't detect the actual Schema and exits:
```
kea-admin db-upgrade pgsql -h localhost -P 5435 -u kea -p "AWlZgeouj5vkRkexSAND" -n kea
psql: error: could not connect to server: Connection refused
Is the server running on host "localhost" (::1) and accepting
TCP/IP connections on port 5435?
could not connect to server: Connection refused
Is the server running on host "localhost" (127.0.0.1) and accepting
TCP/IP connections on port 5435?
```
9. Omit the `-P`-Parameter and successfully upgrade the Schema.
10. Turn back the Database to the port used before
11. Start kea and see it running.
**Expected behavior**
The DB-Update Procedure should take full awareness of the changed port and update the database schema accordingly.
In the best case the APT update procedure should implement this step as well (for unattended updating purpose) - I'm not sure if it already does as the manual process already fails.
**Environment:**
- Kea version: 2.1.3 from Cloudsmith-Repository
- OS: Ubuntu 20.04.4 LTS, AMD64
- pgsql-Lease-Backend with Port different than 5432
**Additional Information**
Lease-Backend-Configuration:
```
"lease-database": {
"type": "postgresql",
"user": "kea",
"password": "<my-fancy-password>",
"name": "kea",
"port": 5435
},
```
As the mentioned update-script does take some parameters via `$@`-Variable kea-admin migth don't declare the `-p` or `--port` Parameter for the pgsql Backend.
Other commands like `lease-dump` do behave accordingly:
```
kea-admin lease-dump pgsql -h localhost -P 5435 -u kea -p "<my-fancy-password>" -n kea -4 -o output-dump.csv
psql: error: could not connect to server: Connection refused
Is the server running on host "localhost" (::1) and accepting
TCP/IP connections on port 5432?
could not connect to server: Connection refused
Is the server running on host "localhost" (127.0.0.1) and accepting
TCP/IP connections on port 5432?
ERROR/kea-admin: lease-dump: psql call failed, exit code: 0
```
**Contacting you**
Please reach out via the contact information on my profile or via Twitter / GitHub.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2145Some MAC's are stored in database in wrong format. Not possible to dump and r...2021-12-02T14:54:11ZJozef RebjakSome MAC's are stored in database in wrong format. Not possible to dump and restore mysql database.---
name: dhcp_identifier Bug
about: Not possible to dump and restore mysql database.
---
**Describe the bug**
Some MAC's are stored in wrong format. DHCP client can get an IP Address within LEASE. This is OK. But if we want to dump ...---
name: dhcp_identifier Bug
about: Not possible to dump and restore mysql database.
---
**Describe the bug**
Some MAC's are stored in wrong format. DHCP client can get an IP Address within LEASE. This is OK. But if we want to dump SQL database and restore database on different server then we can't because `'pOW!y'` is not `varbinary(128)`
Row from mysqldump:
```sql
INSERT INTO `hosts` (host_id, dhcp_identifier, dhcp_identifier_type, dhcp4_subnet_id, dhcp6_subnet_id, ipv4_address, hostname, dhcp4_client_classes, dhcp6_client_classes, dhcp4_next_server, dhcp4_server_hostname, dhcp4_boot_file_name, user_context, auth_key) VALUES
(807, 'pOW!y', 0, 967, NULL, 1681927831, 'cpe-l1wnx.example.com', NULL, NULL, NULL, 'dhcp.example.com', NULL, NULL, NULL),
```
**To Reproduce**
RUN
```sql
INSERT INTO `hosts` (host_id, dhcp_identifier, dhcp_identifier_type, dhcp4_subnet_id, dhcp6_subnet_id, ipv4_address, hostname, dhcp4_client_classes, dhcp6_client_classes, dhcp4_next_server, dhcp4_server_hostname, dhcp4_boot_file_name, user_context, auth_key) VALUES
(807, 0x704f57217f79, 0, 967, NULL, 1681927831, "cpe-l1wnx.example.com", NULL, NULL, NULL, "dhcp.example.com", NULL, NULL, NULL);
```
AFTER insert SELECT:
```sql
SELECT * FROM `hosts` WHERE hostname = 'cpe-l1wnx.example.com';
```
Result:
```
host_id,dhcp_identifier,dhcp_identifier_type,dhcp4_subnet_id,dhcp6_subnet_id,ipv4_address,hostname,dhcp4_client_classes,dhcp6_client_classes,dhcp4_next_server,dhcp4_server_hostname,dhcp4_boot_file_name,user_context,auth_key
807,pOW!y,0,967,NULL,1681927831,cpe-l1wnx.example.com,NULL,NULL,NULL,dhcp.example.com,NULL,NULL,NULL
```
**Expected behavior**
MAC `70:4F:57:21:7F:79` should be stored in dhcp_identifier as `0x704f57217f79` and not as 'pOW!y'. MacVendor is telling that it's TP-LINK TECHNOLOGIES CO.,LTD. so I believe that MAC is right.
**Environment:**
- Kea version: 1.9.11
- OS: Ubuntu 20.04
- SQL: MariaDB 10.5.9https://gitlab.isc.org/isc-projects/kea/-/issues/2094Dangling option data after removing a class from the config backend2021-09-20T21:50:03ZMarcin SiodelskiDangling option data after removing a class from the config backendMySQL CB schema must be updated to add CASCADE deletion of the options for deleted client classes. Currently, when a class is removed, the option remains in the database.MySQL CB schema must be updated to add CASCADE deletion of the options for deleted client classes. Currently, when a class is removed, the option remains in the database.kea2.0.0 (formerly 1.9.12)Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2091class evaluation from db does not work2021-09-16T12:38:18ZWlodzimierz Wencelclass evaluation from db does not workI've tried exactly the same class configuration in file and in db config backend. In configuration it worked correctly but there is an error when classes are pulled from database:
`ERROR [kea-dhcp4.options/21088.139705724942080] EVAL_RE...I've tried exactly the same class configuration in file and in db config backend. In configuration it worked correctly but there is an error when classes are pulled from database:
`ERROR [kea-dhcp4.options/21088.139705724942080] EVAL_RESULT Expression modem evaluated to Incorrect stack order. Expected exactly 1 value at the end of evaluation, got 0`
Scenario 1:
1. configure kea with class in config file (subnets in db), `config-get` return:
```
{
"Dhcp4": {
"authoritative": false,
"boot-file-name": "",
"calculate-tee-times": false,
"client-classes": [
{
"boot-file-name": "",
"name": "modem",
"next-server": "0.0.0.0",
"option-data": [],
"option-def": [],
"server-hostname": "",
"test": "hexstring(pkt4.mac, ':') == '00:00:00:00:00:01'"
}
],
"config-control": {
"config-databases": [
{
"name": "keadb",
"password": "keapass",
"type": "mysql",
"user": "keauser"
}
]
},
"control-socket": {
"socket-name": "/home/wlodek/installed/git/var/run/kea/control_socket",
"socket-type": "unix"
},
"ddns-generated-prefix": "myhost",
"ddns-override-client-update": false,
"ddns-override-no-update": false,
"ddns-qualifying-suffix": "",
"ddns-replace-client-name": "never",
"ddns-send-updates": true,
"ddns-update-on-renew": false,
"ddns-use-conflict-resolution": true,
"decline-probation-period": 86400,
"dhcp-ddns": {
"enable-updates": false,
"max-queue-size": 1024,
"ncr-format": "JSON",
"ncr-protocol": "UDP",
"sender-ip": "0.0.0.0",
"sender-port": 0,
"server-ip": "127.0.0.1",
"server-port": 53001
},
"dhcp-queue-control": {
"capacity": 64,
"enable-queue": false,
"queue-type": "kea-ring4"
},
"dhcp4o6-port": 0,
"echo-client-id": true,
"expired-leases-processing": {
"flush-reclaimed-timer-wait-time": 25,
"hold-reclaimed-time": 3600,
"max-reclaim-leases": 100,
"max-reclaim-time": 250,
"reclaim-timer-wait-time": 10,
"unwarned-reclaim-cycles": 5
},
"hooks-libraries": [
{
"library": "/home/wlodek/installed/git/lib/kea/hooks/libdhcp_cb_cmds.so"
},
{
"library": "/home/wlodek/installed/git/lib/kea/hooks/libdhcp_mysql_cb.so"
}
],
"host-reservation-identifiers": [
"hw-address",
"duid",
"circuit-id",
"client-id"
],
"hostname-char-replacement": "",
"hostname-char-set": "[^A-Za-z0-9.-]",
"interfaces-config": {
"interfaces": [
"enp0s9"
],
"re-detect": true
},
"ip-reservations-unique": true,
"lease-database": {
"type": "memfile"
},
"loggers": [
{
"debuglevel": 99,
"name": "kea-dhcp4",
"output_options": [
{
"output": "/home/wlodek/installed/git/var/log/kea.log"
}
],
"severity": "DEBUG"
}
],
"match-client-id": true,
"multi-threading": {
"enable-multi-threading": true,
"packet-queue-size": 16,
"thread-pool-size": 2
},
"next-server": "0.0.0.0",
"option-data": [],
"option-def": [],
"reservations-global": false,
"reservations-in-subnet": true,
"reservations-out-of-pool": false,
"sanity-checks": {
"lease-checks": "warn"
},
"server-hostname": "",
"server-tag": "abc",
"shared-networks": [],
"statistic-default-sample-age": 0,
"statistic-default-sample-count": 20,
"store-extended-info": false,
"subnet4": [
{
"4o6-interface": "",
"4o6-interface-id": "",
"4o6-subnet": "",
"client-class": "modem",
"id": 1,
"interface": "enp0s9",
"option-data": [],
"pools": [
{
"option-data": [],
"pool": "192.168.50.1-192.168.50.100"
}
],
"relay": {
"ip-addresses": []
},
"reservations": [],
"subnet": "192.168.50.0/24"
}
],
"t1-percent": 0.5,
"t2-percent": 0.875,
"valid-lifetime": 7200
}
},
"result": 0
}
```
and logs for incoming pkt:
```
2021-09-15 10:29:24.078 DEBUG [kea-dhcp4.eval/10419.140439989733120] EVAL_DEBUG_PKT4 Pushing PKT4 field mac with value 0x000000000001
2021-09-15 10:29:24.078 DEBUG [kea-dhcp4.eval/10419.140439989733120] EVAL_DEBUG_STRING Pushing text string ':'
2021-09-15 10:29:24.078 DEBUG [kea-dhcp4.eval/10419.140439989733120] EVAL_DEBUG_TOHEXSTRING Popping binary value 0x000000000001 and separator :, pushing result 00:00:00:00:00:01
2021-09-15 10:29:24.078 DEBUG [kea-dhcp4.eval/10419.140439989733120] EVAL_DEBUG_STRING Pushing text string '00:00:00:00:00:01'
2021-09-15 10:29:24.078 DEBUG [kea-dhcp4.eval/10419.140439989733120] EVAL_DEBUG_EQUAL Popping 0x30303A30303A30303A30303A30303A3031 and 0x30303A30303A30303A30303A30303A3031 pushing result 'true'
2021-09-15 10:29:24.078 INFO [kea-dhcp4.options/10419.140439989733120] EVAL_RESULT Expression modem evaluated to 1
```
all is fine :)
Scenario 2:
configure class in db backend:
```
{'arguments': {'client-classes': [{'boot-file-name': '',
'name': 'modem',
'next-server': '0.0.0.0',
'option-data': [],
'option-def': [],
'server-hostname': '',
'test': "hexstring(pkt4.mac, ':') == "
"'00:00:00:00:00:01'",
'valid-lifetime': 7200}], <<<<< in here I have to add value equal to default, forge limitation :(
'remote': {'type': 'mysql'},
'server-tags': ['all']},
'command': 'remote-class4-set',
'service': ['dhcp4']}
[
{
"arguments": {
"client-classes": [
{
"name": "modem"
}
]
},
"result": 0,
"text": "DHCPv4 client class successfully set."
}
]
```
`config-get` return:
```
{'arguments': {}, 'command': 'config-get', 'service': ['dhcp4']}
[
{
"arguments": {
"Dhcp4": {
"authoritative": false,
"boot-file-name": "",
"calculate-tee-times": false,
"client-classes": [
{
"boot-file-name": "",
"name": "modem",
"next-server": "0.0.0.0",
"option-data": [],
"option-def": [],
"server-hostname": "",
"test": "hexstring(pkt4.mac, ':') == '00:00:00:00:00:01'",
"valid-lifetime": 7200
}
],
"config-control": {
"config-databases": [
{
"name": "keadb",
"password": "keapass",
"type": "mysql",
"user": "keauser"
}
]
},
"control-socket": {
"socket-name": "/home/wlodek/installed/git/var/run/kea/control_socket",
"socket-type": "unix"
},
"ddns-generated-prefix": "myhost",
"ddns-override-client-update": false,
"ddns-override-no-update": false,
"ddns-qualifying-suffix": "",
"ddns-replace-client-name": "never",
"ddns-send-updates": true,
"ddns-update-on-renew": false,
"ddns-use-conflict-resolution": true,
"decline-probation-period": 86400,
"dhcp-ddns": {
"enable-updates": false,
"max-queue-size": 1024,
"ncr-format": "JSON",
"ncr-protocol": "UDP",
"sender-ip": "0.0.0.0",
"sender-port": 0,
"server-ip": "127.0.0.1",
"server-port": 53001
},
"dhcp-queue-control": {
"capacity": 64,
"enable-queue": false,
"queue-type": "kea-ring4"
},
"dhcp4o6-port": 0,
"echo-client-id": true,
"expired-leases-processing": {
"flush-reclaimed-timer-wait-time": 25,
"hold-reclaimed-time": 3600,
"max-reclaim-leases": 100,
"max-reclaim-time": 250,
"reclaim-timer-wait-time": 10,
"unwarned-reclaim-cycles": 5
},
"hooks-libraries": [
{
"library": "/home/wlodek/installed/git/lib/kea/hooks/libdhcp_cb_cmds.so"
},
{
"library": "/home/wlodek/installed/git/lib/kea/hooks/libdhcp_mysql_cb.so"
}
],
"host-reservation-identifiers": [
"hw-address",
"duid",
"circuit-id",
"client-id"
],
"hostname-char-replacement": "",
"hostname-char-set": "[^A-Za-z0-9.-]",
"interfaces-config": {
"interfaces": [
"enp0s9"
],
"re-detect": true
},
"ip-reservations-unique": true,
"lease-database": {
"type": "memfile"
},
"loggers": [
{
"debuglevel": 99,
"name": "kea-dhcp4",
"output_options": [
{
"output": "/home/wlodek/installed/git/var/log/kea.log"
}
],
"severity": "DEBUG"
}
],
"match-client-id": true,
"multi-threading": {
"enable-multi-threading": true,
"packet-queue-size": 16,
"thread-pool-size": 2
},
"next-server": "0.0.0.0",
"option-data": [],
"option-def": [],
"reservations-global": false,
"reservations-in-subnet": true,
"reservations-out-of-pool": false,
"sanity-checks": {
"lease-checks": "warn"
},
"server-hostname": "",
"server-tag": "abc",
"shared-networks": [],
"statistic-default-sample-age": 0,
"statistic-default-sample-count": 20,
"store-extended-info": false,
"subnet4": [
{
"4o6-interface": "",
"4o6-interface-id": "",
"4o6-subnet": "",
"client-class": "modem",
"id": 1,
"interface": "enp0s9",
"option-data": [],
"pools": [
{
"option-data": [],
"pool": "192.168.50.1-192.168.50.100"
}
],
"relay": {
"ip-addresses": []
},
"reservations": [],
"subnet": "192.168.50.0/24"
}
],
"t1-percent": 0.5,
"t2-percent": 0.875,
"valid-lifetime": 7200
}
},
"result": 0
}
]
```
logs of evaluation:
```
2021-09-15 10:35:24.150 DEBUG [kea-dhcp4.options/27331.140580890797824] DHCP4_BUFFER_UNPACK parsing buffer received from 0.0.0.0 to 255.255.255.255 over interface enp0s9
2021-09-15 10:35:24.151 ERROR [kea-dhcp4.options/27331.140580890797824] EVAL_RESULT Expression modem evaluated to Incorrect stack order. Expected exactly 1 value at the end of evaluation, got 0
2021-09-15 10:35:24.151 DEBUG [kea-dhcp4.packets/27331.140580890797824] DHCP4_SUBNET_SELECTION_FAILED [hwtype=1 00:00:00:00:00:01], cid=[no info], tid=0x334954: failed to select subnet for the client
2021-09-15 10:35:24.151 DEBUG [kea-dhcp4.bad-packets/27331.140580890797824] DHCP4_PACKET_DROP_0002 [hwtype=1 00:00:00:00:00:01], cid=[no info], tid=0x334954, from interface enp0s9: no suitable subnet configured for a direct client
```
so yeah... didn't work for me :(kea2.0.0 (formerly 1.9.12)