Roon cannot see endpoint as audio zone on Orbi RBK50 satellite

Message 4 mentioned that the Kitchen Roon appeared briefly and then disappeared.

Is this a repeatable phenomenon? 

I am still mystified about how the Roon server knows what is connected to the network.  I would want to open Wireshark (free for Mac at https://www.wireshark.org/download.html ) in promiscuous mode (so that it will capture broadcast packets) and set an option to capture only from the Kitchen MS200 (Either by IP address, i.e. host 192.168.1.x, or by Ethernet MAC address ether host xx:xx:xx:xx:xx:xx  )

An easy way to verify that Wireshark is capturing would be to ping the MS200 IP address from a command window.

Actually, I would probably put all four Roon devices in the Capture Filter (to see if they behave the same) - server, Kitchen, Lounge, Study.  i.e. host 192.168.1.x or 192.168.1.y or 192.168.1.z or 192.168.1.a

Thanks - I'm out for a few days but will try this later in the week.

Hi CrimpOn 

Have installed Wireshark and tried to capture from those 4 devices. I set it to Ethernet though so not sure if it captured from the Kitchen MS200. File attached.

NB I don't know what I'm doing so please feel free to give idiot proof instructions.

PS I can't upload a gzip file - how do I send you the results? 

I did a ping test to the MS200 IP address and got this:

2017-iMac ~ % ping 172.16.0.12

PING 172.16.0.12 (172.16.0.12): 56 data bytes

64 bytes from 172.16.0.12: icmp_seq=0 ttl=255 time=7.696 ms

64 bytes from 172.16.0.12: icmp_seq=1 ttl=255 time=4.830 ms

64 bytes from 172.16.0.12: icmp_seq=2 ttl=255 time=4.051 ms

64 bytes from 172.16.0.12: icmp_seq=3 ttl=255 time=6.933 ms

64 bytes from 172.16.0.12: icmp_seq=4 ttl=255 time=5.293 ms

64 bytes from 172.16.0.12: icmp_seq=5 ttl=255 time=5.210 ms

64 bytes from 172.16.0.12: icmp_seq=6 ttl=255 time=5.695 ms

64 bytes from 172.16.0.12: icmp_seq=7 ttl=255 time=5.400 ms

64 bytes from 172.16.0.12: icmp_seq=8 ttl=255 time=5.316 ms

64 bytes from 172.16.0.12: icmp_seq=9 ttl=255 time=5.708 ms

64 bytes from 172.16.0.12: icmp_seq=10 ttl=255 time=6.676 ms

64 bytes from 172.16.0.12: icmp_seq=11 ttl=255 time=5.329 ms

64 bytes from 172.16.0.12: icmp_seq=12 ttl=255 time=6.552 ms

64 bytes from 172.16.0.12: icmp_seq=13 ttl=255 time=4.306 ms

64 bytes from 172.16.0.12: icmp_seq=14 ttl=255 time=6.060 ms

64 bytes from 172.16.0.12: icmp_seq=15 ttl=255 time=5.300 ms

64 bytes from 172.16.0.12: icmp_seq=16 ttl=255 time=7.286 ms

64 bytes from 172.16.0.12: icmp_seq=17 ttl=255 time=3.682 ms

64 bytes from 172.16.0.12: icmp_seq=18 ttl=255 time=6.285 ms

64 bytes from 172.16.0.12: icmp_seq=19 ttl=255 time=6.582 ms

64 bytes from 172.16.0.12: icmp_seq=20 ttl=255 time=5.296 ms

64 bytes from 172.16.0.12: icmp_seq=21 ttl=255 time=5.925 ms

64 bytes from 172.16.0.12: icmp_seq=22 ttl=255 time=5.989 ms

64 bytes from 172.16.0.12: icmp_seq=23 ttl=255 time=7.486 ms

64 bytes from 172.16.0.12: icmp_seq=24 ttl=255 time=7.543 ms

64 bytes from 172.16.0.12: icmp_seq=25 ttl=255 time=5.536 ms

64 bytes from 172.16.0.12: icmp_seq=26 ttl=255 time=5.481 ms

64 bytes from 172.16.0.12: icmp_seq=27 ttl=255 time=5.603 ms

64 bytes from 172.16.0.12: icmp_seq=28 ttl=255 time=3.337 ms

64 bytes from 172.16.0.12: icmp_seq=29 ttl=255 time=6.495 ms

64 bytes from 172.16.0.12: icmp_seq=30 ttl=255 time=6.019 ms

64 bytes from 172.16.0.12: icmp_seq=31 ttl=255 time=4.805 ms

64 bytes from 172.16.0.12: icmp_seq=32 ttl=255 time=5.726 ms

^C

--- 172.16.0.12 ping statistics ---

33 packets transmitted, 33 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 3.337/5.740/7.696/1.036 ms

OK I don't know if this is useful but this is the capture from the MS200 only:

Frame 3: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface en0, id 0
Section number: 1
Interface id: 0 (en0)
Encapsulation type: Ethernet (1)
Arrival Time: Jan 26, 2025 20:50:37.635696000 GMT
UTC Arrival Time: Jan 26, 2025 20:50:37.635696000 UTC
Epoch Arrival Time: 1737924637.635696000
[Time shift for this packet: 0.000000000 seconds]
[Time delta from previous captured frame: 23.356887000 seconds]
[Time delta from previous displayed frame: 23.356887000 seconds]
[Time since reference or first frame: 38.293597000 seconds]
Frame Number: 3
Frame Length: 64 bytes (512 bits)
Capture Length: 64 bytes (512 bits)
[Frame is marked: True]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:igmp:igmp]
[Coloring Rule Name: Routing]
[Coloring Rule String: hsrp || eigrp || ospf || bgp || cdp || vrrp || carp || gvrp || igmp || ismp]
Ethernet II, Src: MeridianAudi_00:0e:84 (00:24:c5:00:0e:84), Dst: IPv4mcast_7f:ff:f9 (01:00:5e:7f:ff:f9)
Destination: IPv4mcast_7f:ff:f9 (01:00:5e:7f:ff:f9)
Source: MeridianAudi_00:0e:84 (00:24:c5:00:0e:84)
Type: IPv4 (0x0800)
[Stream index: 0]
Trailer: 0104020000000000000000000000
Frame check sequence: 0x00000000 [unverified]
[FCS Status: Unverified]
Internet Protocol Version 4, Src: 172.16.0.12, Dst: 239.255.255.249
0100 .... = Version: 4
.... 0110 = Header Length: 24 bytes (6)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 32
Identification: 0x899e (35230)
000. .... = Flags: 0x0
...0 0000 0000 0000 = Fragment Offset: 0
Time to Live: 1
Protocol: IGMP (2)
Header Checksum: 0xff23 [validation disabled]
[Header checksum status: Unverified]
Source Address: 172.16.0.12
Destination Address: 239.255.255.249
Options: (4 bytes), Router Alert
[Stream index: 0]
Internet Group Management Protocol
[IGMP Version: 2]
Type: Membership Report (0x16)
Max Resp Time: 0.0 sec (0x00)
Checksum: 0xfa05 [correct]
[Checksum Status: Good]
Multicast Address: 239.255.255.249

