On 17/12/2010, at 09:30 , Dan Shoop wrote: >> Dan initially suggested that I use dyndns and things went downhill >> from there... > > Ghod knows why. It's a practical solution already supported by your router > *directly*. All you need to do is configure it.
There is more than one way of addressing the issue of finding the visible IP address of a router. I had suggested one yesterday (check which interface the default route is using), apparently noone has followed up on it. Though I did make a mistake, the IP address listed alongside the ipRouteIfIndex entries appears to be the next hop. Perish the thought that someone would use the Simple Network Management Protocol to, you know, manage their network! > Because it's not returning what you suggest it is. It's returning a list of > VNICs on the device… So it's also a harder way of getting the information too The required information is likely accessible in some manner via SNMP, so one doesn't have to make assumptions about the structure of the upstream network (eg: non-presence of transparent HTTP proxy, existence of third party web service). I expect that the device itself is more than capable of reporting the required information without involving external third parties. >> [Jerry wrote ] >> skynet is the (local) domain of my lan. >> >> [Dan reponds ] >> No it's not. >> >> The local domain of your LAN is .local. Rather than engaging in a pissing contest, the person making the claim that the ".skynet" network is not the local network (i.e.: "The local domain of your LAN is .local") might want to point the apparently unaware party to the relevant material (education is the key to success in these matters): - RFC 1918: Address Allocation for Private Internets - RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses - Multicast DNS entry on Wikipedia (http://en.wikipedia.org/wiki/Multicast_DNS) - Multicast DNS page talking about the '.local' network (http://www.multicastdns.org/) And in fact in researching these references for the "uninformed" party, one might come to realise that a network with an invented TLD on the non-routed side is not actually a "split horizon" since noone is expecting that invented name to be resolved out on the Internet. [[ Aside ]] "Split Horizon" specifically refers to a situation where you use a valid domain name for internal purposes, and have different results returned depending on whether the request comes from inside or outside the private network. Thus 'intranet.mycompany.com.au' might resolve to 172.16.55.22 for clients on the 172.16.x.x network, but returns an NXDOMAIN to everyone else. [[ End Aside ]] The ".local" namespace is reserved for mDNS where the network is automatically configured, and special steps must be taken if the local administrator is perverse enough to want to use ".local" for unicast DNS too. The sensible administrator would leave ".local" alone, for mDNS to handle as it wants. So for the instance of a non-routable private network it is actually "The Right Way" of doing things to invent a TLD that is not resolvable on the greater Internet, that is also not ".local". So ".skynet" is a perfectly acceptable option. >> Most no one needs to have a mail message sent to them to tell them the >> address of >> their IP since any sane person would use a DNS name and not an IP address. The only dynamic DNS services that can be automatically updated by the AirPort's Wide Area Discovery system are paid services. DynDNS allows you to update your free DynDNS service using a web page - a process which free-DynDNS compatible routers hide for you, but the AirPort range of routers do not support. To use the Wide Area Discovery service you must either subscribe to MobileMe (and use Back to My Mac) or subscribe to DynDNS's Custom DNS service. What I don't know yet is whether one can resolve a particular hostname to get the IP address of the home router when using the Back to My Mac service. If someone isn't willing to pay for that service merely to have the convenience of a domain name that points back to the address of their router, there are other alternatives available. One alternative is to find the external IP address through whatever means, and have a script (running on a machine other than the AirPort) which updates the DynDNS service on a regular basis. Another is to find the external IP address and simply mail the address to an external mail account (since one already uses the mail account anyway). The advantage of using DynDNS is that one can save a domain name into various applications (eg: Mail, iSSH) on the iPhone and those services will "just work". Alex _______________________________________________ MacOSX-admin mailing list [email protected] http://www.omnigroup.com/mailman/listinfo/macosx-admin
