Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2020-01-09T16:56:32Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/1029New built-in client class for incomplete unpacking2020-01-09T16:56:32ZFrancis DupontNew built-in client class for incomplete unpackingCurrent Kea accepts packets which have a not fatal error during unpacking. I believe it was added by @tmark: in such case the SkipRemainingOptionsError exception is thrown and processing continue.
I'd like to put such packets in a new b...Current Kea accepts packets which have a not fatal error during unpacking. I believe it was added by @tmark: in such case the SkipRemainingOptionsError exception is thrown and processing continue.
I'd like to put such packets in a new built-in class so a "not option[xxx].exist" can't be mislead: it will be enough to add "add not member("<new-class-name>')".
This allows too to classify such packets in the DROP class so by configuration accept or drop them.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1030client class added by hooks and expressions2020-01-16T16:36:32ZFrancis Dupontclient class added by hooks and expressionsA client class added by a hook in pkt4_receive can't be used in an expression because the main classification is done before the callout. This means it can be used only directly for subnet selection, e.g. if the hook adds the class "foo"...A client class added by a hook in pkt4_receive can't be used in an expression because the main classification is done before the callout. This means it can be used only directly for subnet selection, e.g. if the hook adds the class "foo" you can guard a subnet by "foo" but not by a class "not-foo" defined by the expression "not member('foo')".
The case of pool guard is more complex because it is possible to move to the host identifier classification point using "KNOWN" or "UNKNOWN" in the expression. Of course it is simpler for required classes which are evaluated late.
This is not beyond repair but if we want to change this IMHO it is better to reconsider the whole classification design as explained in #1028.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1544user-class filtering per reservation (Microsoft DHCP)2020-12-21T13:11:08ZTomek Mrugalskiuser-class filtering per reservation (Microsoft DHCP)Some time ago there was [a discussion on kea-users](https://lists.isc.org/pipermail/kea-users/2019-April/002333.html) (note: the discussion continued in May). Here's what the user was trying to do:
> What mkangelo and I are trying to do...Some time ago there was [a discussion on kea-users](https://lists.isc.org/pipermail/kea-users/2019-April/002333.html) (note: the discussion continued in May). Here's what the user was trying to do:
> What mkangelo and I are trying to do is to replace Microsoft DHCP server which has a feature to create host reservations with
two option 67 values which are served to the client based on the class (type) of the client - for example return undionly.kpxe when client is pxe return https://api.example.com/customurl/ when client is gpxe
Here's an expression they're trying to achieve:
```
Client class is extracted from DHCP Discover packets:
IF Option [77] == gPXE
then second value is being returned
ELSEIF Option [60] == "PXEClient:Arch:00000:UNDI:002001"
then first value is returned
```
This seems like a useful feature that's provided by some other implementations.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2553EVAL_RESULT INFO or DEBUG to provide client ID2022-09-08T13:34:12ZVeroniqueEVAL_RESULT INFO or DEBUG to provide client IDHello,
It would be helpful if the line INFO or DEBUG which is printed with the EVAL_RESULT information, would provide the client identifier (in my case I am interested to have the hardware address of the client, but it could be something...Hello,
It would be helpful if the line INFO or DEBUG which is printed with the EVAL_RESULT information, would provide the client identifier (in my case I am interested to have the hardware address of the client, but it could be something else).
It would help while grepping on the log file.
Many thanks.outstandinghttps://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/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/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/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/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/1153Rewrite the client classification documentation in Kea ARM2022-11-02T15:10:17ZMarcin SiodelskiRewrite the client classification documentation in Kea ARMClient classification is a complex topic. We started simple but over the years we have added more and more feature to client classification. While reviewing the most recent addition to client classification in #1139 we found that certain...Client classification is a complex topic. We started simple but over the years we have added more and more feature to client classification. While reviewing the most recent addition to client classification in #1139 we found that certain paragraphs are unclear. For example, see this thread: https://gitlab.isc.org/isc-projects/kea/-/merge_requests/686#note_115873. We think it may be now good time to rewrite the documentation about the client classification and perhaps add some diagrams explaining how it all works together.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1942Refactor ClientClassDictionary to provide indexing2022-11-02T15:10:41ZMarcin SiodelskiRefactor ClientClassDictionary to provide indexingI would like to propose refactoring the `ClientClassDictionary` internals to support indexing classes by various parameters. Right now we index by class names and we have an ordered index. In #1836 we are adding a change which matches cl...I would like to propose refactoring the `ClientClassDictionary` internals to support indexing classes by various parameters. Right now we index by class names and we have an ordered index. In #1836 we are adding a change which matches classes with configured server identifiers. Without indexing, such matching is sub-optimal. Perhaps, if we migrate the class collection to multi index container we could easily add additional indexing if necessary.backloghttps://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/2736valid-lifetime and required client classes2023-01-26T14:25:43ZPeter Daviesvalid-lifetime and required client classesvalid-lifetime and required client classes:
When defining "valid-lifetime" in a client class the value takes precedence over
the global and subnet values. This does not happen when the class is defined as
"only-if-required" and...valid-lifetime and required client classes:
When defining "valid-lifetime" in a client class the value takes precedence over
the global and subnet values. This does not happen when the class is defined as
"only-if-required" and the subnet is defined with "required-client-classes"
The Kea Arm suggests that "option-data" in required classes take precedence but
no mention is made of "valid-lifetime"
Quote: Required evaluation can be used to express complex dependencies like subnet membership. It can also be used to reverse
the precedence; if option-data is set in a subnet, it takes precedence over option-data in a class. If option-data
is moved to a required class and required in the subnet, a class evaluated earlier may take precedence.
The following offers a lease time with the default value of "7200" and not "123"
for clients classifed as "Class-1"
```
{
"Dhcp4": {
"interfaces-config": { "interfaces": [ "vethserver" ] },
"control-socket": { "socket-type": "unix", "socket-name": "../sockets/kea4_command" },
"lease-database": { "type": "memfile", "name": "./kea-lease4.csv", "lfc-interval": 0, "persist": true },
"client-classes": [ {
"name": "Class-1", "test": "(pkt4.mac == 0x1e503193e1a6)", "only-if-required": true, "valid-lifetime": 123 }],
"subnet4": [ {
"subnet": "10.0.1.0/24", "id": 1,
"pools": [ { "pool": "10.0.1.5 - 10.0.1.254",
"require-client-classes": [ "Class-1" ] } ] }],
"dhcp-ddns": { "enable-updates": false },
"option-data": [ {
"name": "domain-name-servers", "code": 6, "data": "1.1.1.1" }, {
"name": "routers", "code": 3, "data": "10.0.1.1" } ],
"loggers": [ {
"name": "kea-dhcp4", "output_options": [ { "output": "./kea-dhcp4.log" } ],
"severity": "DEBUG", "debuglevel": 99 } ] }
}
```
[RT #21738](https://support.isc.org/Ticket/Display.html?id=21738)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2670renew-timer and rebind-timer in client classes2023-03-03T11:49:51ZPeter Daviesrenew-timer and rebind-timer in client classesFor some users, it may be useful to be able to define "renew-timer" and "rebind-timer"
within client class definitions.
[RT #21543](https://support.isc.org/Ticket/Display.html?id=21543)For some users, it may be useful to be able to define "renew-timer" and "rebind-timer"
within client class definitions.
[RT #21543](https://support.isc.org/Ticket/Display.html?id=21543)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/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/2716reversing the priority of allocated resources in client classes would allow t...2023-05-31T19:56:05ZAndrei Pavelandrei@isc.orgreversing the priority of allocated resources in client classes would allow template-spawned inheritanceThe current behavior for client classes is that any resource (lease times, option data, v4 option definitions, v4 fields) defined in a client class is taken from the first matching class. In the following example (don't worry about its u...The current behavior for client classes is that any resource (lease times, option data, v4 option definitions, v4 fields) defined in a client class is taken from the first matching class. In the following example (don't worry about its uselessness, it's only there to prove a point), the valid lifetime of 100 is always given to clients.
```json
{
"Dhcp6": {
"client-classes": [
{
"name": "foo",
"test": "0 == 0",
"valid-lifetime": 100
},
{
"name": "bar",
"test": "0 == 0",
"valid-lifetime": 200
}
]
}
}
```
Since template classes always need to be defined first relative to their spawned class, that means that template classes always have priority over spawned classes. If a user wanted to have a value overwritten in the spawned class, they cannot do it. Having values overwritten for a more specific set of clients is a legitimate reason. Furthermore, it matches the inheritance priority in other parts of the configuration, see the `global - shared network - subnet` relationship. To exemplify, in the following configuration, nobody would ever get valid lifetime 200.
```json
{
"Dhcp6": {
"client-classes": [
{
"name": "oui-vendor",
"template-test": "hexstring(substring(option[1].hex, 4, 3), ':')",
"valid-lifetime": 100
},
{
"name": "SPAWN_oui-vendor_01:02:03",
"valid-lifetime": 200
}
]
}
}
```outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2911New classification expressions "contains"2023-06-15T14:01:23ZCarsten StrotmannNew classification expressions "contains"---
name: Feature request
about: New classification expressions "contains"
---
Sometimes I find the need to classify a DHCP client based on a string of byte-sequence in the DHCP request, but the string or byte-sequence might vary in po...---
name: Feature request
about: New classification expressions "contains"
---
Sometimes I find the need to classify a DHCP client based on a string of byte-sequence in the DHCP request, but the string or byte-sequence might vary in position inside the packet (option) data (based on version of the client product).
A new classification expression that will search a sub-string or byte-sequence inside packet data and reporting the boolean value based on the existence of this sub-string or byte-sequence would be helpful.
Proposed example:
```
"client-classes": [
{ "name": "foo",
"test": "contains(substring(option[60].hex,0,3),'bar','i')",
"option-data": [{
"name": "domain-name", "data": "bar.example.com" }]
},
{ "name": "baz",
"test": "contains(hexstring(option[55].hex),'01:79:03','')",
"option-data": [{
"name": "domain-name", "data": "quux.example.com" }]
},
```
Proposed syntax format
contains('base-string','search-string','options')
where 'options' modify the search, e.g. using 'i' for case-insensitive searchnext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2917VENDOR_CLASS_ not assigned if kea-dhcp4 receives two or more options of code 602023-06-22T13:38:46ZAndrei Pavelandrei@isc.orgVENDOR_CLASS_ not assigned if kea-dhcp4 receives two or more options of code 60If kea-dhcp4 receives two or more options of code 60, it concatenates them under a single option which is then parsed as a byte-array rather than a string. Not a confirmed use case by any stretch, but potential clients sending two option...If kea-dhcp4 receives two or more options of code 60, it concatenates them under a single option which is then parsed as a byte-array rather than a string. Not a confirmed use case by any stretch, but potential clients sending two options might theoretically expect to be treated as two vendors simultaneously rather than as a single vendor with a kludgy ID. `VENDOR_CLASS_` is not assigned at all to the packet as it usually is when a single option is received. Arguably, it would be better if all vendor classes were assigned or at least one of them.
- Here is how Kea logs a 4-length option 60: `type=060, len=004: "1234" (string)` followed by `DHCP4_CLASS_ASSIGNED [...] client packet has been assigned to the following class(es): ALL, VENDOR_CLASS_1234, UNKNOWN`
- Here is how Kea logs two 4-length options with values `1234` and `5678`: `type=060, len=008: 31:32:33:34:35:36:37:38` followed by `DHCP4_CLASS_ASSIGNED [...] client packet has been assigned to the following class(es): ALL, UNKNOWN`
Tested on current master f390f5ac984b815c67d1af14882a83cfc38d69ab, but happens on 2.2.0 as well.
Capture, config, and log, that help in observing the issue:
- [capture.pcap](/uploads/9091b90e7c58f27228514dbc372ad6c2/capture.pcap)
- [kea-dhcp4.conf](/uploads/c87797a78fc1efb7d8a71c2c4c25e887/kea-dhcp4.conf)
- [kea.log](/uploads/f25867508f64c40acac633d99caa4885/kea.log)next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/1588EVAL_RESULT displays boolean status as an integer2023-07-05T10:39:18ZFrancis DupontEVAL_RESULT displays boolean status as an integerFor instance ```EVAL_RESULT Expression 53148-RU evaluated to 1``` should be ```EVAL_RESULT Expression 53148-RU evaluated to true``` so all uses of EVAL_RESULT should set std::boolalpha or convert the boolean into false and true directly.For instance ```EVAL_RESULT Expression 53148-RU evaluated to 1``` should be ```EVAL_RESULT Expression 53148-RU evaluated to true``` so all uses of EVAL_RESULT should set std::boolalpha or convert the boolean into false and true directly.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/1028New classification design.2023-07-31T11:54:22ZFrancis DupontNew classification design.Some proposals for a new classification design:
- replace the list+set by a multi-index
- replace the required-xxx by a more direct add-client-classes.
- add this new add-client-classes to host reservations as an alias of the existing...Some proposals for a new classification design:
- replace the list+set by a multi-index
- replace the required-xxx by a more direct add-client-classes.
- add this new add-client-classes to host reservations as an alias of the existing client-classes (same entry with the same behavior for all objects which add a class to the query)
- complete the list of class evaluation points:
* new points after the deferred unpack, pkt*_receive hook, etc
* make clear in the doc that which a classification point is for:
+ dependency on a packet procession phase (e.g. KNOWN/UNKNOWN)
+ usage for the next packet processing step (e.g. subnet selection, pool guard, output option)
* add an enum (vs a few flags) for the point where a class must be evaluated
* add a meta-data with the value of its enum and make it visible to users
- same rules on dependency (use of member in expression):
* no forward reference (the user class in a member clause must be already defined)
* get the last classification point
* perhaps a new built-in class for instance for the pkt*_receive hook
- document the way to switch from expired-* to this new stuff (but do not develop a tool to translate configurations)
- (next steps?) new uses of classes (e.g. lifetime), new expressions (e.g. in the response vs the query): in almost all cases this means new classification pointsnext-stable-3.0