Reply
Emerging Member
Posts: 54
Registered: ‎11-05-2016
Kudos: 5

Re: Multicast, Sonos, Phorus & Play-Fi Broadcast 255.255.255.255:<port> Discovery Solution

Thanks very much. I look forward to trying this tonight.

 

I have also found that my Harmony Remote does not appear to be working to control my Roku boxes anymore. I think this is due to it being a network-based control scheme rather than IR.

USG / USW24PoE / AP-AC-LR / AP-LR / AP-IW Pro
Established Member
Posts: 1,408
Registered: ‎10-01-2014
Kudos: 695
Solutions: 66

Re: Multicast, Sonos, Phorus & Play-Fi Broadcast 255.255.255.255:<port> Discovery Solution

Since the Harmony Remote is off topic for this thread, recommend you direct your question to a different forum or if it is related to the Edge Router, create a new topic.

Please help the community find useful posts and solutions by using the "Kudos" and "Accept as Solution" buttons!
Emerging Member
Posts: 54
Registered: ‎11-05-2016
Kudos: 5

Re: Multicast, Sonos, Phorus & Play-Fi Broadcast 255.255.255.255:<port> Discovery Solution

Sorry, to be clear, I think it's not working for exactly the same reasons that apply to the Sonos, etc. In other words, because my Roku box is connected to my hardline network (eth1) and the remote hub is connected to the wireless network (via eth4), I seem to be getting the same issue of messages not propogating between the two.

USG / USW24PoE / AP-AC-LR / AP-LR / AP-IW Pro
Established Member
Posts: 1,408
Registered: ‎10-01-2014
Kudos: 695
Solutions: 66

Re: Multicast, Sonos, Phorus & Play-Fi Broadcast 255.255.255.255:<port> Discovery Solution


@nixlimited wrote:

Sorry, to be clear, I think it's not working for exactly the same reasons that apply to the Sonos, etc. In other words, because my Roku box is connected to my hardline network (eth1) and the remote hub is connected to the wireless network (via eth4), I seem to be getting the same issue of messages not propogating between the two.


I think the Roku uses mDNS for network control, so you might want to try using the MDNS reflector/relay configuration - search the forums for that.

Please help the community find useful posts and solutions by using the "Kudos" and "Accept as Solution" buttons!
New Member
Posts: 25
Registered: ‎07-31-2016
Kudos: 5

Re: Multicast, Sonos, Phorus & Play-Fi Broadcast 255.255.255.255:<port> Discovery Solution

Hi @britannic,

 


@britannic wrote:

@DennisSchmitt, see if you can get some more detailed output; start with these tcpdump parameters:

 

sudo tcpdump -vv ether broadcast

 


 

I'm sorry for the delay of my reply, I've been out of office until yesterday. I just made the tcpdump you proposed. Here's what's been coming out:

 

My test udp packet was sent from 10.0.0.201:3804 to 10.0.1.201:3804 as a unicast through the router perfectly without any problems. After that the test packet with the same content as a broadcast from 10.0.0.201:3804 to 255.255.255.255:3804 does not arrive at 10.0.1.201:3804, like it should.

 

The first tcpdump was exactly the one you wanted, unfortunately it looked at interface switch0 and that's why there was no output:

 

ubnt@ubnt:~$ sudo tcpdump -vv ether broadcast
tcpdump: listening on switch0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

After that I looked at interface eth0, where the sender of the test packet 10.0.0.201 was connected to. Here's the output:

 

ubnt@ubnt:~$ sudo tcpdump -i eth0 -vv ether broadcast                                                                                                                                                                        
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:21:52.454462 IP (tos 0x0, ttl 128, id 519, offset 0, flags [none], proto UDP (17), length 196)
    10.0.0.201.17500 > 255.255.255.255.17500: [udp sum ok] UDP, length 168
22:21:52.456351 IP (tos 0x0, ttl 128, id 520, offset 0, flags [none], proto UDP (17), length 196)
    10.0.0.201.17500 > 255.255.255.255.17500: [udp sum ok] UDP, length 168
22:21:52.456374 IP (tos 0x0, ttl 128, id 522, offset 0, flags [none], proto UDP (17), length 196)
    10.0.0.201.17500 > 10.0.0.255.17500: [udp sum ok] UDP, length 168
22:21:52.456369 IP (tos 0x0, ttl 128, id 521, offset 0, flags [none], proto UDP (17), length 196)
    10.0.0.201.17500 > 255.255.255.255.17500: [udp sum ok] UDP, length 168
