Yes, they do.
-----Original Message-----
From: Thomas Markwalder [mailto:[email protected]]
Sent: Tuesday, March 17, 2020 3:53 PM
To: Stephan Walter <[email protected]>
Subject: Re: [Kea-users] Kea 1.1-epel conf no longer work with kea 1.6
Do your clients use the same MAC address throughout the boot process?
On 3/17/20 10:27 AM, Stephan Walter wrote:
> Dear Thomas,
>
> That seems to be the behavior with kea 1.6, but with kea 1.1 we were able to
> assign a client class object to a specific client, so that we could use the
> same test parameter for all clients. This is no longer possible. The question
> is how to get the same behavior again?
>
> I will attach an example with two nodes, so that it is clear what the problem
> is.
>
> Best Regards,
>
> Stephan Walter
>
> {
> "Dhcp4": {
> "interfaces-config": {
> "interfaces": ["mvlprov"]
> },
> "control-socket": {
> "socket-type": "unix",
> "socket-name": "/tmp/kea-dhcp4-ctrl.sock"
> },
> "lease-database": {
> "type": "memfile",
> "lfc-interval": 1800
> },
> "expired-leases-processing": {
> "reclaim-timer-wait-time": 10,
> "flush-reclaimed-timer-wait-time": 25,
> "hold-reclaimed-time": 3600,
> "max-reclaim-leases": 100,
> "max-reclaim-time": 250,
> "unwarned-reclaim-cycles": 5
> },
> "renew-timer": 900,
> "rebind-timer": 1800,
> "valid-lifetime": 3600,
> "option-data": [ ],
> "client-classes": [
>
>
> {
> "name": "INIT_intel01",
> "test": "substring(option[60].hex,0,4) == 'udhcp'",
> "boot-file-name": "vnfs=centos7.stateless\n\\,group=isle1"
> },
>
> {
> "name": "INIT_intel10",
> "test": "substring(option[60].hex,0,4) == 'udhcp'",
> "boot-file-name": "vnfs=centos7.stateless\n\\,group=isle1"
> },
>
> {
> "name": "INIT_intel11",
> "test": "substring(option[60].hex,0,4) == 'udhcp'",
> "boot-file-name": "vnfs=centos7.stateless\n\\,group=isle1"
> },
>
> {
> "name": "bios",
> "test": "option[93].hex == 0x0000",
> "boot-file-name": "/var/lib/tftp/bios/lpxelinux.0"
> },
> {
> "name": "ipxe_efi64",
> "test": "option[93].hex == 0x0007",
> "boot-file-name": "/var/lib/tftp/efi64/ipxe.efi"
> },
> {
> "name": "efi64",
> "test": "option[93].hex == 0x0009",
> "boot-file-name": "/var/lib/tftp/efi64/bootx64.efi"
> }
> ],
> "subnet4": [
> {
> "subnet": "10.10.0.0/16",
>
> "reservations": [
> { "hw-address": "A4:XX:01:29:YY:3E", "ip-address": "10.10.40.1",
> "next-server": "10.10.1.11", "hostname": "intel01", "client-classes":
> ["INIT_intel01"], "server-hostname": "10.10.1.21"}, { "hw-address":
> "A4:XX:01:2D:YY:AC", "ip-address": "10.10.40.10", "next-server":
> "10.10.1.11", "hostname": "intel10", "client-classes":
> ["INIT_intel10"], "server-hostname": "10.10.1.21"}, { "hw-address":
> "A4:xx:01:2D:YY:4C", "ip-address": "10.10.40.11", "next-server":
> "10.10.1.11", "hostname": "intel11", "client-classes":
> ["INIT_intel11"], "server-hostname": "10.10.1.21"},
>
> ]
> }
> ]
> },
> "DhcpDdns": {
> "ip-address": "127.0.0.1",
> "port": 53001,
> "tsig-keys": [],
> "forward-ddns" : {},
> "reverse-ddns" : {}
> },
> "Logging": {
> "loggers": [
> {
> "name": "kea-dhcp4",
> "output_options": [
> {
> "output": "stdout",
> "flush": false
> }
> ],
> "severity": "INFO",
> "debuglevel": 0
> },
> {
> "name": "kea-dhcp-ddns",
> "output_options": [
> {
> "output": "stdout"
> }
> ],
> "severity": "INFO",
> "debuglevel": 0
> }
> ]
> }
> }
>
> So with this config we are able to provide during the first boot as
> boo-tfile-name the lpxe, ipxe or bootx files, while afterward we provide the
> node specific string defined within the client class. This is working, and we
> have to get the same mechanism with 1.6, but I don't know how we can provide
> within the reservation the necessary information, what we have to provide to
> the specific client within the second/third request. The node itself doesn't
> know anything about this settings. Only kea!
>
>
> -----Original Message-----
> From: Kea-users [mailto:[email protected]] On Behalf Of
> Thomas Markwalder
> Sent: Tuesday, March 17, 2020 2:49 PM
> To: [email protected]
> Subject: Re: [Kea-users] Kea 1.1-epel conf no longer work with kea 1.6
>
> Hello:
>
> If the MAC address is the same for both boot stages and that MAC address
> matches your host reservation, than you are always assigning the INODE class
> to the client, making the test expression that checks vendor id in class
> INODE relevant only for unknown clients. From your log snippet the it is
> clear that the client is being matched to the reservation and is thus being
> assigned to your class.
>
> If you want the class assignment to only occur on vendor-id (option 60), then
> remove client-classes from your reservation.
>
> Hope that helps,
>
> Thomas
> ISC Software Engineering
>
> On 3/17/20 9:27 AM, Stephan Walter wrote:
>> Hi Pavel,
>>
>> Yes I have had checked this already and have modified the logging. All the
>> other topics are not used by us. The problem we face is related to the way
>> how kea evaluates the client classes. I have checked all release notes from
>> 1.1 to 1.6 but haven't found any solution for this problem.
>>
>> The only thing I have found was with 1.4(?) the evaluation order of client
>> classes has changed from definition order to alphabetic, but even if I
>> consider this modification the same problem occurs. And by even if I don't
>> consider this, with respect to the test statement, there shouldn't be any
>> difference on the result.
>>
>> Best Regards,
>>
>> Stephan
>>
>> -----Original Message-----
>> From: Pavel Zhukov [mailto:[email protected]]
>> Sent: Tuesday, March 17, 2020 12:40 PM
>> To: Stephan Walter <[email protected]>
>> Cc: Oswald <[email protected]>;
>> [email protected]
>> Subject: Re: [Kea-users] Kea 1.1-epel conf no longer work with kea
>> 1.6
>>
>> Hi Stephan,
>>
>> Have you checked this article https://kb.isc.org/docs/upgrading-to-kea-16
>> out?
>>
>> incompatible change has been introduced in kea so manual intervention and
>> config changes are required.
>>
>> On Tue, Mar 17, 2020 at 10:16 AM Stephan Walter
>> <[email protected]> wrote:
>>> Hi,
>>>
>>> We have still the problem with the no longer working kea config. In the
>>> meantime, the epel repo was update from kea 1.1 to 1.6 so we will see now
>>> the same problem for all new installations.
>>>
>>> It would be great to get some hints how we can fix this problem. If I can
>>> provide any further details, just ask for them.
>>>
>>> Best Regards,
>>>
>>> Stephan
>>>
>>>
>>> -----Original Message-----
>>> From: Stephan Walter
>>> Sent: Wednesday, February 26, 2020 8:42 PM
>>> To: 'Stephan Walter' <[email protected]>; Oswald
>>> <[email protected]>; [email protected]
>>> Subject: RE: [Kea-users] Kea 1.1-epel conf no longer work with kea
>>> 1.6
>>>
>>> Btw if it helps, I can provide the debug output of the kea 1.1 and
>>> 1.6
>>>
>>> The strange thing is, that I see within the output two different type=60
>>> queries. One match the (I)NODE test and the other doesn't.
>>>
>>> But as explained the boot-file-name is set always to the content of the
>>> (I)NODE client-class...
>>>
>>> Below the output of the working 1.1
>>>
>>> 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.packets/103]
>>> DHCP4_BUFFER_RECEIVED received buffer from 0.0.0.0:68 to
>>> 255.255.255.255:67 over interface eno0
>>> 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.options/103]
>>> DHCP4_BUFFER_UNPACK parsing buffer received from 0.0.0.0 to
>>> 255.255.255.255 over interface eno0
>>> 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.options/103] EVAL_RESULT
>>> Expression NODE evaluated to 0
>>> 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_OPTION
>>> Pushing option 60 with value
>>> 0x505845436C69656E743A417263683A30303030303A554E44493A303032303031
>>> 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_STRING
>>> Pushing text string '0'
>>> 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_STRING
>>> Pushing text string '4'
>>> 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.eval/103]
>>> EVAL_DEBUG_SUBSTRING Popping length 4, start 0, string
>>> 0x505845436C69656E743A417263683A30303030303A554E44493A303032303031
>>> pushing result 0x50584543
>>> 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_STRING
>>> Pushing text string 'udhcp'
>>> 2020-02-26 20:06:07.671 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_EQUAL Popping
>>> 0x7564686370 and 0x50584543 pushing result 'false'
>>> 2020-02-26 20:06:07.672 INFO [kea-dhcp4.options/103] EVAL_RESULT
>>> Expression bios evaluated to 1
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_OPTION
>>> Pushing option 93 with value 0x0000
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.eval/103]
>>> EVAL_DEBUG_HEXSTRING Pushing hex string 0x0009
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_EQUAL Popping
>>> 0x0009 and 0x0000 pushing result 'false'
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.options/103] EVAL_RESULT
>>> Expression efi64 evaluated to 0
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_OPTION
>>> Pushing option 93 with value 0x0000
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.eval/103]
>>> EVAL_DEBUG_HEXSTRING Pushing hex string 0x0007
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.eval/103] EVAL_DEBUG_EQUAL Popping
>>> 0x0007 and 0x0000 pushing result 'false'
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.options/103] EVAL_RESULT
>>> Expression ipxe_efi64 evaluated to 0
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.dhcpsrv/103]
>>> DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.0.0.1/16 for packet
>>> received by matching address 10.0.103.1
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103]
>>> DHCP4_SUBNET_SELECTED [hwtype=1 b4:2e:99:XX:XX:XX], cid=[no info],
>>> tid=0x99XXXXXX: the subnet with ID 1 was selected for client
>>> assignments
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103]
>>> DHCP4_SUBNET_DATA [hwtype=1 b4:2e:99:XX:XX:XX], cid=[no info],
>>> tid=0x99XXXXXX: the selected subnet details: 10.0.0.1/16
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103]
>>> DHCP4_PACKET_RECEIVED [hwtype=1 b4:2e:99:XX:XX:XX], cid=[no info],
>>> tid=0x99XXXXXX: DHCPDISCOVER (type 1) received from 0.0.0.0 to
>>> 255.255.255.255 on interface mvlprov
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103]
>>> DHCP4_QUERY_DATA
>>> [hwtype=1 b4:2e:99:XX:XX:XX], cid=[no info], tid=0x99XXXXXX, packet
>>> details: local_address=255.255.255.255:67, remote_adress=0.0.0.0:68,
>>> msg_type=DHCPDISCOVER (1), transid=0x99XXXXXX,
>>> options:
>>> type=053, len=001: 1 (uint8)
>>> type=055, len=036: 1(uint8) 2(uint8) 3(uint8) 4(uint8) 5(uint8)
>>> 6(uint8) 11(uint8) 12(uint8) 13(uint8) 15(uint8) 16(uint8) 17(uint8)
>>> 18(uint8) 22(uint8) 23(uint8) 28(uint8) 40(uint8) 41(uint8) 42(uint8)
>>> 43(uint8) 50(uint8) 51(uint8) 54(uint8) 58(uint8) 59(uint8) 60(uint8)
>>> 66(uint8) 67(uint8) 128(uint8) 129(uint8) 130(uint8) 131(uint8) 132(uint8)
>>> 133(uint8) 134(uint8) 135(uint8)
>>> type=057, len=002: 1260 (uint16)
>>> type=060, len=032: "PXEClient:Arch:00000:UNDI:002001" (string)
>>> type=093, len=002: 0(uint16)
>>> type=094, len=003: 1 (uint8) 2 (uint8) 1 (uint8)
>>> type=097, len=017: 0 (uint8) YYYYYYYYYYYYYYYYYYYYYYYYYY (binary)
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.dhcpsrv/103]
>>> DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.0.0.1/16 for packet
>>> received by matching address 10.0.103.1
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103]
>>> DHCP4_SUBNET_SELECTED [hwtype=1 b4:2e:99:XX:XX:XX], cid=[no info],
>>> tid=0x99XXXXXX: the subnet with ID 1 was selected for client
>>> assignments
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103]
>>> DHCP4_SUBNET_DATA [hwtype=1 b4:2e:99:XX:XX:XX], cid=[no info],
>>> tid=0x99XXXXXX: the selected subnet details: 10.0.0.1/16
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.hosts/103]
>>> HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4
>>> reservation for subnet id 1, identified by hwaddr=B42E99XXXXXX
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.hosts/103]
>>> HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using
>>> identifier: hwaddr=B42E99XXXXXX
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.hosts/103]
>>> HOSTS_CFG_GET_ALL_IDENTIFIER_HOST using identifier:
>>> hwaddr=B42E99XXXXXX, found host: hwaddr=B42E99XXXXXX
>>> ipv4_subnet_id=1 hostname=my_NODE ipv4_reservation=10.0.7.1
>>> siaddr=10.0.103.25
>>> sname=10.0.103.45 file=(empty) ipv6_reservations=(none)
>>> dhcp4_class0=NODE
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.hosts/103]
>>> HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier
>>> hwaddr=B42E99XXXXXX, found 1 host(s)
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.hosts/103]
>>> HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_HOST using subnet id 1 and
>>> identifier hwaddr=B42E99XXXXXX, found host: hwaddr=B42E99XXXXXX
>>> ipv4_subnet_id=1 hostname=my_NODE ipv4_reservation=10.0.7.1
>>> siaddr=10.0.103.25 sname=10.0.103.45 file=(empty)
>>> ipv6_reservations=(none) dhcp4_class0=NODE
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.dhcp4/103]
>>> DHCP4_CLASS_ASSIGNED [hwtype=1 b4:2e:99:XX:XX:XX], cid=[no info],
>>> tid=0x99XXXXXX: client packet has been assigned to the following
>>> class(es): INIT_n0701,
>>> VENDOR_CLASS_PXEClient:Arch:00000:UNDI:002001,
>>> bios
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.ddns/103]
>>> DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 b4:2e:99:XX:XX:XX], cid=[no
>>> info], tid=0x99XXXXXX: processing client's Hostname option
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.ddns/103]
>>> DHCP4_RESERVED_HOSTNAME_ASSIGNED [hwtype=1 b4:2e:99:XXXXXX], cid=[no
>>> info], tid=0x99XXXXXX: server assigned reserved hostname my_NODE
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.dhcpsrv/103]
>>> DHCPSRV_MEMFILE_GET_SUBID_HWADDR obtaining IPv4 lease for subnet ID
>>> 1 and hardware address hwtype=1 b4:2e:99:XXXXXX
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.alloc-engine/103]
>>> ALLOC_ENGINE_V4_DISCOVER_HR client [hwtype=1 b4:2e:99:XXXXXX],
>>> cid=[no info], tid=0x99XXXXXX sending DHCPDISCOVER has reservation
>>> for the address 10.0.7.1
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.dhcpsrv/103]
>>> DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.0.7.1
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.dhcpsrv/103]
>>> DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.0.7.1
>>> 2020-02-26 20:06:07.672 INFO [kea-dhcp4.leases/103]
>>> DHCP4_LEASE_ADVERT [hwtype=1 b4:2e:99:XXXXXX], cid=[no info],
>>> tid=0x99XXXXXXX: lease 10.0.7.1 will be advertised
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.options/103]
>>> DHCP4_PACKET_PACK [hwtype=1 b4:2e:99:XXXXXX], cid=[no info],
>>> tid=0x99XXXXXXX: preparing on-wire format of the packet to be sent
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103]
>>> DHCP4_PACKET_SEND [hwtype=1 b4:2e:99:XXXXXXX], cid=[no info],
>>> tid=0x99XXXXXXXX: trying to send packet DHCPOFFER (type 2) from
>>> 10.0.103.1:67 to 255.255.255.255:68 on interface mvlprov
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103]
>>> DHCP4_RESPONSE_DATA [hwtype=1 b4:2e:99:XXXXXXX], cid=[no info],
>>> tid=0x99XXXXXXXX: responding with packet DHCPOFFER (type 2), packet
>>> details: local_address=10.0.103.1:67,
>>> remote_adress=255.255.255.255:68, msg_type=DHCPOFFER (2),
>>> transid=0x99XXXXXXX,
>>> options:
>>> type=001, len=004: 4294901760 (uint32)
>>> type=012, len=005: "my_NODE" (string)
>>> type=051, len=004: 3600 (uint32)
>>> type=053, len=001: 2 (uint8)
>>> type=054, len=004: 10.0.103.1
>>> type=058, len=004: 900 (uint32)
>>> type=059, len=004: 1800 (uint32)
>>> 2020-02-26 20:06:07.672 DEBUG [kea-dhcp4.packets/103]
>>> DHCP4_BUFFER_WAIT waiting for next DHCPv4 packet with timeout 1000
>>> ms
>>>
>>> I hope this is the full data that is required.
>>>
>>>
>>> -----Original Message-----
>>> From: Kea-users [mailto:[email protected]] On Behalf
>>> Of Stephan Walter
>>> Sent: Wednesday, February 26, 2020 7:32 PM
>>> To: Oswald <[email protected]>;
>>> [email protected]
>>> Subject: [** SUSPICIOUS EMAIL **] Re: [Kea-users] Kea 1.1-epel conf
>>> no longer work with kea 1.6
>>>
>>> Sorry, I tested INODE as well as NODE with the same result.
>>>
>>> So it is the SAME within the config, not NODE and INODE within the
>>> same file
>>>
>>>
>>> -----Original Message-----
>>> From: Kea-users [mailto:[email protected]] On Behalf
>>> Of Oswald
>>> Sent: Wednesday, February 26, 2020 7:21 PM
>>> To: [email protected]
>>> Subject: Re: [Kea-users] Kea 1.1-epel conf no longer work with kea
>>> 1.6
>>>
>>> Hie Stephan,
>>>
>>> Is the client-class "INODE" or "NODE"
>>>
>>> /Os
>>>
>>> On 26/02/2020 18:07, Stephan_Walter wrote:
>>>> Hi,
>>>>
>>>> I moved from the kea 1.1 server, provided through the epel repo of
>>>> CentOS7, to a kea 1.6 server compiled on CentOS8 from srpm.
>>>>
>>>> The new kea worked from the beginning, but when I tried to boot
>>>> nodes, they received the wrong boot-file from the kea. Let me show
>>>> the relevant part of the kea config.
>>>>
>>>>
>>>> {
>>>> "Dhcp4": {
>>>> ...
>>>> "option-data": [ ],
>>>> "client-classes": [
>>>> {
>>>> "name": "INODE",
>>>> "test": "substring(option[60].hex,0,4) == 'udhcp'",
>>>> "boot-file-name": "somefancy\n\\,string=now"
>>>> },
>>>> {
>>>> "name": "bios",
>>>> "test": "option[93].hex == 0x0000",
>>>> "boot-file-name": "/tftp/bios/lpxelinux.0"
>>>> },
>>>> {
>>>> "name": "ipxe_efi64",
>>>> "test": "option[93].hex == 0x0007",
>>>> "boot-file-name": "/tftp/efi64/ipxe.efi"
>>>> },
>>>> {
>>>> "name": "efi64",
>>>> "test": "option[93].hex == 0x0009",
>>>> "boot-file-name": "/tftp/efi64/bootx64.efi"
>>>> }
>>>> ],
>>>> "subnet4": [
>>>> {
>>>> "subnet": "10.0.0.1/16",
>>>> "reservations": [ { "hw-address":
>>>> "XX:XX:XX:XX:XX:XX", "ip-address": "10.0.2.1",
>>>> "next-server": "10.0.103.22", "hostname": "some_node", "client-classes":
>>>> ["NODE"], "server-hostname": "10.0.103.42"},
>>>> ]
>>>> ....
>>>>
>>>> }
>>>>
>>>>
>>>> So with kea 1.1 the behavior is, that the system boots through PXE
>>>> and get "/tftp/..." as boot-file-name. Afterward, the system make
>>>> again a DHCP request and now get the "somefancy.." string as
>>>> boot-file-name, that it use to fetch additional data for a two
>>>> stage boot
>>>>
>>>> With kea 1.6 already in the first response the "somefancy..."
>>>> string is replied as boot-file-name, what lead to a non working PXE boot.
>>>>
>>>> I tried now for several days without success to figure out what has
>>>> changed.
>>>>
>>>> What I have found is:
>>>>
>>>>
>>>> But even after a reordering of the client class definition, so that
>>>> the pxe boot is at the top, the problem still occurs.
>>>>
>>>> Anybody an idea how I can get with kea 1.6 the same behavior as with 1.1?
>>>>
>>>>
>>>>
>>>> --
>>>> Sent from: http://kea-users.7364.n8.nabble.com/
>>>> _______________________________________________
>>>> Kea-users mailing list
>>>> [email protected]
>>>> https://lists.isc.org/mailman/listinfo/kea-users
>>> _______________________________________________
>>> Kea-users mailing list
>>> [email protected]
>>> https://lists.isc.org/mailman/listinfo/kea-users
>>>
>>>
>>> Click
>>> https://www.mailcontrol.com/sr/TA4wI8ajHdrGX2PQPOmvUpFBc4ZD8M8Usm8CQOShYRk3_VbzlmlReMMFBOEtnguvZn5f4yhWRYpAlVq5uz6AOA==
>>> to report this email as spam.
>>> _______________________________________________
>>> Kea-users mailing list
>>> [email protected]
>>> https://lists.isc.org/mailman/listinfo/kea-users
>>> _______________________________________________
>>> Kea-users mailing list
>>> [email protected]
>>> https://lists.isc.org/mailman/listinfo/kea-users
>>>
>> --
>> Pavel Zhukov
>> Software Engineer
>> IRC: landgraf
>>
>> _______________________________________________
>> Kea-users mailing list
>> [email protected]
>> https://lists.isc.org/mailman/listinfo/kea-users
> _______________________________________________
> Kea-users mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-users
_______________________________________________
Kea-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-users
