Thanks Darren,
I am trying this way: Declaring the sub-option at the global level and
value with vendor op
"option-def": [
{
"code": 1,
"array": false,
"name": "option-1",
"type": "string",
"space": "vendor-encapsulated-options-space"
}]
Within the subnet section the option value and followed by
vendor-encapsulated-options def(without this line I still don't see the
values in the DHCPACK packet)
{
"data": "testvendorclass",
"name": " option-1",
"space": "vendor-encapsulated-options-space"
},{"name": "vendor-encapsulated-options"}
Thanks
On Fri, Jun 23, 2023 at 4:19 PM Darren Ankney <darren.ank...@gmail.com>
wrote:
> Hi Kraishak,
>
> You can put option-def in classes and in the global area. Perhaps not
> in the subnet block. I think you can place them in reservations also.
> You would have to decide what is best for your environment.
>
> Thank you,
>
> Darren Ankney
>
> On Thu, Jun 22, 2023 at 11:42 AM Kraishak Mahtha <kraishak....@gmail.com>
> wrote:
> >
> > Hi Michael,
> >
> > Thanks for sharing the reference.
> > So basically to use vendor option 43 we must implement it using the
> option space(sub-option) concept like this right?
> >
> > "option-data": [ { "name": "vendor-encapsulated-options", "always-send":
> true }, { "name": "pnpserver", "space":
> "vendor-encapsulated-options-space", "data": "5A1D;K4;B2;I192.0.2.16" }
> >
> >
> > I am a bit confused as no one confirms the statement as valid.
> >
> > My ISC config has the format below where I don't have any option spaces
> using while this option 43
> > subnet 3.4.0.0 netmask 255.255.0.0 {
> > pool {
> > range 3.4.0.2 3.4.0.5;
> > range 3.4.0.12 3.4.0.16;
> > range 3.4.0.41 3.4.0.56;
> > }
> > default-lease-time 86400;
> > max-lease-time 86400;
> > option domain-name "test.com";
> > option domain-name-servers 6.6.6.6,7.7.7.7,8.8.8.4;
> > option routers 3.4.0.1;
> > option subnet-mask 255.255.0.0;
> > option vendor-encapsulated-options "test";
> > }
> >
> > It is exactly the same except for the value test for
> vendor-encapsulated-options hence I am getting doubts. even I tried using
> the keama tool but that just converted to option 43 without any new
> sub-options defined
> >
> > On Thu, Jun 22, 2023 at 4:09 PM Michael Schwartzkopff via Kea-users <
> kea-users@lists.isc.org> wrote:
> >>
> >> hi,
> >>
> >>
> >> wrote an article about the use of option 43 in KEA for Cisco PnP.
> Perhaps you can get inspiration from there.
> >>
> >> https://blog.sys4.de/blog/kea-veos/
> >>
> >>
> >> Michael.
> >>
> >>
> >> On 22.06.23 12:27, Kraishak Mahtha wrote:
> >>
> >> kea-dhcp4 -t kea-dhcp4.conf.option43
> >> Syntax check failed with: kea-dhcp4.conf.option43:67.14-25: got
> unexpected keyword "option-def" in subnet4 map
> >>
> >> It is saying we cannot use the option-def inside the subnet4 section,
> It should be within class-def or in the global section I guess
> >>
> >> On Tue, Jun 20, 2023 at 3:08 PM Darren Ankney <darren.ank...@gmail.com>
> wrote:
> >>>
> >>> Hi Kraishak,
> >>>
> >>> Please provide the error message that you received.
> >>>
> >>> Thank you,
> >>>
> >>> Darren Ankney
> >>>
> >>> On Sun, Jun 18, 2023 at 1:34 AM Kraishak Mahtha <
> kraishak....@gmail.com> wrote:
> >>> >
> >>> > Hi Darren,
> >>> > This might be best kept out of the global area (use in subnet,
> classes etc..),
> >>> > ------>do you mean the following?
> >>> >
> >>> > "subnet4": [
> >>> > {
> >>> > "subnet": "4.0.0.0/16",
> >>> > "valid-lifetime": 86400,
> >>> > "option-def": [{
> >>> > "code": 43,
> >>> > "name": "vendor-encapsulated-options",
> >>> > "type": "string",
> >>> > "space": "dhcp4"
> >>> > }],
> >>> > "option-data": [
> >>> > {
> >>> > "name": "vendor-encapsulated-options",
> >>> > "data": "any old string"
> >>> > },
> >>> > {
> >>> > "data": "6.6.6.6, 7.7.7.7, 8.8.8.4",
> >>> > "name": "domain-name-servers"
> >>> > },
> >>> > {
> >>> > "data": "86400",
> >>> > "name": "dhcp-lease-time"
> >>> > },
> >>> > {
> >>> > "data": "255.255.0.0",
> >>> > "name": "subnet-mask"
> >>> > },
> >>> > {
> >>> > "data": "4.0.0.1",
> >>> > "name": "routers"
> >>> > }],
> >>> > "pools": [
> >>> > {
> >>> > "pool": "4.0.0.2-4.0.6.125"
> >>> > }
> >>> > ],
> >>> > "id": 786173
> >>> > },
> >>> > but it gives a syntax error for me and I don't see any reference in
> any forums too that declares the option definition within the subnet.
> >>> >
> >>> >
> >>> > On Thu, Jun 15, 2023 at 9:21 PM Darren Ankney <
> darren.ank...@gmail.com> wrote:
> >>> >>
> >>> >> Hi Kraishak,
> >>> >>
> >>> >> I am informed by a colleague that you can redefine the expected
> >>> >> contents of option 43 as shown:
> >>> >> "option-def": [
> >>> >> {
> >>> >> "name": "vendor-encapsulated-options",
> >>> >> "code": 43,
> >>> >> "type": "string"
> >>> >> }
> >>> >> "option-data": [
> >>> >> {
> >>> >> "name": "vendor-encapsulated-options",
> >>> >> "data": "any old string"
> >>> >> },
> >>> >> ]
> >>> >> which will allow you to store strings directly in the option. This
> >>> >> might be best kept out of the global area (use in subnet, classes
> >>> >> etc..), however, in case you need to use option 43 in the default
> way
> >>> >> with sub-options.
> >>> >>
> >>> >> Thank you,
> >>> >>
> >>> >> Darren Ankney
> >>> >>
> >>> >> On Wed, Jun 14, 2023 at 10:03 AM Kraishak Mahtha <
> kraishak....@gmail.com> wrote:
> >>> >> >
> >>> >> > Yes, for a few of my lab centers that run using the ISC, I have
> checked the config and they only have option 43 in their subnet without any
> option spaces so I thought it would be the same for kea.
> >>> >> > I don't have much familiarity with this option 43 but the current
> clients in the subnet do use option 43, My existing production has the same
> options with different values (a domain, number, and text) . I just
> replaced them with some random text and I am checking the tcpdump of both
> ISC and Kea server output to make sure I see the same results.
> >>> >> >
> >>> >> > In ISC tcpdump I can see the option value for option 43 and for
> kea, it is missing completely
> >>> >> >
> >>> >> > TIME: 13:59:13.451640
> >>> >> > IP: > (00:50:56:99:38:1c) > (00:50:56:99:5c:f3)
> >>> >> > OP: 2 (BOOTPREPLY)
> >>> >> > HTYPE: 1 (Ethernet)
> >>> >> > HLEN: 6
> >>> >> > HOPS: 0
> >>> >> > XID: 36835441
> >>> >> > SECS: 0
> >>> >> > FLAGS: 7f80
> >>> >> > CIADDR: 0.0.0.0
> >>> >> > YIADDR: 3.4.0.2
> >>> >> > SIADDR: 0.0.0.0
> >>> >> > GIADDR: 3.4.0.1
> >>> >> > CHADDR: a1:21:2f:00:00:01:00:00:00:00:00:00:00:00:00:00
> >>> >> > SNAME: .
> >>> >> > FNAME: .
> >>> >> > OPTION: 53 ( 1) DHCP message type 5 (DHCPACK)
> >>> >> > OPTION: 54 ( 4) Server identifier 192.168.0.81
> >>> >> > OPTION: 51 ( 4) IP address leasetime 86400 (24h)
> >>> >> > OPTION: 1 ( 4) Subnet mask 255.255.0.0
> >>> >> > OPTION: 3 ( 4) Routers 3.4.0.1
> >>> >> > OPTION: 6 ( 12) DNS server
> 6.6.6.6,7.7.7.7,8.8.8.4
> >>> >> > OPTION: 15 ( 11) Domainname test.com
> >>> >> > OPTION: 43 ( 11) Vendor specific info 74657374 test
> >>> >> >
> >>> >> >
> >>> >> > >>It sounds like you should be able to send data that isn't a
> suboption, but I cannot find anywhere in the ARM that indicates that Kea
> supports this.
> >>> >> > ---> This is the major thing if we have different behavior change
> for option 43 in kea compared to ISC
> >>> >> >
> >>> >> > On Wed, Jun 14, 2023 at 6:48 PM Darren Ankney <
> darren.ank...@gmail.com> wrote:
> >>> >> >>
> >>> >> >> Hi Kraishak,
> >>> >> >>
> >>> >> >> I don't know if I can provide more specific information than is
> >>> >> >> contained in the RFC 2132 section about option 43:
> >>> >> >> https://www.rfc-editor.org/rfc/rfc2132#section-8.4
> >>> >> >>
> >>> >> >> According to the RFC, the data in option 43 is "opaque" as it is
> meant
> >>> >> >> to be vendor specific. It sounds like you should be able to
> send data
> >>> >> >> that isn't a suboption, but I cannot find anywhere in the ARM
> that
> >>> >> >> indicates that Kea supports this. It definitely supports sending
> >>> >> >> sub-options of option 43 which is the usual case encountered in
> >>> >> >> practice.
> >>> >> >>
> >>> >> >> Thank you,
> >>> >> >>
> >>> >> >> Darren Ankney
> >>> >> >>
> >>> >> >> On Wed, Jun 14, 2023 at 8:46 AM Kraishak Mahtha <
> kraishak....@gmail.com> wrote:
> >>> >> >> >
> >>> >> >> > Hi Darren,
> >>> >> >> >
> >>> >> >> > I am testing for each option and its corresponding behavior in
> kea by checking the tcpdump and packet4.log mainly
> >>> >> >> >
> >>> >> >> > Can you please confirm one thing, so basically to use option
> 43 do we must need to define the vendor-encapsulated-options-space in both
> ISC and Kea-DHCP?
> >>> >> >> >
> >>> >> >> > I am a bit confused here, maybe it would be basic but can you
> please give me more info on it or any reference link so that I can
> understand the scope of option 43
> >>> >> >> >
> >>> >> >> > Thanks In Advance
> >>> >> >> > Kraishak
> >>> >> >> >
> >>> >> >> > On Tue, Jun 13, 2023 at 6:08 PM Darren Ankney <
> darren.ank...@gmail.com> wrote:
> >>> >> >> >>
> >>> >> >> >> Hi Kraishak,
> >>> >> >> >>
> >>> >> >> >> Does this do something for some device you are trying to
> support?
> >>> >> >> >>
> >>> >> >> >> option vendor-encapsulated-options "test";
> >>> >> >> >>
> >>> >> >> >> Typically, option 43 is defined on the basis of something
> that a
> >>> >> >> >> vendor device needs to receive. That gives some constraints
> regarding
> >>> >> >> >> how it is configured. Most of the time, it will be a
> collection of
> >>> >> >> >> one or more sub-options. For example, here is one vendor's
> passing of
> >>> >> >> >> a URL for tr69 in ISC DHCP:
> >>> >> >> >>
> >>> >> >> >> option space CALIXGC;
> >>> >> >> >> option CALIXGC.acs-url code 1 = text;
> >>> >> >> >> vendor-option-space CALIXGC;
> >>> >> >> >> option CALIXGC.acs-url "http://someurl";;
> >>> >> >> >>
> >>> >> >> >> which, translated to Kea, would look like this:
> >>> >> >> >>
> >>> >> >> >> "option-def": [
> >>> >> >> >> {
> >>> >> >> >> "space": "CALIXGC",
> >>> >> >> >> "name": "acs-url",
> >>> >> >> >> "code": 1,
> >>> >> >> >> "type": "string"
> >>> >> >> >> },
> >>> >> >> >> {
> >>> >> >> >> "name": "vendor-encapsulated-options",
> >>> >> >> >> "code": 43,
> >>> >> >> >> "type": "empty",
> >>> >> >> >> "encapsulate": "CALIXGC"
> >>> >> >> >> }
> >>> >> >> >> ],
> >>> >> >> >> "option-data": [
> >>> >> >> >> {
> >>> >> >> >> "name": "vendor-encapsulated-options",
> >>> >> >> >> "code": 43
> >>> >> >> >> },
> >>> >> >> >> {
> >>> >> >> >> "space": "CALIXGC",
> >>> >> >> >> "name": "acs-url",
> >>> >> >> >> "code": 1,
> >>> >> >> >> "data": "http://someurl";
> >>> >> >> >> }
> >>> >> >> >> ]
> >>> >> >> >>
> >>> >> >> >> See if you can send that to your device or discover what
> actual data
> >>> >> >> >> your device needs and we can see how that might be configured?
> >>> >> >> >>
> >>> >> >> >> Thank you,
> >>> >> >> >>
> >>> >> >> >> Darren Ankney
> >>> >> >> >>
> >>> >> >> >> On Tue, Jun 13, 2023 at 7:42 AM Kraishak Mahtha <
> kraishak....@gmail.com> wrote:
> >>> >> >> >> >
> >>> >> >> >> > Hi Darren,
> >>> >> >> >> >
> >>> >> >> >> > Thank you for the suggestion but I am still facing the same
> problem.
> >>> >> >> >> >
> >>> >> >> >> > {
> >>> >> >> >> > "code": "43",
> >>> >> >> >> > "csv-format": true,
> >>> >> >> >> > "data": "74657374",
> >>> >> >> >> > },
> >>> >> >> >> >
> >>> >> >> >> > ---> With the above format I am getting a few issues
> because of double quotes for the code, and for CSV format, If I set that to
> true I am getting an error as
> >>> >> >> >> > 2023-06-13 06:23:40.309 ERROR
> [kea-dhcp4.dhcp4/6561.139810011805888] DHCP4_PARSER_FAIL failed to create
> or run parser for configuration element subnet4: option data does not match
> option definition (space: dhcp4, code: 43): attempt to write invalid option
> data field type into the option buffer: 0 (kea-dhcp4.conf:60:27)
> >>> >> >> >> > Error encountered: option data does not match option
> definition (space: dhcp4, code: 43): attempt to write invalid option data
> field type into the option buffer: 0 (kea-dhcp4.conf:60:27)
> >>> >> >> >> >
> >>> >> >> >> > The final trial is as follows:
> >>> >> >> >> > {
> >>> >> >> >> > "code": "43",
> >>> >> >> >> > "csv-format": false,
> >>> >> >> >> > "data": "74657374",
> >>> >> >> >> > },
> >>> >> >> >> >
> >>> >> >> >> > This also gave me an empty for option 43 in the ACK packet.
> >>> >> >> >> >
> >>> >> >> >> > This is the subnet of the ISC config that I using for
> testing
> >>> >> >> >> > subnet 3.4.0.0 netmask 255.255.0.0 {
> >>> >> >> >> > pool {
> >>> >> >> >> > range 3.4.0.2 3.4.0.5;
> >>> >> >> >> > range 3.4.0.12 3.4.0.16;
> >>> >> >> >> > range 3.4.0.41 3.4.0.56;
> >>> >> >> >> > }
> >>> >> >> >> > default-lease-time 86400;
> >>> >> >> >> > max-lease-time 86400;
> >>> >> >> >> > option domain-name "test.com";
> >>> >> >> >> > option domain-name-servers
> 6.6.6.6,7.7.7.7,8.8.8.4;
> >>> >> >> >> > option routers 3.4.0.1;
> >>> >> >> >> > option subnet-mask 255.255.0.0;
> >>> >> >> >> > option vendor-encapsulated-options "test";
> >>> >> >> >> > }
> >>> >> >> >> >
> >>> >> >> >> > Thanks
> >>> >> >> >> > Kraishak
> >>> >> >> >> >
> >>> >> >> >> >
> >>> >> >> >> >
> >>> >> >> >> > On Tue, Jun 13, 2023 at 12:35 AM Darren Ankney <
> darren.ank...@gmail.com> wrote:
> >>> >> >> >> >>
> >>> >> >> >> >> Hi Kraishak,
> >>> >> >> >> >>
> >>> >> >> >> >> Have a look here:
> >>> >> >> >> >>
> https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html?highlight=%22vendor-encapsulated-options%22#dhcpv4-vendor-specific-options
> >>> >> >> >> >>
> >>> >> >> >> >> You might need to setup encapsulated sub-options and tell
> Kea to
> >>> >> >> >> >> include the "vendor-encapsulated-options-space" content in
> the options
> >>> >> >> >> >> as a sub-option:
> >>> >> >> >> >>
> >>> >> >> >> >> "option-data": [
> >>> >> >> >> >> {
> >>> >> >> >> >> "name": "REPLACE_ME",
> >>> >> >> >> >> "space": "vendor-encapsulated-options",
> >>> >> >> >> >> "code": 1,
> >>> >> >> >> >> "csv-format": false,
> >>> >> >> >> >> "data": "74657374"
> >>> >> >> >> >> },
> >>> >> >> >> >> {
> >>> >> >> >> >> "name": "vendor-encapsulated-options"
> >>> >> >> >> >> }
> >>> >> >> >> >> ]
> >>> >> >> >> >>
> >>> >> >> >> >> So, above, first the data is added as a sub-option of
> option 43
> >>> >> >> >> >> (option 43 typically consists of one or more
> sub-options). Replace
> >>> >> >> >> >> "REPLACE_ME" with the name of the sub-option you are
> trying to send (I
> >>> >> >> >> >> think you can omit name entirely if there is none as that
> part isn't
> >>> >> >> >> >> sent). Set the code to the correct sub-option number. If
> this
> >>> >> >> >> >> particular data should not be a sub-option, then you might
> have to do
> >>> >> >> >> >> something like this:
> >>> >> >> >> >>
> >>> >> >> >> >> {
> >>> >> >> >> >> "code": "43",
> >>> >> >> >> >> "csv-format": true,
> >>> >> >> >> >> "data": "74657374",
> >>> >> >> >> >> },
> >>> >> >> >> >>
> >>> >> >> >> >> please note that if "csv-format" is set to false, then Kea
> will be
> >>> >> >> >> >> expecting "a hexadecimal string." see:
> >>> >> >> >> >>
> https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html?highlight=%22csv-format%22#standard-dhcpv4-options
> >>> >> >> >> >>
> >>> >> >> >> >> Can you share the option 43 portion of the ISC DHCP
> configuration you
> >>> >> >> >> >> are trying to convert if you still have trouble?
> >>> >> >> >> >>
> >>> >> >> >> >> Thank you,
> >>> >> >> >> >>
> >>> >> >> >> >> Darren Ankney
> >>> >> >> >> >>
> >>> >> >> >> >> On Mon, Jun 12, 2023 at 1:59 PM Kraishak Mahtha <
> kraishak....@gmail.com> wrote:
> >>> >> >> >> >> >
> >>> >> >> >> >> > Hi,
> >>> >> >> >> >> > I am trying to convert my ISC config to kea-equivalent
> and testing the changes as part of the testing, I am stuck at testing
> option 43 ,
> >>> >> >> >> >> > Using the keama tool I convert my ISC config to Kea
> equivalent config and tested the leases but in the DHCP ACK packet I cannot
> see option 43 coming when I operate with Kea
> >>> >> >> >> >> >
> >>> >> >> >> >> > sample code config for option 43 that I used in my
> testing subnet
> >>> >> >> >> >> > {
> >>> >> >> >> >> > "data": "74657374",
> >>> >> >> >> >> > "name":
> "vendor-encapsulated-options",
> >>> >> >> >> >> > "csv-format": false
> >>> >> >> >> >> > },
> >>> >> >> >> >> >
> >>> >> >> >> >> > But in log and tcpdump I see the empty value for option
> 43
> >>> >> >> >> >> >
> >>> >> >> >> >> > Log:
> >>> >> >> >> >> > ===
> >>> >> >> >> >> > 2023-06-12 15:10:26.284 DEBUG
> [kea-dhcp4.packets/30590.140464453838592] DHCP4_RESPONSE_DATA [hwtype=1
> 21:21:2f:00:00:01], cid=[01:21:21:2f:00:00:01]x8259145: responding with
> packet DHCPACK (type 5), packet details: local_address=192.168.0.125:67,
> remote_address=4.0.0.1:67, msg_type=DHCPACK (5), =0x8259145,
> >>> >> >> >> >> > options:
> >>> >> >> >> >> > type=001, len=004: 4294901760 (uint32)
> >>> >> >> >> >> > type=003, len=004: 4.0.0.1
> >>> >> >> >> >> > type=006, len=012: 6.6.6.6 7.7.7.7 8.8.8.4
> >>> >> >> >> >> > type=012, len=018: "dhcp-client-000001" (string)
> >>> >> >> >> >> > type=015, len=011: "test.com" (string)
> >>> >> >> >> >> > type=043, len=000: ----->Empty Value, and I
> cross-verified the tcpdump too.
> >>> >> >> >> >> > type=051, len=004: 86400 (uint32)
> >>> >> >> >> >> > type=053, len=001: 5 (uint8)
> >>> >> >> >> >> > type=054, len=004: 192.168.0.125
> >>> >> >> >> >> > type=061, len=007: 01:21:21:2f:00:00:01
> >>> >> >> >> >> >
> >>> >> >> >> >> > I have checked the discover packet option 55 just to
> make sure if my packet is asking for option 43 or not, and yes I can see
> option 43 in the option 55 parameter value.
> >>> >> >> >> >> >
> >>> >> >> >> >> > I am not sure what is wrong I am doing, Can someone who
> has familiar can guide me
> >>> >> >> >> >> >
> >>> >> >> >> >> > Thanks in Advance
> >>> >> >> >> >> > Kraishak
> >>> >> >> >> >> > --
> >>> >> >> >> >> > ISC funds the development of this software with paid
> support subscriptions. Contact us at https://www.isc.org/contact/ for
> more information.
> >>> >> >> >> >> >
> >>> >> >> >> >> > To unsubscribe visit
> https://lists.isc.org/mailman/listinfo/kea-users.
> >>> >> >> >> >> >
> >>> >> >> >> >> > Kea-users mailing list
> >>> >> >> >> >> > Kea-users@lists.isc.org
> >>> >> >> >> >> > https://lists.isc.org/mailman/listinfo/kea-users
> >>> >> >> >> >> --
> >>> >> >> >> >> ISC funds the development of this software with paid
> support subscriptions. Contact us at https://www.isc.org/contact/ for
> more information.
> >>> >> >> >> >>
> >>> >> >> >> >> To unsubscribe visit
> https://lists.isc.org/mailman/listinfo/kea-users.
> >>> >> >> >> >>
> >>> >> >> >> >> Kea-users mailing list
> >>> >> >> >> >> Kea-users@lists.isc.org
> >>> >> >> >> >> https://lists.isc.org/mailman/listinfo/kea-users
> >>> >> >> >> --
> >>> >> >> >> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
> >>> >> >> >>
> >>> >> >> >> To unsubscribe visit
> https://lists.isc.org/mailman/listinfo/kea-users.
> >>> >> >> >>
> >>> >> >> >> Kea-users mailing list
> >>> >> >> >> Kea-users@lists.isc.org
> >>> >> >> >> https://lists.isc.org/mailman/listinfo/kea-users
> >>> >> >> --
> >>> >> >> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
> >>> >> >>
> >>> >> >> To unsubscribe visit
> https://lists.isc.org/mailman/listinfo/kea-users.
> >>> >> >>
> >>> >> >> Kea-users mailing list
> >>> >> >> Kea-users@lists.isc.org
> >>> >> >> https://lists.isc.org/mailman/listinfo/kea-users
> >>> >> --
> >>> >> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
> >>> >>
> >>> >> To unsubscribe visit
> https://lists.isc.org/mailman/listinfo/kea-users.
> >>> >>
> >>> >> Kea-users mailing list
> >>> >> Kea-users@lists.isc.org
> >>> >> https://lists.isc.org/mailman/listinfo/kea-users
> >>> --
> >>> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
> >>>
> >>> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
> >>>
> >>> Kea-users mailing list
> >>> Kea-users@lists.isc.org
> >>> https://lists.isc.org/mailman/listinfo/kea-users
> >>
> >>
> >> --
> >> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
> >>
> >> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
> >>
> >> Kea-users mailing list
> >> Kea-users@lists.isc.org
> >> https://lists.isc.org/mailman/listinfo/kea-users
> >
> > --
> > ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
> >
> > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
> >
> > Kea-users mailing list
> > Kea-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/kea-users
>
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
