>
> 2016-12-15 18:41 GMT+02:00 Dan Williams :
>
>> > 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 :
> 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 :
>
>> 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 " (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
