"basename" is define in libgen.h included from system/dir.h Signed-off-by: Volker Lendecke <vl@samba.org> Reviewed-by: Stefan Metzmacher <metze@samba.org>
If you happen to talloc_free(run_ctx) before all the tevent_req's hanging off it, you run into the following: ==495196== Invalid read of size 8 ==495196== at 0x10D757: run_proc_state_destructor (run_proc.c:413) ==495196== by 0x488F736: _tc_free_internal (talloc.c:1158) ==495196== by 0x488FBDD: _talloc_free_internal (talloc.c:1248) ==495196== by 0x4890F41: _talloc_free (talloc.c:1792) ==495196== by 0x48538B1: tevent_req_received (tevent_req.c:293) ==495196== by 0x4853429: tevent_req_destructor (tevent_req.c:129) ==495196== by 0x488F736: _tc_free_internal (talloc.c:1158) ==495196== by 0x4890AF6: _tc_free_children_internal (talloc.c:1669) ==495196== by 0x488F967: _tc_free_internal (talloc.c:1184) ==495196== by 0x488FBDD: _talloc_free_internal (talloc.c:1248) ==495196== by 0x4890F41: _talloc_free (talloc.c:1792) ==495196== by 0x10DE62: main (run_proc_test.c:86) ==495196== Address 0x55b77f8 is 152 bytes inside a block of size 160 free'd ==495196== at 0x48399AB: free (vg_replace_malloc.c:538) ==495196== by 0x488FB25: _tc_free_internal (talloc.c:1222) ==495196== by 0x488FBDD: _talloc_free_internal (talloc.c:1248) ==495196== by 0x4890F41: _talloc_free (talloc.c:1792) ==495196== by 0x10D315: run_proc_context_destructor (run_proc.c:329) ==495196== by 0x488F736: _tc_free_internal (talloc.c:1158) ==495196== by 0x488FBDD: _talloc_free_internal (talloc.c:1248) ==495196== by 0x4890F41: _talloc_free (talloc.c:1792) ==495196== by 0x10DE62: main (run_proc_test.c:86) ==495196== Block was alloc'd at ==495196== at 0x483877F: malloc (vg_replace_malloc.c:307) ==495196== by 0x488EAD9: __talloc_with_prefix (talloc.c:783) ==495196== by 0x488EC73: __talloc (talloc.c:825) ==495196== by 0x488F0FC: _talloc_named_const (talloc.c:982) ==495196== by 0x48925B1: _talloc_zero (talloc.c:2421) ==495196== by 0x10C8F2: proc_new (run_proc.c:61) ==495196== by 0x10D4C9: run_proc_send (run_proc.c:381) ==495196== by 0x10DDF6: main (run_proc_test.c:79) This happens because run_proc_context_destructor() directly does a talloc_free() on the struct proc_context's and not the enclosing tevent_req's. run_proc_kill() makes sure that we don't follow proc->req, but it forgets the "state->proc", which is free()'ed, but later dereferenced in run_proc_state_destructor(). This is an attempt at a quick fix, I believe we should convert run_proc_context->plist into an array of tevent_req's, so that we can properly TALLOC_FREE() according to the "natural" hierarchy and not just pull an arbitrary thread out of that heap. Signed-off-by: Volker Lendecke <vl@samba.org> Reviewed-by: Martin Schwenke <martin@meltin.net> Autobuild-User(master): Volker Lendecke <vl@samba.org> Autobuild-Date(master): Thu Oct 6 15:10:20 UTC 2022 on sn-devel-184
To debug ctdb_killtcp failures, add CTDB_KILLTCP_DEBUGLEVEL=DEBUG to script.options. Signed-off-by: Martin Schwenke <martin@meltin.net> Reviewed-by: Amitay Isaacs <amitay@gmail.com> Autobuild-User(master): Amitay Isaacs <amitay@samba.org> Autobuild-Date(master): Tue Sep 20 11:42:16 UTC 2022 on sn-devel-184
Add simple support for IPoIB via DLT_LINUX_SLL and DLT_LINUX_SLL2. This seems to work, even when an IB interface is specified. If this is later found to be insufficient, support for DLT_IPOIB can be implemented. See https://www.tcpdump.org/linktypes.html for a starting point. Signed-off-by: Martin Schwenke <martin@meltin.net> Reviewed-by: Amitay Isaacs <amitay@gmail.com>
This uses Linux cooked capture link-layer headers. See: https://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL.html https://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL2.html The header type needs to be checked to ensure the protocol type (i.e. ether type, for the protocols we might be interested in) is meaningful. The size of the header needs to be known so it can be skipped, allowing the IP header to be found and parsed. It would be possible to define support for DLT_LINUX_SLL2 if it is missing. However, if a platform is missing support in the header file then it is almost certainly missing in the run-time library too. Signed-off-by: Martin Schwenke <martin@meltin.net> Reviewed-by: Amitay Isaacs <amitay@gmail.com>
The current code will almost certainly generate ENOMSG for non-ethernet packets, even for ethernet packets when the "any" interface is used. pcap_datalink(3PCAP) says: Do NOT assume that the packets for a given capture or ``savefile`` will have any given link-layer header type, such as DLT_EN10MB for Ethernet. For example, the "any" device on Linux will have a link-layer header type of DLT_LINUX_SLL or DLT_LINUX_SLL2 even if all devices on the sys‐ tem at the time the "any" device is opened have some other data link type, such as DLT_EN10MB for Ethernet. So, pcap_datalink() must be used. Detect pcap packet types that are supported (currently only ethernet) in the open code. There is no use continuing if the read code can't parse packets. The pattern of using switch statements supports future addition of other packet types. Signed-off-by: Martin Schwenke <martin@meltin.net> Reviewed-by: Amitay Isaacs <amitay@gmail.com>
In particular, knowing the reason fetching the packet fails can help with debugging unsupported protocols in the pcap code. Signed-off-by: Martin Schwenke <martin@meltin.net> Reviewed-by: Amitay Isaacs <amitay@gmail.com>
Signed-off-by: Martin Schwenke <martin@meltin.net> Reviewed-by: Amitay Isaacs <amitay@gmail.com>
This is preferred because it will fail for devices that do not support epoll_wait() and similar. Signed-off-by: Martin Schwenke <martin@meltin.net> Reviewed-by: Amitay Isaacs <amitay@gmail.com>
errbuf can't be NULL. Might as well use it. Signed-off-by: Martin Schwenke <martin@meltin.net> Reviewed-by: Amitay Isaacs <amitay@gmail.com>