mir/kea
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/kea synced 2025-08-31 14:05:33 +00:00
Code Issues Releases Wiki Activity

[898-add-a-new-hook-to-support-bootp] Checkpoint: reviewed change and addressed comment, to do import BOOTP class stuff from !522

Browse Source
This commit is contained in:
Francis Dupont
2019-11-21 10:59:59 +01:00
parent e586f960a0
commit 1fc30d1480
5 changed files with 22 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
doc/sphinx/arm/hooks-bootp.rst
View File

@@ -1,4 +1,4 @@
.. _hooks-bootp:
.. _bootp-library:
BOOTP support
=============
@@ -37,9 +37,9 @@ It takes no parameter.
.. _hooks-bootp-config:
Incoming BOOTP packets are added to the BOOTP class. Incoming packets that
are DHCP packets are added to the DHCP class. This can be used to segregate
BOOTP clients to separate pool. For example you can do the following:
Incoming BOOTP packets are added to the BOOTP class. This can be used
to segregate BOOTP clients to separate pool. For example you can do
the following:
::
@@ -72,11 +72,13 @@ BOOTP Hooks Limitations
Currently the BOOTP library has the following limitations:
- BOOTP protocol assumes all lease assignments are permanent. Kea does not support
infinite leases yet. You may configure arbitrarily long leases (e.g. a year), but
after the lease lifetime elapses, Kea will recycle the lease and may assign it
to some other device. This limitation will be removed in the near future.
- BOOTP protocol assumes all lease assignments are permanent. Kea does
not support infinite leases yet. You may configure arbitrarily long
leases (e.g. a year), but after the lease lifetime elapses, Kea will
recycle the lease and may assign it to some other device. This
limitation will be removed in the near future.
- A basic BOOTP as defined in `RFC 951 <https://tools.ietf.org/html/rfc951>`__ is
not supported. Kea only supports the BOOTP with vendor extensions. Depending on
- A basic BOOTP as defined in `RFC 951
<https://tools.ietf.org/html/rfc951>`__ is not supported. Kea only
supports the BOOTP with vendor information extensions. Depending on
the demand, this may or may not be implemented in the future.

2
doc/sphinx/arm/hooks.rst
View File

@@ -442,7 +442,7 @@ loaded by the correct process per the table below.
| | |one of the supported configuration backend implementations. |
+-----------------+---------------+------------------------------------------------------------+
| BOOTP | Kea sources |The BOOTP hooks library adds BOOTP support, as defined in |
| | (since 1.7.2) |RFC1497. It recognizes received BOOTP requests: |
| | (since 1.7.2) |RFC 1497. It recognizes received BOOTP requests: |
| | |they are translated into DHCPREQUEST packets, put into the |
| | |BOOTP client class and get infinite lifetime leases. |
+-----------------+---------------+------------------------------------------------------------+

1
doc/sphinx/conf.py
View File

@@ -74,6 +74,7 @@ language = None
exclude_patterns = [
'_build', 'Thumbs.db', '.DS_Store',
# included files need to be excluded to avoid duplicate labels
'arm/hooks-bootp.rst',
'arm/hooks-class-cmds.rst',
'arm/hooks-cb-cmds.rst',
'arm/config-backend.rst',

1
src/hooks/dhcp/bootp/bootp_callouts.cc
View File

@@ -37,7 +37,6 @@ int pkt4_receive(CalloutHandle& handle) {
try {
if (query->getType() != DHCP_NOTYPE) {
// DHCP query.
query->addClass("DHCP");
return (0);
}
if (query->getOp() == BOOTREPLY) {

22
src/hooks/dhcp/bootp/tests/bootp_unittests.cc
View File

@@ -50,7 +50,7 @@ public:
///
/// @param pkt The packet to submit.
/// @param processed True if the packet must be processed, false otherwise.
void pkt4_receiveCall(Pkt4Ptr& pkt, bool processed, bool dhcp) {
void pkt4_receiveCall(Pkt4Ptr& pkt, bool processed) {
// Get callout handle.
CalloutHandle handle(getCalloutManager());
@@ -73,12 +73,6 @@ public:
EXPECT_FALSE(pkt->inClass("BOOTP"));
EXPECT_EQ(type, pkt->getType());
}
if (dhcp) {
EXPECT_TRUE(pkt->inClass("DHCP"));
} else {
EXPECT_FALSE(pkt->inClass("DHCP"));
}
}
/// @brief Callout manager accessed by this CalloutHandle.
@@ -88,39 +82,39 @@ public:
// Verifies that DHCPDISCOVER goes through unmodified.
TEST_F(BootpTest, dhcpDiscover) {
Pkt4Ptr pkt(new Pkt4(DHCPDISCOVER, 12345));
pkt4_receiveCall(pkt, false, true);
pkt4_receiveCall(pkt, false);
}
// Verifies that DHCPREQUEST goes through unmodified.
TEST_F(BootpTest, dhcpRequest) {
Pkt4Ptr pkt(new Pkt4(DHCPREQUEST, 12345));
pkt4_receiveCall(pkt, false, true);
pkt4_receiveCall(pkt, false);
}
// Verifies that DHCPOFFER goes through unmodified.
TEST_F(BootpTest, dhcpOffer) {
Pkt4Ptr pkt(new Pkt4(DHCPOFFER, 12345));
pkt4_receiveCall(pkt, false, true);
pkt4_receiveCall(pkt, false);
}
// Verifies that BOOTREPLY goes through unmodified.
TEST_F(BootpTest, bootReply) {
// The constructor does not allow to directly create a BOOTREPLY packet.
Pkt4Ptr pkt(new Pkt4(DHCPOFFER, 12345));
//pkt->setType(DHCP_NOTYPE);
pkt->setType(DHCP_NOTYPE);
pkt->delOption(DHO_DHCP_MESSAGE_TYPE);
ASSERT_EQ(BOOTREPLY, pkt->getOp());
pkt4_receiveCall(pkt, false, false);
pkt4_receiveCall(pkt, false);
}
// Verifies that BOOTREQUEST is recognized and processed.
TEST_F(BootpTest, bootRequest) {
// The constructor does not allow to directly create a BOOTREQUEST packet.
Pkt4Ptr pkt(new Pkt4(DHCPDISCOVER, 12345));
// pkt->setType(DHCP_NOTYPE);
pkt->setType(DHCP_NOTYPE);
pkt->delOption(DHO_DHCP_MESSAGE_TYPE);
ASSERT_EQ(BOOTREQUEST, pkt->getOp());
pkt4_receiveCall(pkt, true, false);
pkt4_receiveCall(pkt, true);
}
} // end of anonymous namespace