I also asked Roon support about what subnet they saw. They replied:

Based on a recent diagnostic report, we see the MS200 reporting the following IP: 169.254.133.14

This IP scheme is used when a device cannot obtain an IP address from a DHCP server (e.g., a router or network server). When this happens, the device assigns itself an address in the 169.254.x.x range (with a subnet mask of 255.255.0.0) so it can communicate with other devices on the same local network without requiring manual configuration.

thedigester wrote:

PS I can't upload a gzip file - how do I send you the results? 

---

What I usually do is upload the file to a network share, such as Microsoft One Drive, Google Drive, or Drop Box. Make sure it is sharable to anyone who has the link.  Copy the "link" to the file and paste it into a post.

Here, for example, is a Wireshark file I captured between my PC and a security camera back iin 2022:

https://www.dropbox.com/scl/fi/dr2atiwebnz2tt0ryl6kf/cerebus.pcapng?rlkey=8tkm1essrt81bad2vk86q7ocx&dl=0 

(have no memory of the reason I captured it or who I was sending it to.  getting old sucks.)

Of course - I should have thought of that. Here you go:

https://www.dropbox.com/scl/fi/zqs8hp8y17k7ut3qmeu36/Roon-ethernet-capture.pcapng.gz?rlkey=hexr2x3oqnqsuaalmr9g58cvc&st=o2x5f2s7&dl=0

Got it.  Probably not necessary to zip the pcap file.

Packets captured from:

172.16.0.4 is ?

172.16.0.5 is ?

172.16.0.6 is ?

172.16.0.12 is the Kitchen MS200

172.16.9.58 is ?

The MS200 works correctly when connected to one of the English Electric 8 switches but does not work when connected to either RBS50 satellite.

