Zeroconf between rasbain and osmc

sperfect · 10 April 2017 13:35

I have setup 3 rpi inside my LAN 2 OSMC and 1 rasbian
I want to access everything using “xxx.local”
Between the 2 OSMCs zeroconf works fine.
The rasbian however cannot see the two OSMCs neither be seen them.

myosmc and myosmc0 are OSMC
mypi2 is raspbian

From an osmc with avahi-browse I get these

osmc@myosmc:~$ avahi-browse -a -t
+  wlan0 IPv4 myosmc0                                      Web Site             local
+  wlan0 IPv4 myosmc                                       Web Site             local
+  wlan0 IPv4 myosmc0                                      _xbmc-jsonrpc._tcp   local
+  wlan0 IPv4 myosmc                                       _xbmc-jsonrpc._tcp   local
+  wlan0 IPv4 myosmc0                                      _xbmc-jsonrpc-h._tcp local
+  wlan0 IPv4 myosmc                                       _xbmc-jsonrpc-h._tcp local
+  wlan0 IPv4 myosmc0                                      _xbmc-events._udp    local
+  wlan0 IPv4 myosmc                                       _xbmc-events._udp    local
+  wlan0 IPv4 pulse@myosmc                                 PulseAudio Sound Server local
+  wlan0 IPv4 pulse@myosmc: bcm2835 ALSA Analog Stereo     PulseAudio Sound Sink local
+  wlan0 IPv4 B827EB463E92@myosmc0                         AirTunes Remote Audio local
+  wlan0 IPv4 B827EBB4DDCB@myosmc                          AirTunes Remote Audio local
+  wlan0 IPv4 myosmc0                                      _airplay._tcp        local
+  wlan0 IPv4 myosmc                                       _airplay._tcp        local
+  wlan0 IPv4 myosmc0                                      Remote Disk Management local
+  wlan0 IPv4 myosmc                                       Remote Disk Management local
+  wlan0 IPv4 myosmc0                                      SSH Remote Terminal  local
+  wlan0 IPv4 myosmc                                       SSH Remote Terminal  local
+  wlan0 IPv4 myosmc0                                      SFTP File Transfer   local
+  wlan0 IPv4 myosmc                                       SFTP File Transfer   local
+  wlan0 IPv4 myosmc0 [b8:27:eb:46:3e:92]                  Workstation          local
+  wlan0 IPv4 myosmc [b8:27:eb:b4:dd:cb]                   Workstation          local

from pi these

pi@mypi2:~ $ avahi-browse -a -t
+   eth0 IPv6 mypi2                                        SSH Remote Terminal  local
+   eth0 IPv4 mypi2                                        SSH Remote Terminal  local
+   eth0 IPv6 mypi2                                        _device-info._tcp    local
+   eth0 IPv4 mypi2                                        _device-info._tcp    local
+   eth0 IPv6 mypi2 [b8:27:eb:e3:fc:15]                    Workstation          local
+   eth0 IPv4 mypi2 [b8:27:eb:e3:fc:15]                    Workstation          local

Notice the IPv6 entries. Does it have to do something with messing the packets? Do I have to “enable” IPv6 on OSMC?
Thanks in advance.

dillthedog · 10 April 2017 17:49

It’s difficult to know if it’s IPv6-related. Is IPv6 enabled on your LAN? On my LAN, I don’t use IPv6 and avahi is working fine between a Pi 1 running Raspbian and an OSMC Vero 4K, so there’s no fundamental incompatibility between the two systems.

I assume you can ping between the systems by IP address.
On Raspbian and one OSMC box (use myosmc) please run the following commands:

cat /etc/nsswitch.conf
getent hosts myosmc.local
getent hosts mypi2.local
dpkg -l libnss*
route

(The getent will be for itself and the other box.)

It’s a bit scattergun since it’s not clear where the problem might lie.

yknivag · 10 April 2017 20:06

IIRC IPv6 is not enabled by default in OSMC. It’s not needed on a standard domestic LAN unless you have many thousands of devices.

It would probably be far easier to disable IPv6 on the other Pi and stick with IPv4.

sperfect · 11 April 2017 09:26

myosmc

cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat
gshadow:        files

hosts:          files myhostname mdns4_minimal [NOTFOUND=return] dns mdns4
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

mypi2

cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat
gshadow:        files

hosts:          files mdns4_minimal [NOTFOUND=return] dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

There is a difference in hosts osmc, also contains mdns4

dillthedog · 11 April 2017 09:42

That is only a part of what I asked for. The /etc/nsswitch.conf file on mypi2 is the same as on my Raspbian Pi 1, so that part looks fine.

Running getent both for the other machine and for itself should still be useful. It’s a bit like trying to ping localhost.

sperfect · 11 April 2017 11:59

myosmc

osmc@myosmc:~$  getent hosts mypi2.local
osmc@myosmc:~$ getent hosts myosmc.local
192.168.1.42    myosmc.local
osmc@myosmc:~$  getent hosts myosmc0.local
192.168.1.20    myosmc0.local

osmc@myosmc:~$ dpkg -l libnss*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                                  Version                         Architecture                    Description
+++-=====================================================-===============================-===============================-===============================================================================================================
ii  libnss-mdns:armhf                                     0.10-6                          armhf                           NSS module for Multicast DNS name resolution
ii  libnss-myhostname:armhf                               0.3-9                           armhf                           nss module providing fallback resolution for the current hostname
osmc@myosmc:~$

