Cool technology often comes at a cost, and it’s not always that this cost is justified. For instance, [Rainfay] tells us about how the the ArtNet protocol’s odd design choices are causing incompatibility with certain Ethernet switches. ArtNet is a protocol for lighting control over DMX-512 – simply put, it allows you to blink a whole ton of LEDs, even literally. Unlike DMX-512 which can use different physical mediums, ArtNet uses Ethernet, taking form of the usual kind of network packets – and it does seem to do a great job about that, if it weren’t for this one thing.
For some reason, ArtNet connections are required to use the same destination and source port – unlike the usual network traffic, where the destination port is protocol-dependent and the source port is randomized. This behaviour violates RFCs, and not just in an abstract manner – such behaviour is indicative of certain kinds of attacks, that switches on the smart side are able and are supposed to prevent. As a result, ArtNet traffic actually triggers some protections on switches at the fancier end, specifically, so-called BLAT protection.
In short, if your ArtNet stream is mysteriously not going through and your switch is on the fancier side, [Rainfay] says you might need to disable some security mechanisms. Sadly, as she points out, this problem isn’t even a direct consequence of some inherent property of ArtNet, but merely a consequence of a bizarre design choice. Once you’re done disabling protections, however, do check out some ArtNet projects for inspiration – it’s a genuinely useful protocol supported in a ton of fancy software, and it might be that you want to use it in the firmware of your RGB strip controller board!
Does traffic actually need to follow that rule, or do manufacturers just ignore it? I’ve only used it with Arduino based implementations and never heard of it before, and it seems rather pointless.
It’s widely used in the professional lighting industry. Became increasingly popular when the limitations of DMX became overwhelming, like when you need to control a lot of LEDs separately.
I think they were referring to the pointlessness of the requirement for the ports to be the same, not the protocol itself.
These rules are just recommendations. Good for internet connections, not needed for isolated networks. Art-Net isn’t designed to co-exist with general purpose IP networking on the same medium.
ArtNet is basically obsolete. sACN has replaced it in just about any professional application. Only very old hardware will only support artnet. sACN has some technical advantages but being non proprietary is just about reason enough.
It’s quite common to have UDP with source and destination port being equal, for example NTP. I’m surprised this switch doesn’t cause more problems.
You could try switching to sACN too. Same purpose, better protocol.
The importance of source port randomization is a newer thing, it came to light a decade or two ago because of the DNS spoofing exploits. Basically, the consensus was that any benefits of predictable source ports (using a source port below 1024 requires root, so it was supposed to be “safer” by keeping out the riffraff) was far outweighed by the real world drawbacks, as it made udp spoofing attacks straightforward.
So the old protocols get retrofitted with random source ports and we officially declare predicable source ports to be stupid, and tell people to quit it.
What if RNG randomly generates same source port as destination port? It’s not completely unlikely… :-D unless handled in code obviously…
Well, since most, but not all, destination services have destination port addresses below 1025 and the source port number is random generated from 1025 to 65534 that won’t happen often.
The cited RFCs specifically refer to TCP, not UDP. As you say, it’s very common indeed for a connectionless protocol such as UDP to have a single widely-advertised port.
We’ve mostly moved on to sACN in the production world. Media servers and Resolute are about the only things that I see use it anymore.