[avahi] breaking avahi through vpn

[Sebastien Estienne]

On 2/13/06, Trent Lloyd <lathiat at bur.st> wrote:
> On Sunday 12 February 2006 22:23, Sebastien Estienne wrote:
> > On 2/12/06, Lennart Poettering <lennart at poettering.net> wrote:
> > > On Sun, 12.02.06 13:32, Sebastien Estienne (sebastien.estienne at gmail.com)
> wrote:
> > > > what about doing something like the relaying gateways that i suggested
> > > > to fill the need for zeroconf with vpn?
> > > >
> > > > Would it work? they wouldn't forward the query, but exchange the
> > > > browsing list on a regular basis (or something equivalent)
> > > >
> > > > what are your opinions?
> > >
> > > I suppose you mean something similar to Samba's "remote browse sync"
> > > option?
> >
> > exactly
> >
> > > I don't think it is feasible to implement something like this for
> > > mDNS. In contrast to SMB servers mDNS responders never compile
> > > something like a complete browse list, hence there is nothing two
> > > servers could exchange.
> >
> > the idea would be to periodically browse for all available service
> > (like service_type_browser , avahi-browse -a) and transfer the results
> > over unicast to the other deamon.
>
> That's really ugly
Sorry for the ugliness, any more constructive idea?

>
>  a) That would cause excessive network traffic all the time, especially bad
> on wireless networks
>  b) Not all devices advertise the magic needed for the service type browser,
> so you wont get everything.
>
> Cheers,
> Trent
>
> >
> > I agree that it may be a bit hackish though... and that uniscat dns-sd
> > (wide-area) is a better solution. We just loose the ease of setup as
> > wide-area needs a dns server and configuration on each clients
> > (unicast domain + key/shared secret for publishing), that's why it's
> > not really zeroconf as zero configuration.
> >
> > As far as i know wide area is already widely used in miscrosoft active
> > directory.
> >
> > > Avahi already does forwarding of mDNS traffic between multiple
> > > interfaces. If latency is good enough you may use that to bridge two
> > > networks.
> > >
> > > Unicast DNS is definitely preferable when it comes to high latency
> > > links. There's no point in trying to modify mDNS in a way that it is
> > > capable of coping with high latency. There is already unicast DNS which
> > > is perfectly capable to deal with situations like that.
> >
> > the idea wasn't to modify mdns, but just implementing a separated deamon
> >
> > this idea is not really new, some project already did things a bit like
> > this: - rendezvousproxy:
> > http://ileech.sourceforge.net/index.php?content=RendezvousProxy-News
> > - zerospan:
> > http://www.zerospan.org/
> >
> > > Lennart
> > >
> > > --
> > > Lennart Poettering; lennart [at] poettering [dot] net
> > > ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/
> > > _______________________________________________
> > > avahi mailing list
> > > avahi at lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/avahi
> >
> > --
> > Sebastien Estienne
>
> --
> Trent Lloyd
> Bur.st Networking Inc.
> _______________________________________________
> avahi mailing list
> avahi at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/avahi
>


--
Sebastien Estienne