node-red in Docker not receiving UDP Multicast packets

1,990 views
Skip to first unread message

Cameron Burrows

unread,
Feb 12, 2018, 7:23:45 AM2/12/18
to Node-RED
Hey guys,

I've got node-red installed in a docker container on my QNAP nas and it works with the most basic flows (from getting started).
I'm trying to listen for multicast packets from 224.0.0.50 on both ports 4321 and 9898, but node-red is not receiving them.

I used the following command to create my container.
# docker run -d -p 1880:1880 --name="node-red" -e TZ="Australia/Melbourne" --net=host nodered/node-red-docker

I've recreated my container explicitly exposing udp ports 9898 and 4321, but this hasn't changed anything.
# docker run -d -p 1880:1880 -p 4321:4321/udp -p 9898:9898/udp --name="node-red2" -e TZ="Australia/Melbourne" --net=host nodered/node-red-docker

My networking skills are rudimentary at best, but I'm trying to narrow down where the issue lies.

Wireshark doesn't show udp packets on 224.0.0.50 on either port.
It only shows packets on 224.0.0.251 on port 5353.

However, I've run Multicast Tester on my android phone and can see the relevant traffic.

I've entered the console of the container and installed tcpdump and run using:
# tcpdump port 9898 or port 4321 -vv -w dump.pcap

Copying the file to the host, I can see the guest is receiving the packets. 
I cannot work out why is node-red not receiving them.

My test flow is extremely basic.
[{"id":"24b9b852.1752e8","type":"tab","label":"Flow 1","disabled":false,"info":""},{"id":"8c505884.8c0bf8","type":"udp in","z":"24b9b852.1752e8","name":"","iface":"","port":"9898","ipv":"udp4","multicast":"true","group":"224.0.0.50","datatype":"utf8","x":240,"y":140,"wires":[["2f83a03.3e3e16"]]},{"id":"2f83a03.3e3e16","type":"debug","z":"24b9b852.1752e8","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":470,"y":140,"wires":[]},{"id":"6aa48398.cd415c","type":"udp in","z":"24b9b852.1752e8","name":"","iface":"","port":"4321","ipv":"udp4","multicast":"true","group":"224.0.0.50","datatype":"utf8","x":240,"y":200,"wires":[["2f83a03.3e3e16"]]},{"id":"7375ae5b.2e5cb","type":"udp in","z":"24b9b852.1752e8","name":"","iface":"","port":"5353","ipv":"udp4","multicast":"true","group":"224.0.0.251","datatype":"utf8","x":250,"y":260,"wires":[["2f83a03.3e3e16"]]}]

Is there something I'm not doing correctly?

Any help would be greatly appreciated.

Cam

Cameron Burrows

unread,
Feb 14, 2018, 5:18:26 AM2/14/18
to Node-RED
So I'm stumped.
I've installed 4 instances of node-red in my network. Every instance is connected to the Google Wifi.

Windows 10 laptop - cannot see the multicast through node-red or even wireshark
Docker on Qnap - can see multicast using tcpdump but not in node-red
Directly onto Qnap - can see multicast using tcpdump but not in node-red
Windows 10 mini pc - can finally see multicast in node-red

BTW, I'm not running tcpdump and node-red at the same time.
All instances have been able to see multicast traffic on 224.0.0.251 port 5353, just not 224.0.0.50 ports 4321 or 9898.

My android phone can see all multicast events using Multicast Tester.
Ideally I'd like to run in in a docker on my Qnap. Even though the Windows 10 mini pc is always on, it has a tendency to drop off the network after a windows update.

Any thoughts would still be greatly appreciated.

Cam

xbmcnut

unread,
Apr 12, 2018, 5:55:46 AM4/12/18
to Node-RED
Hey Cameron,

You make any progress with this? I've got NR on my Synology NAS in Docker with the container sharing the host network and also NR on Windows. Both instances fail to 'sniff' UDP packets on 224.0.0.50:9898. I'm trying to get NR talking to my Xiaomi Gateway.

Pete

Cameron Burrows

unread,
Apr 12, 2018, 6:24:41 AM4/12/18
to Node-RED
Hey Pete,

