On 2/7/06, Iván Sánchez Ortega <[EMAIL PROTECTED]> wrote: > Hi there, > > As this is my first message to this mailing list, I might as well introduce > myself briefly. I'm Iván Sánchez, from Spain. Linux junkie, PHP programmer, > Computer Science student. Quite some experience with webservers and IP > networking, near-zero experience with Avahi and MDNS. > > > The fact is, I'm currently working with some Axis IP cameras [1]. Wonderful > gadgets, they've got a 100Mhz µprocessor running Linux, featuring a webserver > and some uPnP/zeroconf support. My goal is to detect a large number of these > cameras in a large network, by using avahi. > [1] http://www.axis.com/products/video/camera/ > > > However, I'm running into some problems. One of the cameras is returning a > "strange" MDNS response, pointing to a non-existant IP address. I managed to > capture that response with ethereal (my workstation is 01:00:5e:xx:xx:xx, the > camera is 00:40:8c:xx:xx:xx at 192.168.2.81): > > > > Frame 339 (354 bytes on wire, 354 bytes captured) > Ethernet II, Src: 192.168.2.81 (00:40:8c:xx:xx:xx), Dst: 01:00:5e:xx:xx:xx > (01:00:5e:xx:xx:xx) > Internet Protocol, Src: axis-00408cxxxxxx.local (192.168.2.81), Dst: > 224.0.0.251 (224.0.0.251) > User Datagram Protocol, Src Port: 5353 (5353), Dst Port: 5353 (5353) > Domain Name System (response) > Transaction ID: 0x0000 > Flags: 0x8400 (Standard query response, No error) > Questions: 0 > Answer RRs: 8 > Authority RRs: 0 > Additional RRs: 0 > Answers > axis-00408cxxxxxx.local: type A, class IN, addr 192.168.2.81 > axis-00408cxxxxxx.local: type A, class FLUSH, addr 169.254.154.134 > AXIS 213 - 00408CXXXXXX._http._tcp.local: type SRV, class FLUSH, > priority 0, weight 0, port 80, target axis-00408cxxxxxx.local > AXIS 213 - 00408CXXXXXX._http._tcp.local: type TXT, class FLUSH > AXIS 213 - 00408CXXXXXX._axis-video._tcp.local: type SRV, class FLUSH, > priority 0, weight 0, port 80, target axis-00408cxxxxxx.local > AXIS 213 - 00408CXXXXXX._axis-video._tcp.local: type TXT, class FLUSH > AXIS 213 - 00408CXXXXXX._rtsp._tcp.local: type SRV, class FLUSH, > priority 0, weight 0, port 554, target axis-00408cxxxxxx.local > AXIS 213 - 00408CXXXXXX._rtsp._tcp.local: type TXT, class FLUSH > > > This translates to: > > [EMAIL PROTECTED]:~$ avahi-browse -acr > [...snip...] > = eth0 IPv4 AXIS 213 - 00408CXXXXXX Web Site local > hostname = [axis-00408cxxxxxx.local] > address = [169.254.154.134] > port = [80] > txt = [] > > > > So, it seems that the camera is returning two addresses: the "real" address > (192.168.2.81), and an ad-hoc zeroconf address (169.254.154.134). Avahi gets > the non-existant, non-working ad-hoc address, while windoze's uPnP gets the > "real", good address. I haven't tried with Apple's Zeroconf. > > > So, questions: > > Avahi doesn't get the correct IP address from this camera. Who is to blame for > this: Axis' implementation of MDNS responses, or Avahi's bad interpretation > of it?
does "avahi-resolve-host-name axis-00408cxxxxxx.local" returns the link local ip? you could try setting a link local address on your host as an alias ip. > > The cameras publish the _axis-video and _rtsp services. However, applications > (such as the zeroconf:/ kioslave aren't aware of these services and ignore > them. What would be the way to do this? support for these services could be easily added to zeroconf kioslave if you know about a kde application that can handle the datas > > > > Thanks for reading all this, > -- > ---------------------------------- > Iván Sánchez Ortega <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > > "I loathed every day and regret every day I spent in school. I like to be > taught to read and write and add and then be left alone." > - Woody Allen > _______________________________________________ > avahi mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/avahi > -- Sebastien Estienne
_______________________________________________ avahi mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/avahi
