First off, thanks for writing such a great library. I looked around at everything out there, and this one is by far the most complete.
I'm working on a power logger that simultaneously reads two 12-bit ADCs at a time, applies true RMS to the stream of data, and sends it to a host over OSC. I'm using the Teensy4's NativeEthernet lib. I renamed NativeEthernet's mDNS class to avoid any namespace conflicts. I updated the includes in the .cpp and the example sketch to point to the NativeEthernet* libs, and it builds fine.
Announcement works with no further modification, however, name lookups fail. I suspect it's in part to the NativeEthernet library using the Arduino's IPAddress.h which defines a class which holds an IP address, rather than the four byte[4] array.
Here's what I've done for testing so far. I'm running a Linux/Ubuntu 20.04 desktop, avahi-daemon 0.7, Arduino 1.8.15. The Teensy4 is attached directly to the second ethernet port. I'm running dnsmasq as a DHCP and DNS server, logs tailed in console. Wireshark capturing traffic for that interface.
Running the stock ResolvingHostNames sketch, I can see the mDNS query go out, and the response come back from the Linux box. I did some tracing, and verified that the response packet is indeed being grocked by _processMDNSQuery(), however when it calls _finishedResolvingName(), for whatever reason, the IP it returns is NULL, and the demo sketch claims resolution has timed out. It does this for every response (as if it's trying to report the address it was sent in each reply), not just when the timeout expires.
The interface the Teensy is attached to only has one IPv4 address, no IPv6. I did eliminate one bug which may or may not make a difference. The Arduino IDE's serial console defaults to sending a linefeed (NL) even when you click the 'send' button. This character gets sent in the mDNS query, which is visible in Wireshark as remotehost\n.local. I added a simple fix, which I'll send along as a patch in a little bit.
Lastly, I intend to eventually call .run() from a thread using the TeensyThreads library. Are there any parts of this code I have to worry about thread safety? Thanks for taking a look!
First off, thanks for writing such a great library. I looked around at everything out there, and this one is by far the most complete.
I'm working on a power logger that simultaneously reads two 12-bit ADCs at a time, applies true RMS to the stream of data, and sends it to a host over OSC. I'm using the Teensy4's NativeEthernet lib. I renamed NativeEthernet's mDNS class to avoid any namespace conflicts. I updated the includes in the .cpp and the example sketch to point to the NativeEthernet* libs, and it builds fine.
Announcement works with no further modification, however, name lookups fail. I suspect it's in part to the NativeEthernet library using the Arduino's IPAddress.h which defines a class which holds an IP address, rather than the four byte[4] array.
Here's what I've done for testing so far. I'm running a Linux/Ubuntu 20.04 desktop, avahi-daemon 0.7, Arduino 1.8.15. The Teensy4 is attached directly to the second ethernet port. I'm running dnsmasq as a DHCP and DNS server, logs tailed in console. Wireshark capturing traffic for that interface.
Running the stock ResolvingHostNames sketch, I can see the mDNS query go out, and the response come back from the Linux box. I did some tracing, and verified that the response packet is indeed being grocked by _processMDNSQuery(), however when it calls _finishedResolvingName(), for whatever reason, the IP it returns is NULL, and the demo sketch claims resolution has timed out. It does this for every response (as if it's trying to report the address it was sent in each reply), not just when the timeout expires.
The interface the Teensy is attached to only has one IPv4 address, no IPv6. I did eliminate one bug which may or may not make a difference. The Arduino IDE's serial console defaults to sending a linefeed (NL) even when you click the 'send' button. This character gets sent in the mDNS query, which is visible in Wireshark as
remotehost\n.local. I added a simple fix, which I'll send along as a patch in a little bit.Lastly, I intend to eventually call .run() from a thread using the TeensyThreads library. Are there any parts of this code I have to worry about thread safety? Thanks for taking a look!