-
Notifications
You must be signed in to change notification settings - Fork 18k
x/net/ipv4: ipv4.Conn.SetTOS fails on "tcp" net.TCPConn #13612
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
On Mac OS X. |
CC @mikioh |
I can get around this by configuring separate tcp4 and a tcp6 listeners on the same port. Hopefully this works on Linux as well as OS X. |
Thanks for the notice, will update examples in both golang.org/x/net/{ipv4,ipv6}. Yup, as the doc describes like "... network connections that use the IPv4 transport", you need to test address family when you use a dual stack listener, even though that feature doesn't work on some platform such as OpenBSD, DragonFly BSD, Plan 9. Of course it's also fine to have multiple explicit address family listeners. |
CL https://golang.org/cl/17798 mentions this issue. |
CL https://golang.org/cl/17799 mentions this issue. |
Updates golang/go#13612. Change-Id: Ic139b6f862a2a24d549bd1f502299a7eac2f0e38 Reviewed-on: https://go-review.googlesource.com/17799 Reviewed-by: Ian Lance Taylor <iant@golang.org>
If you listen for a general "tcp" connection instead of a "tcp4" connection, ipv4.Conn.SetTOS fails on IPv4 connections (but works with ipv6.Conn.SetTrafficClass on IPv6 connections).
From the https://godoc.org/golang.org/x/net/ipv4 example, if you change net.Listen("tcp4", "0.0.0.0:1024") to net.Listen("tcp", ":1024"):
and send an IPv4 request (e.g. curl "127.0.0.1:1024"), the IPv4 connections will not have the TOS set, and SetTOS returns "setsockopt: invalid argument".
IPv6 connections in this same scenario (switch to ipv6.NewConn(c).SetTrafficClass) will work.
In my app, I'm testing for the type of connection by checking TCPConn.RemoteAddr() for IPv6 vs. IPv4 and calling the appropriate NewConn wrapper. IPv6 connections have their TrafficClass set properly. IPv4 connections generate the above error.
The text was updated successfully, but these errors were encountered: