Hi Hamish,
It looks like the problem lies in your ssh configuration. I think
your ssh is configured to bind only the loopback interface when doing
the forwarding. I bet things will work if you change your ssh
command to specify the address that it should bind to, like this:
ssh -N -L 10.0.1.4:10080:my_work_machine:80 my_office_gateway
or tell it to bind on all interfaces:
ssh -N -L *:10080:my_work_machine:80 my_office_gateway
On Jul 20, 2007, at 9:32 PM, Hamish Allan wrote:
> 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
>>
>>
