Skip to content
GitLab
Projects
Groups
Snippets
/
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
Menu
Open sidebar
Sebastian Schrader
Kea
Commits
2f593d03
Commit
2f593d03
authored
Jun 29, 2015
by
Shawn Routhier
Browse files
[3470] Tidy up some typos
parent
08bac337
Changes
2
Hide whitespace changes
Inline
Side-by-side
doc/guide/dhcp4-srv.xml
View file @
2f593d03
...
...
@@ -572,28 +572,28 @@ temporarily override a list of interface names and listen on all interfaces.
<section
id=
"dhcpinform-unicast-issues"
>
<title>
Issues with unicast responses to DHCPINFORM
</title>
<para>
The use of
the
UDP sockets has certain benefits in
the
deployments
where the server receives
a
relayed traffic
only
. These benefits are
<para>
The use of UDP sockets has certain benefits in deployments
where the server receives
only
relayed traffic. These benefits are
mentioned in the
<xref
linkend=
"dhcp4-interface-configuration"
/>
. From
the administrator's perspective it is often desired to be able to
configure the system's firewall to filter out the unwanted traffic, and
the use of UDP sockets faciliates it. However, the administrator must
also be aware of the implications related to filtering certain types
of traffic as it my impair the DHCP server's operation.
of traffic as it m
a
y impair the DHCP server's operation.
</para>
<para>
In this section we are focusing on the case when the server
receives the DHCPINFORM message from the client via a relay. According
to the
<ulink
url=
"http://tools.ietf.org/html/rfc2131"
>
RFC 2131
</ulink>
,
the server should unicast DHCPACK response to the address carried in
the server should unicast
the
DHCPACK response to the address carried in
the 'ciaddr' field. When the UDP socket is in use, the DHCP server
relies on the low level functions of an operating system to build the
data link, IP and UDP layer of the outgoing message. Typically, the
data link, IP and UDP layer
s
of the outgoing message. Typically, the
OS will first use ARP to obtain the client's link layer address to be
inserted into the frame's header, if the address is not cached from
the
previous transaction that the client had with the server.
a
previous transaction that the client had with the server.
When the ARP exchange is successful, the DHCP message can be unicast
to the client, using the
address
obtained.
to the client, using the obtained
address
.
</para>
<para>
Some system administrators block ARP messages in their network,
...
...
@@ -616,9 +616,9 @@ temporarily override a list of interface names and listen on all interfaces.
of the DHCPINFORM message into the link layer.
</para>
<para>
The s
erver administrators willing to support DHCPINFORM
messages via
the
relays should not block ARP traffic in their
networks or
use th
e raw sockets instead of
the
UDP sockets.
<para>
S
erver administrators willing to support DHCPINFORM
messages via relays should not block ARP traffic in their
networks or
should us
e raw sockets instead of UDP sockets.
</para>
</section>
...
...
src/bin/dhcp4/dhcp4_messages.mes
View file @
2f593d03
...
...
@@ -429,18 +429,18 @@ message has been received.
% DHCP4_PACKET_SEND %1: trying to send packet %2 (type %3) from %4:%5 to %6:%7 on interface %8
This debug message is issued when the server is trying to send the
response to the client. When the server is using
the
UDP socket
response to the client. When the server is using
an
UDP socket
to send the packet there are cases when this operation may be
unsuccessful and no error message
is
displayed. One such situation
occurs when the server is unicasting response to the 'ciaddr' of
the
DHCPINFORM message. This often requires broadcasting
the
ARP
unsuccessful and no error message
will be
displayed. One such situation
occurs when the server is unicasting
the
response to the 'ciaddr' of
a
DHCPINFORM message. This often requires broadcasting
an
ARP
message to obtain the link layer address of the unicast destination.
If broadcast ARP messages are blocked in the network, according to
the firewall policy, the ARP message will not
be
respon
ded
.
Consequently, the response to DHCPINFORM will not be sent.
the firewall policy, the ARP message will not
cause a
respon
se
.
Consequently, the response to
the
DHCPINFORM will not be sent.
Since the ARP communication is under the OS control, Kea is not
notified about the drop of the packet which it is trying to send
and it has no means to display
the
error message.
and it has no means to display
an
error message.
The arguments specify the client identification information (HW address
and client identifier), DHCP message name and type, source IPv4
...
...
Write
Preview
Supports
Markdown
0%
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment