DNS-SD PTR record ill formed on Pluto... #1072
Comments
rgetz
changed the title
rgetz
added a commit
to rgetz/libiio
that referenced
this issue
Oct 29, 2023
In the past, we were only checking hostname, as a way to see if the network was ready, but unfortantely - that doesn't work. The kernel really only needs to have a hostname set for uname() to work, which is what glibc and uclibc actaully do in gethostname(). So - now we actualyl check there is a working, configured ethernet card, that supports mdns (ie multicast) that is up before moving on to making sure there is a hostname. We also don't allow "none" or "(none)" to be the hostname until after things time out (3 min). This fixes analogdevicesinc#1072 and turns: 192.168.2.1:5353 : answer _iio._tcp.local. PTR "iiod on (none)._iio._tcp.local." rclass 0x1 ttl 10 length 17 into: 192.168.2.1:5353 : answer _iio._tcp.local. PTR "iiod on pluto._iio._tcp.local." rclass 0x1 ttl 10 length 16 Signed-off-by: Robin Getz <[email protected]>
|
with the fix in #1080 - things seems to be working: and when things get merged - I will close. |
rgetz
added a commit
to rgetz/libiio
that referenced
this issue
Oct 30, 2023
In the past, we were only checking hostname, as a way to see if the network was ready, but unfortantely - that doesn't work. The kernel really only needs to have a hostname set for uname() to work, which is what glibc and uclibc actaully do in gethostname(). So - now we actualyl check there is a working, configured ethernet card, that supports mdns (ie multicast) that is up before moving on to making sure there is a hostname. We also don't allow "none" or "(none)" to be the hostname until after things time out (3 min). This fixes analogdevicesinc#1072 and turns: 192.168.2.1:5353 : answer _iio._tcp.local. PTR "iiod on (none)._iio._tcp.local." rclass 0x1 ttl 10 length 17 into: 192.168.2.1:5353 : answer _iio._tcp.local. PTR "iiod on pluto._iio._tcp.local." rclass 0x1 ttl 10 length 16 Signed-off-by: Robin Getz <[email protected]>
rgetz
added a commit
to rgetz/libiio
that referenced
this issue
Oct 30, 2023
In the past, we were only checking hostname, as a way to see if the network was ready, but unfortunately - that doesn't work. The kernel really only needs to have a hostname set for uname() to work, which is what glibc and uclibc implement in gethostname(). So - now we check there is a working, configured ethernet card, that supports mdns (ie. multicast) that is up before moving on to making sure there is a hostname. We also don't allow "none" or "(none)" to be the hostname until after things time out (3 min). This fixes analogdevicesinc#1072 and turns: 192.168.2.1:5353 : answer _iio._tcp.local. PTR "iiod on (none)._iio._tcp.local." rclass 0x1 ttl 10 length 17 into: 192.168.2.1:5353 : answer _iio._tcp.local. PTR "iiod on pluto._iio._tcp.local." rclass 0x1 ttl 10 length 16 Signed-off-by: Robin Getz <[email protected]>
rgetz
added a commit
to rgetz/libiio
that referenced
this issue
Nov 10, 2023
In the past, we were only checking hostname, as a way to see if the network was ready, but unfortunately - that doesn't work. The kernel really only needs to have a hostname set for uname() to work, which is what glibc and uclibc implement in gethostname(). So - now we check there is a working, configured ethernet card, that supports mdns (ie. multicast) that is up before moving on to making sure there is a hostname. We also don't allow "none" or "(none)" to be the hostname until after things time out (3 min). This fixes analogdevicesinc#1072 and turns: 192.168.2.1:5353 : answer _iio._tcp.local. PTR "iiod on (none)._iio._tcp.local." rclass 0x1 ttl 10 length 17 into: 192.168.2.1:5353 : answer _iio._tcp.local. PTR "iiod on pluto._iio._tcp.local." rclass 0x1 ttl 10 length 16 and when you have multiple on network (with same name): 192.168.1.110:5353 : answer _iio._tcp.local. PTR "iiod on pluto._iio._tcp.local." rclass 0x1 ttl 10 length 16 192.168.1.110:5353 : answer pluto.local. A 192.168.1.110 192.168.1.115:5353 : answer _iio._tcp.local. PTR "iiod on pluto analogdevicesinc#2._iio._tcp.local." rclass 0x1 ttl 10 length 19 192.168.1.115:5353 : answer pluto-2.local. A 192.168.1.115 Signed-off-by: Robin Getz <[email protected]>
rgetz
added a commit
to rgetz/libiio
that referenced
this issue
Nov 10, 2023
In the past, we were only checking hostname, as a way to see if the network was ready, but unfortunately - that doesn't work. The kernel really only needs to have a hostname set for uname() to work, which is what glibc and uclibc implement in gethostname(). So - now we check there is a working, configured ethernet card, that supports mdns (ie. multicast) that is up before moving on to making sure there is a hostname. We also don't allow "none" or "(none)" to be the hostname until after things time out (3 min). This fixes analogdevicesinc#1072 and turns: 192.168.2.1:5353 : answer _iio._tcp.local. PTR "iiod on (none)._iio._tcp.local." rclass 0x1 ttl 10 length 17 into: 192.168.2.1:5353 : answer _iio._tcp.local. PTR "iiod on pluto._iio._tcp.local." rclass 0x1 ttl 10 length 16 and when you have multiple on network (with same name): 192.168.1.110:5353 : answer _iio._tcp.local. PTR "iiod on pluto._iio._tcp.local." rclass 0x1 ttl 10 length 16 192.168.1.110:5353 : answer pluto.local. A 192.168.1.110 192.168.1.115:5353 : answer _iio._tcp.local. PTR "iiod on pluto analogdevicesinc#2._iio._tcp.local." rclass 0x1 ttl 10 length 19 192.168.1.115:5353 : answer pluto-2.local. A 192.168.1.115 Signed-off-by: Robin Getz <[email protected]>
rgetz
added a commit
to rgetz/libiio
that referenced
this issue
Nov 10, 2023
In the past, we were only checking hostname, as a way to see if the network was ready, but unfortunately - that doesn't work. The kernel really only needs to have a hostname set for uname() to work, which is what glibc and uclibc implement in gethostname(). So - now we check there is a working, configured ethernet card, that supports mdns (ie. multicast) that is up before moving on to making sure there is a hostname. We also don't allow "none" or "(none)" to be the hostname until after things time out (3 min). This fixes analogdevicesinc#1072 and turns: 192.168.2.1:5353 : answer _iio._tcp.local. PTR "iiod on (none)._iio._tcp.local." rclass 0x1 ttl 10 length 17 into: 192.168.2.1:5353 : answer _iio._tcp.local. PTR "iiod on pluto._iio._tcp.local." rclass 0x1 ttl 10 length 16 and when you have multiple on network (with same name): 192.168.1.110:5353 : answer _iio._tcp.local. PTR "iiod on pluto._iio._tcp.local." rclass 0x1 ttl 10 length 16 192.168.1.110:5353 : answer pluto.local. A 192.168.1.110 192.168.1.115:5353 : answer _iio._tcp.local. PTR "iiod on pluto analogdevicesinc#2._iio._tcp.local." rclass 0x1 ttl 10 length 19 192.168.1.115:5353 : answer pluto-2.local. A 192.168.1.115 Signed-off-by: Robin Getz <[email protected]>
pcercuei
pushed a commit
that referenced
this issue
Nov 13, 2023
In the past, we were only checking hostname, as a way to see if the network was ready, but unfortunately - that doesn't work. The kernel really only needs to have a hostname set for uname() to work, which is what glibc and uclibc implement in gethostname(). So - now we check there is a working, configured ethernet card, that supports mdns (ie. multicast) that is up before moving on to making sure there is a hostname. We also don't allow "none" or "(none)" to be the hostname until after things time out (3 min). This fixes #1072 and turns: 192.168.2.1:5353 : answer _iio._tcp.local. PTR "iiod on (none)._iio._tcp.local." rclass 0x1 ttl 10 length 17 into: 192.168.2.1:5353 : answer _iio._tcp.local. PTR "iiod on pluto._iio._tcp.local." rclass 0x1 ttl 10 length 16 and when you have multiple on network (with same name): 192.168.1.110:5353 : answer _iio._tcp.local. PTR "iiod on pluto._iio._tcp.local." rclass 0x1 ttl 10 length 16 192.168.1.110:5353 : answer pluto.local. A 192.168.1.110 192.168.1.115:5353 : answer _iio._tcp.local. PTR "iiod on pluto #2._iio._tcp.local." rclass 0x1 ttl 10 length 19 192.168.1.115:5353 : answer pluto-2.local. A 192.168.1.115 Signed-off-by: Robin Getz <[email protected]>
pcercuei
pushed a commit
that referenced
this issue
Nov 13, 2023
In the past, we were only checking hostname, as a way to see if the network was ready, but unfortunately - that doesn't work. The kernel really only needs to have a hostname set for uname() to work, which is what glibc and uclibc implement in gethostname(). So - now we check there is a working, configured ethernet card, that supports mdns (ie. multicast) that is up before moving on to making sure there is a hostname. We also don't allow "none" or "(none)" to be the hostname until after things time out (3 min). This fixes #1072 and turns: 192.168.2.1:5353 : answer _iio._tcp.local. PTR "iiod on (none)._iio._tcp.local." rclass 0x1 ttl 10 length 17 into: 192.168.2.1:5353 : answer _iio._tcp.local. PTR "iiod on pluto._iio._tcp.local." rclass 0x1 ttl 10 length 16 and when you have multiple on network (with same name): 192.168.1.110:5353 : answer _iio._tcp.local. PTR "iiod on pluto._iio._tcp.local." rclass 0x1 ttl 10 length 16 192.168.1.110:5353 : answer pluto.local. A 192.168.1.110 192.168.1.115:5353 : answer _iio._tcp.local. PTR "iiod on pluto #2._iio._tcp.local." rclass 0x1 ttl 10 length 19 192.168.1.115:5353 : answer pluto-2.local. A 192.168.1.115 Signed-off-by: Robin Getz <[email protected]> [pcercuei: change %d to %ld in print format string] Signed-off-by: Paul Cercueil <[email protected]>
pcercuei
pushed a commit
that referenced
this issue
Nov 13, 2023
In the past, we were only checking hostname, as a way to see if the network was ready, but unfortunately - that doesn't work. The kernel really only needs to have a hostname set for uname() to work, which is what glibc and uclibc implement in gethostname(). So - now we check there is a working, configured ethernet card, that supports mdns (ie. multicast) that is up before moving on to making sure there is a hostname. We also don't allow "none" or "(none)" to be the hostname until after things time out (3 min). This fixes #1072 and turns: 192.168.2.1:5353 : answer _iio._tcp.local. PTR "iiod on (none)._iio._tcp.local." rclass 0x1 ttl 10 length 17 into: 192.168.2.1:5353 : answer _iio._tcp.local. PTR "iiod on pluto._iio._tcp.local." rclass 0x1 ttl 10 length 16 and when you have multiple on network (with same name): 192.168.1.110:5353 : answer _iio._tcp.local. PTR "iiod on pluto._iio._tcp.local." rclass 0x1 ttl 10 length 16 192.168.1.110:5353 : answer pluto.local. A 192.168.1.110 192.168.1.115:5353 : answer _iio._tcp.local. PTR "iiod on pluto #2._iio._tcp.local." rclass 0x1 ttl 10 length 19 192.168.1.115:5353 : answer pluto-2.local. A 192.168.1.115 Signed-off-by: Robin Getz <[email protected]> [pcercuei: change %d to %ld in print format string] Signed-off-by: Paul Cercueil <[email protected]>
SRaus
pushed a commit
that referenced
this issue
Feb 27, 2024
In the past, we were only checking hostname, as a way to see if the network was ready, but unfortunately - that doesn't work. The kernel really only needs to have a hostname set for uname() to work, which is what glibc and uclibc implement in gethostname(). So - now we check there is a working, configured ethernet card, that supports mdns (ie. multicast) that is up before moving on to making sure there is a hostname. We also don't allow "none" or "(none)" to be the hostname until after things time out (3 min). This fixes #1072 and turns: 192.168.2.1:5353 : answer _iio._tcp.local. PTR "iiod on (none)._iio._tcp.local." rclass 0x1 ttl 10 length 17 into: 192.168.2.1:5353 : answer _iio._tcp.local. PTR "iiod on pluto._iio._tcp.local." rclass 0x1 ttl 10 length 16 and when you have multiple on network (with same name): 192.168.1.110:5353 : answer _iio._tcp.local. PTR "iiod on pluto._iio._tcp.local." rclass 0x1 ttl 10 length 16 192.168.1.110:5353 : answer pluto.local. A 192.168.1.110 192.168.1.115:5353 : answer _iio._tcp.local. PTR "iiod on pluto #2._iio._tcp.local." rclass 0x1 ttl 10 length 19 192.168.1.115:5353 : answer pluto-2.local. A 192.168.1.115 Signed-off-by: Robin Getz <[email protected]> [pcercuei: change %d to %ld in print format string] Signed-off-by: Paul Cercueil <[email protected]> (cherry picked from commit 38483f3)
SRaus
pushed a commit
that referenced
this issue
Feb 28, 2024
In the past, we were only checking hostname, as a way to see if the network was ready, but unfortunately - that doesn't work. The kernel really only needs to have a hostname set for uname() to work, which is what glibc and uclibc implement in gethostname(). So - now we check there is a working, configured ethernet card, that supports mdns (ie. multicast) that is up before moving on to making sure there is a hostname. We also don't allow "none" or "(none)" to be the hostname until after things time out (3 min). This fixes #1072 and turns: 192.168.2.1:5353 : answer _iio._tcp.local. PTR "iiod on (none)._iio._tcp.local." rclass 0x1 ttl 10 length 17 into: 192.168.2.1:5353 : answer _iio._tcp.local. PTR "iiod on pluto._iio._tcp.local." rclass 0x1 ttl 10 length 16 and when you have multiple on network (with same name): 192.168.1.110:5353 : answer _iio._tcp.local. PTR "iiod on pluto._iio._tcp.local." rclass 0x1 ttl 10 length 16 192.168.1.110:5353 : answer pluto.local. A 192.168.1.110 192.168.1.115:5353 : answer _iio._tcp.local. PTR "iiod on pluto #2._iio._tcp.local." rclass 0x1 ttl 10 length 19 192.168.1.115:5353 : answer pluto-2.local. A 192.168.1.115 Signed-off-by: Robin Getz <[email protected]> [pcercuei: change %d to %ld in print format string] Signed-off-by: Paul Cercueil <[email protected]> (cherry picked from commit 38483f3)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In iiod, we wait until host name is accessible (in a background thread), I thought that would mean that networking/dbus is ready, and then eventually start avahi
https://github.com/analogdevicesinc/libiio/blob/main/iiod/dns-sd.c#L257-L288
However - it looks like this doesn't actually work robustly. PTR records don't include the name like they are supposed to.
the
(none)is wrong, it should be the hostname (just like it is from the zedboard - which is namedanalog).We can see that it's also a problem in mdns (meaning it's not the client side).
according to wireshark, that is what the Pluto Avahi is transmitting...
Meaning the problem is in the code that I pointed to (I think) - since in Kuiper (where things start later) it works fine...
-Robin
The text was updated successfully, but these errors were encountered: