On Feb 9, 2006, at 5:17 PM, Lennart Poettering wrote:
On Tue, 07.02.06 20:26, Iván Sánchez Ortega ([EMAIL PROTECTED])
wrote:
El Martes 07 de Febrero de 2006 19:03, Marc Krochmal escribió:
[...] there's still many poor customers in the world that don't
have the
benefits of Zeroconf, [...] This doesn't work when you have two
cameras on
the network that both use the same IP [...]
I can see your point. If Avahi returned the 192.168.x.x IPs for
the cameras,
I'd be running into that problem. So the right way for Avahi to do
this is,
as you say, to use the 169.254.x.x addresses...
Actually, Avahi uses the first address record it gets from the
device, so this
is somewhat dependant of the device logic, though this is not fully
deterministic, due to cache management and stuff.
BTW: Avahi itself doesn't publish link local addresses if an
interface has both a public and an ipv4ll address assigned. So, if the
the Axis camera would run Avahi, the problem would go away. ;-)
Except that this isn't a problem for Macs and Windows machines with
Bonjour for Windows. It only affects machines that don't fully
implement RFC 3927. We specifically asked Axis to advertise their
link-local address in order to provide a true zeroconf out-of-the-box
experience, since they were also constrained by their requirement to
support non-zeroconf aware computers, by having a statically assigned
IP address, which could potentially be on the wrong subnet,
preventing you from communicating with it.
I wonder if we should add some logic to always prefer real addresses
over ipv4ll if we recieve both when browsing for them. Would make some
sense, I guess.
Yes, for functions that can only return a single IP address, it makes
sense to prefer the routable address, but ideally a client could use
an API that returned all available IP addresses so it could try each
one until it found one that succeeded.
-Marc
_______________________________________________
avahi mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/avahi