22:21:53.424501 IP (tos 0x0, ttl 128, id 528, offset 0, flags [none], proto UDP (17), length 116)
    10.0.0.201.63834 > 255.255.255.255.19540: [udp sum ok] UDP, length 88
22:21:54.777582 IP (tos 0x0, ttl 128, id 541, offset 0, flags [none], proto UDP (17), length 43)
    10.0.0.201.3804 > 255.255.255.255.3804: [udp sum ok] UDP, length 15
22:21:55.937402 IP (tos 0x0, ttl 128, id 551, offset 0, flags [none], proto UDP (17), length 43)
    10.0.0.201.3804 > 255.255.255.255.3804: [udp sum ok] UDP, length 15
22:21:56.825703 IP (tos 0x0, ttl 128, id 563, offset 0, flags [none], proto UDP (17), length 43)
    10.0.0.201.3804 > 255.255.255.255.3804: [udp sum ok] UDP, length 15
22:21:57.222662 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.1 tell 10.0.0.201, length 46
^C
9 packets captured
9 packets received by filter
0 packets dropped by kernel

Seems like that only three of the packets are sent by me manually, the other ones are sent not by me manually, but I guess from the os, but I'm not sure.

 

After thatI looked at eth1, where the broadcast should be forwarded to, unfortunately without results:

 

ubnt@ubnt:~$ sudo tcpdump -i eth1 -vv ether broadcast                                                                                                                                                                        
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
22:22:14.997022 IP (tos 0x0, ttl 128, id 32563, offset 0, flags [none], proto UDP (17), length 116)
    10.0.1.201.54013 > 255.255.255.255.19540: [udp sum ok] UDP, length 88
22:22:19.179604 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.1.1 tell 10.0.1.201, length 46
22:22:20.403962 IP (tos 0x0, ttl 128, id 32564, offset 0, flags [none], proto UDP (17), length 293)
    10.0.1.201.17500 > 255.255.255.255.17500: [udp sum ok] UDP, length 265
22:22:20.411647 IP (tos 0x0, ttl 128, id 32565, offset 0, flags [none], proto UDP (17), length 293)
    10.0.1.201.17500 > 255.255.255.255.17500: [udp sum ok] UDP, length 265
22:22:20.411661 IP (tos 0x0, ttl 128, id 32566, offset 0, flags [none], proto UDP (17), length 293)
    10.0.1.201.17500 > 255.255.255.255.17500: [udp sum ok] UDP, length 265
22:22:20.412450 IP (tos 0x0, ttl 128, id 17736, offset 0, flags [none], proto UDP (17), length 293)
    10.0.1.201.17500 > 10.0.1.255.17500: [udp sum ok] UDP, length 265
^C
6 packets captured
6 packets received by filter
0 packets dropped by kernel

 

Again seems like that only automatic packets from the system are being received, but not my manually sent test packets.

 

Any ideas how to further troubleshoot?

 

Once again, thanks a lot for your big help!

 

Best regards,
Dennis

Established Member
Posts: 1,408
Registered: ‎10-01-2014
Kudos: 695
Solutions: 66

Re: Multicast, Sonos, Phorus & Play-Fi Broadcast 255.255.255.255:<port> Discovery Solution

@DennisSchmitt, I see ports 17500 19540 also being broadcast, you might want to experiment by adding additional relays for them:

set service bcast-relay id 2 description 'Test 17500 bcast relay'
set service bcast-relay id 2 interface eth0
set service bcast-relay id 2 interface eth1
set service bcast-relay id 2 port 17500

set service bcast-relay id 3 description 'Test 19540 bcast relay'
set service bcast-relay id 3 interface eth0
set service bcast-relay id 3 interface eth1
set service bcast-relay id 3 port 19540

Let us know what happens.

Please help the community find useful posts and solutions by using the "Kudos" and "Accept as Solution" buttons!
New Member
Posts: 25
Registered: ‎07-31-2016
Kudos: 5

Re: Multicast, Sonos, Phorus & Play-Fi Broadcast 255.255.255.255:<port> Discovery Solution

Hi @britannic

 

First of all, one more big thank for your patience and your continuous support!!

 

I was just able to test the output with the two additional relayed ports:

 

When sending udp test packets to my desired port 3804 from the device connected to eth0, there's still no output on eth1, like before. Unfortunately also when sending test packets to the just testwise relayed ports 17500 or 19540 from the device on eth0, there is still no output to those ports on eth1.

 

