From: Marcin Siodelski Date: Thu, 11 Jun 2015 05:36:59 +0000 (+0200) Subject: [master] Merge branch 'trac3070' X-Git-Tag: trac3732a_base~15 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=a6b6156aaa95ab74c69a537e90483f82e9fbe4a2;p=thirdparty%2Fkea.git [master] Merge branch 'trac3070' --- a6b6156aaa95ab74c69a537e90483f82e9fbe4a2 diff --cc src/bin/dhcp6/dhcp6_messages.mes index 9f9de5626f,3fcd1a1745..a119ae6548 --- a/src/bin/dhcp6/dhcp6_messages.mes +++ b/src/bin/dhcp6/dhcp6_messages.mes @@@ -463,78 -394,54 +463,85 @@@ of the named configuration element, or parsing actions and committal of changes failed. The reason for the failure is given in the message. -% DHCP6_PD_LEASE_ADVERT prefix lease %1/%2 advertised (client duid=%3, iaid=%4) -This debug message indicates that the server successfully advertised -a prefix lease. It is up to the client to choose one server out of the -advertised servers and continue allocation with that server. This -is a normal behavior and indicates successful operation. +% DHCP6_PD_LEASE_ADVERT %1: lease for prefix %2/%3 and iaid=%4 will be advertised +This debug message indicates that the server will advertise a +prefix to the client in the ADVERTISE message. The client will +request allocation of this prefix with the REQUEST message sent +in the next message exchange. The first argument includes the client +and transaction identification information. The remaining arguments +hold the allocated prefix, prefix length and IAID. -% DHCP6_PD_LEASE_ADVERT_FAIL failed to advertise a prefix lease for client duid=%1, iaid=%2 +% DHCP6_PD_LEASE_ADVERT_FAIL %1: failed to advertise a prefix lease for iaid=%2 This message indicates that in response to a received SOLICIT, the -server failed to advertise a prefix lease for the client. There may +server failed to advertise a prefix lease for a given client. There may be many reasons for such failure. Each failure is logged in a separate -log entry. +log entry. The first argument holds the client and transaction identification +information. The second argument holds the IAID. -% DHCP6_PD_LEASE_ALLOC prefix lease %1/%2 has been allocated (client duid=%3, iaid=%4) +% DHCP6_PD_LEASE_ALLOC %1: lease for prefix %2/%3 and iaid=%4 has been allocated This debug message indicates that in response to a client's REQUEST -message, the server successfully granted a prefix delegation lease. This -is a normal behavior and indicates successful operation. - -% DHCP6_PD_LEASE_ALLOC_FAIL failed to grant a prefix lease for client duid=%1, iaid=%2 -This message indicates that the server failed to grant (in response to -received REQUEST) a prefix lease for a given client. There may be many reasons -for such failure. Each failure is logged in a separate log entry. +message, the server successfully granted an non-temporary address +lease. This is a normal behavior and indicates successful operation. +The first argument includes the client and transaction identification +information. The remaining arguments hold the allocated prefix, +prefix lenngth and and IAID. -% DHCP6_PROCESS_IA_NA_REQUEST server is processing IA_NA option (duid=%1, iaid=%2, hint=%3) +% DHCP6_PD_LEASE_ALLOC_FAIL %1: failed to grant a prefix lease for iaid=%2 +This message indicates that in response to a received REQUEST, the server +failed to grant a prefix lease for the client. There may be many reasons +for such failure. Each failure is logged in a separate log entry. The first +argument holds the client and transaction identification information. +The second argument holds the IAID. + +% DHCP6_PROCESS_IA_NA_EXTEND %1: extending lease lifetime for IA_NA option with iaid=%2 +This message is logged when the server is starting to extend the lifetime +of the address lease associated with the particular IAID. The first argument +includes the client and transaction identification information. The second +argument contains the IAID. + +% DHCP6_PROCESS_IA_NA_RELEASE %1: releasing lease for IA_NA option with iaid=%2 +This message is logged when the server is trying to release the client's +as a result of receiving the RELEASE message. The first argument +includes the client and transaction identification information. The second +argument contains the IAID. + +% DHCP6_PROCESS_IA_NA_REQUEST %1: server is processing IA_NA option with iaid=%2 and hint=%3 This is a debug message that indicates the processing of a received -IA_NA option. It may optionally contain an address that may be used by -the server as a hint for possible requested address. - -% DHCP6_PROCESS_IA_PD_REQUEST server is processing IA_PD option (duid=%1, iaid=%2, hint=%3) +IA_NA option. The first argument contains the client and the transaction +identification information. The second argument holds the IAID of the +IA_NA option. The third argument may hold the hint for the server +about the address that the client would like to have allocated. +If there is no hint, the argument should provide the text indicating +that the hint hasn't been sent. + +% DHCP6_PROCESS_IA_PD_EXTEND %1: extending lease lifetime for IA_PD option with iaid=%2 +This message is logged when the server is starting to extend the lifetime +of the prefix lease associated with the particular IAID. The first argument +includes the client and transaction identification information. The second +argument contains the IAID. + +% DHCP6_PROCESS_IA_PD_REQUEST %1: server is processing IA_PD option with iaid=%2 and hint=%3 This is a debug message that indicates a processing of received IA_PD -option. It may optionally contain an prefix that may be used by the server -as a hint for possible requested prefix. - -% DHCP6_QUERY_DATA received packet length %1, data length %2, data is %3 -A debug message listing the data received from the client or relay. +option. The first argument contains the client and the transaction +identification information. The second argument holds the IAID of the +IA_PD option. The third argument may hold the hint for the server +about the prefix that the client would like to have allocated. +If there is no hint, the argument should provide the text indicating +that the hint hasn't been sent. + +% DHCP6_QUERY_DATA %1, packet details: %2 +A debug message printing the details of the received packet. The first +argument includes the client and the transaction identification +information. + % DHCP6_RAPID_COMMIT %1: Rapid Commit option received, following 2-way exchange + This debug messgage is issued when the server found a Rapid Commit option + in the client's message and 2-way exchanges are supported by the + server for the subnet on which the client is connected. The argument + specifies the client and transaction identification information. + -% DHCP6_RELEASE_MISSING_CLIENTID client (address=%1) sent RELEASE message without mandatory client-id -This warning message indicates that client sent RELEASE message without -mandatory client-id option. This is most likely caused by a buggy client -(or a relay that malformed forwarded message). This request will not be -processed and a response with error status code will be sent back. + -% DHCP6_RELEASE_NA address %1 belonging to client duid=%2, iaid=%3 was released properly +% DHCP6_RELEASE_NA %1: binding for address %2 and iaid=%3 was released properly This debug message indicates that an address was released properly. It is a normal operation during client shutdown. diff --cc src/bin/dhcp6/dhcp6_srv.cc index 9adda172d2,8c7ff070aa..a57f1f539d --- a/src/bin/dhcp6/dhcp6_srv.cc +++ b/src/bin/dhcp6/dhcp6_srv.cc @@@ -1373,17 -1298,32 +1373,18 @@@ Dhcpv6Srv::assignIA_NA(const Pkt6Ptr& q return (ia_rsp); } - // "Fake" allocation is processing of SOLICIT message. We pretend to do an - // allocation, but we do not put the lease in the database. That is ok, - // because we do not guarantee that the user will get that exact lease. If - // the user selects this server to do actual allocation (i.e. sends REQUEST) - // it should include this hint. That will help us during the actual lease - // allocation. - bool fake_allocation = false; - if (query->getType() == DHCPV6_SOLICIT) { - /// @todo: Check if we support rapid commit - fake_allocation = true; - // Check if the client sent us a hint in his IA_NA. Clients may send an - // address in their IA_NA options as a suggestion (e.g. the last address - // they used before). - boost::shared_ptr hint_opt = - boost::dynamic_pointer_cast(ia->getOption(D6O_IAADDR)); - IOAddress hint("::"); - if (hint_opt) { - hint = hint_opt->getAddress(); -- } - - LOG_DEBUG(dhcp6_logger, DBG_DHCP6_DETAIL, DHCP6_PROCESS_IA_NA_REQUEST) - .arg(duid ? duid->toText() : "(no-duid)").arg(ia->getIAID()) - .arg(hint_opt ? hint.toText() : "(no hint)"); - + // "Fake" allocation is the case when the server is processing the Solicit + // message without the Rapid Commit option and advertises a lease to + // the client, but doesn't commit this lease to the lease database. If + // the Solicit contains the Rapid Commit option and the server is + // configured to honor the Rapid Commit option, or the client has sent + // the Request message, the lease will be committed to the lease + // database. The type of the server's response may be used to determine + // if this is the fake allocation case or not. When the server sends + // Reply message it means that it is committing leases. Other message + // type (Advertise) means that server is not committing leases (fake + // allocation). + bool fake_allocation = (answer->getType() != DHCPV6_REPLY); // Get DDNS update direction flags bool do_fwd = false; @@@ -1542,13 -1458,32 +1543,18 @@@ Dhcpv6Srv::assignIA_PD(const Pkt6Ptr& q return (ia_rsp); } - // "Fake" allocation is processing of SOLICIT message. We pretend to do an - // allocation, but we do not put the lease in the database. That is ok, - // because we do not guarantee that the user will get that exact lease. If - // the user selects this server to do actual allocation (i.e. sends REQUEST) - // it should include this hint. That will help us during the actual lease - // allocation. - bool fake_allocation = (query->getType() == DHCPV6_SOLICIT); - // Check if the client sent us a hint in his IA_PD. Clients may send an - // address in their IA_PD options as a suggestion (e.g. the last address - // they used before). - boost::shared_ptr hint_opt = - boost::dynamic_pointer_cast(ia->getOption(D6O_IAPREFIX)); - IOAddress hint("::"); - if (hint_opt) { - hint = hint_opt->getAddress(); - } - - LOG_DEBUG(dhcp6_logger, DBG_DHCP6_DETAIL, DHCP6_PROCESS_IA_PD_REQUEST) - .arg(duid ? duid->toText() : "(no-duid)").arg(ia->getIAID()) - .arg(hint_opt ? hint.toText() : "(no hint)"); - + // "Fake" allocation is the case when the server is processing the Solicit + // message without the Rapid Commit option and advertises a lease to + // the client, but doesn't commit this lease to the lease database. If + // the Solicit contains the Rapid Commit option and the server is + // configured to honor the Rapid Commit option, or the client has sent + // the Request message, the lease will be committed to the lease + // database. The type of the server's response may be used to determine + // if this is the fake allocation case or not. When the server sends + // Reply message it means that it is committing leases. Other message + // type (Advertise) means that server is not committing leases (fake + // allocation). + bool fake_allocation = (answer->getType() != DHCPV6_REPLY); // Use allocation engine to pick a lease for this client. Allocation engine // will try to honour the hint, but it is just a hint - some other address