Date: Fri, 26 Nov 2021 13:25:30 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 260055] recvmsg / IP_RECVDSTADDR issue Message-ID: <bug-260055-227-4GE3PUsnrq@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-260055-227@https.bugs.freebsd.org/bugzilla/> References: <bug-260055-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260055 --- Comment #2 from Eugene Grosbein <eugen@freebsd.org> --- (In reply to Konstantin Belousov from comment #1) mpd5 uses additional threads to talk with RADIUS server only and these additional threads are short-lived. The output of "thread apply all bt" in = this PR was not redacted, so there was only single thread 1 at the moment. The socket is IPv4 UDP created by incoming L2TP over UDP request. It is in blocking read mode. > That said, GetSockDstAddress() is strange. From its name, it seems that the purpose of the function is to obtain the destination address, as the control message. But it also tries to read some data from the socket, and the data is discarded. I coded the function GetSockDstAddress(). It is called just once after sock= et creation in case L2TP server "self" address not specified in the mpd.conf You are right, the purpose is to receive control message with destination address from the kernel and it is my first attempt to programm this. I beli= eved this is right way to do that without reading payload data from the socket.= =20 Maybe there is some application logic error if some payload data is discard= ed, but recvmsg() still has control message to return because of IP_RECVDSTADDR socket option, hasn't it? So it should not block just after first UDP datag= ramm arrived, I believe. I am interested in fixing the problem and will add more information you requested. However, I need also to minimize impact on this production serve= r, so please show exact command I should use to catch the kernel-side backtrac= e. This my machine still uses FreeBSD 11.4-STABLE/i386 r365547 (September 2020= ). --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-260055-227-4GE3PUsnrq>