Fast Question
Have a "UDP IN" node, work fine but need detect is packet received is broadcast or not. Is possible?
Detailed question
Need know when udp packet received is unicast or broadcast, at this moment udp node send equal msg for booth packets (unicast and broadcast), this picture show equal result, each packet is attached to wireshark packet.
This test run on Raspberry PI2 but is only for this example.
27 Mar 12:13:51 - [info] Node-RED version: v4.0.9
27 Mar 12:13:51 - [info] Node.js version: v20.19.0
27 Mar 12:13:51 - [info] Linux 6.1.21-v7+ arm LE
27 Mar 12:13:52 - [info] Loading palette nodes
27 Mar 12:13:55 - [info] Dashboard version 3.6.5 started at /
27 Mar 12:13:57 - [info] Settings file : /home/admin/.node-red/settings.js
27 Mar 12:13:57 - [info] Context store : 'default' [module=memory]
27 Mar 12:13:57 - [info] User directory : /home/admin/.node-red
27 Mar 12:13:57 - [warn] Projects disabled : editorTheme.projects.enabled=false
27 Mar 12:13:57 - [info] Flows file : /home/admin/.node-red/flows.json
27 Mar 12:13:57 - [warn] Encrypted credentials not found
Why do I need to detect if it is broadcast?:
My idea is if packet received is broadcast, need reply for broadcast, but if packet is received for unicast need send reply for unicast
BroadcastReceived->Broadcast Reply (Important when subnet not match)
UnicastReceived->Unicast Reply (It is used when there are routings)
My suggestion:
Set msg.ip to "Dst IP" instead "Src IP"
In typical networks, especially in enterprise environments like the one I work in, broadcast packets are typically directed to a specific port. Clients that expect to receive broadcasts will listen on designated ports.
For instance, in the case of DHCP, the server is specifically set up to listen for client requests (sent via broadcast) on port 67.
Broadcast traffic should always be sent to a dedicated port and not mixed with unicast traffic to avoid confusion and potential performance issues.
Therefore, I would suggest keeping broadcast to specific port (and therefore a UDP Node, setup for that port)
if expecting unicast, it should not use the same port
In this case not is possible change broadcast port, the app client is a enterprise app and don't have source code.
I understand that my proposal isn't harmful in any way, and it would help to easily distinguish between broadcast and non-broadcast.
There's also the "fromIP" property, so it doesn't make sense for both properties to give the same IP address.
This is my point of view, and I'd like to discuss it with the goal of improving this fantastic nodeRed that I love so much.
I'm sorry if my English level is that of a preschooler
Unfortunately, the Node.js dgram module's rinfo object, as provided in the message event, and it does not directly expose the destination IP address of the incoming packet
Proof:
This is what is received in the dgram servers on message event handler when it received a broadcast message (and it matches the very latest docs (linked above)):
The operating system's networking stack handles the delivery of UDP packets to the appropriate socket. By the time node (node-red) receives the message event, the OS has already determined the packet is for your socket's bound address.
NOTE: there may be some dgram server options or hacks that can get to the dst address (but I dont think so).
You could use a packet sniffing library (like pcap) to capture raw network packets. This would allow you to inspect the entire IP header and retrieve the destination (dst) IP address.
There is a node named node-red-contrib-pcap but I have not tried it.
I liked the solution, libpcap to the rescue! try it out this week. I understand that the application layer doesn't receive the destination IP address, making it impossible for dgram to expose it in the rinfo module.
Marcus-J-Davies' strategy of using two different ports would have been the right approach, as it would allow detection without having to go below the application layer. Thanks for reply!