Here's the tcpdump on eth0:

 

Welcome to EdgeOS
ubnt@EdgeRouterDSM25:~$ sudo tcpdump -i eth0 -vv ether broadcast
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:25:02.944093 IP (tos 0x0, ttl 128, id 979, offset 0, flags [none], proto UDP (17), length 116)
    10.0.0.201.52104 > 255.255.255.255.19540: [udp sum ok] UDP, length 88
13:25:08.547127 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.1 tell 10.0.0.201, length 46
13:25:11.174876 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 32)
    10.0.0.1.34954 > 255.255.255.255.10001: [udp sum ok] UDP, length 4
13:25:11.180167 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 159)
    10.0.0.1.46827 > 255.255.255.255.34954: [udp sum ok] UDP, length 131
13:25:12.957540 IP (tos 0x0, ttl 128, id 1012, offset 0, flags [none], proto UDP (17), length 116)
    10.0.0.201.52104 > 255.255.255.255.19540: [udp sum ok] UDP, length 88
13:25:18.551107 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.1 tell 10.0.0.201, length 46
13:25:22.973248 IP (tos 0x0, ttl 128, id 1052, offset 0, flags [none], proto UDP (17), length 116)
    10.0.0.201.52104 > 255.255.255.255.19540: [udp sum ok] UDP, length 88
13:25:30.265688 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.1 tell 10.0.0.201, length 46
13:25:32.976621 IP (tos 0x0, ttl 128, id 1124, offset 0, flags [none], proto UDP (17), length 116)
    10.0.0.201.52104 > 255.255.255.255.19540: [udp sum ok] UDP, length 88
13:25:40.381480 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.1 tell 10.0.0.201, length 46
13:25:42.174680 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 32)
    10.0.0.1.48004 > 255.255.255.255.10001: [udp sum ok] UDP, length 4
13:25:42.178651 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 159)
    10.0.0.1.50256 > 255.255.255.255.48004: [udp sum ok] UDP, length 131
13:25:42.988874 IP (tos 0x0, ttl 128, id 1193, offset 0, flags [none], proto UDP (17), length 116)
    10.0.0.201.52104 > 255.255.255.255.19540: [udp sum ok] UDP, length 88
13:25:44.413239 IP (tos 0x0, ttl 128, id 1201, offset 0, flags [none], proto UDP (17), length 42)
    10.0.0.201.3804 > 255.255.255.255.3804: [udp sum ok] UDP, length 14
13:25:46.349465 IP (tos 0x0, ttl 128, id 1213, offset 0, flags [none], proto UDP (17), length 42)
    10.0.0.201.3804 > 255.255.255.255.3804: [udp sum ok] UDP, length 14
13:25:48.542867 IP (tos 0x0, ttl 128, id 1236, offset 0, flags [none], proto UDP (17), length 42)
    10.0.0.201.3804 > 255.255.255.255.3804: [udp sum ok] UDP, length 14
13:25:52.101337 IP (tos 0x0, ttl 128, id 1255, offset 0, flags [none], proto UDP (17), length 42)
    10.0.0.201.3804 > 255.255.255.255.3804: [udp sum ok] UDP, length 14
13:25:52.988831 IP (tos 0x0, ttl 128, id 1270, offset 0, flags [none], proto UDP (17), length 116)
    10.0.0.201.52104 > 255.255.255.255.19540: [udp sum ok] UDP, length 88
^C
18 packets captured
19 packets received by filter
0 packets dropped by kernel

 

and here's the output of tcpdump on eth1, which I did a few seconds after the tcpdump on eth0:

 

ubnt@EdgeRouterDSM25:~$ sudo tcpdump -i eth1 -vv ether broadcast
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
13:26:05.758718 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.1.1 tell 10.0.1.201, length 46
13:26:09.301453 IP (tos 0x0, ttl 128, id 21288, offset 0, flags [none], proto UDP (17), length 116) 
    10.0.1.201.54454 > 255.255.255.255.19540: [udp sum ok] UDP, length 88 
13:26:12.473813 IP (tos 0x0, ttl 128, id 21289, offset 0, flags [none], proto UDP (17), length 292) 
    10.0.1.201.17500 > 255.255.255.255.17500: [udp sum ok] UDP, length 264 
13:26:12.479593 IP (tos 0x0, ttl 128, id 21290, offset 0, flags [none], proto UDP (17), length 292) 
    10.0.1.201.17500 > 255.255.255.255.17500: [udp sum ok] UDP, length 264 
