Hi Willy,
> One is a fix (to->from) and can as well include the doc fix. Attaching the patch. I stole your explanation for the commit message, hope you don't mind :) >> - when haproxy listens on both families with one bind statement, it sees >> IPv4 connection in the AF_INET6 family (like ::ffff:10.0.0.3 instead of >> 10.0.0.3): when this happens, we set IPV6_TCLASS, but it has no effect. > Good point, I didn't think about this case either. I don't even know what > method we can use to set the flags in this case. Maybe using the IPv4 method > works ? Yes, that works indeed. I'm thinking about this logic (pseudo code): #if defined(IP_TOS) && defined(IPV6_TCLASS) /* IP_TOS needs to be set for both families, because a AF_INET6 socket may carries IPv4 traffic (when IPV6_V6ONLY is 0) */ if (address-family == AF_INET || address-family == AF_INET6) setsockopt(fd, IPPROTO_IP, IP_TOS, &tos, sizeof(tos)); if (address-family == AF_INET6) setsockopt(fd, IPPROTO_IPV6, IPV6_TCLASS, &tos, sizeof(tos)); #endif Is the address-family check needed anyway or is this a result of your intention to do this in v4 only? Its hard to upset setsockopt, it will just return -1 when things don't make sense, nothing breaks: when family is AF_INET (a true ipv4 socket): setsockopt->IPV6_TCLASS returns -1 setsockopt->IP_TOS returns 0 when family is AF_INET6 (either a true ipv6 or a v4 mapped socket) setsockopt->IPV6_TCLASS returns 0 setsockopt->IP_TOS returns 0 when family is a unix-socket obviously: setsockopt->IPV6_TCLASS returns -1 setsockopt->IP_TOS returns -1 With the pseudo code example above, setsockopt would always be successful, so this should be most portable and the corner case of a v4-in-a-v6-mapped socket would be addressed. Let me know how you think about this. Best regards, Lukas
0001-BUG-MINOR-http-fix-set-tos-not-working-in-certain-co.patch
Description: Binary data
