go-libp2p icon indicating copy to clipboard operation
go-libp2p copied to clipboard

Libp2p fails to determine default route on FreeBSD

Open Stebalien opened this issue 5 years ago • 5 comments

On FreeBSD, netroute.Router.Route('0.0.0.0') returns an error instead of returning the default route. We need some other way to determine the default route. We could just try looking up a well known IP address.

https://github.com/libp2p/go-libp2p/blob/6a3b138a57ed3ad31d531906f47b3f3cc1d8d9b6/p2p/host/basic/basic_host.go#L260-L280

Stebalien avatar Jul 02 '20 05:07 Stebalien

what error do you get? I'm guessing you're able to load the routing table, but asking for the route is failing?

willscott avatar Jul 02 '20 05:07 willscott

"no route found for 0.0.0.0"

Stebalien avatar Jul 02 '20 06:07 Stebalien

just to confirm, you're specifically referring to FreeBSD, and not macs, right?

willscott avatar Jul 06 '20 03:07 willscott

I am. I haven't tested on MacOS.

Stebalien avatar Jul 06 '20 18:07 Stebalien

spun up a FreeBSD VM and can't reproduce:

FreeBSD 12.1-RELEASE r354233 GENERIC  amd64

The RIB's returned by the system call are:

rtNFO: &{10.0.2.15/0 0.0.0.0/0 10.0.2.2 10.0.2.15 0 1 0}
rtNFO: &{10.0.2.15/32 10.0.2.0/24 <nil> 10.0.2.15 0 1 0}
rtNFO: &{127.0.0.1/32 10.0.2.15/32 <nil> 127.0.0.1 0 2 0}
rtNFO: &{127.0.0.1/32 127.0.0.1/32 <nil> 127.0.0.1 0 2 0}
rtNFO: &{::1/128 ::1/128 <nil> ::1 0 2 0}
rtNFO: &{fe80::1/128 fe80::/64 <nil> fe80::1 0 2 0}
rtNFO: &{fe80::1/128 fe80::1/128 <nil> fe80::1 0 2 0}

(em0 network interface 10.0.2.15/24 with gw 10.0.2.2) default route works as expected in this case.

I think to debug / reproduce, the most useful thing to do would be to modify here to insert the line fmt.Printf("rtNFO: %v", routeInfo) so that we can try to understand what's happening with regards to the parsed routing table.

willscott avatar Jul 10 '20 19:07 willscott

Cannot reproduce FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64

Printing route info here shows results similary to above. Default route is found.

Maybe this issue was reported on a host that only has IPv6 addresses and no default route was found for 0.0.0.0?

In either case, this does not seem to be a defect (or has not been for a long time), so suggest closing this issue.

gammazero avatar Jul 30 '24 09:07 gammazero

It had an IPv4 address. But this was a long time ago on a machine that no longer exists (and was probably in a FreeBSD jail). Given that nobody can reproduce, I'm just going to close this.

Stebalien avatar Jul 30 '24 18:07 Stebalien