13:26:12.479606 IP (tos 0x0, ttl 128, id 21291, offset 0, flags [none], proto UDP (17), length 292) 
    10.0.1.201.17500 > 255.255.255.255.17500: [udp sum ok] UDP, length 264 
13:26:12.479771 IP (tos 0x0, ttl 128, id 21292, offset 0, flags [none], proto UDP (17), length 292)
    10.0.1.201.17500 > 255.255.255.255.17500: [udp sum ok] UDP, length 264
13:26:12.479931 IP (tos 0x0, ttl 128, id 12990, offset 0, flags [none], proto UDP (17), length 292)
    10.0.1.201.17500 > 10.0.1.255.17500: [udp sum ok] UDP, length 264
13:26:13.189964 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 32)
    10.0.1.1.51421 > 255.255.255.255.10001: [udp sum ok] UDP, length 4
13:26:13.195720 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 159)
    10.0.1.1.46678 > 255.255.255.255.51421: [udp sum ok] UDP, length 131
13:26:15.837777 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.1.1 tell 10.0.1.201, length 46
13:26:19.301670 IP (tos 0x0, ttl 128, id 21293, offset 0, flags [none], proto UDP (17), length 116)
    10.0.1.201.54454 > 255.255.255.255.19540: [udp sum ok] UDP, length 88
13:26:25.915460 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.1.1 tell 10.0.1.201, length 46
13:26:29.301969 IP (tos 0x0, ttl 128, id 21294, offset 0, flags [none], proto UDP (17), length 116)
    10.0.1.201.54454 > 255.255.255.255.19540: [udp sum ok] UDP, length 88
13:26:35.946660 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.1.1 tell 10.0.1.201, length 46
13:26:39.293909 IP (tos 0x0, ttl 128, id 21295, offset 0, flags [none], proto UDP (17), length 116)
    10.0.1.201.54454 > 255.255.255.255.19540: [udp sum ok] UDP, length 88
13:26:42.556568 IP (tos 0x0, ttl 128, id 21296, offset 0, flags [none], proto UDP (17), length 292)
    10.0.1.201.17500 > 255.255.255.255.17500: [udp sum ok] UDP, length 264
13:26:42.561694 IP (tos 0x0, ttl 128, id 21297, offset 0, flags [none], proto UDP (17), length 292) 
    10.0.1.201.17500 > 255.255.255.255.17500: [udp sum ok] UDP, length 264 
13:26:42.561707 IP (tos 0x0, ttl 128, id 21298, offset 0, flags [none], proto UDP (17), length 292) 
    10.0.1.201.17500 > 255.255.255.255.17500: [udp sum ok] UDP, length 264 
13:26:42.561892 IP (tos 0x0, ttl 128, id 21299, offset 0, flags [none], proto UDP (17), length 292)
    10.0.1.201.17500 > 255.255.255.255.17500: [udp sum ok] UDP, length 264
13:26:42.561900 IP (tos 0x0, ttl 128, id 13056, offset 0, flags [none], proto UDP (17), length 292) 
    10.0.1.201.17500 > 10.0.1.255.17500: [udp sum ok] UDP, length 264 
13:26:44.176854 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 32) 
    10.0.1.1.55818 > 255.255.255.255.10001: [udp sum ok] UDP, length 4
13:26:44.181767 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 159) 
    10.0.1.1.41209 > 255.255.255.255.55818: [udp sum ok] UDP, length 131
13:26:46.028111 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.1.1 tell 10.0.1.201, length 46
13:26:49.294308 IP (tos 0x0, ttl 128, id 21300, offset 0, flags [none], proto UDP (17), length 116) 
    10.0.1.201.54454 > 255.255.255.255.19540: [udp sum ok] UDP, length 88 
13:26:59.294931 IP (tos 0x0, ttl 128, id 21301, offset 0, flags [none], proto UDP (17), length 116) 
    10.0.1.201.54454 > 255.255.255.255.19540: [udp sum ok] UDP, length 88 
13:27:09.291110 IP (tos 0x0, ttl 128, id 21302, offset 0, flags [none], proto UDP (17), length 116) 
    10.0.1.201.54454 > 255.255.255.255.19540: [udp sum ok] UDP, length 88 
13:27:12.595650 IP (tos 0x0, ttl 128, id 21303, offset 0, flags [none], proto UDP (17), length 292)  
    10.0.1.201.17500 > 255.255.255.255.17500: [udp sum ok] UDP, length 264 