Do you happen to have a WiFi Extender?  (I am partial to the TP-Link RE220 because they are about $15US on Amazon. The brand doesn't matter as long as it has an Ethernet port.)

Why?  The point would be to eliminate the RBS50 Ethernet switch from the communication link.  A WiFi extender located in the Kitchen would most likely connect to the RBS50 satellite over 5G WiFi.  Connect the MS200 to the Ethernet port on the WiFi extender.

Another more complicated experiment would be to temporarily move the RBS50 and MS200 to be near the RBR50 router and connect the satellite with an Ethernet cable.  That would move the satellite backhaul link from 5G WiFi to Ethernet.

You are going to a lot of effort to solve this.

As are you!

172.16.0.4 is the Study audio (Meridian 218)

172.16.0.5 is iMac (not sure why I included that)

172.16.0.6 is Roon server (Nucleus)

172.16.0.12 is the Kitchen MS200

172.16.9.58 is the Lounge audio (Meridian ID41)

I have ordered your suggested TP-Link extender - thanks.

It's a burden having good hearing.  For me, an Echo Dot has more fidelity than I can appreciate.  "The refrigerator door was left ajar again.  Don't you HEAR that beeping?"  - nope.

That Wireshark capture is fascinating.

• The server (172.16.0.6) is constantly sending out MDNS broadcasts
  https://en.wikipedia.org/wiki/Multicast_DNS 
  asking if there are any devices which can handle airplay, googlecast, and raop.
• All three speaker systems send out IGMP broadcasts
  https://en.wikipedia.org/wiki/Internet_Group_Management_Protocol 
  
  
• But only the two speakers wired to the local switches send out lots of other broadcast packets, while the kitchen speaker appears to send none.
• The Mac carries on quite a conversation with the Music storage server (as one would expect).
•  

What a relief!

Even simple "unmanaged" Ethernet switches have a ton of software embedded into the hardware.  Things like:

• Autonegotiation. Where the devices at each end of the cable decide what speeds they both can handle and settle on one. https://en.wikipedia.org/wiki/Autonegotiation 
• Auto MDI/MDI-X which accepts straight through or 'crossover' cables automatically. https://en.wikipedia.org/wiki/Medium-dependent_interface 
• Green capability, to reduce power in specific circumstances. https://en.wikipedia.org/wiki/Energy-Efficient_Ethernet 
• IGMP Snooping. To prevent networks from being flooded with IGMP broadcasts that no device wants to see.
  https://en.wikipedia.org/wiki/IGMP_snooping 

Users have no control over this level of hardware.  For years the Forum dealt with situations where Orbi satellites would not function correctly because users had installed switches with poorly designed IGMP Snooping or Green features.

What this solution appears to indicate is that the Ethernet switch module soldered onto the satellite motherboard was blocking some of the IGMP broadcasts from the MS200.  Bypass that one piece of hardware, and "all good".

CrimpOn I'm afraid I spoke too soon... the MS200 has disappeared again. The only change I made was to update the TP-link firmware. Perhaps that was a mistake.

I cannot see the MS200 on the network, but it is shown via the TP-link app as being hardwire connected.

Here is another Wireshark capture - hopefully that gives you a clue as to what's going on:

https://www.dropbox.com/scl/fo/1q439rr0likpnm0877w4t/AHRye2QNQ-VTGqK7Hx49DC0?rlkey=57xsqrbxadsly1xfku4pib9pu&st=lddpqcfo&dl=0

One "feature" of some WiFi Extenders is to manipulate the MAC address of devices connected to the Extender.

I ran into this four years ago when I installed a WiFi Extender in the garage to replace a Powerline adapter that was failing.  All of the devices that I had carefully assigned IP addresses to in the LAN Setup page got different addresses. What???  When I looked more closely, it seemed like they no longer had the MAC address that I had entered into the LAN Setup table.  (My memory of 2020 is a bit dim.)

Would it be possible to compare the MAC address and IP address of the MS200

• When it is connected to the Orbi satellite
• When it is connected to the TP-Link RE220

I will dig out my RE220 and perform a similar experiment.

Looks like I jumped before looking.

This capture shows exactly the same pattern as before.  MS200 sends out** a lot of IGMPv2 broadcasts, but none of the UDP broadcasts that the other speakers do.

Ethernet MAC address of 00:24:C5:00:0E:84 and IP of 172.16.0.12 are the same on both captures.

Darn.

Actually, we do not know what the MS200 is broadcasting, only what the iMac is receiving.  Capturing Ethernet is a tricky business because of how Ethernet switches function..

• Switches "learn" the route to every device on the network by creating address tables.  "To get to this MAC address, send packets out this port."  They have no idea whether that port leads directly to the device, or to another part of the network that (eventually) reaches the physical device.
• Broadcast packets are sent out every network port.

When Wireshark puts an Ethernet adapter into promiscuous mode, the adapter captures every pack that comes in:

• Unicast packets that are addressed to it, plus
• Multicast packets that are going everywhere.
• Unicast packets that are destined for some other MAC address cannot be captured because they do not get sent to this adapter.

All we know is that we are not seeing those UDP broadcasts.  My guess is that the MS200 is sending them out, because it works fine when connected to one of the Electric 8 switches.

Just to close this one off, I ended up buying a new streamer (iFi Zen Stream FWIW) to replace the Meridian MS200 and it is working fine on Roon via the Orbi satellite + Ethernet.

Many thanks to CrimpOn for all their help.

Smart move!

I realize there is no major benefit to struggling any more with the MS200 (it is really from 2013?)  I was researching a similar issue in 2023 and picked up a pair of cheap stereo speakers on Amazon for $15USD.  With a 3.5mm jack, they are intended for connection to a PC, but should also work with the MS200.

It might be interesting to verify where the MS200:

• works consistently.  never fails.
• works inconsistently.  sometimes, but not all the time.
• never works.