osmc@myosmc:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.1     0.0.0.0         UG    0      0        0 wlan0
google-public-d 192.168.1.1     255.255.255.255 UGH   0      0        0 wlan0
192.168.1.0     *               255.255.255.0   U     0      0        0 wlan0
192.168.1.1     *               255.255.255.255 UH    0      0        0 wlan0
osmc@myosmc:~$

###mypi2

pi@mypi2:~ $ getent hosts mypi2.local
192.168.1.13    mypi2.local
pi@mypi2:~ $ getent hosts myosmc.local
pi@mypi2:~ $ getent hosts myosmc0.local
pi@mypi2:~ $

pi@mypi2:~ $ dpkg -l libnss*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                                  Version                         Architecture                    Description
+++-=====================================================-===============================-===============================-===============================================================================================================
ii  libnss-mdns:armhf                                     0.10-6                          armhf                           NSS module for Multicast DNS name resolution

pi@mypi2:~ $ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.1     0.0.0.0         UG    202    0        0 eth0
192.168.1.0     *               255.255.255.0   U     202    0        0 eth0
pi@mypi2:~ $

dillthedog · 11 April 2017 16:03

Thanks for all that. Nothing jumps out at me. The most interesting snippet of information is that mypi2 is able to get its own domain name from avahi/mdns, which suggests that avahi is probably working on the Pi.

Before going any further, if at all possible, please reboot your router, then:

Please confirm that pings between machines work using IP addresses.
Confirm that you don’t have any unusual subnetting or vlans configured on the router.
Temporarily move one OSMC box onto eth0, ie directly attached to the router. Before moving the box, ensure that the ethernet port is switched on using sudo connmanctl enable ethernet. Then attach the box to the router and ensure that wireless is switched off using sudo connmanctl disable wifi.
Repeat the getent hosts <hostname> commands so that each box gets the details of the other two boxes, this time excluding itself. There should be six results.

sperfect · 12 April 2017 14:22

thank you @dillthedog i’ll give it a try
@yknivag @dillthedog how can I disable ipv6 on the pi, in case that is causing the problem?

dillthedog · 12 April 2017 16:09

Don’t turn off IPv6 just yet. Run my tests first or you’ll complicate the picture.

sperfect · 25 April 2017 10:21

Helllo @dillthedog
I restarted the router,pinging with addresses was OK.
I mover myosmc on ethernet.
Now mypi2 and myosmc are visible with its other (both on eth) and myosmc0 became invisible from both.

mypi2

pi@mypi2:~ $ getent hosts myosmc.local
192.168.1.2     myosmc.local
pi@mypi2:~ $ getent hosts myosmc0.local
pi@mypi2:~ $ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.1     0.0.0.0         UG    202    0        0 eth0
192.168.1.0     *               255.255.255.0   U     202    0        0 eth0
pi@mypi2:~ $

myosmc0

osmc@myosmc0:~$ getent hosts mypi2.local
osmc@myosmc0:~$ getent hosts myosmc.local
osmc@myosmc0:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.1     0.0.0.0         UG    0      0        0 wlan0
google-public-d 192.168.1.1     255.255.255.255 UGH   0      0        0 wlan0
192.168.1.0     *               255.255.255.0   U     0      0        0 wlan0
192.168.1.1     *               255.255.255.255 UH    0      0        0 wlan0
osmc@myosmc0:~$

myosmc

osmc@myosmc:~$ getent hosts myosmc0.local
osmc@myosmc:~$ getent hosts mypi2.local
192.168.1.13    mypi2.local
osmc@myosmc:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
192.168.1.1     *               255.255.255.255 UH    0      0        0 eth0
osmc@myosmc:~$

sperfect · 25 April 2017 10:22

And pinging by IP works fine for everything

dillthedog · 25 April 2017 11:13

I thought you were never going to return!

I had a feeling this would happen.

My best guess is that multicast bridging is not working on your router. It’s possible (and unfortunately far too common with domestic routers) that it just doesn’t work at all on your router. However, depending on the router, it might also be possible to change one of the settings to allow multicast bridging. If you can find an option (probably in an Advanced menu) related to multicast bridging or streaming, enable it.

Here’s a thread that seems to mirror your problem:

Edit: I forgot to include IGMP snooping. If available on the router, also try enabling it.

sperfect · 27 April 2017 11:52

No luck.
IGMP snooping is enabled.
I did not find any option about multicast bridging.
Thanks a lot for your help

dillthedog · 27 April 2017 12:57

Bummer.

Before you do anything too radical, we can test if multicast is getting through the router using iperf.

Install iperf using apt-get on two machines that can’t see each other.

Then on one machine, which will be on the listening end, run:

iperf -u -s -B 224.0.0.251 -i 1

On the other (sending) end, run:

iperf -u -c 224.0.0.251 -t 5

The sender will stop after 5 seconds, but you’ll need to to ctrl-C the listener.

(I’ve used the same multicast address as zeroconf but any 224.0.0.XXX address will do.)

For completeness, you can always try it both directions.

If nothing gets through, it’s very likely to be your router that’s the problem.

sperfect · 28 April 2017 10:39

Nothing indeed…

dillthedog · 28 April 2017 10:44

iperf -u -c 224.0.0.251 -t 5

That’s the sender, but I assume the listener also came up with nothing.

Looks like you’ll need to rejig your network or simply live with it.

Out of interest, what’s the router?

sperfect · 28 April 2017 10:47

I’ll live with it…
ZTE ZXHN H208N