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: Possibility of disabling raw socket use in Kea ? ->
works! (Marcin Siodelski)
2. Re: IA_NA + IA_PD (Tomek Mrugalski)
3. Re: Possibility of disabling raw socket use in Kea ? ->
works! (Chaigneau, Nicolas)
----------------------------------------------------------------------
Message: 1
Date: Wed, 24 Sep 2014 18:14:00 +0200
From: Marcin Siodelski <[email protected]>
To: "Chaigneau, Nicolas" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Possibility of disabling raw socket use in Kea
? -> works!
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
Nicolas,
Great to hear.
We are going to add a configuration switch to enable/disable this
behavior at some point. Maybe in 0.9.1 release, or 0.9.2.
Can you tell what OS you're using. I presume it is some Linux flavor?
We will need to test this on other OSes too, when we introduce a config
switch.
Marcin
On Wed 24 Sep 2014 17:47:32 CEST, Chaigneau, Nicolas wrote:
>
> Hello,
>
>
> I've rebuilt Kea with the code change you described.
>
> In file:
> src/bin/dhcp4/dhcp4_srv.h
>
> The following modification was applied to Dhcpv4Srv constructor:
> // const bool direct_response_desired = true);
> const bool direct_response_desired = false);
>
>
>
> And I'm quite happy with the results, it works perfectly :)
>
>
>
> I ran the following test cases:
>
> 1) Started Kea on an interface with a single IP address (no iptables
> filtering set up initially)
>
> - Sent a unicast DHCP request from a relay to Kea
> -> Request is correctly received and handled by Kea. Client gets a response.
>
> - Applied a simple filtering rule through iptables:
> iptables -I INPUT -p udp --dport 67:68 --sport 67:68 -j DROP
>
> - Sent a unicast DHCP request from a relay to Kea
> -> iptables drops the packet. Kea does not receive anything. Client does
> not get a response.
>
>
> 2) Started Kea on an interface with two IP addresses (no iptables filtering
> is set up initially)
>
> - Noticed the following warning log:
>
> 2014-09-24 17:18:51.134 WARN [kea-dhcp4.dhcpsrv/10731]
> DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Binding socket to an
> interface is not supported on this OS; therefore only one socket listening to
> broadcast traffic can be opened. Sockets will not be opened on remaining
> interfaces
>
> (which could be improved to be more informative, when (if) disabling raw
> socket becomes configurable. But that's a minor detail.)
>
> - Sent a unicast DHCP request from a relay to Kea (using either IP address)
> -> Request is correctly received and handled by Kea. Client gets a response.
>
> - Applied iptables filtering, as previously
>
> - Sent a unicast DHCP request from a relay to Kea (using either IP address)
> -> iptables drops the packet. Kea does not receive anything. Client does
> not get a response.
>
>
>
> Regards,
> Nicolas.
>
>
>> On 22/09/14 12:13, Marcin Siodelski wrote:
>>> The code in Kea is prepared to switch between the use of raw sockets
>>> and regular datagram sockets. But, currently the selection is
>>> hardcoded and there is no configuration parameter to control this
>>> selection by the administrator. We're now going through some
>>> refactoring of the configuration code, so once this is done we can easily
>>> implement the switch.
>> For the time being, you can do an experiment. It requires a minor change to
>> the source code.
>>
>> The specific socket handling objects are called PktFilterLPF (raw
>> sockets) PktFilterInet(udp sockets). They are initialized in
>> IfaceMgr::setMatchingPacketFilter in iface_mgr_linux.cc in src/lib/dhcp
>> directory. That is called from Dhcpv4Srv constructor, which is in turn
>> controlled by direct_response_desired flag. Its default value is set to
>> true. If you edit it (line 91 in src/lib/dhcp/dhcp4_srv.h) to false and
>> recompile, it is possible that the code will be able to successfully use UDP
>> sockets.
>>
>> Disclaimer: It's a quick hack. I haven't done any experiments with this, so
>> it may break down. We can't apply it, as most people are interested in
>> direct traffic, so a proper switch (either compile time or run time) is
>> needed. That's something that we can't do immediately.
>>
>> Tomek
>>
>>
> 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.
>
------------------------------
Message: 2
Date: Wed, 24 Sep 2014 20:08:50 +0200
From: Tomek Mrugalski <[email protected]>
To: Sebasti?n Fritz <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] IA_NA + IA_PD
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 23.09.2014 22:26, Sebasti?n Fritz wrote:
> Hi Tomek,
> Thank you for your help. I believe that, there is not
> any problem in assign an IA_NA at the DOCSIS eRouter?s WAN side and a
> different range prefix IAPREFIX at the DOCSIS eRouter?s LAN side. In
> this way, I could have an smaller prefix to only assign IA_NA at the
> WAN side and a bigger subnet to assign IAPREFIX at the LAN side.
In a typical network, you would put both addresses (IA_NA + IAADDR) and
prefixes (IA_PD + IAPREFIX) in the same subnet. That is important,
because otherwise you can't aggregate routing configuration and for X
clients you'd have to have X routing entries.
Does that scale if you X goes into thousands clients? I honestly don't
know. And I have very limited experience with cable modems.
> Knowing that DOCSIS Spec suggests to do the
> assignment (IA_NA) and DHCPv6 prefix delegation (IA_PD) in a single
> DHCPv6 session. Do you plan to support it in the future?.
Yes, we support responding to IA_NA and IA_PD in a single session already.
> Below, there
> is the references with this recommendation.
>
> ?CM-SP-eRouter-I13-140729? -( Section 8.3 - Obtain IPv6 address and
> other configuration parameters),
>
> (http://www.cablelabs.com/wp-content/uploads/specdocs/CM-SP-eRouter-I13-140729.pdf):
>
>
> ?...DHCPv6 address assignment (IA_NA) and DHCPv6 prefix delegation
> (IA_PD) SHOULD be done as a single DHCPv6 session....?
As stated above, we fully support that. I just read the whole section
8.3. There is nothing in there that says that addresses and prefixes
should belong to different subnets.
What we don't support is the ability you are requesting: to send
prefixes and addresses that belong to disjoint subnets.
How many CTMSes you need to support? Here's something you may consider.
If you need to provide arbitrary addresses and arbitrary prefixes, maybe
subnet ::/0 would work for you?
Hope that helps,
Tomek
p.s.
Oh, and we don't support SOLMAXRT option mentioned in the docsis specs
you linked. Fortunately, you can define custom option format and start
sending this particular option. See section 6.2.7 of Kea ARM.
------------------------------
Message: 3
Date: Thu, 25 Sep 2014 07:17:44 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: Marcin Siodelski <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Possibility of disabling raw socket use in Kea
? -> works!
Message-ID:
<ab94b0b675bdf14189cd5a861db36c8414197...@de-cm-mbx26.corp.capgemini.com>
Content-Type: text/plain; charset="utf-8"
Hello Marcin,
I'm using Red Hat Enterprise Linux Server release 6.4 (Santiago)
>
> -----Message d'origine-----
> De : Marcin Siodelski [mailto:[email protected]]
> Envoy? : mercredi 24 septembre 2014 18:14
> ? : Chaigneau, Nicolas
> Cc : Tomek Mrugalski; [email protected]
> Objet : Re: Possibility of disabling raw socket use in Kea ? -> works!
>
> Nicolas,
>
> Great to hear.
>
> We are going to add a configuration switch to enable/disable this behavior at
> some point. Maybe in 0.9.1 release, or 0.9.2.
>
> Can you tell what OS you're using. I presume it is some Linux flavor?
> We will need to test this on other OSes too, when we introduce a config
> switch.
>
> Marcin
>
> On Wed 24 Sep 2014 17:47:32 CEST, Chaigneau, Nicolas wrote:
> >
> > Hello,
> >
> >
> > I've rebuilt Kea with the code change you described.
> >
> > In file:
> > src/bin/dhcp4/dhcp4_srv.h
> >
> > The following modification was applied to Dhcpv4Srv constructor:
> > // const bool direct_response_desired = true);
> > const bool direct_response_desired = false);
> >
> >
> >
> > And I'm quite happy with the results, it works perfectly :)
> >
> >
> >
> > I ran the following test cases:
> >
> > 1) Started Kea on an interface with a single IP address (no iptables
> > filtering set up initially)
> >
> > - Sent a unicast DHCP request from a relay to Kea
> > -> Request is correctly received and handled by Kea. Client gets a
> > response.
> >
> > - Applied a simple filtering rule through iptables:
> > iptables -I INPUT -p udp --dport 67:68 --sport 67:68 -j DROP
> >
> > - Sent a unicast DHCP request from a relay to Kea
> > -> iptables drops the packet. Kea does not receive anything. Client does
> > not get a response.
> >
> >
> > 2) Started Kea on an interface with two IP addresses (no iptables
> > filtering is set up initially)
> >
> > - Noticed the following warning log:
> >
> > 2014-09-24 17:18:51.134 WARN [kea-dhcp4.dhcpsrv/10731]
> > DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Binding socket to an
> > interface is not supported on this OS; therefore only one socket
> > listening to broadcast traffic can be opened. Sockets will not be
> > opened on remaining interfaces
> >
> > (which could be improved to be more informative, when (if) disabling
> > raw socket becomes configurable. But that's a minor detail.)
> >
> > - Sent a unicast DHCP request from a relay to Kea (using either IP address)
> > -> Request is correctly received and handled by Kea. Client gets a
> > response.
> >
> > - Applied iptables filtering, as previously
> >
> > - Sent a unicast DHCP request from a relay to Kea (using either IP address)
> > -> iptables drops the packet. Kea does not receive anything. Client does
> > not get a response.
> >
> >
> >
> > 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.
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 6, Issue 19
**************************************
