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. Re: how to unparse token (Tomek Mrugalski)
2. Re: how to unparse token (Francis Dupont)
3. Hooks called in incorrect order (Adrian Moreno)
4. KEN and RFC7598 S46 Port Parameters Option (92)
([email protected])
----------------------------------------------------------------------
Message: 1
Date: Thu, 26 Nov 2015 13:52:21 +0100
From: Tomek Mrugalski <[email protected]>
To: [email protected]
Subject: Re: [kea-dev] how to unparse token
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Why is this needed at all? For debugging purposes?
If that is so, simply store the string. We can even enforce this by
requiring a string parameter in the base Token class. But it is needed
in 1.0?
Tomek
On 25.11.2015 17:40, Francis Dupont wrote:
> (the whole topic is about the clasification expression which are parsed
> as a vector of Token objects)
>
> We are divided between two ways to provide an "unparse" method which
> from a Token gives back its textual input.
> In both case we have:
> parse o unparse = identity
> which means if you parse again the result of unparse you get the same Token.
> Only a solution provides too:
> unparse o parse = identity
> Ie., unparse gives back the exact input (there is no miracle: this solution
> simply caches the input into the Token object).
>
> I argue we don't need this (expensive to implement) property, i.e.,
> we can live with in "substring('foo', 01, all)" the "01" be unparsed
> into "1". Opinion? Argument?
>
> Thanks
>
> Francis Dupont <[email protected]>
>
> PS: I wrote a decompile function too but it requires only a from Token
> to string method so works with #4115 or #4124. Of course the same question
> can be raise: decompile or simply keep the "to be parsed" sring. And
> the day we'll provide a get text config you can guess the question...
> (with in this case the two common arguments: keep comments vs. pretty
> print the output which shows bad constructs :-).
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
>
------------------------------
Message: 2
Date: Thu, 26 Nov 2015 14:46:35 +0000
From: Francis Dupont <[email protected]>
To: Tomek Mrugalski <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] how to unparse token
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Tomek Mrugalski writes:
> Why is this needed at all? For debugging purposes?
=> yes and also for unit tests (i.e. for the second for the same
reason we have getCode() method in TokenOption). IMHO this should
stay minimal so without adding a member (vs a method) to all Token
objects (methods are only in a per class internal table so the
memory overhead is static).
Regards
Francis Dupont <[email protected]>
------------------------------
Message: 3
Date: Thu, 26 Nov 2015 17:01:49 +0100
From: Adrian Moreno <[email protected]>
To: [email protected]
Subject: [kea-dev] Hooks called in incorrect order
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
I'm trying to make use of Kea's hooks system and I'm encountering a what
I think is a contradiction between the documentation and the actual
behaviour
In the docs
(http://git.kea.isc.org/~tester/kea/doxygen/de/df3/dhcpv4Hooks.html) I
can read:
"...The following list is ordered by appearance of specific hook points
during packet processing. Hook points that are not specific to packet
processing (e.g. lease expiration) will be added to the end of this list..."
The list that follows start with:
buffer4_receive
pkt4_receive
subnet4_select
lease4_select
lease4_renew
...
Based on this, I'd expect "subnet4_select" hook to be called *after*
"pkt4_receive". However, this is not the case.
Following the code flow, the culprit seems to be the following code
which is run *before* going through the "pkt4_receive" callouts.
src/bin/dhcp4/dhcp4_srv.cc:
515 // Check whether the message should be further processed
or discarded.
516 // There is no need to log anything here. This function
logs by itself.
517 if (!accept(query)) {
518 // Increase the statistic of dropped packets.
519 isc::stats::StatsMgr::instance().addValue("pkt4-receive-drop",
520 static_cast<int64_t>(1));
521 continue;
522 }
With the stack being:
isc::dhcp::Subnet4Ptr Dhcpv4Srv::selectSubnet(const Pkt4Ptr& query) const
bool Dhcpv4Srv::acceptDirectRequest(const Pkt4Ptr& pkt) const
bool Dhcpv4Srv::accept(const Pkt4Ptr& query) const
bool Dhcpv4Srv::run()
I can see the point of dropping messages for which there is no valid
subnet but, isn't that the reason why selectSubnet is called in
"Dhcpv4Srv::processDiscover(Pkt4Ptr& discover)"?
Why call it twice?
and
Shouldn't this counter-intuitive behaviour be reflected in the
Documentation?
Many thanks!
Adrian
PS: By the way, I'm running Kea 0.9.2.
------------------------------
Message: 4
Date: Thu, 26 Nov 2015 18:41:56 +0100
From: <[email protected]>
To: <[email protected]>
Subject: [kea-dev] KEN and RFC7598 S46 Port Parameters Option (92)
Message-ID:
<62aa760926a38745aaf06ad7319065fd605a63a...@he113456.emea1.cds.t-internal.com>
Content-Type: text/plain; charset="us-ascii"
Hi Tomek,
after checking if the RFC was referenced in the (current - thanks for the
reminder!) docs [1], I wonder how I in KEA can construct the S46 IPv4/IPv6
Address Binding Option (92) as listed in an RFC7598 [2]
The question arises because I fail to understand which data types kea currently
could use to express the variable prefix length constructs as defined in the
option (RFC7598 chapter 4.4.)
o bindprefix6-len: 8 bits long; expresses the bitmask length of the
IPv6 prefix specified in the bind-ipv6-prefix field. Allowed
values range from 0 to 128.
o bind-ipv6-prefix: a variable-length field specifying the IPv6
prefix or address for the S46 CE. This field is right-padded with
zeros to the nearest octet boundary when bindprefix6-len is not
divisible by 8
I am aware that I COULD create content externally to kea as a list of plane
words/bytes and assign it, but I was more interested to have a "proper" option
object with a "proper" underlying data type...
Should this be currently not possible, it that a part of what is planned to
make it into kea 1.0 ?
Thanks a lot,
Normen Kowalewski
[1] https://ftp.isc.org/isc/kea/0.9.2/doc/kea-guide.html#dhcp6-std-options-list
[2] https://tools.ietf.org/html/rfc7598
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 20, Issue 13
***************************************
