Re: Problems getting device state change events through

[matti kaasinen <matti kaasinen gmail com>]

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