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.
Details
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 Skipped - Unit
Tests Skipped
Event Timeline
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. | |
| sys/netinet/udp_usrreq.c | ||
|---|---|---|
| 1054 | Sure. Will do. | |