You can build the daemon either under CodeBlocks (using the .cbp file provided in the root) or using the makefile located in the jacknetumpd subfolder
In my case, I use NetBeans IDE to compile the daemon remotely on the Zynthian itself (but I think you can use directly the makefile from CLI, as NetBeans simply upload them and launch them remotely)
I have found the Makefile (I don’t know why it eluded me before) but it fails because it looks for ../../../../../SDK/beb/common_src/CThread.cpp which takes it beyond the root directory! I cloned the three repos into the root home directory on the zynthian and run make from command line whilst within the jacknetumpd/jacknetumpd directory.
Hi @riban
from your previous message, I assume you managed to compile the daemon. Am I right ?
By the way, I have updated the github to provide more detailed explanations about the process to compile the file. This may be helpful to others
Benoit
Nope! I can’t compile it. I get errors and am still not clear on the compile process.
I will try to create a makefile tomorrow. On your side, maybe you can ask to @jofemodo how he deals with the compilation for the Zynthian (as far as I know, he compiles the daemon locally, and does not use the compiled binary available on my Git)
Hi @BEB,
I found what looks like a startup race / unchecked ioctl error in jacknetumpd.
After boot, Bome Network discovered my Zynthian Network MIDI 2.0 endpoint as:
Zynthian V5
with the incorrect address:
103.94.26.203:5504
while the real Ethernet address of the Zynthian was:
192.168.88.194
The machine has:
eth0 = 192.168.88.194/24
wlan0 = DOWN
and jacknetumpd listens on UDP port 5504.
The interesting part is that the Ethernet MAC address is:
2c:cf:67:5e:1a:cb
and the invalid advertised IPv4 address:
103.94.26.203
corresponds exactly to the last four bytes of that MAC address:
67 5e 1a cb -> 103.94.26.203
Looking at UMP_mDNS.cpp, initUMP_mDNS() first uses the same struct ifreq ifr to read the MAC address of eth0 using SIOCGIFHWADDR, and later reuses it for SIOCGIFADDR. The return value of ioctl(SIOCGIFADDR) is not checked.
My assumption is that when jacknetumpd starts before IPv4 is assigned to eth0, SIOCGIFADDR fails and the previous contents of ifr remain. The code then interprets part of the MAC-address data as sin_addr, which produces exactly the bogus address seen above.
This also seems consistent with the current systemd unit:
After=networking.service
but there is no explicit guarantee that eth0 already has its IPv4 address when jacknetumpd starts.
Reproduction / confirmation
After the system was fully up, I restarted only:
sudo systemctl restart jacknetumpd
After that, the Network MIDI 2.0 mDNS advertisement contained the correct address:
192.168.88.194
I also captured the _midi2 multicast packets directly. Packets sent by 192.168.88.194 contained:
192.168.88.194 = True
103.94.26.203 = False
Bome initially retained both addresses because it had cached the previous discovery record. After forgetting the old endpoint and reconnecting the newly discovered one, Network MIDI 2.0 communication worked correctly again to:
192.168.88.194:5504
Possible fix
At minimum, check the return value of:
ioctl(mDNSSocket, SIOCGIFADDR, &ifr)
before building the mDNS A record.
It might also be useful to initialise/clear ifr before each ioctl, and possibly delay/retry mDNS initialisation until eth0 actually has a valid IPv4 address.
Let me know if you want me to test a patched binary on the Zynthian.
Regards,
ToFF - Tomas /with assisted AI help/
