Menu
▾
▴
Re: [Jmdns-discuss] Problem resolving some services
|
From: Pierre F. <pie...@sp...> - 2012-03-06 17:52:28
|
Sorry I was slow on this one. I guess I don't understand how the IP addresses of this camera are configured. The short answer is that we never see the packet form the camera because it is ignored. The long answer is that the camera has 2 IP addresses one is 169.254.114.216 which is a link-local address (http://en.wikipedia.org/wiki/Link-local_address) the other one is a regular IP address which according to the documentation should be determined by DHCP. The PC has a regular IP address and send the queries using the regular non-link-local address and ignore any responses with link-local addresses. This is an intentional check to prevent duplicate answers, What I don't understand is why is the camera not answering using the regular IP. Link-local are fallback when there is no other mechanism to assign addresses. This should not be the case here (I am assuming you have a functional DHCP service on the network). I will have another look as this issue and see if I can come up with a patch around this, but I think you should revisit the camera configuration. Cheers Pierre On 2012-03-05, at 11:12, David R Robison wrote: > No I never see the service added. Even running with the jmdns browser, > clicking on the _http._tcp.local I do not see the camera. Here is the > log from the browser: > > TYPE: _http._tcp.local. > TYPE: _axis-video._tcp.local. > TYPE: _rtsp._tcp.local. > TYPE: _ssh._tcp.local. > TYPE: _pelco-camera._tcp.local. > TYPE: _pelco-device._tcp.local. > TYPE: _pelco-skewer._tcp.local. > VALUE CHANGED: type: _http._tcp.local. > ADD: IP Camera - TXB-N-ACGDXV1 > ADD: AXIS 209MFD - 00408C9FBDE4 > RESOLVED: AXIS 209MFD - 00408C9FBDE4 > > > On 3/5/2012 1:40 PM, Pierre Frisch wrote: >> Hi David, >> >> Do you see the service added? You should get 2 service from the camera it I read the packet correctly. One is the http service the other one is the _x_lumenera_mjpeg1._udp.local. If I read the packet correctly you see the _http._tcp.local. service from the camera and it gets resolved. I would like to know if you see the other one in the logs. If the services are visible then will dig to find why they are not resolved. >> >> Cheers >> >> Pierre >> >> >> On 2012-03-02, at 4:01, David R Robison wrote: >> >>> Here is how I start listening for updates >>> >>> try { >>> jmdns = JmDNS.create(); >>> jmdns.addServiceTypeListener(this); >>> } catch (IOException e) { >>> LOG.warn("Error starting Bonjour: " + e); >>> } >>> >>> And here is my listener >>> >>> @Override >>> public void serviceTypeAdded(ServiceEvent event) { >>> jmdns.addServiceListener(event.getType(), this); >>> LOG.info("Service type added: " + event.getType() + " (ignore = >>> " + ignore + ")"); >>> } >>> >>> @Override >>> public void subTypeForServiceTypeAdded(ServiceEvent event) { >>> LOG.info("SubService type added: " + event.getType()); >>> } >>> >>> @Override >>> public void serviceAdded(ServiceEvent event) { >>> LOG.info("Service added : " + event.getName() + "." + >>> event.getType()); >>> } >>> >>> @Override >>> public void serviceRemoved(ServiceEvent event) { >>> LOG.info("Service removed : " + event.getName() + "." + >>> event.getType()); >>> } >>> >>> @Override >>> public void serviceResolved(ServiceEvent event) { >>> LOG.info("Service resolved : " + event.getName() + "." + >>> event.getType()); >>> String service = event.getName() + "." + event.getType(); >>> Inet4Address ipAddress = event.getInfo().getInet4Addresses()[0]; >>> String fullName = event.getInfo().getName(); >>> String hostName = event.getInfo().getHostAddresses()[0]; >>> int port = event.getInfo().getPort(); >>> foundDevices.put(service, new BonjourDevice(service, >>> ipAddress.getHostAddress(), fullName, hostName, port)); >>> } >>> >>> Is there something more I should be doing to resolve the service? >>> >>> On 3/1/2012 12:25 PM, Pierre Frisch wrote: >>>> Ok I have add another session with wireshark. There are 5 message from the lumenera camera. >>>> >>>> Message 2 is a response to the list of services provided that list 2 services, one is a Web server (_http._tcp.local.) the other one is some undocumented service (_x_lumenera_mjpeg1._udp.local.). Message 20 and 64 resolve the Web service providing the standard info. Message 23 and 67 are Address record to provide the IPv4 address of the device. Those messages are responses to queries from the host. I cannot see any attempt to resolve the _x_lumenera_mjpeg1._udp.local. service, could you check that you are actually trying to resolve that service and that there is no typo. >>>> >>>> Thanks >>>> >>>> Pierre >>>> >>>> >>>> If you look at message 2 >>>> >>>> On 2012-03-01, at 7:54, David R Robison wrote: >>>> >>>>> Here is a wireshark http://dl.dropbox.com/u/37804952/bonjour3.pcap. >>>>> Packet 20 appears to be the response form the Lumenera. Does it look OK. >>>>> Is there any reason the jmdns would not read this response? David >>>>> >>>>> On 3/1/2012 9:30 AM, Pierre Frisch wrote: >>>>>> David, >>>>>> >>>>>> Bonjour is a broadcast protocol. We should see the Lumenera camera advertise itself on the network. You can test this by starting wireshark and turning the camera off and on you should see the packets. What I suspect is happening is that the camera does not answer the queries because they don't come from the same subnet. You can try to get your supplier to confirm this. >>>>>> >>>>>> You should also get them to register their service type. Axis is regsitered but neither Lumenera nor Pelco is. It is free and take very little time… >>>>>> >>>>>> Cheers >>>>>> >>>>>> Pierre >>>>>> >>>>>> >>>>>> On 2012-03-01, at 4:44, David R Robison wrote: >>>>>> >>>>>>> Is the basic problem that the response from the lumenera camera comes >>>>>>> from another subnet so that it is not read by the jmdns software? If so >>>>>>> then at least I have something I can go back to the manufacturer with. >>>>>>> Thanks, David >>>>>>> >>>>>>> On 2/29/2012 3:08 PM, David R Robison wrote: >>>>>>>> My basic question is that I would have thought that it would have >>>>>>>> resolved the Lumenera camera. Any idea why its not? I even tried >>>>>>>> putting it on the same subnet. The new address was 192.168.111.130 but >>>>>>>> it did not help. David >>>>>>>> >>>>>>>> On 2/29/2012 2:51 PM, David R Robison wrote: >>>>>>>>> Thanks for looking at this: >>>>>>>>> >>>>>>>>> 192.168.111.75 is the client machine. >>>>>>>>> 192.168.111.30 is the Pelco camera >>>>>>>>> 192.168.111.6 is an Axis camera >>>>>>>>> 169.254.114.216 is a fixed IP of the Lumenera camera. Its other IP is >>>>>>>>> 192.168.25.103. One is fixed in the camera one is set by the user. >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 2/28/2012 6:21 PM, Pierre Frisch wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> I am not sure what you are looking for and how it is supposed to >>>>>>>>>> work. Lumenera is not registered for their service >>>>>>>>>> (http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml) >>>>>>>>>> neither is pelco (pelco-camera or pelco-device). You should scold >>>>>>>>>> your suppliers the registration is free. >>>>>>>>>> >>>>>>>>>> Could you help me by confirming the address of the devices in the >>>>>>>>>> wireshark capture. I am assuming that the PC is 192.168.111.75. I >>>>>>>>>> suppose 192.168.111.30 is a Pelco camera unrelated to you issue. >>>>>>>>>> Similarly 192.168.111.6 is an Axis video unit. It look like the >>>>>>>>>> Lumenera camera is on 169.254.114.216. It is not on the same subnet. >>>>>>>>>> Could please try the same test putting the Lumenera camera on the >>>>>>>>>> same subnet as the PC. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> Pierre >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2012-02-28, at 14:11, David R Robison wrote: >>>>>>>>>> >>>>>>>>>>> I have a digital camera that I am having trouble resolving via >>>>>>>>>>> Bonjour. >>>>>>>>>>> Here is a wireshark showing the Bonjour network traffic >>>>>>>>>>> http://dl.dropbox.com/u/37804952/bonjour3.pcap. I log when a service >>>>>>>>>>> type and service is added and when a service is resolved. Here is my >>>>>>>>>>> logging: >>>>>>>>>>> >>>>>>>>>>> Service type added: _http._tcp.local. (ignore = false) >>>>>>>>>>> Service type added: _axis-video._tcp.local. (ignore = false) >>>>>>>>>>> Service type added: _rtsp._tcp.local. (ignore = false) >>>>>>>>>>> Service type added: _ssh._tcp.local. (ignore = true) >>>>>>>>>>> Service type added: _pelco-camera._tcp.local. (ignore = false) >>>>>>>>>>> Service type added: _pelco-device._tcp.local. (ignore = false) >>>>>>>>>>> Service type added: _pelco-skewer._tcp.local. (ignore = false) >>>>>>>>>>> Service added : IP Camera - TXB-N-ACGDXV1._http._tcp.local. >>>>>>>>>>> Service added : AXIS 209MFD - 00408C9FBDE4._http._tcp.local. >>>>>>>>>>> Service added : AXIS 209MFD - 00408C9FBDE4._axis-video._tcp.local. >>>>>>>>>>> Service added : AXIS 209MFD - 00408C9FBDE4 >>>>>>>>>>> MPEG-4._rtsp._tcp.local. >>>>>>>>>>> Service resolved : AXIS 209MFD - 00408C9FBDE4._http._tcp.local. >>>>>>>>>>> Service resolved : AXIS 209MFD - >>>>>>>>>>> 00408C9FBDE4._axis-video._tcp.local. >>>>>>>>>>> Service resolved : AXIS 209MFD - 00408C9FBDE4 >>>>>>>>>>> MPEG-4._rtsp._tcp.local. >>>>>>>>>>> Service added : IP Camera - >>>>>>>>>>> TXB-N-ACGDXV1._pelco-camera._tcp.local. >>>>>>>>>>> Service resolved : IP Camera - >>>>>>>>>>> TXB-N-ACGDXV1._pelco-camera._tcp.local. >>>>>>>>>>> Service added : IP Camera - >>>>>>>>>>> TXB-N-ACGDXV1._pelco-device._tcp.local. >>>>>>>>>>> Service added : IP Camera - >>>>>>>>>>> TXB-N-ACGDXV1._pelco-skewer._tcp.local. >>>>>>>>>>> Service resolved : IP Camera - >>>>>>>>>>> TXB-N-ACGDXV1._pelco-device._tcp.local. >>>>>>>>>>> Service resolved : IP Camera - >>>>>>>>>>> TXB-N-ACGDXV1._pelco-skewer._tcp.local. >>>>>>>>>>> >>>>>>>>>>> What I do not see in my logging is the _x_lumenera_mpeg1._udp.local >>>>>>>>>>> service type and the Lumenera LE165C service. Am I doing something >>>>>>>>>>> wrong >>>>>>>>>>> or is there an issue with what this camera is sending back? >>>>>>>>>>> >>>>>>>>>>> Thanks, David >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> David R Robison >>>>>>>>>>> Open Roads Consulting, Inc. >>>>>>>>>>> 103 Watson Road, Chesapeake, VA 23320 >>>>>>>>>>> phone: (757) 546-3401 >>>>>>>>>>> e-mail: drr...@op... >>>>>>>>>>> web: http://openroadsconsulting.com >>>>>>>>>>> blog: http://therobe.blogspot.com >>>>>>>>>>> book: >>>>>>>>>>> http://www.xulonpress.com/bookstore/bookdetail.php?PB_ISBN=9781597816526 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This email communication (including any attachments) may contain >>>>>>>>>>> confidential and/or privileged material intended solely for the >>>>>>>>>>> individual or entity to which it is addressed. >>>>>>>>>>> If you are not the intended recipient, please delete this email >>>>>>>>>>> immediately. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>>> >>>>>>>>>>> Keep Your Developer Skills Current with LearnDevNow! >>>>>>>>>>> The most comprehensive online learning library for Microsoft >>>>>>>>>>> developers >>>>>>>>>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, >>>>>>>>>>> MVC3, >>>>>>>>>>> Metro Style Apps, more. Free future releases when you subscribe now! >>>>>>>>>>> http://p.sf.net/sfu/learndevnow-d2d >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Jmdns-discuss mailing list >>>>>>>>>>> Jmd...@li... >>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/jmdns-discuss >>>>>>> -- >>>>>>> >>>>>>> David R Robison >>>>>>> Open Roads Consulting, Inc. >>>>>>> 103 Watson Road, Chesapeake, VA 23320 >>>>>>> phone: (757) 546-3401 >>>>>>> e-mail: drr...@op... >>>>>>> web: http://openroadsconsulting.com >>>>>>> blog: http://therobe.blogspot.com >>>>>>> book: http://www.xulonpress.com/bookstore/bookdetail.php?PB_ISBN=9781597816526 >>>>>>> >>>>>>> >>>>>>> >>>>>>> This email communication (including any attachments) may contain confidential and/or privileged material intended solely for the individual or entity to which it is addressed. >>>>>>> If you are not the intended recipient, please delete this email immediately. >>>>>>> >>>>> -- >>>>> >>>>> David R Robison >>>>> Open Roads Consulting, Inc. >>>>> 103 Watson Road, Chesapeake, VA 23320 >>>>> phone: (757) 546-3401 >>>>> e-mail: drr...@op... >>>>> web: http://openroadsconsulting.com >>>>> blog: http://therobe.blogspot.com >>>>> book: http://www.xulonpress.com/bookstore/bookdetail.php?PB_ISBN=9781597816526 >>>>> >>>>> >>>>> >>>>> This email communication (including any attachments) may contain confidential and/or privileged material intended solely for the individual or entity to which it is addressed. >>>>> If you are not the intended recipient, please delete this email immediately. >>>>> >>> -- >>> >>> David R Robison >>> Open Roads Consulting, Inc. >>> 103 Watson Road, Chesapeake, VA 23320 >>> phone: (757) 546-3401 >>> e-mail: drr...@op... >>> web: http://openroadsconsulting.com >>> blog: http://therobe.blogspot.com >>> book: http://www.xulonpress.com/bookstore/bookdetail.php?PB_ISBN=9781597816526 >>> >>> >>> >>> This email communication (including any attachments) may contain confidential and/or privileged material intended solely for the individual or entity to which it is addressed. >>> If you are not the intended recipient, please delete this email immediately. >>> > > -- > > David R Robison > Open Roads Consulting, Inc. > 103 Watson Road, Chesapeake, VA 23320 > phone: (757) 546-3401 > e-mail: drr...@op... > web: http://openroadsconsulting.com > blog: http://therobe.blogspot.com > book: http://www.xulonpress.com/bookstore/bookdetail.php?PB_ISBN=9781597816526 > > > > This email communication (including any attachments) may contain confidential and/or privileged material intended solely for the individual or entity to which it is addressed. > If you are not the intended recipient, please delete this email immediately. > |