13:27:12.599599 IP (tos 0x0, ttl 128, id 21304, offset 0, flags [none], proto UDP (17), length 292)  
    10.0.1.201.17500 > 255.255.255.255.17500: [udp sum ok] UDP, length 264 
13:27:12.599612 IP (tos 0x0, ttl 128, id 21305, offset 0, flags [none], proto UDP (17), length 292) 
    10.0.1.201.17500 > 255.255.255.255.17500: [udp sum ok] UDP, length 264 
13:27:12.599618 IP (tos 0x0, ttl 128, id 21306, offset 0, flags [none], proto UDP (17), length 292) 
    10.0.1.201.17500 > 255.255.255.255.17500: [udp sum ok] UDP, length 264 
13:27:12.599794 IP (tos 0x0, ttl 128, id 13122, offset 0, flags [none], proto UDP (17), length 292)  
    10.0.1.201.17500 > 10.0.1.255.17500: [udp sum ok] UDP, length 264 
13:27:15.180416 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 32)
    10.0.1.1.48787 > 255.255.255.255.10001: [udp sum ok] UDP, length 4 
13:27:15.186543 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 159) 
    10.0.1.1.49942 > 255.255.255.255.48787: [udp sum ok] UDP, length 131
13:27:19.304170 IP (tos 0x0, ttl 128, id 21307, offset 0, flags [none], proto UDP (17), length 116) 
    10.0.1.201.54454 > 255.255.255.255.19540: [udp sum ok] UDP, length 88 
13:27:29.290330 IP (tos 0x0, ttl 128, id 21308, offset 0, flags [none], proto UDP (17), length 116)
    10.0.1.201.54454 > 255.255.255.255.19540: [udp sum ok] UDP, length 88
13:27:39.294170 IP (tos 0x0, ttl 128, id 21309, offset 0, flags [none], proto UDP (17), length 116)
    10.0.1.201.54454 > 255.255.255.255.19540: [udp sum ok] UDP, length 88 
13:27:42.658709 IP (tos 0x0, ttl 128, id 21310, offset 0, flags [none], proto UDP (17), length 292) 
    10.0.1.201.17500 > 255.255.255.255.17500: [udp sum ok] UDP, length 264 
13:27:42.662193 IP (tos 0x0, ttl 128, id 21311, offset 0, flags [none], proto UDP (17), length 292)
    10.0.1.201.17500 > 255.255.255.255.17500: [udp sum ok] UDP, length 264
13:27:42.662206 IP (tos 0x0, ttl 128, id 21312, offset 0, flags [none], proto UDP (17), length 292) 
    10.0.1.201.17500 > 255.255.255.255.17500: [udp sum ok] UDP, length 264 
13:27:42.662354 IP (tos 0x0, ttl 128, id 21313, offset 0, flags [none], proto UDP (17), length 292) 
    10.0.1.201.17500 > 255.255.255.255.17500: [udp sum ok] UDP, length 264 
13:27:42.662364 IP (tos 0x0, ttl 128, id 13189, offset 0, flags [none], proto UDP (17), length 292) 
    10.0.1.201.17500 > 10.0.1.255.17500: [udp sum ok] UDP, length 264 
13:27:46.179812 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 32) 
    10.0.1.1.50488 > 255.255.255.255.10001: [udp sum ok] UDP, length 4 
13:27:46.184692 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 159)  
    10.0.1.1.55961 > 255.255.255.255.50488: [udp sum ok] UDP, length 131 
^C
43 packets captured
43 packets received by filter
0 packets dropped by kernel

I let the tcpdump run a few seconds longer than I did before, that's why there were a lot more packets captured than before.

 

Here's once more my config, which is updated with the two additional relayed ports:

 

