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/276Congestion Handling should be ENABLED by default for Beta22018-11-26T19:44:02ZThomas MarkwalderCongestion Handling should be ENABLED by default for Beta2To increase the odds of testing occurring congestion handling should be on by default for BETA2.To increase the odds of testing occurring congestion handling should be on by default for BETA2.Kea1.5-beta2Thomas MarkwalderThomas Markwalderhttps://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 Markwalder