Internet problem eth0: avahi

[johnrego]

When connecting my BPI-M2 the internet connects Wifi, so that there is no network cable connected to it, an interface "eth0: avahi" appears, so I do not have internet access. Can anyone help?

[johnrego]

I think I was able to solve the problem as follows:

Edit the / etc / default / avahi-daemon file
Change the line: AVAHI_DAEMON_START = 1
In: AVAHI_DAEMON_START = 0
Sudo update-rc.d -f avahi-daemon remove

[Learnincurve]

Sorry to revive an old thread:

 

The problem (on my system) is that something seems to be constantly monitoring the interfaces and reconfiguring avahi for eth0, even if there is no link. The default route is therefore being assigned to a disconnected interface.  Removing the route will only work until the next time the interface comes up. It won't permanently disable Avahi for the interface.  I tried doing a ifconfig eth0 down on the disconnected interface, which also kills the route, but a couple of minutes later it's back up and so is the route.

 

What we need is something equivalent to:

Johnrego found the standard solutionas follows:

 

I think I was able to solve the problem as follows:

Edit the / etc / default / avahi-daemon file
Change the line: AVAHI_DAEMON_START = 1
In: AVAHI_DAEMON_START = 0
Sudo update-rc.d -f avahi-daemon remove

 

but on my orangepiplus2e there is no /etc/default/avahi-daemon file.

 

It looks like the whole shabang is being triggered by /etc/avahi/avahi-autoipd.action

but I don't see any way to turn it off.

 

As a test I did an ifconfix wlanX up without assigning a wireless network to wlanX. The same think happened. The interface came up with a 169.254 address and was assigned the default route.

 

It looks as if avahi is assigning a 169.254 address to any interface that is brought up, even if no link is available.

 

Any ideas about where the misconfiguration is, or how to cure it?

 

BR.

 

--Marius--

[tkaiser]

57 minutes ago, Learnincurve said:

Johnrego found the standard solution

Johnrego maybe just ran into the usual 'connected eth0 and wlan0 to same network, disconnect eth0 and wlan0 stops to work' (which resolves itself after 10 minutes or something like that since then the AP/router both interfaces were connected to learned that wlan0's MAC/IP address has now to be connected directly and not using the disappeared one from eth0).

 

If you want some progress on the 'issue' (whatever that is) please provide at least any INFORMATION (no one has a clue yet which distro you use on which board with which kernel and so on). Best idea is output from 'armbianmonitor -u' first and then also 'netstat -rn' in working and non working state.

 

And just as a general remark: People thinking zeroconf would be evil can simply do an 'apt purge avahi-autoipd' and should be happy again. The purpose of avahi-autoipd is being able to setup a board with Armbian truly headless even without any network infrastructure (especially no DHCP server needed) available but just a network cable. If you boot for example an Orange Pi Zero with most recent Armbian images then you can connect later the Ethernet cable to your laptop and simply do a 'ssh root@orangepizero.local' which will work.

[Learnincurve]

Point taken. I gave no information.

 

Board is Orangepiplus2e running ARMBIAN 5.33 user-built Debian GNU/Linux 8 (jessie) 4.13.5-sunxi

 

Reason I'm using mainline is that I had a lot of trouble with oom errors on this board with the legacy kernel (known issue).

 

 

Thanks for the suggestion to remove/purge avahi-autoipd. I wasn't sure if that was so tightly integrated into the rest of the networking stuff that it would break the whole network setup.  I'll follow the suggestion as dhcp will be available wherever I connect.

 

No further action needed.

 

BR.

 

--M--

 

 

[MtLastBest007]

Herr Kaiser, 

 

A Newbie, so I apologize in advance ... yes, I did spend considerable time reading forum prior to submitting this...and yes, prepared for verbal flogging....at any rate:

 

Board:  OrangepiPC2  Using: https://dl.armbian.com/orangepipc2/nightly/Armbian_5.34.171021_Orangepipc2_Ubuntu_xenial_next_4.13.8_desktop.7z  (nightly)

 

DHCP works fine.  When I try to set static IP, using either desktop config utility (nmcli) or manually editing /etc/network/interfaces, I cannot get internet connection.  My guess is that nightly's will not allow static configuration?  Am I missing something?

 

Danke!

 

[martinayotte]

Most probably, your static config works, but you don't have any DNS config to resolve internet IP addresses.

Check if you are able to ping something like google.com but using their IP instead of server name.

 

[MtLastBest007]

Thank you for prompt response!

 

 Yes, I am able to ping 8.8.8.8 successfully with static IP.  I also can ping piC2 from other devices on my LAN. nmcli device show looks right.  My /etc/network/interfaces is the same as produced by Config desktop utility.:

 

address 192.168.1.217 (example) 

netmask 255.255.255.0 

gateway 192.168.1.1

dns-nameservers 8.8.8.8 8.8.4.4

 

However, the Chromium web browser in the desktop no longer works.  Furthermore, with set static IP I can not open the desktop "Config" with the result "Configurator can't work properly without internet connection.. " So now I have to use terminal to open /etc/network/interfaces.  

 

So yes, with static IP there does appear to be a problem with DNS resolution.  Therein lies my issue...

[martinayotte]

Is the /etc/resolv.conf has been regenerated by resolvconf ? do you have your DNS IPs in /etc/resolv.conf ?

 

[MtLastBest007]

martinayotte,  thanks ... you are a veritable armbian wizard ....

 

after I edited: sudo nano /etc/resolv.conf  and added:  nameserver 8.8.8.8.,  in spite of dire warning "DO NOT EDIT THIS FILE BY HAND -- YOUR CONFIGURATION WILL BE OVERWRITTEN",  internet access with static IP is success!  

 

Interestingly, /etc/resolvconf/resolvconf.d/original  HAD the proper line 'nameserver 8.8.8.8' automatically generated even PRIOR to my editing the above.  So it appears that the resolver routine correctly generates this file but NOT /etc/resolv.conf?   Therefore, on each reboot it appears that I must re-edit /etc/resolv.conf.   This doesn't feel right but, hey, my intermediate goal has been achieved...

[martinayotte]

did you tried doing a "resolvconf -u" to see if /etc/resolv.conf getting updated ?

Reading the whole "resolvconf" will probably help to fix the issue.

 

[snowsquizy]

When I run 'resolvconf -u' I get a warning

 

/etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /etc/resolvconf/run/resolv.conf

 

when I checked the file properties it appears to me that the symbolic link is point to somewhere different.

 

lrwxrwxrwx 1 root root 27 Jun 14 13:39 /etc/resolv.conf -> /run/resolvconf/resolv.conf