Page MenuHomeFreeBSD

Improve sending UDP messages using IPv6 mapped addresses
ClosedPublic

Authored by tuexen on Oct 1 2023, 8:53 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Apr 29, 9:12 PM
Unknown Object (File)
Fri, Apr 26, 1:52 AM
Unknown Object (File)
Sun, Apr 7, 11:29 AM
Unknown Object (File)
Mar 27 2024, 3:50 AM
Unknown Object (File)
Mar 25 2024, 8:34 PM
Unknown Object (File)
Jan 28 2024, 2:58 AM
Unknown Object (File)
Jan 28 2024, 2:58 AM
Unknown Object (File)
Jan 28 2024, 2:58 AM
Subscribers

Details

Summary

PR 274009 reports a problem with sending UDP messages using IPv6 mapped addresses. This is due to an inconsistent handling of inp_vflag. This patch fixes this.

Test Plan

Ensure

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

int main() {
	struct sockaddr_in6 sa6 = { 0 };
	int optval=0;
	int sock;

	sa6.sin6_family = AF_INET6;
	sa6.sin6_port = htons(1);
	inet_pton(AF_INET6, "::ffff:127.0.0.1", &(sa6.sin6_addr));
	sock = socket (PF_INET6, SOCK_DGRAM, 0);
	setsockopt (sock, IPPROTO_IPV6, IPV6_V6ONLY, &optval, sizeof(optval));
	sendto (sock, "abcd", 4, 0, (struct sockaddr *)&sa6, sizeof(sa6));
	inet_pton(AF_INET6, "::1", &(sa6.sin6_addr));
	sendto (sock, "efgh", 4, 0, (struct sockaddr *)&sa6, sizeof(sa6));
	return 0;
}

runs successfully.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

tuexen requested review of this revision.Oct 1 2023, 8:53 PM

Forgive me for saying but replaying history in my head -- I hopefully am wrong -- I have a feeling that we've been going in circles in the last decade and with each iterations things get more complicated and I really dislike the temporary change of inp_vflags just to pass it on.

In D42031#958748, @bz wrote:

Forgive me for saying but replaying history in my head -- I hopefully am wrong -- I have a feeling that we've been going in circles in the last decade and with each iterations things get more complicated and I really dislike the temporary change of inp_vflags just to pass it on.

I'm not arguing that. I just want to have a consistent way of using the inp code. I think, this patch is consistent with other code in the UDP and TCP stack. I'm not saying that it needs to be this way. But I don't know what the API of the inp code is. And it can be changed. That is what I'm asking about. I'm just a consumer of the inp code. So if you think things should be different: fine. But how do we fix the panic. I guess this panic is also in stable/14, so we might want to fix this sooner than later.

Yes, this manipulation of the vflag is ugly but it's consistent with how we handle this problem elsewhere. I verified that my regression test passes with this commit.

sys/netinet/udp_usrreq.c
1054

Can put this in the same line as the tos declaration.

This revision is now accepted and ready to land.Oct 5 2023, 3:24 PM
tuexen added inline comments.
sys/netinet/udp_usrreq.c
1054

Sure. Will do.

This revision was automatically updated to reflect the committed changes.
tuexen marked an inline comment as done.