Hi Jae,
That does help, thank you. I'm still slightly perplexed as to why the
following works:
$ dns-sd -P "iTunes@work" _daap._tcp . 13689 something.local 127.0.0.1
whereas the following doesn't:
$ dns-sd -R "iTunes@work" _daap._tcp . 13689
and neither does this (where 10.0.1.4 is the IP address for my machine
on my local subnet):
$ dns-sd -P "iTunes@work" _daap._tcp . 13689 something.local 10.0.1.4
It seems to me that all of these should be equivalent. At first I
figured that iTunes was probably deliberately blocking access to any
machine not on the same subnet as the interface used to connect to it.
But then I tried proxying port 80 from my work machine in the same
way, and it fails in the same way:
$ ssh -N -L 10080:my_work_machine:80 my_office_gateway &
$ dns-sd -P "Webserver@work" _http._tcp . 10080 something.local
127.0.0.1 &
$ curl something.local.:11180
HTTP/1.1 200 OK
[...]
$ curl locke.local.:11180 # (locke.local is my
primary .local address)
[...after some time...]
curl: (7) couldn't connect to host
$ curl 10.0.1.4:11180
[immediately]
curl: (7) couldn't connect to host
I really don't understand what's going on here, because the following
works fine (fetching data from my local webserver):
$ curl locke.local.:80
HTTP/1.1 200 OK
[...]
$ curl 10.0.1.4:80
HTTP/1.1 200 OK
[...]
Again, any clues gratefully appreciated!
Best wishes,
Hamish
P.S. I eagerly await the Zeroconf-to-Zeroconf Toolkit :)
On 7/20/07, Jae Woo Lee <email@hidden> wrote:
You can look at the dns-sd source code (included in the mDNSResponder
source download from Apple) to see exactly what it's doing.
Basically when invoked with -P option, it takes 2 additional
arguments: host name and IP address. Normally dns-sd will use your
own .local hostname to register the service, but when the hostname is
given it'll use that instead. And it also injects an 'A' DNS record
into the local mdns, mapping the hostname to the given IP address.
This lets you "proxy-register" a service that is hosted on some other
machine.
In your dns-sd -P command line below, what's really happening is that
it is trying to add an 'A' record mapping "localhost" into 127.0.0.1,
which is getting rejected because it's not a name that ends
with .local, but it still works because the SRV record for the
service itself is going through with the hostname "localhost" and the
DNS resolver is resolving it to 127.0.0.1 without the help of mdns.
If you replace the "localhost" with "something.local.", it'll work
without giving you that error message.
Hope this helps.
- Jae
p.s.) Incidentally, in a few days we are going to release a piece of
open-source software we named Zeroconf-to-Zeroconf Toolkit, which
will let you do what you're trying to do with the SSH tunnel and
more, so you might wanna keep an eye on that.
On Jul 20, 2007, at 11:53 AM, Hamish Allan wrote:
> Hi,
>
> Is there a description anywhere of exactly how the -P option
differs
> from the -R for the dns-sd utility? The man page doesn't
document it.
>
> The reason I ask is that if I set up an ssh tunnel, e.g.:
>
> $ ssh -N -L 13689:my_work_machine:3689 my_office_gateway
>
> and then do:
>
> $ dns-sd -R "iTunes@work" _daap._tcp . 13689
>
> iTunes won't connect, but if I do:
>
> $ dns-sd -P "iTunes@work" _daap._tcp . 13689 localhost 127.0.0.1
>
> that works, even though it reports "Got a reply for localhost:
> Error -65538".
>
> Any clues gratefully appreciated.
>
> Thanks,
> Hamish
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Bonjour-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/bonjour-dev/jae%
> 40cs.columbia.edu
>
> This email sent to email@hidden
