My concern is that certain fields appear to contain dynamic information like the software version (see "srcvers=120.2) and other information (what does "35CF2488F02660B1" mean ?).
The only way it seems to collect this information is to connect the device to local net, run Bonjour Browser or run "dns-sd –Z" command on a MAC and copy and paste results into your DNS configs. If certain data is dynamic then, you are out of luck. -Neil -- Neil Johnson Network Engineer The University of Iowa Phone: 319 384-0938 Fax: 319 335-2951 Mobile: 319 540-2081 E-Mail: neil-john...@uiowa.edu From: Joel Coehoorn <jcoeho...@york.edu<mailto:jcoeho...@york.edu>> Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> Date: Tuesday, July 10, 2012 7:22 PM To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>" <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> Subject: Re: [WIRELESS-LAN] Apple Petition If those entries work, and are all that is needed, then we're not far from full support. It seems like we could get a tool or set of scripts to automate creating/modifying the needed records. Sent from my iPad On Jul 10, 2012, at 7:11 PM, "Johnson, Neil M" <neil-john...@uiowa.edu<mailto:neil-john...@uiowa.edu>> wrote: We looked into DNS-SD, but with entries like this (example taken from an earlier e-mail from Oscar Silva at the Univ. or Texas , and confirmed by our own testing): _airplay._tcp PTR utnet-appletv._airplay._tcp utnet-appletv._airplay._tcp SRV 0 0 7000 utnet-appletv.bonjour.utexas.edu<http://utnet-appletv.bonjour.utexas.edu>. ; Replace with unicast FQDN of target host utnet-appletv._airplay._tcp TXT "deviceid=28:E7:CF:DB:6E:E0" "features=0x39f7" "model=AppleTV2,1" "pw=1" "srcvers=120.2" _raop._tcp PTR 28E7CFDB6EE0@utnet-appletv._raop._tcp<mailto:28E7CFDB6EE0@utnet-appletv._raop._tcp> 28E7CFDB6EE0@utnet-appletv._raop._tcp<mailto:28E7CFDB6EE0@utnet-appletv._raop._tcp> SRV 0 0 49152 utnet-appletv.bonjour.utexas.edu<http://utnet-appletv.bonjour.utexas.edu>. ; Replace with unicast FQDN of target host 28E7CFDB6EE0@utnet-appletv._raop._tcp<mailto:28E7CFDB6EE0@utnet-appletv._raop._tcp> TXT "txtvers=1" "ch=2" "cn=0,1,2,3" "da=true" "et=0,3" "md=0,1,2" "pw=true" "sv=false" "sr=44100" "ss=16" "tp=UDP" "vn=65537" "vs=120.2" "am=AppleTV2,1" "sf=0x4" _appletv-v2._tcp PTR 35CF2488F02660B1._appletv-v2._tcp 35CF2488F02660B1._appletv-v2._tcp SRV 0 0 3689 utnet- appletv.bonjour.utexas.edu<http://appletv.bonjour.utexas.edu>. ; Replace with unicast FQDN of target host 35CF2488F02660B1._appletv-v2._tcp TXT "txtvers=1" "hG=00000000-06f6-4f5d-0171-0bcc51d34d14" "MniT=167845888" "fs=2" "Name=utnet-appletv" "PrVs=65538" "DFID=2" "EiTS=1" "MiTPV=196611" _sleep-proxy._udp PTR 70-35-60-63\032utnet-appletv._sleep-proxy._udp 70-35-60-63\032utnet-appletv._sleep-proxy._udp SRV 0 0 55597 utnet-appletv.bonjour.utexas.edu<http://utnet-appletv.bonjour.utexas.edu>. ; Replace with unicast FQDN of target host 70-35-60-63\032utnet-appletv._sleep-proxy._udp TXT "" required for every Apple TV (and no direction from Apple on what entries/fields are actually required) our DNS admins were ready with pitch forks and torches if we attempted saddle them with the the responsibility of trying to maintain records for 100's such devices (not to mention printers, etc.). -Neil -- Neil Johnson Network Engineer The University of Iowa Phone: 319 384-0938 Fax: 319 335-2951 Mobile: 319 540-2081 E-Mail: neil-john...@uiowa.edu<mailto:neil-john...@uiowa.edu> From: Garry Peirce <pei...@maine.edu<mailto:pei...@maine.edu>> Reply-To: "pei...@maine.edu<mailto:pei...@maine.edu>" <pei...@maine.edu<mailto:pei...@maine.edu>> Date: Tuesday, July 10, 2012 10:15 AM To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>" <WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> Subject: Re: [WIRELESS-LAN] Apple Petition I’m in support of the collective request to help enable further operational flexibility, although also not sure Apple will feel enough pressure to assist. To the first item: ‘That Apple establish a way for Apple TV's (and other Bonjour/Airplay enabled devices) be accessible across multiple IPv4 and IPv6 sub-nets.” Isn’t this item solved to a degree by wide area DNS-SD? If not, I assume this is left open to solve by either making it use a routable mcast addr or by creating some non-standard solution. Controls will be needed to make sense of all the advertised services and possibly for security/privacy reasons. I would think navigating a large Bonjour enabled subnet for a production service must be an ugly exercise - nevermind if enabled to pass L2 boundaries. Who remembers those IPX service filtering ACLs? Request #2 might soon follow to network vendors to be able to support Bonjour service filtering. For production services, wide area DNS-SD seems a better tool to me, as opposed to using the wild west of zeroconf end device advertisements or some special hardware solution. We’ve trialed it (static entries) for printing and it seems to work well. This leverages our existing DNS infrastructure, allows for control of the advertised entries, and a uniform naming convention making it easier to identify the service. One could also opt to block 224.0.0.251 altogether, if there is concern about unnecessary device traffic. So in tandem to supporting this request, I’d also be interested in anyone’s recap of their wide area DNS-SD (WAB) environment, the services being advertised , how it is scaling, and any major stumbling blocks. From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Lee H Badman Sent: Monday, July 09, 2012 4:00 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] Apple Petition Please consider this- as we get to the point where we have an agreed on document, say by this Friday, and we find an online petition site to use where individuals can "sign" on in whatever form that takes before we close the signing window and present it to Apple- are each one of us able to do so on behalf of our institutions or organizations? If you need to seek permission, now is the time. If a CIO or Director is the only one allowed to make such public-facing declarations on behalf of your school/or org, it would be good to start working the notion. Ideally, no one would overstep their position by jumping on this worthy endeavor. Lee H. Badman Wireless Architect/Network Engineer Information Technology and Services Adjunct Instructor, iSchool Syracuse University 315 443-3003 From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU]<mailto:[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU]>On Behalf Of Andy Voelker Sent: Monday, July 09, 2012 12:44 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] Apple Petition That confuses me as well. It is obviously built in to many other iOS devices (iPod Touch, iPad) and has been for some time. Why the change? I suspect it just due to the GUI difference. If so, that’s easily fixable. -- Andy Voelker Manager of Student Computing in the Technology Commons WCU Staff Senator Western Carolina University Check the status of your IT requests at any time at http://help.wcu.edu/ ! From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU]<mailto:[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU]>On Behalf Of Voll, Toivo Sent: Friday, July 06, 2012 1:28 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> Subject: Re: [WIRELESS-LAN] Apple Petition Also, for me, the lack of support for WPA2-Enterprise is a head-scratcher. If they go through the trouble of supporting the rest of the encryption schemes, and obviously support it on a bunch of their other products, why randomly leave it out of some products? I’d prioritize that a bit more, personally. -- Toivo Voll Network Engineer Information Technology Communications University of South Florida ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
