search

nanovms / ops

ops - build and run nanos unikernels
https://ops.city
MIT License
1.3k stars 132 forks source link

ops net setup fails on dynamic address acquisition #188

Closed ExternalReality closed 3 years ago

ExternalReality commented 5 years ago 
panic: no DHCP packet received within 10s

goroutine 1 [running]:
main.netSetupCommandHandler(0xc0000c7400, 0xc61b80, 0x0, 0x0)
    /home/externalreality/go/src/github.com/nanovms/ops/ops.go:192 +0x9d
github.com/spf13/cobra.(*Command).execute(0xc0000c7400, 0xc61b80, 0x0, 0x0, 0xc0000c7400, 0xc61b80)
    /home/externalreality/go/src/github.com/spf13/cobra/command.go:766 +0x2cc
github.com/spf13/cobra.(*Command).ExecuteC(0xc00012ac80, 0x8, 0x0, 0xc00012a780)
    /home/externalreality/go/src/github.com/spf13/cobra/command.go:852 +0x2fd
github.com/spf13/cobra.(*Command).Execute(0xc00012ac80, 0xc0000c3ef8, 0x1)
    /home/externalreality/go/src/github.com/spf13/cobra/command.go:800 +0x2b
main.main()
    /home/externalreality/go/src/github.com/nanovms/ops/ops.go:488 +0x1135

I am using a wired connection on my Manjaro host machine (The fact that ops net setup replaces my existing bridge setup is another issue)

2: eno1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq master xenbr0 state UP group default qlen 1000
    link/ether 30:9c:23:00:7a:85 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::329c:23ff:fe00:7a85/64 scope link 
       valid_lft forever preferred_lft forever

I have also tried this on a KVM/Qemu debian stretch setup which only presents a virtual wired interface and I get the same result.

Note that on both my Manjaro host and the debian VM dhclient works fine and I can easily verify that I can reach the dhcp service.

Should the bridge not assume the address of the attached interface rather than trying to acquire a new address via dhcp?

This may be a dup of https://github.com/nanovms/ops/issues/98

ExternalReality commented 5 years ago

The author of the github.com/d2g/dhcp4client package used here suggests that all projects use branch v2 of the package in the README. go get defaults to the v1 branch. After reading through a few of the issues on the github of the package, I have a strong suspicion that the package is at fault for this error. V2 of the package itself relies on github.com/krolaw/dhcp4 which seems more reliable. Is it possible to switch to that package for dynamic address acquisition? ~Is it possible to use google the netstack lib https://github.com/google/netstack?~

eyberg commented 5 years ago

we really need to improve the networking docs - i do see the xenbr0

this isn't really a yes/no question as diff. people will have diff. requirements but assuming a linux with a physical interface i'd expect ops net to a) create a new tap, b) create a new bridge, c) attach said bridge to a physical interface (in this case prob. the first interface that it finds - eno1) that allows outgoing traffic to the net (as most ppl want that) - any others that get spun up in the same class c (see https://github.com/nanovms/ops/issues/177) would run in that same bridge unless otherwise configured - most ppl prob. don't have a need for multiple networks in a dev env - however as mentioned networking is one of those things that is infinitely configurable

lastly - you can (and by default imo) should keep the original ip on that interface eno1 - if that's not the case than we should prob. modify it to do so as I'd find that to be expected behavior for most folks just trying out one on a local dev box

tijoytom-zz commented 5 years ago

I remove the dhcp lookup, it's not necessary, it's error prone and slow. Assigning the next valid IP to bridge is good enough.

eyberg commented 3 years ago

@fabioDMFerreira - should we leave this old code in or rip it out?

fabioDMFerreira commented 3 years ago

@eyberg most of the features merged in https://github.com/nanovms/ops/pull/851 are present in the old code. By old code, I'm assuming it is the code present in next files cmd/net, cmd/network, cmd/network_windows.go, cmd/network_linux.go and cmd/network_darwin.go.

Some features not supported yet are: