Linux: Art-Net IPv4 packets not received

[Pac72]

Describe the bug While starting to investigate on #1419 I realized I was not receiving Art-Net packets sent to my IPv4 address. Investigating on the new issue, I saw that when binding the UDP socket with udpSocket->bind(ARTNET_PORT, QUdpSocket::ShareAddress | QUdpSocket::ReuseAddressHint)

netstat showed only an IPv6 bind

netstat -pnul | grep 6454 (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) udp6 0 0 :::6454 :::* 50071/qlcplus

and strace on the process showed

socket(AF_INET6, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 4 setsockopt(4, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0 setsockopt(4, SOL_IPV6, IPV6_RECVPKTINFO, [1], 4) = 0 setsockopt(4, SOL_IPV6, IPV6_RECVHOPLIMIT, [1], 4) = 0 setsockopt(4, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 setsockopt(4, SOL_IPV6, IPV6_V6ONLY, [0], 4) = 0 bind(4, {sa_family=AF_INET6, sin6_port=htons(6454), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::", &sin6_addr), sin6_scope_id=0}, 28) = 0 getsockname(4, {sa_family=AF_INET6, sin6_port=htons(6454), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::", &sin6_addr), sin6_scope_id=0}, [28]) = 0 getsockopt(4, SOL_IPV6, IPV6_V6ONLY, [0], [4]) = 0 getpeername(4, 0x7ffc645dde20, [28]) = -1 ENOTCONN (Transport endpoint is not connected) getsockopt(4, SOL_SOCKET, SO_TYPE, [2], [4]) = 0

Replacing the bind with udpSocket->bind(QHostAddress::SpecialAddress::AnyIPv4, ARTNET_PORT, QUdpSocket::ShareAddress | QUdpSocket::ReuseAddressHint)

solves the problem and qlcplus receives the UDP packets regularly.

In this case netstat shows only an IPv4 binding

netstat -pnul | grep 6454 (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) udp 0 0 0.0.0.0:6454 0.0.0.0:* 22208/qlcplus

and strace shows

socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 4 setsockopt(4, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0 setsockopt(4, SOL_IP, IP_PKTINFO, [1], 4) = 0 setsockopt(4, SOL_IP, IP_RECVTTL, [1], 4) = 0 setsockopt(4, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 bind(4, {sa_family=AF_INET, sin_port=htons(6454), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 getsockname(4, {sa_family=AF_INET, sin_port=htons(6454), sin_addr=inet_addr("0.0.0.0")}, [28 => 16]) = 0 getpeername(4, 0x7ffccc1f13a0, [16]) = -1 ENOTCONN (Transport endpoint is not connected) getsockopt(4, SOL_SOCKET, SO_TYPE, [2], [4]) = 0

To Reproduce Steps to reproduce the behavior:

1. Go to Inputs/Outputs, Universe 1, select a reachable IP as ArtNet input, a DMX USB device as Output and then select Passthrough
2. Stream ArtNet data changing some channel values
3. All the channels on the output device remains at 0

Expected behavior qlcplus receives the Art-Net UDP stream and, when configured with passthrough, sends it on an output, for instance a DMX USB device.

Screenshots N.A.

Desktop (please complete the following information):

• OS: Linux Ubuntu 22.04 LTS
• QLC+ Version: master, commit 3424652 - Qt 5.15.2
  • hardware setup: a PC with wifi + ethernet + some bridge interfaces; DMX device: Future Technology Devices International, Ltd FT232 Serial (UART) IC

Additional context N.A.

[Pac72]

The easy fix proposed with #1589 fixes IPv4 but, of course, breaks IPv6

As stated on the pull request, a more complicated approach is to create several sockets, one for each input address, and bind them to their specific address.

[Pac72]

qlcplus 4.13.1 on Windows 11 and qlcplus 4.12.7 on Mac seem to work out of the box.

Anyway, my first test on Windows went crazy. At the beginning the passthrough was not working (all output fixed to 0), then I started activating/deactivating passthrough, enabling/disabilng Artnet inputs and outputs (thinking I was facing #1419), fiddling with Simple Desk, adding some dimmers and went on trying different things. Don't know how, I started to see at the output the Artnet inputs together with other (few) random channel values appearing both at the output and on Simple Desk - Black Out zeroed everything but going back to normal resulted in random values coming back. I then zeroed all the inputs on Artnet and on Simple Desk and opened the Fixture Monitor: random values were also showing there. I then restarted to do a clean test from the beginning and... everything worked as expected :-/

Note that I'm checking Artnet with Wireshark to be sure the problem is not on the source (this controller on an Android phone) and monitor the output of the DMX USB adapter with an oscilloscope (I don't have fixtures available).

I'll go on testing.