From: Shawn Routhier Date: Tue, 30 Jun 2015 05:50:19 +0000 (-0700) Subject: [3470] Tidy up some typos X-Git-Tag: trac3771_base~5^2~1 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=2f593d033176479d9bb5862b4f32c1ad37c7aa10;p=thirdparty%2Fkea.git [3470] Tidy up some typos --- diff --git a/doc/guide/dhcp4-srv.xml b/doc/guide/dhcp4-srv.xml index f61c49bb4f..f197b55815 100644 --- a/doc/guide/dhcp4-srv.xml +++ b/doc/guide/dhcp4-srv.xml @@ -572,28 +572,28 @@ temporarily override a list of interface names and listen on all interfaces.
Issues with unicast responses to DHCPINFORM - The use of the UDP sockets has certain benefits in the deployments - where the server receives a relayed traffic only. These benefits are + The use of UDP sockets has certain benefits in deployments + where the server receives only relayed traffic. These benefits are mentioned in the . 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 may impair the DHCP server's operation. 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 RFC 2131, - 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 layers 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. 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. - The server administrators willing to support DHCPINFORM - messages via the relays should not block ARP traffic in their - networks or use the raw sockets instead of the UDP sockets. + Server administrators willing to support DHCPINFORM + messages via relays should not block ARP traffic in their + networks or should use raw sockets instead of UDP sockets.
diff --git a/src/bin/dhcp4/dhcp4_messages.mes b/src/bin/dhcp4/dhcp4_messages.mes index 2aae7fe4d6..1afe386680 100644 --- a/src/bin/dhcp4/dhcp4_messages.mes +++ b/src/bin/dhcp4/dhcp4_messages.mes @@ -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 responded. -Consequently, the response to DHCPINFORM will not be sent. +the firewall policy, the ARP message will not cause a response. +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