Welcome to EdgeOS
ubnt@EdgeRouterDSM25:~$ show configuration 
interfaces {
    ethernet eth0 {   
        address 10.0.0.1/24
        duplex auto 
        speed auto 
    }  
    ethernet eth1 { 
        address 10.0.1.1/24
        duplex auto 
        speed auto 
    } 
    ethernet eth2 { 
        duplex auto
        speed auto 
    } 
    ethernet eth3 { 
        duplex auto
        speed auto 
    } 
    ethernet eth4 { 
        duplex auto 
        poe { 
            output pthru
        }
        speed auto
    }
    loopback lo {
    }
    switch switch0 {
        address 10.1.0.1/24
        mtu 1500
        switch-port {
            interface eth4 {
            }
            vlan-aware disable
        }
    }
}
service {
    bcast-relay {
        id 1 {
            description "desired forwarding 3804"
            interface eth0
            interface eth1
            port 3804
        }
        id 2 {
            description "Test 17500 bcast relay"
            interface eth0
            interface eth1
            port 17500
        }
        id 3 {
            description "Test 19540 bcast relay"
            interface eth0
            interface eth1
            port 19540
        }
    }
    dhcp-server {
        disabled false
        hostfile-update disable
        shared-network-name DHCP_eth0 {
            authoritative disable
            subnet 10.0.0.0/24 {
                default-router 10.0.0.1
                lease 86400
                start 10.0.0.201 {
                    stop 10.0.0.249
                }
            }
        }
        shared-network-name DHCP_eth1 {
            authoritative disable
            subnet 10.0.1.0/24 {
                default-router 10.0.1.1
                lease 86400
                start 10.0.1.201 {
                    stop 10.0.1.249
                }
            }
        }
        use-dnsmasq disable
    }
    gui {
        http-port 80
        https-port 443
        older-ciphers enable
    }
    ssh {
        port 22
        protocol-version v2
    }
}
system {
    host-name EdgeRouterDSM25
    login {
        user Dennis {
            authentication {
                encrypted-password ****************
                plaintext-password ****************
            }
            full-name "Dennis Schmitt"
            level admin
        }
        user ubnt {
            authentication {
                encrypted-password ****************
            }
            level admin
        }
    }
    ntp {
        server 0.ubnt.pool.ntp.org {
        }
        server 1.ubnt.pool.ntp.org {
        }
        server 2.ubnt.pool.ntp.org {
        }
        server 3.ubnt.pool.ntp.org {
        }
    }
    syslog {
        global {
            facility all {
                level notice
            }
            facility protocols {
                level debug
            }
        }
    }
    time-zone Europe/Berlin
}
ubnt@EdgeRouterDSM25:~$ 

Any more ideas about how to further troubleshoot?

 

Thanks a lot once more !!!

 

Best regards,

Dennis

Established Member
Posts: 1,408
Registered: ‎10-01-2014
Kudos: 695
Solutions: 66

Re: Multicast, Sonos, Phorus & Play-Fi Broadcast 255.255.255.255:<port> Discovery Solution

@DennisSchmitt, is your test device's IP address: 10.0.0.201? Have you tried tracing just the 3804 port so you can see both interfaces at once? This link has some hints on tcpdump command lines. 

Please help the community find useful posts and solutions by using the "Kudos" and "Accept as Solution" buttons!
New Member
Posts: 25
Registered: ‎07-31-2016
Kudos: 5

Re: Multicast, Sonos, Phorus & Play-Fi Broadcast 255.255.255.255:<port> Discovery Solution

@britannic

 

Thanks once more for your very fast reply.

 

Yeah exactly, the device where the test packets are sent from is 10.0.0.201 and the device where the test packets are received is 10.0.1.201

 

Here's what came out tracing port 3804, I hope that's the command you wanted to see. If you want to see further options of tcpdump please let me know.

 

ubnt@EdgeRouterDSM25:~$ sudo tcpdump -i any -n dst port 3804 -vv                                                                                                                                                                 
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes                                                                                                                                         
13:42:36.014758 IP (tos 0x0, ttl 128, id 30898, offset 0, flags [none], proto UDP (17), length 42)                                                                                                                               
    10.0.0.201.3804 > 255.255.255.255.3804: [udp sum ok] UDP, length 14                                                                                                                                                          
13:43:08.230199 IP (tos 0x0, ttl 128, id 31021, offset 0, flags [none], proto UDP (17), length 42)                                                                                                                               
    10.0.0.201.3804 > 10.0.1.201.3804: [udp sum ok] UDP, length 14                                                                                                                                                               
13:43:08.230351 IP (tos 0x0, ttl 127, id 31021, offset 0, flags [none], proto UDP (17), length 42)                                                                                                                               
    10.0.0.201.3804 > 10.0.1.201.3804: [udp sum ok] UDP, length 14                                                                                                                                                               
^C                                                                                                                                                                                                                               
3 packets captured                                                                                                                                                                                                               
3 packets received by filter                                                                                                                                                                                                     
0 packets dropped by kernel                                                                                                                                                                                   

where you can see again that a broadcast isn't relayed. For reference purposes, a unicast test packet to the same port is recognized by tcpdump on both interfaces.

 

Any more ideas?

 

Thanks,

Dennis

