Skip to content
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

x/net/ipv4: ipv4.Conn.SetTOS fails on "tcp" net.TCPConn #13612

Closed
sbowman opened this issue Dec 14, 2015 · 6 comments
Closed

x/net/ipv4: ipv4.Conn.SetTOS fails on "tcp" net.TCPConn #13612

sbowman opened this issue Dec 14, 2015 · 6 comments

Comments

@sbowman
Copy link

sbowman commented Dec 14, 2015

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"):

ln, err := net.Listen("tcp", ":1024")
    if err != nil {
        // error handling
    }
    defer ln.Close()
    for {
        c, err := ln.Accept()
        if err != nil {
            // error handling
        }
        go func(c net.Conn) {
            defer c.Close()

            if err := ipv4.NewConn(c).SetTOS(0x28); err != nil {
                fmt.Println("Error: ", err.Error())
            }
        }(c)
    }

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.

@sbowman
Copy link
Author

sbowman commented Dec 14, 2015

On Mac OS X.

@ianlancetaylor ianlancetaylor added this to the Unreleased milestone Dec 14, 2015
@ianlancetaylor
Copy link
Contributor

CC @mikioh

@sbowman
Copy link
Author

sbowman commented Dec 14, 2015

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.

@mikioh
Copy link
Contributor

mikioh commented Dec 15, 2015

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.

@gopherbot
Copy link

CL https://golang.org/cl/17798 mentions this issue.

@gopherbot
Copy link

CL https://golang.org/cl/17799 mentions this issue.

gopherbot pushed a commit to golang/net that referenced this issue Dec 15, 2015
Updates golang/go#13612.

Change-Id: Ic139b6f862a2a24d549bd1f502299a7eac2f0e38
Reviewed-on: https://go-review.googlesource.com/17799
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@golang golang locked and limited conversation to collaborators Dec 14, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants