On Dec 14, 2010, at 5:52 PM, Nat! wrote: > > Am 14.12.2010 um 22:28 schrieb Dan Shoop: > >> >>> >>> I think it's fairly clever to use snmpwalk, with the result piped through >>> >>> egrep -v >>> '^127\.0\.0.|^169\.254\.|^172\.3[0-1]\.|^172\.2[0-9]\.|^172\.1[6-9]\.|^192\.168\.|^224\.|^2[45][0-9]\.|^10\.' >>> >> >> All you're doing is filtering out what may not be the WAN IP and it doesn't >> account for duplicates returned if the router has any additional VLANs that >> operate or VPNs. That could lead to additional false positives. > > True, though aren't these also usually of the 172.31.xxx.xx variety ? At > least, in my experience they are.
Not at all. They could be RFC1918 addresses or public, depends in the network and CIDR blocks involved. >>> it should be OK in normal configurations and to me it's a better solution, >>> than using whatismyip.com because: >>> >>> a) more robust, you are not at the mercy of another entity, which is not >>> legally required to provide this service 24/7 at no cost for eternity >>> b) more paranoid, whatismyip.com won't "log" him >> >> I just picked whatsmyip from a quick google, there's no dearth of these >> services. > > yeah, but in terms of "things that could go wrong", snmpwalk just is more > robust than whatever internet service, I think that's hard to deny. Won't go > away, client and server are known to be up, etc... Well considering how you can't guarantee that you're culling the right address from the SNMP return that the OP has coughed up I'd say that's a problem. It may work for this particular guy, whch is fine, but it's hardly a rock solid solution. Moreover as I pointed out this is such a well solved problem from various different angles but the OP seems adamant about going about it the hardest way possible. >>> c) more lightweight, technologically better, faster, just local network >>> traffic, less network traffic >> >> Um, it's the same actually. And a HTTP request is lighter weight than a SNMP >> traverse. As far ass network traffic, it's less bytes. >> >> And as I've said, the real solution to knowing what your IP address and have >> a way to get back to your LAN would be to use DNS. Since dyndns (and other >> similar services) do this for free, are lightweight and provide FOSS clients >> to set the DNS entry, it would seem to solve all the problems cleanly. But >> obvious it's too simple. ;) > > I personally also use dyndns for such. But i kinda respect the old unix > mentality too. Yeah well I respect when I had control over /etc/hosts for old time host lookups too but doesn't mean I'm stuck in the past. There's nothing glorious about complex solutions to trivial and well solved non-problems. http://www.dyndns.com/services/dns/dyndns/ is just far too much the solution for this exact problem. And support for it is even built in to many NAT/"routers". And dyndns *is* even supported directly from the router (airport extreme base station) he's using. So it really should have been a no brainer. >> But since the OP has resorted to personal attacks, I could care less. >> > > Ah come on, you aren't that soft skinned. ;) No but I have low tolerance for twits. I try to keep personal attacks out of things, and since you normally go on lists to solicit help it's just poor form to dis those trying to honestly help you. My pajamas remain flame retardant, but that doesn't mean I have to comfort those clearly not interested in level discussion. -d ------------------------------------------------------------------------ Dan Shoop [email protected] GoogleVoice: 1-646-402-5293 aim: iWiring twitter: @colonelmode _______________________________________________ MacOSX-admin mailing list [email protected] http://www.omnigroup.com/mailman/listinfo/macosx-admin
