Connection problem to Cambridge 851N endpoint

Have you allowed multicast (IGMP) traffic (see the article linked above by Noris)?

Yes i also tried enabling the multicast but it failed, the 851N zone wasn’t present after a core reboot.

The only thing that seems to work is to allow a wide range of udp local ports for incoming connections from my 851N’s ip.

That’s why i asked for a more precise range if possible.

Port 1900 udp should be sufficient but don’t restrict it to your local network (192.168.1.0/24) – multicast doesn’t use this network. The rule seems to effectively block multicast from accessing port 1900 udp.

Or to sum up the thread Noris linked:

Allow IGMP
Allow connections to port 9003 udp (optionally restrict access to 192.168.1.0/24)
Allow connections to ports 9100-9200 tcp (optionally restrict access to 192.168.1.0/24)

1 Like

That’s exactly what i did (with the option on) and as i told that doesn’t worked.

What i saw in ufw logs is that connexion from 851N’s ip to my NUC (no broadcast ip but 851N explicit ip) were blocked because trying to reach unallowed udp ports between 30000 and 60000.

But enabling a big range of udp ports like that by example :

30000:60000/udp ALLOW IN 192.168.1.20

where 192.168.1.20 is the 851N’s ip address make it works (without multicast on).

It’s not what you showed.

and

isn’t it the same that :

with the optionnally local restrict acces to on ?

Did i miss something ?

Yes, you missed to quote the whole section of your post:

My rule is less restrictive than the one used in the previously linked thread :

sudo ufw allow from 192.168.1.0/24 to any port 1900 proto udp

it allows 2 more ports.

Port 1900 (SSDP) is multicast. You block multicast by restricting access to 192.168.1.0/24. It’s best to drop that line and allow IGMP instead.

I see your point but that’s not what was in linked thread.

Ok so to check your point, i just tried enabling ports without local restriction :

9100:9200/tcp ALLOW Anywhere
9003/udp ALLOW Anywhere
1900/udp ALLOW Anywhere

and

IGMP

-A ufw-user-input -s 224.0.0.0/4 -j ACCEPT
-A ufw-user-input -d 224.0.0.0/4 -j ACCEPT
-A ufw-user-input -s 240.0.0.0/5 -j ACCEPT
-A ufw-user-input -m pkttype --pkt-type multicast -j ACCEPT
-A ufw-user-input -m pkttype --pkt-type broadcast -j ACCEPT

in user.rules

=> and that doesn’t work.

I still see incoming rejected connexions from my 851N’s ip to udp ports above 30000 in logs.

So i think the problem is here.

After searching in the forum I was able to dig up the thread that I used as a guideline back in the days:

I see but my problem is not exactly the same and the solution given doesn’t seem to solve it.
I use ipads an iphones as remotes and they work well, even if the roon core is restarted they find it.
The problem is that once the core is restarted i lost the 851 sound zone as a roon endpoint.

I also found earlier that when I have the problem and go in 851N settings and change « DSD mode compatible with Roon » value to PCM and back to DoP that makes the 851N endpoint visible again in Roon.
It seems it’s because when doing this, the 851N sends UDP requests to the core, one on port 1902 (NOTIFY ALIVE) and on port 9003 with some informatons related to roon service running on 851N.
It seems to have the same effect as rebooting the 851N and makes the 851N endoint visible again by the roon core.

But if i don’t do this trick and reboot roon server, i can’t see the 851N zone anymore and i only see udp requests on random ports above 30000 rejected. If i allow them, the 851N is visible again 


Normal firewall operation is to block all incoming packets – unless they belong to a previously established connection. All outgoing packets are allowed.

AFAIK there is no service belonging to Roon listening on random ports above 30000. If there is incoming traffic that makes a difference, then it’s most-likely belonging to an established connection. It seems you are running a firewall in an uncommon setup. None of the firewall setup examples in the forums are meant for such a scenario. You’re maybe best off to allow all incoming packets to any port if the originate from your 815N. Additionally allow igmp, multicast and eventually also broadcasts if they get blocked otherwise – or adapt the common firewall approach outlined above.

I’m not a firewall expert. The example setup (adapted to my network situation) given in the last thread I linked worked – and still works – for me. Nothing more should be needed for common firewall setups.

Sorry that I can’t be of more help for your situation.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.