Can't build/run on macOS due to client.go code

[begetan]

go build
# github.com/insomniacslk/dhcp/dhcpv4
../../insomniacslk/dhcp/dhcpv4/client.go:125:25: undefined: unix.AF_PACKET
../../insomniacslk/dhcp/dhcpv4/client.go:125:68: undefined: unix.ETH_P_IP
../../insomniacslk/dhcp/dhcpv4/client.go:133:12: undefined: unix.SockaddrLinklayer

There are no constants in package golang.org/x/sys/unix for darwin_amd64

grep AF_PACKET *
grep: linux: Is a directory
syscall_linux.go:// SockaddrLinklayer implements the Sockaddr interface for AF_PACKET type sockets.
syscall_linux.go:	sa.raw.Family = AF_PACKET
syscall_linux.go:	case AF_PACKET:
zerrors_linux_386.go:	AF_PACKET                            = 0x11
zerrors_linux_amd64.go:	AF_PACKET                            = 0x11
zerrors_linux_arm.go:	AF_PACKET                            = 0x11
zerrors_linux_arm64.go:	AF_PACKET                            = 0x11
zerrors_linux_mips.go:	AF_PACKET                            = 0x11
zerrors_linux_mips64.go:	AF_PACKET                            = 0x11
zerrors_linux_mips64le.go:	AF_PACKET                            = 0x11
zerrors_linux_mipsle.go:	AF_PACKET                            = 0x11
zerrors_linux_ppc64.go:	AF_PACKET                            = 0x11
zerrors_linux_ppc64le.go:	AF_PACKET                            = 0x11
zerrors_linux_riscv64.go:	AF_PACKET                            = 0x11
zerrors_linux_s390x.go:	AF_PACKET                            = 0x11
zerrors_linux_sparc64.go:	AF_PACKET                        = 0x11
zerrors_solaris_amd64.go:	AF_PACKET                     = 0x20

This is a commit probably breaks compilation:
4eedccf

In BSD system AF_PACKET should be replaced by AF_LINK

BTW, why not to move client for separate package? I just removed file client.go from repo in order to compile server code.

[insomniacslk]

cc @get9

[insomniacslk]

BTW, why not to move client for separate package? I just removed file client.go from repo in order to compile server code.

This is actually something I've considered in the past, splitting client and server from protocol parsing. The library structure wold become a bit more fragmented but I can try and see if it doesn't look too bad.

[get9]

I'm fine with that; this package should be reserved for dhcp library code. We can have a separate one for sample clients that's a consumer of this code.

Do we have CI set up for mac builds of this library?

[abh]

Compiling for FreeBSD I ran into the same thing.

[insomniacslk]

I'm fine with that; this package should be reserved for dhcp library code. We can have a separate one for sample clients that's a consumer of this code.

I think what @begetan meant was to split out client.go and server.go in a separate package, correct me if I'm wrong. As per the sample client, there is a working (yet not full-featured) dhclient implementation in the examples repo, https://github.com/insomniacslk/exdhcp/blob/master/dhclient/main.go

Do we have CI set up for mac builds of this library?

No, the tests are linux-only. We would just need an os section in .travis.yml, like this, https://github.com/insomniacslk/dublin-traceroute/blob/master/.travis.yml#L20. I will add it today,

[insomniacslk]

This is the PR that broke the build, http://github.com/insomniacslk/dhcp/pull/198 (not the commit mentioned above). AF_PACKET was introduced to deal with unconfigured interfaces, which is fundamental for a DHCP client to work, but AF_PACKET is Linux-specific. I'll work on a fix for darwin/freebsd

[insomniacslk]

Quick search: https://stackoverflow.com/questions/17169298/af-packet-on-osx

EDIT: this doesn't help as it basically recommends to go back to L3 sockets and wouldn't work on unconfigured interfaces

[insomniacslk]

If I'm reading it right, dhclient in FreeBSD uses... BPF, https://github.com/freebsd/freebsd/blob/master/sbin/dhclient/bpf.c#L100 . Basically like running tcpdump

[begetan]

I think what @begetan meant was to split out client.go and server.go in a separate package, correct me if I'm wrong.

Exactly! That packages can handle network specific stuff (like this case) so people can manage which component of the library they actually need.

[insomniacslk]

Tracked at #231

[pmazzini]

Should we close this one after PR #241? cc @begetan

[insomniacslk]

not really - the build still fails on darwin. Just not a hi-pri at the moment

[begetan]

Should we close this one after PR #241? cc @begetan

@pmazzini
This PR makes library indpendent from client code and usable on Darwin/BSD, but client code not compiled yet. It should be fixed one day.

[hans-d]

Any update yet on being able to use the client on non-linux (eg darwin) ?

[pmazzini]

PRs are welcomed. There is even a patch that needs testing in #378 (comment).

[pmazzini]

Related:

• [BUG] Binding to an interface on MacOS does not function correctly #378
• [interfaces] darwin #423

The main package should compile now and the nclient code should be usable.

[pmazzini]

The client code was moved to a separate package since. I am leaving #318 for OSX related support.