I gave up and decided on using the Raspberry Pi running node-red in a docker. Work without issues.
However, just tonight I thought I'd give it another go as I couldn't get a mongo container on the same rpi. I think it ran out of memory. So I'm thinking of giving it another go on the NAS.
Now that I have some success with the rpi I might have missed something silly.

Will let you know how I go.

Last night I noticed that my rpi couldn't communicate with the mongo container I setup on the NAS. The rpi could ping the NAS (192.168.86.20), but not the IP of the container (10.0.3.3). I'm thinking it could be due to the rpi's default gateway being the internet router, whereas I route my windows machine through the NAS which runs a VPN. The traceroute from the pi to the container ip bypasses the NAS and heads out to the internet.
My network skills are basic at best.


Cam

xbmcnut

unread,
Apr 12, 2018, 6:29:55 AM4/12/18
to Node-RED
Thanks for the prompt reply Cam. Wonder why it works on the Pi using Docker and not the NAS? I've tried everything and I can't get any data to appear in the debug window. Heading to bed now. Let me know if you find anything out. Here is my run file.

docker run -it --net=host -p 1880:1880 --user root -v /volume1/docker/node-red/:/data --name nasnodered nodered/node-red-docker

Dave C-J

unread,
Apr 12, 2018, 7:14:17 AM4/12/18
to node...@googlegroups.com

Cameron Burrows

unread,
Apr 12, 2018, 7:21:06 AM4/12/18
to Node-RED
Hey Dave, you shouldn't have to, but happy to be corrected.

I've just got it up and running again on the nas and the xiaomi gateway node shows as offline. 
The rpi shows it online. I didn't explicitly expose ports there, but it was a prebuilt image (hypriot).

Setting up the udp node (on the nas) to listen on 224.0.0.251 on port 5353 shows a heap of traffic coming in but it's not the right traffic.

But I did try explicitly allowing the udp ports when I first tried.
# docker run -d -p 1880:1880 -p 4321:4321/udp -p 9898:9898/udp --name="node-red2" -e TZ="Australia/Melbourne" --net=host nodered/node-red-docker

cheers,

Cam

Timur Fatykhov

unread,
Apr 12, 2018, 8:39:32 AM4/12/18
to Node-RED
It should work if you define net=host in docker container start command. Without that there is a more complex solution with custom routing but I am not sure it worth exploration.

Cameron Burrows

unread,
Jun 9, 2018, 3:16:51 AM6/9/18
to Node-RED
Hey all,

I've finally come up with a solution.

I believe that the issue is that the QNAP isn't forwarding on the UDP messages. I could get TCPDump to see the UDP messages, but from what I've read, TCPDump reads directly from the NIC and before any routing (netfilter/iptables).
My investigation of the iptables on the QNAP wasn't fruitful. I tried to make it look like the RPI's iptables but no dice. I've read contradicting reports about iptables on the QNAP.

I ended up finding a nodejs and then node-red pcap node "node-red-contrib-pcap" to capture and decode network packets using libpcap.

It wasn't the easiest to get this installed as you need a heap of other dependencies.
But once I got it, I could see the UDP packets from within node-red.

The message content I needed was many layers deep, but I was able to extract them. So I can now receive events from my Xiaomi devices.
Because the Xiaomi node isn't seeing the UDP packets, I'm not able to interact directly with the Gateway.

So, to get this working in an Alpine docker container for QNAP (and maybe Synology) a combination of these steps were taken:
# apk add --no-cache git
# apk add --no-cache --virtual .build-deps make gcc g++ python
# apk add --no-cache libpcap-dev
# npm install socketwatcher
# npm install pcap2
# npm install node-red-contrib-pcap

Check out the pages - as there are some tricks to getting pcap2 and node-red-contrib-pcap to compile.

Once you have the pcap node installed in node-red, use the following settings.
You may need to play around to see what worked. 
This worked for me:
Interface: br0
Output: Decoded pcap Object
Filter: port 4321
Path: left blank

Use a function node:
let pcap = msg.payload;
msg.payload = JSON.parse(pcap.payload.payload.payload.data.toString());  // that is no typo. the content may be within multiple nested payloads
return msg;

I hope this helps someone out as it's frustrated me for months.
Now to decide if I roll my own Xiaomi node or not.

Cheers,

Cam
Reply all
Reply to author
Forward
0 new messages