What breaks
router.go:47 calls routing.New() from github.com/google/gopacket/routing. The upstream package is Linux-only and provides a stub for every other GOOS:
// gopacket/routing/other.go
// +build !linux
func New() (Router, error) {
panic("router only implemented in linux")
}Result: the binary will go build and start on macOS / Windows / FreeBSD, but the first destination check unrecoverably crashes the process with:
panic: router only implemented in linux
This is hit by every subcommand that does network work — check, wait, waitfor, monitor — via Destination.Check() → GetRoute() in destinations.go:168. There's no recover() anywhere, so the whole process dies on the first non-localhost destination.
Why this matters
go build ./... succeeds on every platform, so a macOS/Windows contributor's local ./build.sh (or go install) produces an apparently-working binary that fatally crashes the moment it's used.- The README and CLI advertise no platform restrictions.
Suggested fixes (any one)
-
Declare Linux-only at the module level. Add //go:build linux to router.go (and a router_other.go stub that returns a no-op Route with the destination IP, no gateway, no source iface) so the rest of the tool degrades gracefully on other platforms. The existing code in destinations.go:168-171 already tolerates GetRoute() returning an error.
-
Fail with a clear error rather than a panic. Wrap the call:
func GetRoute(ip net.IP) (route *Route, err error) {
defer func() {
if r := recover(); r != nil {
err = fmt.Errorf("routing not supported on %s", runtime.GOOS)
}
}()
...
}This at least lets check/wait/monitor continue without route metadata on non-Linux.
-
Declare Linux-only and refuse to build on other platforms. Add //go:build linux to connectivity.go (the package main) so go build cleanly fails on macOS/Windows with a build error instead of producing a crashing binary.
Option (3) is the cleanest given how Linux-centric the rest of the design is (/etc/connectivity.yml, statsd-via-UDP defaults, the release pipeline already only builds linux/amd64 per #26). Combined with a README note this gives users an honest experience.
Related: this is broader than #26 (single-arch release): the issue is whether the code works on other platforms, not whether binaries are built for them.
What breaks
router.go:47callsrouting.New()fromgithub.com/google/gopacket/routing. The upstream package is Linux-only and provides a stub for every other GOOS:Result: the binary will
go buildand start on macOS / Windows / FreeBSD, but the first destination check unrecoverably crashes the process with:This is hit by every subcommand that does network work —
check,wait,waitfor,monitor— viaDestination.Check()→GetRoute()indestinations.go:168. There's norecover()anywhere, so the whole process dies on the first non-localhost destination.Why this matters
go build ./...succeeds on every platform, so a macOS/Windows contributor's local./build.sh(orgo install) produces an apparently-working binary that fatally crashes the moment it's used.Suggested fixes (any one)
Declare Linux-only at the module level. Add
//go:build linuxtorouter.go(and arouter_other.gostub that returns a no-opRoutewith the destination IP, no gateway, no source iface) so the rest of the tool degrades gracefully on other platforms. The existing code indestinations.go:168-171already toleratesGetRoute()returning an error.Fail with a clear error rather than a panic. Wrap the call:
This at least lets
check/wait/monitorcontinue without route metadata on non-Linux.Declare Linux-only and refuse to build on other platforms. Add
//go:build linuxtoconnectivity.go(the packagemain) sogo buildcleanly fails on macOS/Windows with a build error instead of producing a crashing binary.Option (3) is the cleanest given how Linux-centric the rest of the design is (
/etc/connectivity.yml, statsd-via-UDP defaults, the release pipeline already only builds linux/amd64 per #26). Combined with a README note this gives users an honest experience.Related: this is broader than #26 (single-arch release): the issue is whether the code works on other platforms, not whether binaries are built for them.