> > 2016-12-15 18:41 GMT+02:00 Dan Williams <d...@redhat.com>: > >> > ping started to work after executing >> > > *route add default dev eth0 metric 99* >> > So, everything is fine! >> >> That implies that the default route was not set up correctly >> beforehand. What's the output of "ip route" before you add that >> default route? >> > Yes, there was no default route set at all. In fact it should have been > created by avahi-autoipd.action script command: > > ip route add default dev "$2" metric "$METRIC" scope link ||: > > Somehow this did not do the trick. I changed that to: > > ip route add default dev "$2" metric "$METRIC"||: > > Default route was produced after that. I did not check that command > manually, but I suppose that ip command is coming from busybox and do not > support ip command properly. It's also possibly that I had ordinary ip > command installed in that older set-up. > I ran above route add command manually producing following error message: ip: either "to" is duplicate, or "scope" is garbage
> I found out just before leaving office that connection did not recover > after unplugging and plugging again. It could come from the fact that I did > not fix "CONFLICT|UNBIND|STOP" branch of avahi-autoipd.action script that > seems also having these "scope link" statements. I'll check that tomorrow > Modifications to that branch did not help. Instead I had to track both eth0 to/from "unavailable" events. I had to start avahi-autoipd when exiting from "unavailable" state and stop it when entering to "unavailable" state. > >> You might try setting the "never-default" option in the VPN >> connection's config to "true", to indicate that the VPN shouldn't grab >> the default route >> > > Do you expect problems with VPN when default route is set? I'll bear this in mind. Thanks, Matti 2016-12-15 13:48 GMT+02:00 matti kaasinen <matti.kaasi...@gmail.com>: > Hi Dan, > Story below is kind of follow up of my late query referenced: > https://mail.gnome.org/archives/networkmanager-list/ > 2016-April/msg00055.html > > 2016-12-14 16:36 GMT+02:00 matti kaasinen <matti.kaasi...@gmail.com>: > >> I used to have NM 0.9.8.10 together with dhclient. Now I upgraded to NM >> 1.0.10 together with internal dhcp client. Old system had very cumbersome >> network up sequence in order to preserve dhcp provided IP. Both set-ups >> have also avahi/avahi-auto-ip running for providing IPv4LL addresses trying >> to provide "known" IP in case no DHCP server is available. So, I try to >> preserve both eth0 and eth0:avahi interfaces. This seems a problem with >> this new set-up. Wired interface starts always up due to eth0:avahi/avahi >> server even if cable is unplugged with the new set-up reaching activated >> -state at the end. Therefore, cable plugging does not produce unavailable >> -> disconnected event and interface does not get truly activated. >> NetworkManager seems providing "<info> (eth0): link connected" message. >> >> Everything is fine if I start connection having cable connected. Then >> proper events are generated both when plugging and unplugging cable. >> Should, I now use nm-dispatcher for starting up/shutting down avahi >> services? >> > > I changed avahi-autoipd service start moment so that it does not start > before I get event from dbus where last state is "unavailable", that means > that cable is plugged. This seems recovering problem where > plugging/unplugging does not show as from/to "unavailable" state. > ath0:avahi interface is listed quite fine with ifconfig. However, > eth0:avahi is not really up as NM has not switched eth0 up. IPv4ll address > does not ping before for instance dhcp server answers(and most likely also > when manual IP is used). However, after dhcp ping works both to dhcp > address and IPv4LL address when dhcp address is bound. I have tried using > ifconfig eth0:avahi up - without any luck. > > So, now I am not really sure if that original set-up really worked without > dhcp server or manual addressing. > > What should I do to get eth0 up also with plain IPv4ll addressing? That > would be important to get service access in environment where no dhcp > servers exist. > > Thanks, > Matti > >
_______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
