Discussion:
[avahi] Avahi daemon dies on certain hostnames
Iván Sánchez Ortega
2006-03-21 14:32:08 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I just discovered that the Avahi daemon dies if one machine in the network
handles out a response with a strange host (or domain) name.

I'm attaching the ethereal capture of the packet that "kills" the avahi
daemon, but this is how I can reproduce this:

- - Buy an Axis IP camera
- - Change the camera hostname by issuing the following command:
wget
http://{camera_ip_address}/axis-cgi/admin/param.cgi?action=update&Network.Bonjour.FriendlyName=f?obar
(notice the acute in the '?')
- - Run avahi-browse -at
- - Watch how the avahi daemon dies.

I guess that setting up any other kind of mDNS responder (an avahi daemon, a
Bonjour-enabled Mac, etc) to return a hostname with "strange" characters
(anything not in 7-bit ASCII, I guess, like in "f?obar") may be able to
reproduce this bug. By the way, I'm running Avahi 0.6.9 here.


Running avahi-browse -at in a network with such a device results in the
following error message:

Client failure, exiting: Daemon connection failed
14700: arguments to dbus_connection_get_is_connected() were incorrect,
assertion "connection != NULL" failed in file dbus-connection.c line 1984.
This is normally a bug in some application using the D-BUS library.

And the following line in /var/log/syslog:

Mar 21 16:23:27 localhost avahi-daemon[14700]: Disconnnected from D-BUS,
terminating...



Obviously, capable network administrators won't set invalid FQDNs in their
networks, but I don't like the possibility of an (un)intentionally malformed
mDNS response packet being able to shut down the avahi daemons in my network.



P.S.: Should I open a new ticket in the Avahi TRAC with this information?



Best regards,
- - --
- - ----------------------------------
Iv?n S?nchez Ortega <***@escomposlinux.org> <***@mirame.net>

Now listening to: Underworld - Caf? Del Mar: Volumen Uno - [8] Second Hand
(9:01) (94%)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEICp23jcQ2mg3Pc8RAm7GAKCDAclj2yjTwB1ZOxOUuLZlaMYKQACeNnot
V3WvX3KS62JhZ9Jufg8H/fs=
=qGE3
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ethereal_capture.png
Type: image/png
Size: 10281 bytes
Desc: not available
Url : Loading Image...
Sebastien Estienne
2006-03-21 14:53:17 UTC
Permalink
Post by Iván Sánchez Ortega
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I just discovered that the Avahi daemon dies if one machine in the network
handles out a response with a strange host (or domain) name.
I'm attaching the ethereal capture of the packet that "kills" the avahi
- - Buy an Axis IP camera
wget
http://{camera_ip_address}/axis-cgi/admin/param.cgi?action=update&Network.Bonjour.FriendlyName=f?obar
(notice the acute in the '?')
- - Run avahi-browse -at
- - Watch how the avahi daemon dies.
I guess that setting up any other kind of mDNS responder (an avahi daemon, a
Bonjour-enabled Mac, etc) to return a hostname with "strange" characters
(anything not in 7-bit ASCII, I guess, like in "f?obar") may be able to
reproduce this bug. By the way, I'm running Avahi 0.6.9 here.
Running avahi-browse -at in a network with such a device results in the
Client failure, exiting: Daemon connection failed
14700: arguments to dbus_connection_get_is_connected() were incorrect,
assertion "connection != NULL" failed in file dbus-connection.c line 1984.
This is normally a bug in some application using the D-BUS library.
Are you sure that it's not the dbus daemon that is dying and then
avahi-daemon cleanly exit because no more dbus-daemon is available?
Post by Iván Sánchez Ortega
Mar 21 16:23:27 localhost avahi-daemon[14700]: Disconnnected from D-BUS,
terminating...
this message happens when the dbus-daemon is stopped, so avahi-daemon
exits cleanly
Post by Iván Sánchez Ortega
Obviously, capable network administrators won't set invalid FQDNs in their
networks, but I don't like the possibility of an (un)intentionally malformed
mDNS response packet being able to shut down the avahi daemons in my network.
P.S.: Should I open a new ticket in the Avahi TRAC with this information?
yes please
Post by Iván Sánchez Ortega
Best regards,
- - --
- - ----------------------------------
Now listening to: Underworld - Caf? Del Mar: Volumen Uno - [8] Second Hand
(9:01) (94%)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFEICp23jcQ2mg3Pc8RAm7GAKCDAclj2yjTwB1ZOxOUuLZlaMYKQACeNnot
V3WvX3KS62JhZ9Jufg8H/fs=
=qGE3
-----END PGP SIGNATURE-----
_______________________________________________
avahi mailing list
http://lists.freedesktop.org/mailman/listinfo/avahi
--
Sebastien Estienne
Iván Sánchez Ortega
2006-03-21 15:08:30 UTC
Permalink
El Martes 21 de Marzo de 2006 17:53, Sebastien Estienne escribi?:
[...]
Post by Sebastien Estienne
Are you sure that it's not the dbus daemon that is dying and then
avahi-daemon cleanly exit because no more dbus-daemon is available?
Don't think so... dbus-daemon is still alive, while two avahi-daemon processes die:

