By looking at the code, I see a reason why the trigger for both guess_sockaddr_in and guess_udp_sendmsg can timeout.
Those two probes, and maybe others, require the loopback interface to be assigned the network 127.0.0.1/8. They will try to communicate using addresses like 127.123.123.123 (actually a random address). Maybe a change in your system is preventing such communication by having the loopback associated to 127.0.0.1/32 or 127.0.0.1/24.
Can you check the output of any of these commands:
ip a ls dev lo
should return:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
ip route ls table local dev lo
broadcast 127.0.0.0 proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 proto kernel scope host src 127.0.0.1
local 127.0.0.1 proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 proto kernel scope link src 127.0.0.1
And also check communication with the following commands in different terminals:
(server)
nc -vln -s 127.123.123.123 -p 8888
(client)
echo hello | nc -v 127.123.123.123 8888
If communication if possible the server should output:
listening on [127.123.123.123] 8888 ...
connect to [127.123.123.123] from (UNKNOWN) [127.0.0.1] 55994
hello