net: need to document the behavior regarding the raw protocol over IP?

[mehrdadrad]

Please answer these questions before submitting your issue. Thanks!

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

go version go1.7 linux/amd64

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

GOARCH="amd64"
GOOS="linux"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build351337243=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"

What did you do?

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

func main() {
	c, err := net.ListenPacket("ip4", "0.0.0.0")
	if err != nil {
		println(err.Error())
		return
	}
	defer c.Close()
	p, err := ipv4.NewRawConn(c)
	if err != nil {
		println(err.Error())
		return
	}
	_ = p
}

What did you expect to see?

It shows: listen ip4 0.0.0.0: socket: protocol not supported
but it works @ Darwin properly

https://golang.org/pkg/net/#ListenPacket

func ListenPacket(net, laddr string) (PacketConn, error)
ListenPacket announces on the local network address laddr. The network net must be a packet-oriented network: "udp", "udp4", "udp6", "ip", "ip4", "ip6" or "unixgram". For TCP and UDP, the syntax of laddr is "host:port", like "127.0.0.1:8080". If host is omitted, as in ":8080", ListenPacket listens on all available interfaces instead of just the interface with the given host address. See Dial for the syntax of laddr.

What did you see instead?

listen ip4 0.0.0.0: socket: protocol not supported

[mehrdadrad]

if we put the protocol name or number like ip4:tcp or ip4:6 then it works at Linux too.

[cwgem]

I'm noticing in strace output based on the sample script provided:

26035 socket(PF_INET, SOCK_RAW|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = -1 EPROTONOSUPPORT (Protocol not supported) 26035 socket(PF_INET, SOCK_RAW, IPPROTO_IP) = -1 EPROTONOSUPPORT (Protocol not supported)

IPPROTO_IP is a dummy protocol for TCP (according to /usr/include/netinet/in.h on my system. Unfortunately it appears to toss an error with that's mixed with raw sockets (SOCK_RAW) which would explain the need to explicitly indicate ip4:tcp which instead maps to IPPROTO_IP on the call.

[mikioh]

As the existing documentation says, the network must have the form "address family : protocol name or number over IP transport". Looks like there's a bug for parsing the 1st argument. At least the parser should check the existence of the delimiter ":". Thanks for the notice.

For the information about manipulating raw IP sockets, I'm not sure whether documenting the IP protocol stack implementation internal is worth because it's pretty useless for most people and I guess that each operating system's online manual describes the details.

For what it's worth, on most IP stack implementations, the protocol number "0" means a wildcard and it designates a default protocol on IP transport when specifying AF_INET or AF_INET6+SOCK_RAW. On BSD variants, the default protocol number for IP transport is "255". On Linux, IIRC, there is no default protocol for IP transport and the kernel returns an error. On most Unix variants, "255" means a raw protocol on IP transport and it can transmit any protocol over IP and receive only the raw protocol over IP. The behavior of the wildcard and the raw protocol on IP transport may differ on other platforms such as Windows, Plan9.

[bradfitz]

@mikioh,

For the information about manipulating raw IP sockets, I'm not sure whether documenting the IP protocol stack implementation internal is worth because it's pretty useless for most people and I guess that each operating system's online manual describes the details.

The net package is supposed to be a portable interface. Users should not have to read their operating system manuals.

Can we make something work everywhere, and then document it? 0? 255? *?

[mikioh]

Can we make something work everywhere, and then document it? 0? 255? *?

The protocol number 255 is one of reserved protocol numbers by IANA, and is used as a platform-dependent scaffold on Unix variants. I don't think it's possible to make the behavior consistent across platforms. Documenting the wildcard behavior is fine if necessary.