New Member
Posts: 25
Registered: ‎07-31-2016
Kudos: 5

Re: Multicast, Sonos, Phorus & Play-Fi Broadcast 255.255.255.255:<port> Discovery Solution

@britannic

 

I just had another idea. I connected my two devices to the ports eth3 and eth4 of my router and configured them as switch0 and added the switch interface to be another bcast-relay interface.

 

interfaces {                                                                                                                                                
........
    loopback lo {
    }
    switch switch0 {
        address 10.1.0.1/24
        mtu 1500
        switch-port {
            interface eth3 {
            }
            interface eth4 {
            }
            vlan-aware disable
        }
    }
}
service {
    bcast-relay {
        id 1 {
            description "desired forwarding 3804"
            interface eth0
            interface eth1
            interface switch0
            port 3804
        }

As I understand it, a broadcast should then be delivered directly to the test receiving device, because it's in the same layer3 subnet, and additionally the broadcast should be relayed to the other interfaces configured in the bcast-relay, eth3 and eth4.

 

But as I could observe, the broadcast was only captured once on the switch0 interface, it wasn't captured more than once on the other configured interfaces eth3 and eth4.

 

ubnt@EdgeRouterDSM25:~$ sudo tcpdump -i any -n dst port 3804 -vv                                                                                            
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes                                                                    
13:56:21.729458 IP (tos 0x0, ttl 128, id 4475, offset 0, flags [none], proto UDP (17), length 42)                                                           
    10.1.0.201.3804 > 255.255.255.255.3804: [udp sum ok] UDP, length 14                                                                                     
^C                                                                                                                                                          
1 packet captured                                                                                                                                           
1 packet received by filter                                                                                                                                 
0 packets dropped by kernel

Maybe this helps.

 

Thanks!!

Established Member
Posts: 1,408
Registered: ‎10-01-2014
Kudos: 695
Solutions: 66

Re: Multicast, Sonos, Phorus & Play-Fi Broadcast 255.255.255.255:<port> Discovery Solution

It doesn't help, as a switch doesn't need a bcast relay (unless VLAN segmentation required it). I'm out of ideas at this point. 

Please help the community find useful posts and solutions by using the "Kudos" and "Accept as Solution" buttons!
New Member
Posts: 25
Registered: ‎07-31-2016
Kudos: 5

Re: Multicast, Sonos, Phorus & Play-Fi Broadcast 255.255.255.255:<port> Discovery Solution

@britannic

 

By using the switch interface I just wanted to check wether the problem really is the bcast-relay function itself oder anything else, but unfortunately it seems to be.

 

Nevertheless I thank you one last time for your huge amount of support, your help, your great introductions and the amazing work you did in this thread for all the users!!!

 

Best regards,

Dennis

New Member
Posts: 25
Registered: ‎07-31-2016
Kudos: 5

Re: Multicast, Sonos, Phorus & Play-Fi Broadcast 255.255.255.255:<port> Discovery Solution

For anyone else out there, who has similar problems like me to get things managed to work in that case and no further ideas how to troubleshoot, here's what I just did. It's not a solution as nice as it would be when the bcast-relay would work fine on my EdgeRouter, but at least it works at all now:

 

I use a combination of EdgeSwitch Lite and EdgeRouter. I want to forward limited broadcasts from one vlan into another for devices to connect to each other, but I also want to apply firewall policies for the unicast traffic between the vlans.

 

What I just did is configuring the 'ip helper' functionality on EdgeSwitch, described in the EdgeSwitch CLI Command Reference on pages 349-354. I've set up routing interfaces on EdgeSwitch for each vlan, the one where the broadcast is sent, and the one(s) it should be received. After that I configured the ip helper functionality to forward incoming udp broadcasts on a certain port in the first vlan to be relayed to the second vlan, which works absolutely fine.

 

Furthermore I created an IP Access Control List (see EdgeSwitch CLI Command Reference on pages 390-398) to let only those relayed broadcasts pass through the routing interface of EdgeSwitch, no other traffic. If then all your client devices have the EdgeRouter configured as their standard gateway, not the routing interface of the EdgeSwitch, then it's nicely possible to apply all firewall policies to all the unicast-traffic, you like to.

 

Hope that's helpful to anyone who has had similar problems...

 

If anyone has further questions to this compromise solution, you're welcome to pm to me...

 

Best regards,

Dennis

New Member
Posts: 36
Registered: ‎12-18-2013
Kudos: 1
Solutions: 2

Re: Multicast, Sonos, Phorus & Play-Fi Broadcast 255.255.255.255:<port> Discovery Solution

F**king Brilliant!  apologies for the language, but this was driving me nuts...

Member
Posts: 146
Registered: ‎08-10-2015
Kudos: 9
Solutions: 3

Re: Multicast, Sonos, Phorus & Play-Fi Broadcast 255.255.255.255:<port> Discovery Solution

Does anyone know if applying this same procedure to the USG instead of an edge switch will work?  More importantly, will it break anything if I try to do this to the USG?

 

My hardware:

Model:       UniFi-Gateway-3
Version:     4.3.33.4936086
MAC Address: 80:2a:a8:xx:xx:xx
IP Address:  73.15.135.55
Hostname:    USG
Uptime:      146604 seconds

Status:      Connected
Emerging Member
Posts: 68
Registered: ‎05-07-2016
Kudos: 19
Solutions: 5

Re: Multicast, Sonos, Phorus & Play-Fi Broadcast 255.255.255.255:<port> Discovery Solution

Hi @britannic ,

I was looking for a solution to multicast between VLANs issue and found this thread.

Downloaded the script and did all the steps but not working, so I give it a try running it by hand to see the debug or more logs and I have this:

/opt/vyatta/sbin/udp-bcast-relay: /opt/vyatta/sbin/udp-bcast-relay: cannot execute binary file

 

The file has +x permissions so I'm guessing if it's maybe something that only work on ERL and same platforms?

I'm trying on a ER-X SFP, different CPU etc. than the ERL.

 

Is it supposed to work on ER-X too? Already tested or had feedbacks about that? (Google doesn't have answers for "udp-bcast-relay: cannot execute binary file", so I assume nobody had this before or they didn't posted it).

 

Happy to hear from you if it's just because of the platform or any other reasons crossing your mind.

Established Member
Posts: 1,408
Registered: ‎10-01-2014
Kudos: 695
Solutions: 66

Re: Multicast, Sonos, Phorus & Play-Fi Broadcast 255.255.255.255:<port> Discovery Solution

Yes, the ER-X has a different CPU architecture and thus an incompatible binary format, see this link.

Please help the community find useful posts and solutions by using the "Kudos" and "Accept as Solution" buttons!
Emerging Member
Posts: 68
Registered: ‎05-07-2016
Kudos: 19
Solutions: 5

Re: Multicast, Sonos, Phorus & Play-Fi Broadcast 255.255.255.255:<port> Discovery Solution

Sorry for the basic question but ... crosscompiling isn't something I master at all ...

 

So if I get it right the archive (http://community.ubnt.com/ubnt/attachments/ubnt/EdgeMAX/67208/1/ubnt-bcast-relay.tgz) can't work on ER-X.

 

Based on the thread you linked I understand it would need to be compiled again using that "mipsel" thing, right?

 

And for that it would require the sources I guess and an environment to compile it and end up with a new archive containing the new binaries/udp-bcast-relay file.

 

So I guess I'm looking for the sources now.

Based on link found here and on your GitHub I will look into https://github.com/nomeata/udp-broadcast-relay/ and see what I end up with (what a lovely topic for the weekend Man Very Happy )

Established Member
Posts: 1,408
Registered: ‎10-01-2014
Kudos: 695
Solutions: 66

Re: Multicast, Sonos, Phorus & Play-Fi Broadcast 255.255.255.255:<port> Discovery Solution

[ Edited ]

Correct, I compiled the binary for the mips64 big endian byte order CPU architecture, whereas the ER-X uses mips32el, which is little endian, so it cannot run without errors. You will actually need a gcc tool chain that can cross compile mipsel on a Linux system (the ER-X doesn't have enough space and is also pretty slow for compilation in any case). There are some preassembled/compiled tool chains that can do the job, here's a link to a Google search that may be helpful. There may also be a forum member who has a tool chain environment ready to go that can help out, might be worth a new thread requesting that?

Please help the community find useful posts and solutions by using the "Kudos" and "Accept as Solution" buttons!
Established Member
Posts: 1,408
Registered: ‎10-01-2014
Kudos: 695
Solutions: 66

Re: Multicast, Sonos, Phorus & Play-Fi Broadcast 255.255.255.255:<port> Discovery Solution

@spoon25, although this is for a different package, this github link has some good tips on building a cross compilation environment on a Linux system for an ER-X target. 

Please help the community find useful posts and solutions by using the "Kudos" and "Accept as Solution" buttons!
Reply