Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Use cases and questions regarding lease allocation
(Chaigneau, Nicolas)
2. Re-designing the config parsers (Marcin Siodelski)
3. Re: Re-designing the config parsers (Daniil Baturin)
4. installation report on debian wheezy (Michael Richardson)
----------------------------------------------------------------------
Message: 1
Date: Tue, 9 Sep 2014 15:03:04 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Use cases and questions regarding lease allocation
Message-ID:
<ab94b0b675bdf14189cd5a861db36c8414182...@de-cm-mbx26.corp.capgemini.com>
Content-Type: text/plain; charset="us-ascii"
Hello,
I've done some more testing, and have questions related to some use cases
(which I compared to how dhcpd behaves).
Note that the point of this mail is not to report defects ; I'm merely trying
to understand what may be design choices.
(Nothing here is, strictly speaking, against the RFC, but some "should" and
"should not" are not enforced.)
Anyway, here goes.
1) Use case 1:
- Client C1 sends a Discover, is offered lease L1.
- Client C1 sends a Request, with Requested IP Address = L1.
- Client C1 gets an Ack, with yiaddr = requested address.
Nothing to say, this is the standard case, just for comparison purpose.
2) Use case 2:
- Client C1 (not previously known from the server) sends a Discover, with a
specific Requested IP Address (which is valid and free).
- Client C1 gets an Offer but with yiaddr = another lease than the one he asked
for
The option Requested IP Address seems to be ignored. Is this on purpose ?
(in the same use case, dhcpd will send back the Requested IP address)
>From RFC:
If an address is available, the new address SHOULD be chosen as follows:
o The client's current address as recorded in the client's current
binding, ELSE
o The client's previous address as recorded in the client's (now
expired or released) binding, if that address is in the server's
pool of available addresses and not already allocated, ELSE
o The address requested in the 'Requested IP Address' option, if that
address is valid and not already allocated, ELSE
o A new address allocated from the server's pool of available
addresses
3) Use case3:
- Client C1 (not previously known from the server) sends a Request, with a
specific Requested IP Address (which is valid and free).
- Client C1 gets an Ack but with yiaddr = another lease than the one he asked
for
It seems that, if a lease has not been provided in an Offer response, then it
cannot be specifically asked for in a Request.
Is this on purpose ?
(in the same use case, dhcpd will send back the Requested IP address)
4) Use case 4:
- Client C1 sends a Request, with a specific Requested IP Address, which is
invalid (not in a pool).
- Client C1 gets an Ack (with a valid lease)
>From RFC:
If a server receives a DHCPREQUEST message with an invalid 'requested
IP address', the server SHOULD respond to the client with a DHCPNAK
message
Same question: is this behavior on purpose ?
(in the same use case, dhcpd will send back an Nack)
5) Use case 5:
Client C1 sends a Discover, is offered lease L1.
Client C2 sends a Request, with Requested IP Address = L1.
Client C2 gets an Ack, with yiaddr = requested address.
Client C1 then sends a Request, with Requested IP Address = L1.
Client C1 gets an Ack, but with yiaddr = a new IP address (L1 +1).
It seems that as long as an IP address has been offered, anyone can "grab" it
in a Request.
Is that the intended behavior ? shouldn't be a lease reserved to the client to
whom it was offered ?
Thanks for your time.
Regards,
Nicolas.
This message contains information that may be privileged or confidential and is
the property of the Capgemini Group. It is intended only for the person to whom
it is addressed. If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or use this message or
any part thereof. If you receive this message in error, please notify the
sender immediately and delete all copies of this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20140909/450bfd73/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 09 Sep 2014 17:20:10 +0200
From: Marcin Siodelski <[email protected]>
To: Kea Dev List <[email protected]>
Subject: Re-designing the config parsers
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
We have been discussing for a while that our configuration parsers are
not friendly and adding new configuration parameters to Kea is a pain. I
created a thread on this mailing list, not so long ago, which is about
changing the CfgMgr to support atomic commits and rolling back changes
if the configuration fails:
https://lists.isc.org/pipermail/kea-dev/2014-August/000065.html
As a followup to this thread I would like to propose that we re-design
our configuration parsers so as adding new configuration parameters to
Kea is easier and less error prone.
Briefly....
I'd like to propose that we make use of the .spec files to define the
supported parameters, the required order in which the parsing should be
done, to associate the parsed parameter with the actual parser and to
allow self documentation of the supported parameters.
I would also like to create a central repository of the parsers which
will expose a factory function returning appropriate parser instance for
each element in the spec file (either default parser or specialized one
when defined).
Please see the draft document for full details:
http://kea.isc.org/wiki/ConfigParseDesign and throw tomatoes if needed.
I should also explain that we discussed with Tomek a use of Bizon
framework (http://www.gnu.org/software/bison/) in Kea.
However, since we already have the JSON parsers and spec files I am not
sure we want to create additional dependency for Kea or include a third
party software in our code base. But, it is obviously something that we
can take into consideration.
Marcin
------------------------------
Message: 3
Date: Tue, 09 Sep 2014 22:28:37 +0700
From: Daniil Baturin <[email protected]>
To: [email protected]
Subject: Re: Re-designing the config parsers
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
What is wrong with Bison dependency? It's available from
repositories/ports/etc.
on any UNIX-like system in existence and can be installed even on
platforms that
do not exist anymore. :)
On 09/09/2014 10:20 PM, Marcin Siodelski wrote:
> We have been discussing for a while that our configuration parsers are
> not friendly and adding new configuration parameters to Kea is a pain. I
> created a thread on this mailing list, not so long ago, which is about
> changing the CfgMgr to support atomic commits and rolling back changes
> if the configuration fails:
> https://lists.isc.org/pipermail/kea-dev/2014-August/000065.html
>
> As a followup to this thread I would like to propose that we re-design
> our configuration parsers so as adding new configuration parameters to
> Kea is easier and less error prone.
>
> Briefly....
>
> I'd like to propose that we make use of the .spec files to define the
> supported parameters, the required order in which the parsing should be
> done, to associate the parsed parameter with the actual parser and to
> allow self documentation of the supported parameters.
>
> I would also like to create a central repository of the parsers which
> will expose a factory function returning appropriate parser instance for
> each element in the spec file (either default parser or specialized one
> when defined).
>
> Please see the draft document for full details:
> http://kea.isc.org/wiki/ConfigParseDesign and throw tomatoes if needed.
>
> I should also explain that we discussed with Tomek a use of Bizon
> framework (http://www.gnu.org/software/bison/) in Kea.
>
> However, since we already have the JSON parsers and spec files I am not
> sure we want to create additional dependency for Kea or include a third
> party software in our code base. But, it is obviously something that we
> can take into consideration.
>
> Marcin
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
- --
#!/usr/bin/env perl
@a=split(//, "daniil @ baturin . org" );# Daniil Baturin
@b=split(//,q/Px%!+o0Q6lh*7dp$.@8#%|y{/);while($i<24){$_.=
chr((ord(@b[$i])-ord(@a[$i])+62)%94+32);$i++};print"$_\n"#
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJUDxykAAoJEEcm35UR4K8fyucQAPHpUCOLHUz/fBwUvIAGkxvr
g1agFVZ1PUteuMNG7zWRChZ5aEr20odR/+Q95GrANPh5kSJLwl43NQWAvQhR6QE7
QxgeHjoFG56jXkqd69Iokn/l8BGkBHG7H9xmRAHt5usjnOfDLpQQmZgyGUHjQdvv
/EODw/Xqv4KLCwZO4tD05diUydOk2gyYBPg1Pu+AzLJnYX5xaAV7ctcGOyly+JiI
F3Sp+O8OUBuC770fQzXCV3LyL6AvYmufsBV2yt5A4C4lOElG6pOdJo623JgwpLU8
7goSHSAuMn4l8s9KBioq2HY5rFaC4EJczI9KwegQvqGzC4CEvsVWG7sbwB7ilAM5
nzRmDowBDcUDJAutdNA+KYs3/Wb6RoyLy80WnePvU1RcG/1dBuB+fbbHWrNiTUqo
Pt75ODowV3pHg4S7bYbKf3eWA2dHNQIa7XXOnE/CW/uJRac9FW6OseLUYSlNqaiE
9/enK2zNDInt4BIfpcrq3LW1xue2crSShddzgk+MoR5u1/DFg2DWzQHtKlnf0t/H
V40A5PXTJtg0kdd4C1hNsQsZXu9sPwKfMNB5PHnzKA7ZfUx1WzmAVOdFd21kitqd
Fb2uP9UltROxJQLaAEfidP1NEdcHKIH1ZwsdlcUUYYCSjaDaYhXF2sjLh2RNJJbg
IJTbhuUpxKanNRy0knc+
=TPIR
-----END PGP SIGNATURE-----
------------------------------
Message: 4
Date: Tue, 09 Sep 2014 21:43:13 -0400
From: Michael Richardson <[email protected]>
To: [email protected]
Subject: installation report on debian wheezy
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
A power outage blew up a disk, taking out my asterisk server (mostly backed
up), but it was rather old, so I'm replacing it. It is also the DHCPv4 for
my home "media" / "phone" VLAN, so I thought I'd try kea. Why not get names
into my DNS for the phones and WII, and the like...
I did a git checkout, git checkout -b kea-0.9 origin/kea-0.9.
I initially ran "autoconf", but that failed, read the instructions and ran:
autoreconf --install
I needed
apt-get install liblog4cplus-dev
to get around:
checking log4cplus/logger.h usability... no
checking log4cplus/logger.h presence... no
checking for log4cplus/logger.h... no
configure: error: Missing required header files.
having read some things, I thought I'd install libbotan1.10-dev too.
It seems that "sudo make install" on results a stack of things
being relinked again by libtool. I don't know why, they were already
build. This is a problem if I want to build on one machine and install onto
another machine using a (read-only) NFS/SSHFS mount.
In the end, I had to install a devel environment on my compiler-free target
machine, and build there, which significantly upset me, as the set -dev
packages I needed was large and difficult to determine.
I recommend making debian (which likely will run on Ubuntu, but not VV), dpkg
available via a repository available for KEA if you want people to try it
out. Since building it seems to require a bunch of packages (such as botan
needing libbz2 to be properly detected), it might be worth having (in
addition), a virtual package that simply Pre-Depends upon all the things
needed to build. That way I can install "kea-dev-depends" as a package, and
then build from git tree.
here is what wound up being installed (grepping for -dev packages)
libbison-dev:i386
libboost-dev
libboost1.49-dev
libbotan1.10-dev
libbz2-dev:i386
libc-dev-bin
libc6-dev:i386
libgmp-dev:i386
libgmp3-dev
liblog4cplus-dev
libltdl-dev:i386
libssl-dev
libstdc++6-4.4-dev
libstdc++6-4.7-dev
linux-libc-dev:i386
zlib1g-dev:i386
Comments on things, once I got things installed.
1) this is the example installed:
# Below an example of the simple subnet declaration. Uncomment to
# enable it.
"subnet4": [
# { "subnet": "192.0.2.0/24",
# "pool": [ "192.0.2.1 - 192.0.2.200" ] }
]
this is what http://git.kea.isc.org/~tester/kea/guide/kea-guide.html says:
"Dhcp4": {
"subnet4": [
"subnet": "192.0.2.0/24",
"pools": [
{
"pool": "192.0.2.10 - 192.0.2.20"
}
],
...
]
}
note "pools" vs "pool". The installed example is wrong.
2) It appears that comments # are valid only in column 0. That's really
annoying. Really really really really annoying. I understand that
comments probably not valid JSON, period.
3) it is not obvious what userid kea is going to run as, or if it has to run
as root, or if there is any priveledge seperation.
4) despite repeated attempts, I can't make it like my config:
# DHCPv4 configuration starts here.
"Dhcp4":
{
# Add names of interfaces to listen on.
"interfaces": [ "eth0" ],
# Use Memfile lease database backend to store leases in a CSV file.
"lease-database": {
"type": "memfile"
},
# Global (inherited by all subnets) lease lifetime is mandatory parameter.
"valid-lifetime": 4000,
# Below an example of the simple subnet declaration. Uncomment to
# enable it.
"subnet4": [
"subnet": "172.30.55.0/24", <--- seems to be line 25.
"pools": [
{ "pool": "172.30.55.192/26" }
]
]
},
halibut-[~/kea] mcr 10106 %sudo keactrl start
INFO/keactrl: Starting kea-dhcp4 -c /sandel/etc/kea/kea.conf
INFO/keactrl: Starting kea-dhcp6 -c /sandel/etc/kea/kea.conf
2014-09-09 20:16:58.557 ERROR [kea-dhcp4.dhcp4/10390] DHCP4_INIT_FAIL failed to
initialize Kea server: configuration error using file
'/sandel/etc/kea/kea.conf': ':' read, one of ",]" expected in
/sandel/etc/kea/kea.conf:25:17
INFO/keactrl: Starting kea-dhcp-ddns -c /sandel/etc/kea/kea.conf
5) okay, I played some more, and with:
"Dhcp4":
{
# Add names of interfaces to listen on.
"interfaces": [ "eth0" ],
# Use Memfile lease database backend to store leases in a CSV file.
"lease-database": {
"type": "memfile"
},
# Global (inherited by all subnets) lease lifetime is mandatory parameter.
"valid-lifetime": 4000,
# Below an example of the simple subnet declaration. Uncomment to
# enable it.
"subnet4": {
"subnet": "172.30.55.0/24",
"pools": [
{ "pool": "172.30.55.192/26" }
]
}
},
(that is, subnet4, takes a directionary, not an array, I get:
halibut-[~/kea] mcr 10113 %sudo keactrl start
INFO/keactrl: Starting kea-dhcp4 -c /sandel/etc/kea/kea.conf
INFO/keactrl: Starting kea-dhcp6 -c /sandel/etc/kea/kea.conf
2014-09-09 20:19:37.726 INFO [kea-dhcp4.dhcpsrv/10541]
DHCPSRV_CFGMGR_ADD_IFACE listening on interface eth0
2014-09-09 20:19:37.741 INFO [kea-dhcp4.dhcpsrv/10541] DHCPSRV_MEMFILE_DB
opening memory file lease database: type=memfile universe=4
2014-09-09 20:19:37.749 INFO [kea-dhcp4.dhcpsrv/10541]
DHCPSRV_MEMFILE_LEASES_RELOAD4 reloading leases from
/sandel/var/kea/kea-leases4.csv
2014-09-09 20:19:37.760 ERROR [kea-dhcp4.dhcp4/10541] DHCP4_PARSER_FAIL failed
to create or run parser for configuration element subnet4: listValue() called
on non-list Element
2014-09-09 20:19:37.763 ERROR [kea-dhcp4.dhcp4/10541] DHCP4_CONFIG_LOAD_FAIL
configuration error using file: /sandel/etc/kea/kea.conf, reason: listValue()
called on non-list Element
2014-09-09 20:19:37.786 ERROR [kea-dhcp4.dhcp4/10541] DHCP4_INIT_FAIL failed to
initialize Kea server: configuration error using file
'/sandel/etc/kea/kea.conf': listValue() called on non-list Element
INFO/keactrl: Starting kea-dhcp-ddns -c /sandel/etc/kea/kea.conf
which sort of seems to be an improvement, because it's no longer a parser
error, but rather an semantic error, but it seemto suggest that the [] was
right, but something about it was really wrong.
AHA, the installed example CONFIG is CORRECT, but the documentation is
totally borked. [] around :-items would be invalid JSON anyway.
AHA 2... trailing , on dictionaries is not accepted.
I'm pretty sure that Javascript deals with it just fine, btw.
Finally, got it working. WII liked it, phones liked it.
WTF... I gotta write the options out like that... wow... nobody gonna live
with that long.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: not available
URL:
<https://lists.isc.org/pipermail/kea-dev/attachments/20140909/41315fd4/attachment.bin>
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 6, Issue 5
*************************************
