x/net/ipv4: wrong endianness in IP header on darwin-amd64

[hrqiang]

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

$ go version
go version go1.11.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
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/rhuang/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/rhuang/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.11.5/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.11.5/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
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/xy/qpsgj2816g97b0ctzkq0ps_r0000gs/T/go-build097375093=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

marshall IPv4 IP header with x/net/ipv4/header, but I got little-endian instead of big-endian.

What did you expect to see?

Got big-endian IP header len.

What did you see instead?

little-endian

Looking at By looking at the code https://github.com/golang/net/blob/master/ipv4/header.go#L71., for darwin, 32bit/64bit os should have a different conversion.
Darwin amd64 is little-endian, it should convert.

[bradfitz]

/cc @mikioh

[ianlancetaylor]

Can you show us a self-contained program we can use to recreate the problem?

[hrqiang]

@ianlancetaylor this is the program to recreate the issue. https://github.com/hrqiang/iphdr/blob/master/iphdr.go

[networkimprov]

@gopherbot add "help wanted"
@gopherbot add OS-Darwin

cc @odeke-em

[WingLim]

You can see this answer: https://stackoverflow.com/a/15881825/13019406
This is the 'feature' of BSD and OSX, golang should and just read it from sock.
You should to use ipv4.ParseHeader to parse raw bytes, rather than golang modify it to big-endian IP header len.

[emilianobilli]

I understand the expected behavior, but this function is designed to receive a packet directly from the host's network layer and is not useful for parsing a header coming from another source. Imagine it coming from a tunnel or a VPN. The IP header is encapsulated in UDP, for example, and this function becomes unusable because it is only useful for messages that come exclusively from the native stack.