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: calling SetTOS doesn't work on Windows #42728

Open
levesquejf opened this issue Nov 19, 2020 · 8 comments
Open

x/net/ipv4: calling SetTOS doesn't work on Windows #42728

levesquejf opened this issue Nov 19, 2020 · 8 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Windows
Milestone

Comments

@levesquejf
Copy link

What version of Go are you using (go version)?

$ go version
go version go1.15.5 darwin/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/jfl/Library/Caches/go-build"
GOENV="/Users/jfl/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/jfl/.gopath/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/jfl/.gopath"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/yt/fs5f0tjj0w1bj2md7j4r5t2c0000gn/T/go-build812979714=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I try to use the ipv4.Conn.SetTOS() function on Windows. It works well on Mac OS but it silently fail on Windows (no error and no TOS marking). Should it work on Windows? No bugs about it listed on https://godoc.org/golang.org/x/net/ipv4#pkg-note-bug.

To reproduce:

package main

import (
	"fmt"
	"net"

	"golang.org/x/net/ipv4"
)

func main() {
	raddr, err := net.ResolveUDPAddr("udp", "8.8.8.8:12345")
	if err != nil {
		panic(err)
	}
	c, err := net.DialUDP("udp", nil, raddr)
	if err != nil {
		panic(err)
	}

	nc := ipv4.NewConn(c)
	if err := nc.SetTOS(184); err != nil {
		panic(err)
	}
	tos, err := nc.TOS()
	if err != nil {
		panic(err)
	}
	fmt.Printf("ToS is %d\n", tos)

	_, err = c.Write([]byte("Test1234"))
	if err != nil {
		panic(err)
	}
}

What did you expect to see?

Outbound packet with the ToS field set to 184 (0xb8, DSCP EF).

What did you see instead?

ToS is 0x0 on Windows. It is 0xb8 on MacOS.

@gopherbot gopherbot added this to the Unreleased milestone Nov 19, 2020
@cagedmantis cagedmantis added OS-Windows NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Dec 2, 2020
@cagedmantis cagedmantis changed the title x/net: SetTOS doesn't work on Windows x/net/ipv4: calling SetTOS doesn't work on Windows Dec 2, 2020
@cagedmantis
Copy link
Contributor

/cc @ianlancetaylor @alexbrainman

@iwdgo
Copy link
Contributor

iwdgo commented Dec 31, 2020

With the following versions, the issue does not seem to reproduce.
Sample returns ToS is 184

Maybe go get-ing x/net to upgrade dependencies.

  • ver prints Microsoft Windows [Version 10.0.19042.685]
  • go version prints go version go1.15.6 windows/amd64
  • go.mod has dependency require golang.org/x/net v0.0.0-20201224014010-6772e930b67b
  • And go.sum contains:
golang.org/x/net v0.0.0-20201224014010-6772e930b67b h1:iFwSg7t5GZmB/Q5TjiEAsdoLDrdJRC1RiF2WhuV29Qw=
golang.org/x/net v0.0.0-20201224014010-6772e930b67b/go.mod h1:m0MpNAwzfU5UDzcl9v0D8zg8gWTRqZa9RBIspLL5mdg=
golang.org/x/sys v0.0.0-20201119102817-f84b799fce68 h1:nxC68pudNYkKU6jWhgrqdreuFiOQWj1Fs7T3VrH4Pjw=
golang.org/x/sys v0.0.0-20201119102817-f84b799fce68/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs=
golang.org/x/term v0.0.0-20201126162022-7de9c90e9dd1/go.mod h1:bj7SfCRtBDWHUb9snDiAeCFNEtKQo2Wmx5Cou7ajbmo=
golang.org/x/text v0.3.3/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ=
golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ=

@levesquejf
Copy link
Author

I tried with version 1.15.6 and the latest golang.org/x/net/ipv4 but it still fails. However, I was not clear with my initial message. The print output is ok (it is ToS is 184) but when you capture the traffic with wireshark, the ToS/DSCP field is 0x00 on Windows.

@shushen
Copy link

shushen commented Jan 2, 2021

@levesquejf Which Windows version are you seeing the problem? Note that according to this Windows doc, not all Windows support setting the IP_TOS option. Windows 10 does.

@levesquejf
Copy link
Author

@shushen I am testing on Windows 10 version 1909 (Build 18363.1198) so it should be supported according to the doc.

@levesquejf
Copy link
Author

According to the Windows Documentation, IP_TOS is supported on Windows 10. However, the description is:

Do not use. Type of Service (TOS) settings should only be set using the Quality of Service API. See Differentiated Services in the Quality of Service section of the Platform SDK for more information.

I am not the only one having issues with ToS and Windows. Some people suggest to change windows registries (DisableUserTOSSetting or Do not use NLA) but it didn't help.

The Windows Advanced QoS DSCP Marking Override Settings is set to the default (Allowed) which should let the application override the DSCP.

Anyone has experience with the Windows Quality of Service API or has any idea how to make this work?

@levesquejf
Copy link
Author

Anyone with Windows Advanced QoS API can help troubleshoot this ongoing issue?

@iwdgo
Copy link
Contributor

iwdgo commented Oct 30, 2023

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Windows
Projects
None yet
Development

No branches or pull requests

5 participants