***@littlespark:~$ ps -Af | grep dbus ; ps -Af | grep avahi
101 6312 1 0 10:31 ? 00:00:00 /usr/bin/dbus-daemon --system
ivan 7508 7452 0 10:32 ? 00:00:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
ivan 7511 1 0 10:32 ? 00:00:00 /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
ivan 7512 1 0 10:32 ? 00:00:00 dbus-daemon --fork --print-pid 8 --print-address 6 --session
ivan 17642 11533 0 18:03 pts/2 00:00:00 grep dbus
avahi 17636 1 0 18:03 ? 00:00:00 avahi-daemon: running [littlespark.local]
avahi 17637 17636 0 18:03 ? 00:00:00 avahi-daemon: chroot helper process
ivan 17644 11533 0 18:03 pts/2 00:00:00 grep avahi
***@littlespark:~$ avahi-browse -at
avahi_service_browser_new() failed: Daemon not running
***@littlespark:~$ ps -Af | grep dbus ; ps -Af | grep avahi
101 6312 1 0 10:31 ? 00:00:00 /usr/bin/dbus-daemon --system
ivan 7508 7452 0 10:32 ? 00:00:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
ivan 7511 1 0 10:32 ? 00:00:00 /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
ivan 7512 1 0 10:32 ? 00:00:00 dbus-daemon --fork --print-pid 8 --print-address 6 --session
ivan 17650 11533 0 18:04 pts/2 00:00:00 grep dbus
ivan 17652 11533 0 18:04 pts/2 00:00:00 grep avahi


