Commit 21b9e729 authored by Marcin Siodelski's avatar Marcin Siodelski
Browse files

[3083] Merge branch 'master' into trac3083

Conflicts:
	src/lib/dhcpsrv/alloc_engine.cc
	src/lib/dhcpsrv/alloc_engine.h
	src/lib/dhcpsrv/tests/alloc_engine_unittest.cc
parents 9fab3d3a 343252ae
667. [func] tomek
Additional hooks (buffer4_receive, lease4_renew,
lease4_release, buffer4_send) added to the DHCPv4 server.
(Trac #2983, git fd47f18f898695b98623a63a0a1c68d2e4b37568)
666. [func] vorner
The CmdCtl's command "print_settings" was removed. It served no real
purpose and was just experimental leftover from early development.
(Trac #3028, git 0d22246092ad4822d48f5a52af5f644f5ae2f5e2)
665. [doc] stephen
Added the "Hook's Maintenance Guide" to the BIND 10 developer
documentation.
(Trac #3063, git 5d1ee7b7470fc644b798ac47db1811c829f5ac24)
664. [bug] tmark
Corrects a bug in Hooks processing that was improperly
creating a new callout handle on every call, rather
than maintaining it throughout the context of the
packet being processed.
(Trac #3062, git 28684bcfe5e54ad0421d75d4445a04b75358ce77)
663. [func] marcin
bind10-dhcp6: Server processes the DHCPv6 Client FQDN Option
b10-dhcp6: Server processes the DHCPv6 Client FQDN Option
sent by a client and generates the response. The DHCPv6 Client
FQDN Option is represented by the new class in the libdhcp++.
As a result of FQDN Option processing, the server generates
NameChangeRequests which represent changes to DNS mappings for
a particular lease (addition or removal of DNS mappings).
Currently all generated NameChangeRequests are dropped. Sending
them to bind10-d2 will be implemented with the future tickets.
them to b10-dhcp-ddns will be implemented with the future tickets.
(Trac #3036, git 209f3964b9f12afbf36f3fa6b62964e03049ec6e)
662. [func] marcin
......
......@@ -21,7 +21,7 @@
*
* If you wish to write "hook" code - code that is loaded by BIND 10 at
* run-time and modifies its behavior you should read the section
* @ref hookDevelopersGuide.
* @ref hooksdgDevelopersGuide.
*
* BIND 10 maintanenace information is divided into a number of sections
* depending on focus. DNS-specific issues are covered in the
......@@ -30,16 +30,18 @@
* specific to any protocol, are discussed in @ref miscellaneousTopics.
*
* If you are a user or system administrator, rather than software engineer,
* you should read <a href="http://bind10.isc.org/docs/bind10-guide.html">BIND10
* you should read the
* <a href="http://bind10.isc.org/docs/bind10-guide.html">BIND10
* Guide (Administrator Reference for BIND10)</a> instead.
*
* Regardless of your field of expertise, you are encouraged to visit
* Regardless of your field of expertise, you are encouraged to visit the
* <a href="http://bind10.isc.org/">BIND10 webpage (http://bind10.isc.org)</a>
* @section hooksFramework Hooks Framework
* - @subpage hooksdgDevelopersGuide
* - @subpage dhcpv4Hooks
* - @subpage dhcpv6Hooks
* - @subpage hooksComponentDeveloperGuide
* - @subpage hooksmgMaintenanceGuide
*
* @section dnsMaintenanceGuide DNS Maintenance Guide
* - Authoritative DNS (todo)
......@@ -70,7 +72,7 @@
* - @subpage perfdhcpInternals
* - @subpage libdhcp_ddns
*
* @section miscellaneousTopics Miscellaneous topics
* @section miscellaneousTopics Miscellaneous Topics
* - @subpage LoggingApi
* - @subpage LoggingApiOverview
* - @subpage LoggingApiLoggerNames
......
......@@ -169,8 +169,6 @@
The configuration command is:
</para>
<!-- NOTE: print_settings is not documented since I think will be removed -->
<para>
<command>shutdown</command> exits <command>b10-cmdctl</command>.
This has an optional <varname>pid</varname> argument to
......
......@@ -370,8 +370,6 @@ class CommandControl():
self._httpserver.shutdown()
self._serving = False
elif command == 'print_settings':
answer = ccsession.create_answer(0, self._cmdctl_config_data)
else:
answer = ccsession.create_answer(1, 'unknown command: ' + command)
......
......@@ -23,11 +23,6 @@
}
],
"commands": [
{
"command_name": "print_settings",
"command_description": "Print some_string and some_int to stdout",
"command_args": []
},
{
"command_name": "shutdown",
"command_description": "shutdown cmdctl",
......
......@@ -462,10 +462,22 @@ class TestCommandControl(unittest.TestCase):
answer = self.cmdctl.command_handler('unknown-command', None)
self._check_answer(answer, 1, 'unknown command: unknown-command')
answer = self.cmdctl.command_handler('print_settings', None)
# Send a real command. Mock stuff so the shutdown command doesn't
# cause an exception.
class ModuleCC:
def send_stopping():
pass
self.cmdctl._module_cc = ModuleCC
called = []
class Server:
def shutdown():
called.append('shutdown')
self.cmdctl._httpserver = Server
answer = self.cmdctl.command_handler('shutdown', None)
rcode, msg = ccsession.parse_answer(answer)
self.assertEqual(rcode, 0)
self.assertTrue(msg != None)
self.assertIsNone(msg)
self.assertEqual(['shutdown'], called)
def test_command_handler_spec_update(self):
# Should not be present
......@@ -543,10 +555,10 @@ class TestCommandControl(unittest.TestCase):
self.assertEqual(1, rcode)
# Send a command to cmdctl itself. Should be the same effect.
rcode, value = self.cmdctl.send_command('Cmdctl', 'print_settings',
rcode, value = self.cmdctl.send_command('Cmdctl', 'shutdown',
None)
self.assertEqual(2, len(self.cmdctl.sent_messages))
self.assertEqual(({'command': ['print_settings']}, 'Cmdctl'),
self.assertEqual(({'command': ['shutdown']}, 'Cmdctl'),
self.cmdctl.sent_messages[-1])
self.assertEqual(1, rcode)
......
......@@ -68,7 +68,7 @@
</para>
<para>
<command>b10-dbutil</command> operates in one of two modesr: check mode
<command>b10-dbutil</command> operates in one of two modes: check mode
or upgrade mode.
</para>
......
......@@ -49,22 +49,45 @@ 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.
@subsection dhcpv4HooksBuffer4Receive buffer4_receive
- @b Arguments:
- name: @b query4, type: isc::dhcp::Pkt4Ptr, direction: <b>in/out</b>
- @b Description: this callout is executed when an incoming DHCPv4
buffer is received, before its content is parsed. The sole argument
- query4 - contains a pointer to an isc::dhcp::Pkt4 object that
contains raw information regarding incoming packet, including its
source and destination addresses, interface over which it was
received, and a raw buffer stored in data_ field. None of the
packet fields (op_, hlen_, chaddr_, etc.) are set yet. Callouts
installed on this hook point can modify the incoming buffer. The
server will parse the buffer afterwards.
- <b>Skip flag action</b>: If any callout sets the skip flag, the server will
skip the buffer parsing. In such case there is an expectation that
the callout will parse the buffer and create option objects (see
isc::dhcp::Pkt4::addOption()). Otherwise the server will find out
that some mandatory options are missing (e.g. DHCP Message Type) and
will drop the packet. If you want to have the capability to drop
a message, it is better to use skip flag in pkt4_receive callout.
@subsection dhcpv4HooksPkt4Receive pkt4_receive
- @b Arguments:
- name: @b query4, type: isc::dhcp::Pkt4Ptr, direction: <b>in/out</b>
- @b Description: this callout is executed when an incoming DHCPv4
packet is received and its content is parsed. The sole argument -
query4 - contains a pointer to an isc::dhcp::Pkt4 object that contains
all information regarding incoming packet, including its source and
destination addresses, interface over which it was received, a list
of all options present within and relay information. All fields of
the Pkt4 object can be modified at this time, except data_. (data_
contains the incoming packet as raw buffer. By the time this hook is
reached, that information has already parsed and is available though
other fields in the Pkt4 object. For this reason, it doesn't make
sense to modify it.)
packet is received and its content has been parsed. The sole
argument - query4 - contains a pointer to an isc::dhcp::Pkt4 object
that contains all information regarding incoming packet, including
its source and destination addresses, interface over which it was
received, a list of all options present within and relay
information. All fields of the Pkt4 object can be modified at this
time, except data_. (By the time this hook is reached, the contents
of the data_ field has been already parsed and stored in other
fields. Therefore, the modification in the data_ field has no
effect.)
- <b>Skip flag action</b>: If any callout sets the skip flag, the server will
drop the packet and start processing the next one. The reason for the drop
......@@ -97,42 +120,97 @@ packet processing. Hook points that are not specific to packet processing
- name: @b lease4, type: isc::dhcp::Lease4Ptr, direction: <b>in/out</b>
- @b Description: this callout is executed after the server engine
has selected a lease for client's request but before the lease
has been inserted into the database. Any modifications made to the
isc::dhcp::Lease4 object will be stored in the lease's record in the
database. The callout should make sure that any modifications are
sanity checked as the server will use that data as is with no further
checking.\n\n The server processes lease requests for DISCOVER and
REQUEST in a very similar way. The only major difference is that
for DISCOVER the lease is just selected, but not inserted into
the database. It is possible to distinguish between DISCOVER and
REQUEST by checking value of the fake_allocation flag: a value of true
means that the lease won't be inserted into the database (DISCOVER),
a value of false means that it will (REQUEST).
has selected a lease for client's request but before the lease has
been inserted into the database. Any modifications made to the
isc::dhcp::Lease4 object will be stored in the lease's record in
the database. The callout should sanity check all modifications as
the server will use that data as is with no further checking.\n\n
The server processes lease requests for DISCOVER and REQUEST in a
very similar way. The only major difference is that for DISCOVER
the lease is just selected, but not inserted into the database. It
is possible to distinguish between DISCOVER and REQUEST by checking
value of the fake_allocation flag: a value of true indicates that the
lease won't be inserted into the database (DISCOVER), a value of
false indicates that it will (REQUEST).
- <b>Skip flag action</b>: If any callout installed on 'lease4_select'
sets the skip flag, the server will not assign any lease. Packet
processing will continue, but client will not get an address.
@subsection dhcpv4HooksLeaseRenew lease4_renew
- @b Arguments:
- name: @b subnet4, type: isc::dhcp::Subnet4Ptr, direction: <b>in</b>
- name: @b clientid, type: isc::dhcp::ClientId, direction: <b>in</b>
- name: @b hwaddr, type: isc::dhcp::HWAddr, direction: <b>in</b>
- name: @b lease4, type: isc::dhcp::Lease4Ptr, direction: <b>in/out</b>
- @b Description: this callout is executed when the server engine
is about to renew a lease, as a result of receiving REQUEST/Renewing
packet. The lease4 argument points to Lease4 object that contains
the updated values. Callout can modify those values. Care should be taken
as the server will attempt to update the lease in the database without
any additional checks.
- <b>Skip flag action</b>: If any callout installed on 'lease4_renew'
sets the skip flag, the server will not update the lease and will
use old values instead.
@subsection dhcpv4HooksLeaseRelease lease4_release
- @b Arguments:
- name: @b query4, type: isc::dhcp::Pkt4Ptr, direction: <b>in</b>
- name: @b lease4, type: isc::dhcp::Lease4Ptr, direction: <b>in</b>
- @b Description: this callout is executed when the server engine
is about to release a lease, as a result of receiving RELEASE packet.
The lease4 argument points to Lease4 object that contains the lease to
be released. It doesn't make sense to modify it at this time.
- <b>Skip flag action</b>: If any callout installed on 'lease4_release'
sets the skip flag, the server will not delete the lease. It will be
kept in the database and will go through the regular expiration/reuse
process.
@subsection dhcpv4HooksPkt4Send pkt4_send
- @b Arguments:
- name: @b response4, type: isc::dhcp::Pkt4Ptr, direction: <b>in/out</b>
- @b Description: this callout is executed when server's response
is about to be send back to the client. The sole argument - response4 -
is about to be sent back to the client. The sole argument - response4 -
contains a pointer to an isc::dhcp::Pkt4 object that contains the
packet, with set source and destination addresses, interface over which
it will be send, list of all options and relay information. All fields
of the Pkt4 object can be modified at this time, except bufferOut_.
packet, with source and destination addresses set, interface over which
it will be sent, and a list of all options and relay information. All fields
of the Pkt4 object can be modified at this time, except buffer_out_.
(This is scratch space used for constructing the packet after all
pkt4_send callouts are complete, so any changes to that field will
be overwritten.)
- <b>Skip flag action</b>: if any callout sets the skip flag, the server
will not construct raw buffer. The expectation is that if the callout
set skip flag, it is responsible for constructing raw form on its own.
Otherwise the output packet will be sent with zero length.
@subsection dhcpv4HooksBuffer4Send buffer4_send
- @b Arguments:
- name: @b response4, type: isc::dhcp::Pkt4Ptr, direction: <b>in/out</b>
- @b Description: this callout is executed when server's response
is about to be sent back to the client. The sole argument - response4 -
contains a pointer to an isc::dhcp::Pkt4 object that contains the
packet, with source and destination addresses set, interface over which
it will be sent, and a list of all options and relay information. The raw
on-wire form is already prepared in buffer_out_ (see isc::dhcp::Pkt4::getBuffer())
It doesn't make any sense to modify packet fields or options content
at this time, because they were already used to construct on-wire buffer.
- <b>Skip flag action</b>: if any callout sets the skip flag, the server
will drop this response packet. However, the original request packet
from a client was processed, so server's state was most likely changed
(e.g. lease was allocated). Setting this flag merely stops the change
being communicated to the client.
*/
......@@ -70,6 +70,24 @@ This message is printed when DHCPv4 server disables an interface from being
used to receive DHCPv4 traffic. Sockets on this interface will not be opened
by the Interface Manager until interface is enabled.
% DHCP4_HOOK_BUFFER_RCVD_SKIP received DHCPv4 buffer was dropped because a callout set the skip flag.
This debug message is printed when a callout installed on buffer4_receive
hook point set the skip flag. For this particular hook point, the
setting of the flag by a callout instructs the server to drop the packet.
% DHCP4_HOOK_BUFFER_SEND_SKIP prepared DHCPv4 response was dropped because a callout set the skip flag.
This debug message is printed when a callout installed on buffer4_send
hook point set the skip flag. For this particular hook point, the
setting of the flag by a callout instructs the server to drop the packet.
Server completed all the processing (e.g. may have assigned, updated
or released leases), but the response will not be send to the client.
% DHCP4_HOOK_LEASE4_RELEASE_SKIP DHCPv4 lease was not released because a callout set the skip flag.
This debug message is printed when a callout installed on lease4_release
hook point set the skip flag. For this particular hook point, the
setting of the flag by a callout instructs the server to not release
a lease.
% DHCP4_HOOK_PACKET_RCVD_SKIP received DHCPv4 packet was dropped, because a callout set the skip flag.
This debug message is printed when a callout installed on the pkt4_receive
hook point sets the skip flag. For this particular hook point, the
......@@ -138,6 +156,10 @@ This is a general catch-all message indicating that the processing of a
received packet failed. The reason is given in the message. The server
will not send a response but will instead ignore the packet.
% DHCP4_PACKET_DROP_NO_TYPE packet received on interface %1 dropped, because of missing msg-type option
This is a debug message informing that incoming DHCPv4 packet did not
have mandatory DHCP message type option and thus was dropped.
% DHCP4_PACKET_RECEIVED %1 (type %2) packet received on interface %3
A debug message noting that the server has received the specified type of
packet on the specified interface. Note that a packet marked as UNKNOWN
......
This diff is collapsed.
......@@ -366,13 +366,6 @@ private:
uint16_t port_; ///< UDP port number on which server listens.
bool use_bcast_; ///< Should broadcast be enabled on sockets (if true).
/// @brief returns callout handle for specified packet
///
/// @param pkt packet for which the handle should be returned
///
/// @return a callout handle to be used in hooks related to said packet
isc::hooks::CalloutHandlePtr getCalloutHandle(const Pkt4Ptr& pkt);
/// Indexes for registered hook points
int hook_index_pkt4_receive_;
int hook_index_subnet4_select_;
......
This diff is collapsed.
......@@ -118,7 +118,7 @@ hook point set the skip flag. For this particular hook point, the
setting of the flag by a callout instructs the server to drop the packet.
% DHCP6_HOOK_BUFFER_SEND_SKIP prepared DHCPv6 response was dropped because a callout set the skip flag.
This debug message is printed when a callout installed on buffer6_receive
This debug message is printed when a callout installed on buffer6_send
hook point set the skip flag. For this particular hook point, the
setting of the flag by a callout instructs the server to drop the packet.
Server completed all the processing (e.g. may have assigned, updated
......
......@@ -30,17 +30,18 @@
#include <dhcp/pkt6.h>
#include <dhcp6/dhcp6_log.h>
#include <dhcp6/dhcp6_srv.h>
#include <dhcpsrv/callout_handle_store.h>
#include <dhcpsrv/cfgmgr.h>
#include <dhcpsrv/lease_mgr.h>
#include <dhcpsrv/lease_mgr_factory.h>
#include <dhcpsrv/subnet.h>
#include <dhcpsrv/utils.h>
#include <exceptions/exceptions.h>
#include <hooks/callout_handle.h>
#include <hooks/hooks_manager.h>
#include <util/encode/hex.h>
#include <util/io_utilities.h>
#include <util/range_utilities.h>
#include <util/encode/hex.h>
#include <hooks/hooks_manager.h>
#include <hooks/callout_handle.h>
#include <boost/foreach.hpp>
#include <boost/tokenizer.hpp>
......@@ -1810,33 +1811,6 @@ Dhcpv6Srv::processInfRequest(const Pkt6Ptr& infRequest) {
return reply;
}
isc::hooks::CalloutHandlePtr Dhcpv6Srv::getCalloutHandle(const Pkt6Ptr& pkt) {
// This method returns a CalloutHandle for a given packet. It is guaranteed
// to return the same callout_handle (so user library contexts are
// preserved). This method works well if the server processes one packet
// at a time. Once the server architecture is extended to cover parallel
// packets processing (e.g. delayed-ack, some form of buffering etc.), this
// method has to be extended (e.g. store callouts in a map and use pkt as
// a key). Additional code would be required to release the callout handle
// once the server finished processing.
CalloutHandlePtr callout_handle;
static Pkt6Ptr old_pointer;
if (!callout_handle ||
old_pointer != pkt) {
// This is the first packet or a different packet than previously
// passed to getCalloutHandle()
// Remember the pointer to this packet
old_pointer = pkt;
callout_handle = HooksManager::getHooksManager().createCalloutHandle();
}
return (callout_handle);
}
void
Dhcpv6Srv::openActiveSockets(const uint16_t port) {
IfaceMgr::instance().closeSockets();
......
......@@ -473,12 +473,10 @@ private:
/// initiate server shutdown procedure.
volatile bool shutdown_;
/// @brief returns callout handle for specified packet
///
/// @param pkt packet for which the handle should be returned
///
/// @return a callout handle to be used in hooks related to said packet
isc::hooks::CalloutHandlePtr getCalloutHandle(const Pkt6Ptr& pkt);
/// Indexes for registered hook points
int hook_index_pkt6_receive_;
int hook_index_subnet6_select_;
int hook_index_pkt6_send_;
/// UDP port number on which server listens.
uint16_t port_;
......
......@@ -285,10 +285,6 @@ public:
/// @return always 0
static int
buffer6_receive_skip(CalloutHandle& callout_handle) {
Pkt6Ptr pkt;
callout_handle.getArgument("query6", pkt);
callout_handle.setSkip(true);
// Carry on as usual
......@@ -561,7 +557,7 @@ TEST_F(HooksDhcpv6SrvTest, simple_buffer6_receive) {
// Server will now process to run its normal loop, but instead of calling
// IfaceMgr::receive6(), it will read all packets from the list set by
// fakeReceive()
// In particular, it should call registered pkt6_receive callback.
// In particular, it should call registered buffer6_receive callback.
srv_->run();
// Check that the callback called is indeed the one we installed
......@@ -577,7 +573,7 @@ TEST_F(HooksDhcpv6SrvTest, simple_buffer6_receive) {
EXPECT_TRUE(expected_argument_names == callback_argument_names_);
}
// Checks if callouts installed on pkt6_received is able to change
// Checks if callouts installed on buffer6_receive is able to change
// the values and the parameters are indeed used by the server.
TEST_F(HooksDhcpv6SrvTest, valueChange_buffer6_receive) {
......
......@@ -33,7 +33,8 @@ namespace dhcp {
const IOAddress DEFAULT_ADDRESS("0.0.0.0");
Pkt4::Pkt4(uint8_t msg_type, uint32_t transid)
:local_addr_(DEFAULT_ADDRESS),
:buffer_out_(DHCPV4_PKT_HDR_LEN),
local_addr_(DEFAULT_ADDRESS),
remote_addr_(DEFAULT_ADDRESS),
iface_(""),
ifindex_(0),
......@@ -48,8 +49,7 @@ Pkt4::Pkt4(uint8_t msg_type, uint32_t transid)
ciaddr_(DEFAULT_ADDRESS),
yiaddr_(DEFAULT_ADDRESS),
siaddr_(DEFAULT_ADDRESS),
giaddr_(DEFAULT_ADDRESS),
bufferOut_(DHCPV4_PKT_HDR_LEN)
giaddr_(DEFAULT_ADDRESS)
{
memset(sname_, 0, MAX_SNAME_LEN);
memset(file_, 0, MAX_FILE_LEN);
......@@ -58,7 +58,8 @@ Pkt4::Pkt4(uint8_t msg_type, uint32_t transid)
}
Pkt4::Pkt4(const uint8_t* data, size_t len)
:local_addr_(DEFAULT_ADDRESS),
:buffer_out_(0), // not used, this is RX packet
local_addr_(DEFAULT_ADDRESS),
remote_addr_(DEFAULT_ADDRESS),
iface_(""),
ifindex_(0),
......@@ -72,8 +73,7 @@ Pkt4::Pkt4(const uint8_t* data, size_t len)
ciaddr_(DEFAULT_ADDRESS),
yiaddr_(DEFAULT_ADDRESS),
siaddr_(DEFAULT_ADDRESS),
giaddr_(DEFAULT_ADDRESS),
bufferOut_(0) // not used, this is RX packet
giaddr_(DEFAULT_ADDRESS)
{
if (len < DHCPV4_PKT_HDR_LEN) {
isc_throw(OutOfRange, "Truncated DHCPv4 packet (len=" << len
......@@ -111,25 +111,25 @@ Pkt4::pack() {
try {
size_t hw_len = hwaddr_->hwaddr_.size();
bufferOut_.writeUint8(op_);
bufferOut_.writeUint8(hwaddr_->htype_);
bufferOut_.writeUint8(hw_len < MAX_CHADDR_LEN ?
buffer_out_.writeUint8(op_);
buffer_out_.writeUint8(hwaddr_->htype_);
buffer_out_.writeUint8(hw_len < MAX_CHADDR_LEN ?
hw_len : MAX_CHADDR_LEN);
bufferOut_.writeUint8(hops_);
bufferOut_.writeUint32(transid_);
bufferOut_.writeUint16(secs_);
bufferOut_.writeUint16(flags_);
bufferOut_.writeUint32(ciaddr_);
bufferOut_.writeUint32(yiaddr_);
bufferOut_.writeUint32(siaddr_);
bufferOut_.writeUint32(giaddr_);
buffer_out_.writeUint8(hops_);
buffer_out_.writeUint32(transid_);
buffer_out_.writeUint16(secs_);
buffer_out_.writeUint16(flags_);
buffer_out_.writeUint32(ciaddr_);
buffer_out_.writeUint32(yiaddr_);
buffer_out_.writeUint32(siaddr_);
buffer_out_.writeUint32(giaddr_);
if (hw_len <= MAX_CHADDR_LEN) {
// write up to 16 bytes of the hardware address (CHADDR field is 16
// bytes long in DHCPv4 message).
bufferOut_.writeData(&hwaddr_->hwaddr_[0],
(hw_len < MAX_CHADDR_LEN ?
buffer_out_.writeData(&hwaddr_->hwaddr_[0],
(hw_len < MAX_CHADDR_LEN ?
hw_len : MAX_CHADDR_LEN) );
hw_len = MAX_CHADDR_LEN - hw_len;
} else {
......@@ -138,20 +138,20 @@ Pkt4::pack() {
// write (len) bytes of padding
vector<uint8_t> zeros(hw_len, 0);
bufferOut_.writeData(&zeros[0], hw_len);
// bufferOut_.writeData(chaddr_, MAX_CHADDR_LEN);
buffer_out_.writeData(&zeros[0], hw_len);
// buffer_out_.writeData(chaddr_, MAX_CHADDR_LEN);
bufferOut_.writeData(sname_, MAX_SNAME_LEN);
bufferOut_.writeData(file_, MAX_FILE_LEN);
buffer_out_.writeData(sname_, MAX_SNAME_LEN);
buffer_out_.writeData(file_, MAX_FILE_LEN);
// write DHCP magic cookie
bufferOut_.writeUint32(DHCP_OPTIONS_COOKIE);
buffer_out_.writeUint32(DHCP_OPTIONS_COOKIE);
LibDHCP::packOptions(bufferOut_, options_);
LibDHCP::packOptions(buffer_out_, options_);
// add END option that indicates end of options
// (End option is very simple, just a 255 octet)
bufferOut_.writeUint8(DHO_END);
buffer_out_.writeUint8(DHO_END);
} catch(const Exception& e) {
// An exception is thrown and message will be written to Logger
isc_throw(InvalidOperation, e.what());
......@@ -259,7 +259,7 @@ void Pkt4::setType(uint8_t dhcp_type) {
}
void Pkt4::repack() {
bufferOut_.writeData(&data_[0], data_.size());
buffer_out_.writeData(&data_[0], data_.size());
}
std::string
......
......@@ -70,7 +70,7 @@ public:
///
/// Prepares on-wire format of message and all its options.
/// Options must be stored in options_ field.
/// Output buffer will be stored in bufferOut_.
/// Output buffer will be stored in buffer_out_.
///
/// @throw InvalidOperation if packing fails
void
......@@ -103,7 +103,7 @@ public:
///
/// This is mostly a diagnostic function. It is being used for sending
/// received packet. Received packet is stored in bufferIn_, but
/// transmitted data is stored in bufferOut_. If we want to send packet
/// transmitted data is stored in buffer_out_. If we want to send packet
/// that we just received, a copy between those two buffers is necessary.
void repack();
......@@ -307,11 +307,12 @@ public:
/// is only valid till Pkt4 object is valid.
///