Date: Mon, 13 Apr 2009 10:33:07 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Max Laier <max@love2party.net> Cc: Tim Kientzle <kientzle@freebsd.org>, Robert Watson <rwatson@freebsd.org>, Julian Elischer <julian@elischer.org>, freebsd-arch@freebsd.org Subject: Re: getting a callback ip address for nfsv4 client Message-ID: <Pine.GSO.4.63.0904131024160.21566@muncher.cs.uoguelph.ca> In-Reply-To: <200904130025.31771.max@love2party.net> References: <Pine.GSO.4.63.0903301733120.17182@muncher.cs.uoguelph.ca> <Pine.GSO.4.63.0904121515220.27116@muncher.cs.uoguelph.ca> <49E25816.9010907@freebsd.org> <200904130025.31771.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 12 Apr 2009, Max Laier wrote: [Tim's good stuff snipped] > > Well, the client also needs to listen at the address - that is a local > decision. For now, it just listens on INADDR_ANY, but I suppose there's an argument for adding an option to the daemon to set an address, to restrict it to listening on one interface? (I do currently have a sysctl variable for overriding what rtalloc1() returns, but that requires manual intervention. There is an argument for setting the port#. Does someone have to set the port in the NAT gateway manually or is there a protocol/library for doing that? > This is much like the problem with active mode FTP - and it has the > same problems with NAT (i.e. the NAT service must be aware of the protocol and > translate the address inside). The alternative is to use things like UPnP to > retrieve an external address mapping ... there are libraries to deal with > that. > Are these libraries in FreeBSD-CURRENT? If so, please point me towards them, so I can take a look. Since the callback daemon starts out in userland, talking to userland libraries to handle NAT shouldn't be a problem. Thanks for the help sofar, rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.63.0904131024160.21566>