(I wonder why I'm getting a different error message this time... ??)
Post by Sebastien Estienne
Post by Iván Sánchez Ortega
P.S.: Should I open a new ticket in the Avahi TRAC with this information?
yes please
Will do, ASAP.

- --
- ----------------------------------
Iv?n S?nchez Ortega <***@escomposlinux.org> <***@mirame.net>

http://acm.asoc.fi.upm.es/~mr/
Proudly running Debian Linux with 2.6.15-1-686 kernel, KDE3.5.0, and PHP 5.1.2-1 generating this signature.
Uptime: 18:04:38 up 7:34, 1 user, load average: 0.48, 0.27, 0.29
Sebastien Estienne
2006-03-21 15:23:16 UTC
Permalink
Post by Iván Sánchez Ortega
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[...]
Post by Sebastien Estienne
Are you sure that it's not the dbus daemon that is dying and then
avahi-daemon cleanly exit because no more dbus-daemon is available?
101 6312 1 0 10:31 ? 00:00:00 /usr/bin/dbus-daemon --system
ivan 7508 7452 0 10:32 ? 00:00:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
ivan 7511 1 0 10:32 ? 00:00:00 /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
ivan 7512 1 0 10:32 ? 00:00:00 dbus-daemon --fork --print-pid 8 --print-address 6 --session
ivan 17642 11533 0 18:03 pts/2 00:00:00 grep dbus
avahi 17636 1 0 18:03 ? 00:00:00 avahi-daemon: running [littlespark.local]
avahi 17637 17636 0 18:03 ? 00:00:00 avahi-daemon: chroot helper process
ivan 17644 11533 0 18:03 pts/2 00:00:00 grep avahi
avahi_service_browser_new() failed: Daemon not running
101 6312 1 0 10:31 ? 00:00:00 /usr/bin/dbus-daemon --system
ivan 7508 7452 0 10:32 ? 00:00:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
ivan 7511 1 0 10:32 ? 00:00:00 /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
ivan 7512 1 0 10:32 ? 00:00:00 dbus-daemon --fork --print-pid 8 --print-address 6 --session
ivan 17650 11533 0 18:04 pts/2 00:00:00 grep dbus
ivan 17652 11533 0 18:04 pts/2 00:00:00 grep avahi
(I wonder why I'm getting a different error message this time... ??)
Post by Sebastien Estienne
Post by Iván Sánchez Ortega
P.S.: Should I open a new ticket in the Avahi TRAC with this information?
yes please
Will do, ASAP.
thanx, could you also post a
- strace log
- a backtrace
? thanx
Post by Iván Sánchez Ortega
- --
- ----------------------------------
http://acm.asoc.fi.upm.es/~mr/
Proudly running Debian Linux with 2.6.15-1-686 kernel, KDE3.5.0, and PHP 5.1.2-1 generating this signature.
Uptime: 18:04:38 up 7:34, 1 user, load average: 0.48, 0.27, 0.29
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFEIDMF3jcQ2mg3Pc8RAgkNAKCIZLiL8PHFZnU4ULZAOL1lVwJZZgCdF2wh
Z0E2e2Id1BXxuhzLfdVKKls=
=/cmH
-----END PGP SIGNATURE-----
_______________________________________________
avahi mailing list
http://lists.freedesktop.org/mailman/listinfo/avahi
--
Sebastien Estienne
Iván Sánchez Ortega
2006-03-21 15:34:14 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Sebastien Estienne
thanx, could you also post a
- strace log
- a backtrace
? thanx
I'm attaching the 50 last lines from a "strace /usr/sbin/avahi-daemon".

The backtrace might prove difficult: I'm using binary Debian packages;
recompiling avahi on my own with the debug flags may take a while on my
part...

- --
- ----------------------------------
Iv?n S?nchez Ortega <***@escomposlinux.org> <***@mirame.net>

Reason is lasting, passion is living
and dying is teaching us how to live
--Enigma
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEIDkN3jcQ2mg3Pc8RAt0iAJ9mBLqHNK2VVZep2QvVZu7GCCin9ACZASXG
zy52VuX75H2jXxc/bUgF3NE=
=/own
-----END PGP SIGNATURE-----
-------------- next part --------------
read(4, "W", 10) = 1
gettimeofday({1142962128, 504266}, NULL) = 0
write(5, "W", 1) = 1
writev(9, [{"l\4\1\1T\0\0\0\17\0\0\0\206\0\0\0\1\1o\0\30\0\0\0/Clie"..., 152}, {"\2\0\0\0\0\0\0\0\37\0\0\0littlespark [00:0f:b"..., 84}], 2) = 236
gettimeofday({1142962128, 505163}, NULL) = 0
gettimeofday({1142962128, 505344}, NULL) = 0
write(5, "W", 1) = 1
gettimeofday({1142962128, 505701}, NULL) = 0
write(5, "W", 1) = 1
write(5, "W", 1) = 1
writev(9, [{"l\4\1\1\0\0\0\0\20\0\0\0~\0\0\0\1\1o\0\30\0\0\0/Client"..., 144}, {"", 0}], 2) = 144
write(5, "W", 1) = 1
read(4, "WWWWW", 10) = 5
gettimeofday({1142962128, 507006}, NULL) = 0
poll([{fd=4, events=POLLIN}, {fd=13, events=POLLIN}, {fd=12, events=POLLIN}, {fd=11, events=POLLIN}, {fd=10, events=POLLIN}, {fd=9, events=POLLIN, revents=POLLIN}, {fd=8, events=POLLIN}, {fd=6, events=POLLIN}], 8, 93) = 1
gettimeofday({1142962128, 507784}, NULL) = 0
read(9, "l\1\0\1(\0\0\0\n\0\0\0\226\0\0\0\1\1o\0\1\0\0\0/\0\0\0"..., 2048) = 208
read(9, 0x80642a8, 2048) = -1 EAGAIN (Resource temporarily unavailable)
write(5, "W", 1) = 1
read(4, "W", 10) = 1
write(5, "W", 1) = 1
writev(9, [{"l\2\1\1\35\0\0\0\21\0\0\0\37\0\0\0\6\1s\0\5\0\0\0:1.90"..., 48}, {"\30\0\0\0/Client0/ServiceBrowser3\0", 29}], 2) = 77
read(4, "W", 10) = 1
gettimeofday({1142962128, 509986}, NULL) = 0
write(5, "W", 1) = 1
writev(9, [{"l\4\1\0014\0\0\0\22\0\0\0\206\0\0\0\1\1o\0\30\0\0\0/Cl"..., 152}, {"\2\0\0\0\0\0\0\0\6\0\0\0f\363obar\0\0\n\0\0\0_rtsp._t"..., 52}], 2) = 204
gettimeofday({1142962128, 511255}, NULL) = 0
gettimeofday({1142962128, 511436}, NULL) = 0
write(5, "W", 1) = 1
gettimeofday({1142962128, 511794}, NULL) = 0
write(5, "W", 1) = 1
write(5, "W", 1) = 1
writev(9, [{"l\4\1\1\0\0\0\0\23\0\0\0~\0\0\0\1\1o\0\30\0\0\0/Client"..., 144}, {"", 0}], 2) = -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
write(5, "W", 1) = 1
close(9) = 0
write(5, "W", 1) = 1
write(5, "W", 1) = 1
read(4, "WWWWWWW", 10) = 7
write(2, "Disconnnected from D-BUS, termin"..., 40Disconnnected from D-BUS, terminating...) = 40
write(2, "\n", 1
) = 1
tgkill(18332, 18332, SIGQUIT) = 0
--- SIGQUIT (Quit) @ 0 (0) ---
write(7, "\3\0\0\0", 4) = 4
sigreturn() = ? (mask now [])
exit_group(1) = ?
Trent Lloyd
2006-03-21 20:31:51 UTC
Permalink
Hi Ivan,

Thanks for the report, could you please send the full strace
output to me personally (don't send the whole thing to the list :)

Trent
Post by Iván Sánchez Ortega
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Sebastien Estienne
thanx, could you also post a
- strace log
- a backtrace
? thanx
I'm attaching the 50 last lines from a "strace /usr/sbin/avahi-daemon".
The backtrace might prove difficult: I'm using binary Debian packages;
recompiling avahi on my own with the debug flags may take a while on my
part...
- --
- ----------------------------------
Reason is lasting, passion is living
and dying is teaching us how to live
--Enigma
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFEIDkN3jcQ2mg3Pc8RAt0iAJ9mBLqHNK2VVZep2QvVZu7GCCin9ACZASXG
zy52VuX75H2jXxc/bUgF3NE=
=/own
-----END PGP SIGNATURE-----
read(4, "W", 10) = 1
gettimeofday({1142962128, 504266}, NULL) = 0
write(5, "W", 1) = 1
writev(9, [{"l\4\1\1T\0\0\0\17\0\0\0\206\0\0\0\1\1o\0\30\0\0\0/Clie"..., 152}, {"\2\0\0\0\0\0\0\0\37\0\0\0littlespark [00:0f:b"..., 84}], 2) = 236
gettimeofday({1142962128, 505163}, NULL) = 0
gettimeofday({1142962128, 505344}, NULL) = 0
write(5, "W", 1) = 1
gettimeofday({1142962128, 505701}, NULL) = 0
write(5, "W", 1) = 1
write(5, "W", 1) = 1
writev(9, [{"l\4\1\1\0\0\0\0\20\0\0\0~\0\0\0\1\1o\0\30\0\0\0/Client"..., 144}, {"", 0}], 2) = 144
write(5, "W", 1) = 1
read(4, "WWWWW", 10) = 5
gettimeofday({1142962128, 507006}, NULL) = 0
poll([{fd=4, events=POLLIN}, {fd=13, events=POLLIN}, {fd=12, events=POLLIN}, {fd=11, events=POLLIN}, {fd=10, events=POLLIN}, {fd=9, events=POLLIN, revents=POLLIN}, {fd=8, events=POLLIN}, {fd=6, events=POLLIN}], 8, 93) = 1
gettimeofday({1142962128, 507784}, NULL) = 0
read(9, "l\1\0\1(\0\0\0\n\0\0\0\226\0\0\0\1\1o\0\1\0\0\0/\0\0\0"..., 2048) = 208
read(9, 0x80642a8, 2048) = -1 EAGAIN (Resource temporarily unavailable)
write(5, "W", 1) = 1
read(4, "W", 10) = 1
write(5, "W", 1) = 1
writev(9, [{"l\2\1\1\35\0\0\0\21\0\0\0\37\0\0\0\6\1s\0\5\0\0\0:1.90"..., 48}, {"\30\0\0\0/Client0/ServiceBrowser3\0", 29}], 2) = 77
read(4, "W", 10) = 1
gettimeofday({1142962128, 509986}, NULL) = 0
write(5, "W", 1) = 1
writev(9, [{"l\4\1\0014\0\0\0\22\0\0\0\206\0\0\0\1\1o\0\30\0\0\0/Cl"..., 152}, {"\2\0\0\0\0\0\0\0\6\0\0\0f\363obar\0\0\n\0\0\0_rtsp._t"..., 52}], 2) = 204
gettimeofday({1142962128, 511255}, NULL) = 0
gettimeofday({1142962128, 511436}, NULL) = 0
write(5, "W", 1) = 1
gettimeofday({1142962128, 511794}, NULL) = 0
write(5, "W", 1) = 1
write(5, "W", 1) = 1
writev(9, [{"l\4\1\1\0\0\0\0\23\0\0\0~\0\0\0\1\1o\0\30\0\0\0/Client"..., 144}, {"", 0}], 2) = -1 EPIPE (Broken pipe)
write(5, "W", 1) = 1
close(9) = 0
write(5, "W", 1) = 1
write(5, "W", 1) = 1
read(4, "WWWWWWW", 10) = 7
write(2, "Disconnnected from D-BUS, termin"..., 40Disconnnected from D-BUS, terminating...) = 40
write(2, "\n", 1
) = 1
tgkill(18332, 18332, SIGQUIT) = 0
write(7, "\3\0\0\0", 4) = 4
sigreturn() = ? (mask now [])
exit_group(1) = ?
_______________________________________________
avahi mailing list
http://lists.freedesktop.org/mailman/listinfo/avahi
--
Trent Lloyd <***@bur.st>
Bur.st Networking Inc.
Sjoerd Simons
2006-03-21 16:12:23 UTC
Permalink
Post by Sebastien Estienne
Post by Iván Sánchez Ortega
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I just discovered that the Avahi daemon dies if one machine in the network
handles out a response with a strange host (or domain) name.
I'm attaching the ethereal capture of the packet that "kills" the avahi
- - Buy an Axis IP camera
wget
http://{camera_ip_address}/axis-cgi/admin/param.cgi?action=update&Network.Bonjour.FriendlyName=f?obar
(notice the acute in the '?')
- - Run avahi-browse -at
- - Watch how the avahi daemon dies.
I guess that setting up any other kind of mDNS responder (an avahi daemon, a
Bonjour-enabled Mac, etc) to return a hostname with "strange" characters
(anything not in 7-bit ASCII, I guess, like in "f?obar") may be able to
reproduce this bug. By the way, I'm running Avahi 0.6.9 here.
Running avahi-browse -at in a network with such a device results in the
Client failure, exiting: Daemon connection failed
14700: arguments to dbus_connection_get_is_connected() were incorrect,
assertion "connection != NULL" failed in file dbus-connection.c line 1984.
This is normally a bug in some application using the D-BUS library.
Are you sure that it's not the dbus daemon that is dying and then
avahi-daemon cleanly exit because no more dbus-daemon is available?
Post by Iván Sánchez Ortega
Mar 21 16:23:27 localhost avahi-daemon[14700]: Disconnnected from D-BUS,
terminating...
this message happens when the dbus-daemon is stopped, so avahi-daemon
exits cleanly
This is probably caused by dbus kicking avahi-daemon of the bus. Try sending
invalid utf-8 as a string and it will kick you off.

Hal had the same problem with volume labels that had non-utf8 strings. You
really need to sanatize untrusted strings before sending them onto dbus :)

Sjoerd
--
If I set here and stare at nothing long enough, people might think
I'm an engineer working on something.
-- S. R. McElroy
Lennart Poettering
2006-03-31 21:50:37 UTC
Permalink
Post by Iván Sánchez Ortega
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I just discovered that the Avahi daemon dies if one machine in the network
handles out a response with a strange host (or domain) name.
I'm attaching the ethereal capture of the packet that "kills" the avahi
- - Buy an Axis IP camera
wget
http://{camera_ip_address}/axis-cgi/admin/param.cgi?action=update&Network.Bonjour.FriendlyName=f?obar
(notice the acute in the '?')
- - Run avahi-browse -at
- - Watch how the avahi daemon dies.
I guess that setting up any other kind of mDNS responder (an avahi daemon, a
Bonjour-enabled Mac, etc) to return a hostname with "strange" characters
(anything not in 7-bit ASCII, I guess, like in "f?obar") may be able to
reproduce this bug. By the way, I'm running Avahi 0.6.9 here.
Hmm. While Avahi shouldn't die when such a host name appears on the
network it's primarily a bug in the axis cameras. They shouldn't send
hostnames with invalid UTF-8 characters in the first place. However, I
don't know what to do in such a case. Ignore the hostanem entirely
because it isn't valid UTF-8? Treat is as ISO8859-1 if it doesn't
validate as UTF8?

I think i will simply write a message to syslog and ignore the RRs
which contains such bogus host names. What do you think?

Lennart
--
Lennart Poettering; lennart [at] poettering [dot] net
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/
Marc Krochmal
2006-03-31 22:57:38 UTC
Permalink
Post by Lennart Poettering
Post by Iván Sánchez Ortega
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I just discovered that the Avahi daemon dies if one machine in the network
handles out a response with a strange host (or domain) name.
I'm attaching the ethereal capture of the packet that "kills" the avahi
- - Buy an Axis IP camera
wget
http://{camera_ip_address}/axis-cgi/admin/param.cgi?
action=update&Network.Bonjour.FriendlyName=f?obar
(notice the acute in the '?')
- - Run avahi-browse -at
- - Watch how the avahi daemon dies.
I guess that setting up any other kind of mDNS responder (an avahi daemon, a
Bonjour-enabled Mac, etc) to return a hostname with "strange"
characters
(anything not in 7-bit ASCII, I guess, like in "f?obar") may be able to
reproduce this bug. By the way, I'm running Avahi 0.6.9 here.
Hmm. While Avahi shouldn't die when such a host name appears on the
network it's primarily a bug in the axis cameras. They shouldn't send
hostnames with invalid UTF-8 characters in the first place. However, I
don't know what to do in such a case. Ignore the hostanem entirely
because it isn't valid UTF-8? Treat is as ISO8859-1 if it doesn't
validate as UTF8?
I think i will simply write a message to syslog and ignore the RRs
which contains such bogus host names. What do you think?
Couldn't you just allow the UTF-8 hostname but log a warning
message? UTF-8 is a valid encoding scheme for mDNS in general, just
in practice, hostnames are traditionally restricted to letter,
digits, hyphens so as to make them easy to type into command-line
interfaces.

-Marc
Lennart Poettering
2006-03-31 23:06:49 UTC
Permalink
Post by Marc Krochmal
Post by Lennart Poettering
Hmm. While Avahi shouldn't die when such a host name appears on the
network it's primarily a bug in the axis cameras. They shouldn't send
hostnames with invalid UTF-8 characters in the first place. However, I
don't know what to do in such a case. Ignore the hostanem entirely
because it isn't valid UTF-8? Treat is as ISO8859-1 if it doesn't
validate as UTF8?
I think i will simply write a message to syslog and ignore the RRs
which contains such bogus host names. What do you think?
Couldn't you just allow the UTF-8 hostname but log a warning
message? UTF-8 is a valid encoding scheme for mDNS in general, just
in practice, hostnames are traditionally restricted to letter,
digits, hyphens so as to make them easy to type into command-line
interfaces.
The problem is not with host names that are proper UTF8 names. Those
are supported properly right now. The problem appears with host names
that contain characters that are not valid in UTF8. Avahi doesn't
check for this right now, but the IPC system we use (DBUS) does and
runs amok.

(At least that's what I understood)

See

http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/character-encoding.html

for more information about valid and invalid UTF8 sequences.

Lennart
--
Lennart Poettering; lennart [at] poettering [dot] net
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/
Ross Burton
2006-04-01 07:27:28 UTC
Permalink
Post by Lennart Poettering
The problem is not with host names that are proper UTF8 names. Those
are supported properly right now. The problem appears with host names
that contain characters that are not valid in UTF8. Avahi doesn't
check for this right now, but the IPC system we use (DBUS) does and
runs amok.
How about returning the valid portion of the string, whilst logging the
failure to syslog? Incomplete hostnames will alert the user that
something is up, and syslog will tell them the problem (log an ASCII
representation of the byte sequence and the offset to the invalid
character).

Ross
--
Ross Burton mail: ***@burtonini.com
jabber: ***@burtonini.com
www: http://www.burtonini.com./
PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
Lennart Poettering
2006-04-01 10:20:52 UTC
Permalink
Post by Ross Burton
Post by Lennart Poettering
The problem is not with host names that are proper UTF8 names. Those
are supported properly right now. The problem appears with host names
that contain characters that are not valid in UTF8. Avahi doesn't
check for this right now, but the IPC system we use (DBUS) does and
runs amok.
How about returning the valid portion of the string, whilst logging the
failure to syslog? Incomplete hostnames will alert the user that
something is up, and syslog will tell them the problem (log an ASCII
representation of the byte sequence and the offset to the invalid
character).
This is actually not as simple as it sounds. If we sanitize a host
name in the way you described, this would not be an invertible
function. However, we need it to be a bijective function. Just think
of the following situation: Avahi finds a service with an invalid UTF8
name. it sanitizes it and passes it to the application which was
browsing for it. Now that app wants to resolve it, hence it sends the
sanitized string back to Avahi. To resolve it Avahi needs to remap
this sanitized string back to the original, invalid string. If the
sanitation function isn't invertible this is not possible, at least
not without ugly kludges to deal with collisions.

Due to the size limitation of DNS labels we cannot expand the length
in that sanitation function if we want to keep bijectiveness. Hence
we cannot use character escaping for invalid characters. Hence I would
say that there is no bijective function that would fulfill the
sanitation purpose.

In short: all we can do is ignore the invalid RRs and log something
about this fact.

If I understood correctly the Axis cameras don't come with invalid
host names by default, correct? This was a bad manual configuration,
right? If so, I don't see such a big problem if we simple refuse to
work with badly configured devices.

This whole issue is something that should be fixed in the Axis
cameras and not by Avahi.

Lennart
--
Lennart Poettering; lennart [at] poettering [dot] net
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/
Iván Sánchez Ortega
2006-04-01 11:18:18 UTC
Permalink
Post by Lennart Poettering
If I understood correctly the Axis cameras don't come with invalid
host names by default, correct?
Yes.
Post by Lennart Poettering
This was a bad manual configuration, right?
Yes.
Post by Lennart Poettering
If so, I don't see such a big problem if we simple refuse to work with badly
configured devices.
I don't like that idea much... a "badly configured device" today may be
a "device with default config" tomorrow.

You say that escaping the string is not a valid solution, due to the DNS label
size limit. But, how about this?:

if (the label is not a valid UTF8 string)
{
escape the invalid characters
if (new lenght of the DNS label < 255)
Return the escaped label
else
Ignore this label, log a warning into syslog
}


This way, Avahi should work with *most* badly configured devices (as people
don't usually use up 256 characters for a device name); and devices
with "bad" names, that are too long to be sanitized, will be just ignored.


Just an idea...

- --
- ----------------------------------
Iv?n S?nchez Ortega <***@escomposlinux.org> <***@mirame.net>

Now listening to: Vangelis - Spiral (1977) - [2] Ballad (8:31) (86%)
Sebastien Estienne
2006-04-01 11:46:50 UTC
Permalink
Post by Iván Sánchez Ortega
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Lennart Poettering
If I understood correctly the Axis cameras don't come with invalid
host names by default, correct?
Yes.
Post by Lennart Poettering
This was a bad manual configuration, right?
Yes.
Post by Lennart Poettering
If so, I don't see such a big problem if we simple refuse to work with badly
configured devices.
I don't like that idea much... a "badly configured device" today may be
a "device with default config" tomorrow.
You say that escaping the string is not a valid solution, due to the DNS label
if (the label is not a valid UTF8 string)
{
escape the invalid characters
if (new lenght of the DNS label < 255)
Return the escaped label
else
Ignore this label, log a warning into syslog
}
This way, Avahi should work with *most* badly configured devices (as people
don't usually use up 256 characters for a device name); and devices
with "bad" names, that are too long to be sanitized, will be just ignored.
Just an idea...
i proposed something like this.
btw i think the limit is not 256, but something like 63
Post by Iván Sánchez Ortega
- --
- ----------------------------------
Now listening to: Vangelis - Spiral (1977) - [2] Ballad (8:31) (86%)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFELn2P3jcQ2mg3Pc8RAqaqAJ0QtqmGZ/EFa1DbrM1i4/yPUHK3hQCeLffS
3Hf9AolE4fFLsYT1iXBrl5E=
=KYPl
-----END PGP SIGNATURE-----
_______________________________________________
avahi mailing list
http://lists.freedesktop.org/mailman/listinfo/avahi
--
Sebastien Estienne
Lennart Poettering
2006-04-01 12:29:20 UTC
Permalink
On Sat, 01.04.06 15:18, Iv?n S?nchez Ortega (***@mirame.net) wrote:

Hi!
Post by Iván Sánchez Ortega
Post by Lennart Poettering
If so, I don't see such a big problem if we simple refuse to work with badly
configured devices.
I don't like that idea much... a "badly configured device" today may be
a "device with default config" tomorrow.
hee. working around the bugs of tomorrow already today seems a little
strange to me. ;-)
Post by Iván Sánchez Ortega
You say that escaping the string is not a valid solution, due to the DNS label
if (the label is not a valid UTF8 string)
{
escape the invalid characters
if (new lenght of the DNS label < 255)
Return the escaped label
else
Ignore this label, log a warning into syslog
}
This way, Avahi should work with *most* badly configured devices (as people
don't usually use up 256 characters for a device name); and devices
with "bad" names, that are too long to be sanitized, will be just ignored.
as sebest already mentioned: the limit is 63, not 255.

The scheme you suggest isn't invertible. There needs to be a way to
detect whether a sanitized string has been escaped or not.

Lennart
--
Lennart Poettering; lennart [at] poettering [dot] net
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/
Iván Sánchez Ortega
2006-04-07 09:32:13 UTC
Permalink
El S?bado 01 de Abril de 2006 16:29, Lennart Poettering escribi?:
[...]
Post by Lennart Poettering
The scheme you suggest isn't invertible. There needs to be a way to
detect whether a sanitized string has been escaped or not.
Don't worry about invertibility: Apple does not.

I managed to get my hands over a iBook G4 today, and tried to set its hostname
to "f?obar". Interestingly, the mDNS response has another charset, and it
does not kill Avahi. Check the attachments at http://avahi.org/ticket/21

Seen that, I agree with the idea of "f*ck^H^H^H^Hignore devices with non-UTF8
hostnames".

However, at some point, MacOS X converts "f?obar.local" into "f-obar.local".
I'll post a screenshot of that ASAP. I wonder how Apple deals with name
collisions... :-/

- --
- ----------------------------------
Iv?n S?nchez Ortega <***@escomposlinux.org> <***@mirame.net>

Un ordenador no es un televisor ni un microondas, es una herramienta compleja.
Lennart Poettering
2006-04-07 10:49:22 UTC
Permalink
Post by Iván Sánchez Ortega
[...]
Post by Lennart Poettering
The scheme you suggest isn't invertible. There needs to be a way to
detect whether a sanitized string has been escaped or not.
Don't worry about invertibility: Apple does not.
I managed to get my hands over a iBook G4 today, and tried to set its hostname
to "f?obar". Interestingly, the mDNS response has another charset, and it
does not kill Avahi. Check the attachments at http://avahi.org/ticket/21
Seen that, I agree with the idea of "f*ck^H^H^H^Hignore devices with non-UTF8
hostnames".
However, at some point, MacOS X converts "f?obar.local" into "f-obar.local".
I'll post a screenshot of that ASAP. I wonder how Apple deals with name
collisions... :-/
These are actually two different things. One thing is how to deal with
hostnames with invalid UTF8 that are recieved from other hosts, and
the other is how to mangle the local hostname before publishing it on
the LAN. Ther former mapping requires perfect bijectiveness, the
latter doesn't.

It's perfectly valid for Apple to mangle the local host name the way
they do. However, I don't think it really is necessary. One could
publish an UTF8-Domain here directly. As long as it is correct UTF8 i
see no problem here.

Lennart
--
Lennart Poettering; lennart [at] poettering [dot] net
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/
Marc Krochmal
2006-04-07 21:21:56 UTC
Permalink
Post by Lennart Poettering
Post by Iván Sánchez Ortega
[...]
Post by Lennart Poettering
The scheme you suggest isn't invertible. There needs to be a way to
detect whether a sanitized string has been escaped or not.
Don't worry about invertibility: Apple does not.
I managed to get my hands over a iBook G4 today, and tried to set its hostname
to "f?obar". Interestingly, the mDNS response has another charset, and it
does not kill Avahi. Check the attachments at http://avahi.org/
ticket/21
Seen that, I agree with the idea of "f*ck^H^H^H^Hignore devices with non-UTF8
hostnames".
However, at some point, MacOS X converts "f?obar.local" into "f-
obar.local".
I'll post a screenshot of that ASAP. I wonder how Apple deals with name
collisions... :-/
These are actually two different things. One thing is how to deal with
hostnames with invalid UTF8 that are recieved from other hosts, and
the other is how to mangle the local hostname before publishing it on
the LAN. Ther former mapping requires perfect bijectiveness, the
latter doesn't.
It's perfectly valid for Apple to mangle the local host name the way
they do. However, I don't think it really is necessary. One could
publish an UTF8-Domain here directly. As long as it is correct UTF8 i
see no problem here.
Right. The Mac OS X user interface prevents you from entering a
local hostname with non-ascii characters by automatically converting
everything into letters, digits and hyphens. If you could manage to
bypass this and enter non-ascii characters, then Mac OS X would
advertise the raw UTF-8, instead of using something like IDN. mDNS
was designed before IDN was fully standardized, and the mDNS authors
aren't big fans of it, so we made the decision to use UTF-8 as the
encoding scheme on the wire, since we didn't have any backward
compatibly issues, which was one of the stated reasons for the
necessity of IDN in DNS.

We're still contemplating how to handle this for wide-area discovery,
but our current implementation uses UTF-8 for wide-area as well.
Note that BIND 9 servers allow you to specify full UTF-8 domain names
in zone files and this works, meaning you can query for raw UTF-8 on
the wire and the server responds as expected.

-Marc

Iván Sánchez Ortega
2006-04-01 09:30:16 UTC
Permalink
Post by Lennart Poettering
Hmm. While Avahi shouldn't die when such a host name appears on the
network it's primarily a bug in the axis cameras. They shouldn't send
hostnames with invalid UTF-8 characters in the first place.
I'll ask the Axis guys about it...
Post by Lennart Poettering
However, I don't know what to do in such a case. Ignore the hostanem
entirely because it isn't valid UTF-8? Treat is as ISO8859-1 if it doesn't
validate as UTF8?
I suggest that Avahi should have the same behaviour as Apple's Bonjour.
Convert the non-valid characters to whitespaces (or other glyph, such an
underscore), but never discard a host because the mDNS hostname is invalid. I
mostly agree with Ross Burton at this point.
Post by Lennart Poettering
Couldn't you just allow the UTF-8 hostname but log a warning
message? UTF-8 is a valid encoding scheme for mDNS in general, just
in practice, hostnames are traditionally restricted to letter,
digits, hyphens so as to make them easy to type into command-line
interfaces.
As RFC 2181, chapter 11 points out, a DNS server can return just any binary
string, and the DNS client (avahi-daemon, in our case) is responsible for
validating the data.

IMHO, Avahi cannot restrict itself to "traditional" hostnames
(non-case-sensitive, only a-z, 0-9, hyphen and underscore): there are lots of
bonjour-enabled devces out there that have blank spaces in their mDNS
hostnames. There are even *examples* of Bonjour using names with spaces.

- --
- ----------------------------------
Iv?n S?nchez Ortega <***@escomposlinux.org> <***@mirame.net>

Un ordenador no es un televisor ni un microondas, es una herramienta compleja.
Lennart Poettering
2006-04-01 10:39:01 UTC
Permalink
Post by Iván Sánchez Ortega
Post by Lennart Poettering
However, I don't know what to do in such a case. Ignore the hostanem
entirely because it isn't valid UTF-8? Treat is as ISO8859-1 if it doesn't
validate as UTF8?
I suggest that Avahi should have the same behaviour as Apple's Bonjour.
Convert the non-valid characters to whitespaces (or other glyph, such an
underscore), but never discard a host because the mDNS hostname is invalid. I
mostly agree with Ross Burton at this point.
My ISO8859-1 idea doesn't make a lot of sense actually, due to the
bijectiveness issues i pointed out in that response to Ross' mail.

For the same reasons the solution you suggest here isn't going to
work.
Post by Iván Sánchez Ortega
Post by Lennart Poettering
Couldn't you just allow the UTF-8 hostname but log a warning
message? UTF-8 is a valid encoding scheme for mDNS in general, just
in practice, hostnames are traditionally restricted to letter,
digits, hyphens so as to make them easy to type into command-line
interfaces.
As RFC 2181, chapter 11 points out, a DNS server can return just any binary
string, and the DNS client (avahi-daemon, in our case) is responsible for
validating the data.
AFAIK the restriction to letter, digits, hyphens is imposed by the
registrars not DNS specs itself.
Post by Iván Sánchez Ortega
IMHO, Avahi cannot restrict itself to "traditional" hostnames
(non-case-sensitive, only a-z, 0-9, hyphen and underscore): there are lots of
bonjour-enabled devces out there that have blank spaces in their mDNS
hostnames. There are even *examples* of Bonjour using names with spaces.
BTW, Marc: What is the the way Apple suggests to handle the issues of
i18n domains on unicast DNS? Transform each label that contains
non-ascii characters to punycode? This would result in an algorithm
like this:

1. if the name validates as ascii, encode it as is
2. if the name validates as utf8 and destination port is 53, encode it
as punycode
3. if the name validates as utf and destination port is 5353, encode
it as is
4. else, cry and log about it to syslog

Lennart
--
Lennart Poettering; lennart [at] poettering [dot] net
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/
Jim Gettys
2006-04-07 17:44:59 UTC
Permalink
There are IETF standards around character sets used in host names (I
believe you should be able to find them in the DNS and/or mail
standards).

The Internet Koan is "Be liberal in what you accept and strict with what
you produce". (e.g. accept anything that is anything remotely
understandable, but ensure your implementation only transmits the
standards.

So you should never die, do the best you can with garbage, and ensure
you never transmit trash.

I'm not convinced the current standards even allow UTF-8 in host names;
but then again, it's been a while since I was steeped in this stuf.
Jim Gettys
OLPC
Editor of the HTTP/1.1 spec...
--
Jim Gettys
One Laptop Per Child
Loading...