search

goodrobots / maverick

UAV Autonomous Systems Management
https://goodrobots.github.io/maverick/
MIT License
171 stars 61 forks source link

More avahi problems.. #930

Closed fnoop closed 4 years ago

fnoop commented 4 years ago 
Mar 22 11:38:39 maverick-raspberry avahi-daemon[7040]: Found user 'avahi' (UID 108) and group 'avahi' (GID 113).
Mar 22 11:38:39 maverick-raspberry avahi-daemon[7040]: Successfully dropped root privileges.
Mar 22 11:38:39 maverick-raspberry avahi-daemon[7040]: avahi-daemon 0.7 starting up.
Mar 22 11:38:39 maverick-raspberry avahi-daemon[7040]: Successfully called chroot().
Mar 22 11:38:39 maverick-raspberry avahi-daemon[7040]: Successfully dropped remaining capabilities.
Mar 22 11:38:39 maverick-raspberry avahi-daemon[7040]: No service file found in /etc/avahi/services.
Mar 22 11:38:39 maverick-raspberry avahi-daemon[7040]: *** WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. ***
Mar 22 11:38:39 maverick-raspberry avahi-daemon[7040]: Joining mDNS multicast group on interface wman0.IPv4 with address 192.168.1.104.
Mar 22 11:38:39 maverick-raspberry avahi-daemon[7040]: New relevant interface wman0.IPv4 for mDNS.
Mar 22 11:38:39 maverick-raspberry avahi-daemon[7040]: Network interface enumeration completed.
Mar 22 11:38:39 maverick-raspberry avahi-daemon[7040]: Registering new address record for fe80::dea6:32ff:fe0a:583b on wman0.*.
Mar 22 11:38:39 maverick-raspberry avahi-daemon[7040]: Registering new address record for 192.168.1.104 on wman0.*.
Mar 22 11:38:39 maverick-raspberry avahi-daemon[7040]: Withdrawing address record for fe80::dea6:32ff:fe0a:583b on wman0.
Mar 22 11:38:39 maverick-raspberry avahi-daemon[7040]: Host name conflict, retrying with maverick-raspberry-2
Mar 22 11:38:39 maverick-raspberry avahi-daemon[7040]: Registering new address record for fe80::dea6:32ff:fe0a:583b on wman0.*.
Mar 22 11:38:39 maverick-raspberry avahi-daemon[7040]: Registering new address record for 192.168.1.104 on wman0.*.
Mar 22 11:38:41 maverick-raspberry avahi-daemon[7040]: Server startup complete. Host name is maverick-raspberry-2.local. Local service cookie is 74790528.
fnoop commented 4 years ago

This only seems to happen on raspberry. reflectors are all turned off, other maverick installs on the same network work fine without conflicts. Only a single (wifi) interface is active on the rpi. ipv6 is disabled for avahi.

fnoop commented 4 years ago

Think this is a local issue with a conflicting record, not a wider problem.

fnoop commented 4 years ago

Ah no, @SamuelDudley this is caused by the new zeroconf in visiond. If you stop visiond, avahi gets a hostname conflict when starting up, stop visiond and it goes away.

SamuelDudley commented 4 years ago

Sigh. Do you think setting this to True could help? https://github.com/jstasiak/python-zeroconf/blob/master/zeroconf/__init__.py#L2204

fnoop commented 4 years ago

The odd thing is -api doesn't seem to cause the problem, just visiond.

SamuelDudley commented 4 years ago

Hmm perhaps keeping the thread alive in visiond is the problem..? It’s really the only difference.

SamuelDudley commented 4 years ago

Perhaps keeping self.zeroconf() alive by keeping the class instance alive is enough?

fnoop commented 4 years ago

If it's not kept alive in -api, how does -api respond to the mdns requests?

SamuelDudley commented 4 years ago

That is a good question! The self.zerconf() object is kept alive by the module instance in -api but there is no seperate thread. Pretty sure self.zeroconf() makes its own threads and starts them so as long as the containing object is alive it will respond to mdns requests.

Edit: it really shouldn't matter we have that thread alive in visiond... This sounds like a morning problem for me :)

SamuelDudley commented 4 years ago

Are the logs posted from the system journal? Should my pi have the same problem to reproduce? I'll check tomorrow morning.

fnoop commented 4 years ago

Oh no, this is happening with -api instances as well. For some reason sometimes it conflicts with avahi and forces it to make up a different hostname. Stopping all -api instances allows avahi to startup as expected. Related: https://github.com/goodrobots/visiond/issues/21

fnoop commented 4 years ago

Removing the ServiceInfo.server property seems to fix this problem: https://github.com/goodrobots/maverick-api/commit/80181708cf3129ebd1d09a5b0db42ce969651911

fnoop commented 4 years ago

Fixed in visiond as well: https://github.com/goodrobots/visiond/commit/6ddf8b526eb99c3a4b5e86910c41653a0f8393d7

Just need to fix warning caused by -discovery: https://github.com/goodrobots/maverick-discovery/issues/3

fnoop commented 4 years ago

Think we're good with avahi now.