Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2018-11-28T16:53:54Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/294Linux packet filter send() emits valgrind error2018-11-28T16:53:54ZThomas MarkwalderLinux packet filter send() emits valgrind errorOn the first packet send, the linux packet filter emits the following valgrind error:
```
2018-11-28 10:57:04.527 DEBUG [kea-dhcp4.packets/12342] DHCP4_RESPONSE_DATA [hwtype=1 08:00:27:25:d3:f4], cid=[32:32:32:32], tid=0x91bfb7: respond...On the first packet send, the linux packet filter emits the following valgrind error:
```
2018-11-28 10:57:04.527 DEBUG [kea-dhcp4.packets/12342] DHCP4_RESPONSE_DATA [hwtype=1 08:00:27:25:d3:f4], cid=[32:32:32:32], tid=0x91bfb7: responding with packet DHCPOFFER (type 2), packet details: local_address=178.16.1.30:67, remote_address=178.16.1.78:68, msg_type=DHCPOFFER (2), transid=0x91bfb7,
options:
type=001, len=004: 4294967040 (uint32)
type=051, len=004: 7200 (uint32)
type=053, len=001: 2 (uint8)
type=054, len=004: 178.16.1.30
type=061, len=004: 32:32:32:32
==12342== Syscall param socketcall.sendto(to.sa_data) points to uninitialised byte(s)
==12342== at 0x80FADC3: ??? (syscall-template.S:81)
==12342== by 0x64E2C21: isc::dhcp::PktFilterLPF::send(isc::dhcp::Iface const&, unsigned short, boost::shared_ptr<isc::dhcp::Pkt4> const&) (in /labspace/var/kea/radius-150-b2/lib/libkea-dhcp++.so.9.0.0)
==12342== by 0x64478CB: isc::dhcp::IfaceMgr::send(boost::shared_ptr<isc::dhcp::Pkt4> const&) (in /labspace/var/kea/radius-150-b2/lib/libkea-dhcp++.so.9.0.0)
==12342== by 0x4AC873: isc::dhcp::Dhcpv4Srv::sendPacket(boost::shared_ptr<isc::dhcp::Pkt4> const&) (in /labspace/var/kea/radius-150-b2/sbin/kea-dhcp4)
==12342== by 0x4B0167: isc::dhcp::Dhcpv4Srv::processPacketBufferSend(boost::shared_ptr<isc::hooks::CalloutHandle>&, boost::shared_ptr<isc::dhcp::Pkt4>&) (in /labspace/var/kea/radius-150-b2/sbin/kea-dhcp4)
==12342== by 0x4ACD98: isc::dhcp::Dhcpv4Srv::run_one() (in /labspace/var/kea/radius-150-b2/sbin/kea-dhcp4)
==12342== by 0x4AC890: isc::dhcp::Dhcpv4Srv::run() (in /labspace/var/kea/radius-150-b2/sbin/kea-dhcp4)
==12342== by 0x4833F5: main (in /labspace/var/kea/radius-150-b2/sbin/kea-dhcp4)
==12342== Address 0x1ffefffa58 is on thread 1's stack
==12342== in frame #1, created by isc::dhcp::PktFilterLPF::send(isc::dhcp::Iface const&, unsigned short, boost::shared_ptr<isc::dhcp::Pkt4> const&) (???:)
==12342==
```
It may not be harmful but it is distraction and something any user doing testing would point out. The fix is a one liner:
```
diff --git a/src/lib/dhcp/pkt_filter_lpf.cc b/src/lib/dhcp/pkt_filter_lpf.cc
index ba64b00..158754d 100644
--- a/src/lib/dhcp/pkt_filter_lpf.cc
+++ b/src/lib/dhcp/pkt_filter_lpf.cc
@@ -305,6 +305,7 @@ PktFilterLPF::send(const Iface& iface, uint16_t sockfd, const Pkt4Ptr& pkt) {
buf.writeData(pkt->getBuffer().getData(), pkt->getBuffer().getLength());
sockaddr_ll sa;
+ memset(&sa, 0x0, sizeof(sa));
sa.sll_family = AF_PACKET;
sa.sll_ifindex = iface.getIndex();
sa.sll_protocol = htons(ETH_P_IP);
```Kea1.5-beta2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/275config-control syntax cleanup2023-05-23T13:10:07ZFrancis Dupontconfig-control syntax cleanupThree issues:
- PARSER_CONFIG_CONTROL is not defined so there is a sub-parser for config-control but it is not usable.
- config_control is defined twice (bison behavior is not clear: it seems it uses only the second one). I removed the...Three issues:
- PARSER_CONFIG_CONTROL is not defined so there is a sub-parser for config-control but it is not usable.
- config_control is defined twice (bison behavior is not clear: it seems it uses only the second one). I removed the spurious first definition.
- unknown_map_entry is called with a short choice: when the parser finds something not matching a choice it emits a message with possible alternatives when their number is low, the unknown_map_entry handles cases where there are too many alternatives to get an suer friendly message. It does not make sense to use it with one alternative...Kea1.5-beta2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/260Follow-up from "WIP: Resolve "Congestion handling - add receive thread and pa...2018-11-20T21:06:12ZMarcin SiodelskiFollow-up from "WIP: Resolve "Congestion handling - add receive thread and packet queue"The following discussions from !103 should be addressed:
- [ ] @marcin started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/103#note_28121): (+4 comments)
> I have some worries about this initialization pa...The following discussions from !103 should be addressed:
- [ ] @marcin started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/103#note_28121): (+4 comments)
> I have some worries about this initialization part being done in the thread and not really guarded from concurrent access to IfaceMgr. Although unlikely, there is a possibility that ifaces_ is modified while the thread is starting up. To mitigate this problem, the method which starts the thread should maybe wait for it to signal that it has been initialized and the for() loop has started. I mean, we should maybe revise the whole IfaceMgr to see whether something in it can be modified that is concurrently used in the thread and not allow such modification if the thread is running? Specifically, sockets and interfaces should not be touched while the thread is running because even the for() loop accesses them.
- [ ] @marcin started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/103#note_28138): (+3 comments)
> Parameters of the constructor aren't properly documented.
- [ ] @marcin started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/103#note_28180): (+4 comments)
> That deserves some comment.
- [ ] @marcin started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/103#note_28205): (+5 comments)
> I was scratching my head how is the new IfaceMgr code compatible with perfdhcp, which is also using receive4() and receive6() functions, but it doesn't (at least not explicitly) start receiver thread? On that matter, I also wonder if it shouldn't be optional to use the thread? perfdhcp probably doesn't want to drop any packets in the ring buffer?Kea1.5-beta2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/182Remove always-include-fqdn configuration parameter from D2ClientConfig2018-11-20T13:52:16ZThomas MarkwalderRemove always-include-fqdn configuration parameter from D2ClientConfigDHCP DDNS configuration for Kea includes a parameter, always-include-fqdn. The intent to not include the FQDN option in the response back to a client, unless it was in the request's PRL. After some discussion this was deemed to be an unn...DHCP DDNS configuration for Kea includes a parameter, always-include-fqdn. The intent to not include the FQDN option in the response back to a client, unless it was in the request's PRL. After some discussion this was deemed to be an unneeded ability.
The current behavior will always include an FQDN option in the response if the request included an FQDN option.
This was formerly Trac issue: http://kea.isc.org/ticket/3294Kea1.5-beta2