The OTHER problem with Netgear WGT624 (and probably others)

This isn't exactly a wireless issue. But it did happen with wireless
devices and people buying those might see this some day:

When I first got those 2 Netgear routers, one thing I found was that the
instructions said to use a browser URL like:

http://routerlogin.com/

to connect to the router. I just assumed they had configured the DNS for
that domain name to have an A-record for 192.168.1.1 or whatever IP they
made default if not that usual one. But it didn't work. I actually got
the Netgear web site. Strange. So I checked the actual DNS:

routerlogin.com. 3600 IN A 64.202.189.170

WTF? Idiots! Since 192.168.1.1 was pinging OK, I just went to:

http://192.168.1.1/

as is usual for most other products. But that got me the same web site.
Now this is getting strange. Surely they didn't package their whole web
site into this box. I cut off my internet connection and tried again.
This time nothing. It just hung waiting. But then I could see that a
redirect had been made to their web site. So I put in a fake zone for
routerlogin.com in my DNS server to fool the browser, pointing it to
192.168.1.1 to see what that would do. Maybe their Windows program (not
in use here since I'm running on Linux) was intercepting lookups of the
routerlogin.com domain. As feared, it caused a redirect loop.

So maybe their Windows program was actually _routing_ 64.202.189.170
to the attached device? I thought about testing that, but never got
around to it.

In the documentation I downloaded, I found where it had some examples
which showed configuration URLs with pathnames in them. I tried one
of those, but with "192.168.1.1" instead of "routerlogin.com":

http://192.168.1.1/basicsetting.htm

That got me in OK, so I just set up a local page with that as a link
along with all my setting info.

What I'm still curious about is how Netgear expected this to work. Now
I can see they might want to have more people visit their web site to do
things like get them to register so they can send them more marketing
junk. But it took me in a round about way to their main web site, not
one that would do something like urge me to register the product and give
me a real working link once I did.

And what if I had no internet connection at all because this device was
to be that connection only after it gets set up?

What were those guys thinking, especially with http://192.168.1.1/ not even
working (because it redirects to http://routerlogin.com/ instead).

The wireless HP printer I bought, and the cheap nameless bridge (MAC lookup
revealed Senao International of Taiwan) my sister-in-law gave me, worked
just fine with http://192.168.1.1/ to reach their setup.

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2006-07-29-(E-Mail Removed) |
|------------------------------------/-------------------------------------|

Works fine here (and everywhere else I've used it):

>nslookup routerlogin.com

Non-authoritative answer:
Name: routerlogin.com
Address: 192.168.1.1

You may have something wrong in your configuration.

On 29 Jul 2006 17:32:26 GMT, phil-news-(E-Mail Removed) wrote in
<(E-Mail Removed)>:

>This isn't exactly a wireless issue. But it did happen with wireless
>devices and people buying those might see this some day:
>
>When I first got those 2 Netgear routers, one thing I found was that the
>instructions said to use a browser URL like:
>
> http://routerlogin.com/
>
>to connect to the router. I just assumed they had configured the DNS for
>that domain name to have an A-record for 192.168.1.1 or whatever IP they
>made default if not that usual one. But it didn't work. I actually got
>the Netgear web site. Strange. So I checked the actual DNS:
>
>routerlogin.com. 3600 IN A 64.202.189.170
>
>WTF? Idiots! Since 192.168.1.1 was pinging OK, I just went to:
>
> http://192.168.1.1/
>
>as is usual for most other products. But that got me the same web site.
>Now this is getting strange. Surely they didn't package their whole web
>site into this box. I cut off my internet connection and tried again.
>This time nothing. It just hung waiting. But then I could see that a
>redirect had been made to their web site. So I put in a fake zone for
>routerlogin.com in my DNS server to fool the browser, pointing it to
>192.168.1.1 to see what that would do. Maybe their Windows program (not
>in use here since I'm running on Linux) was intercepting lookups of the
>routerlogin.com domain. As feared, it caused a redirect loop.
>
>So maybe their Windows program was actually _routing_ 64.202.189.170
>to the attached device? I thought about testing that, but never got
>around to it.
>
>In the documentation I downloaded, I found where it had some examples
>which showed configuration URLs with pathnames in them. I tried one
>of those, but with "192.168.1.1" instead of "routerlogin.com":
>
> http://192.168.1.1/basicsetting.htm
>
>That got me in OK, so I just set up a local page with that as a link
>along with all my setting info.
>
>What I'm still curious about is how Netgear expected this to work. Now
>I can see they might want to have more people visit their web site to do
>things like get them to register so they can send them more marketing
>junk. But it took me in a round about way to their main web site, not
>one that would do something like urge me to register the product and give
>me a real working link once I did.
>
>And what if I had no internet connection at all because this device was
>to be that connection only after it gets set up?
>
>What were those guys thinking, especially with http://192.168.1.1/ not even
>working (because it redirects to http://routerlogin.com/ instead).
>
>The wireless HP printer I bought, and the cheap nameless bridge (MAC lookup
>revealed Senao International of Taiwan) my sister-in-law gave me, worked
>just fine with http://192.168.1.1/ to reach their setup.

--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>

On Sun, 30 Jul 2006 18:51:11 GMT John Navas <(E-Mail Removed)> wrote:
| Works fine here (and everywhere else I've used it):
|
| >nslookup routerlogin.com
|
| Non-authoritative answer:
| Name: routerlogin.com
| Address: 192.168.1.1
|
| You may have something wrong in your configuration.

Nope.

Here is a trace dependent on nothing but the root hint file, which is
configured correctly:

================================================== ===========================
phil@hadar:/home/phil 1173> dig +trace a routerlogin.com

; <<>> DiG 9.2.3 <<>> +trace a routerlogin.com
;; global options: printcmd
.. 36021 IN NS G.ROOT-SERVERS.NET.
.. 36021 IN NS H.ROOT-SERVERS.NET.
.. 36021 IN NS I.ROOT-SERVERS.NET.
.. 36021 IN NS J.ROOT-SERVERS.NET.
.. 36021 IN NS K.ROOT-SERVERS.NET.
.. 36021 IN NS L.ROOT-SERVERS.NET.
.. 36021 IN NS M.ROOT-SERVERS.NET.
.. 36021 IN NS A.ROOT-SERVERS.NET.
.. 36021 IN NS B.ROOT-SERVERS.NET.
.. 36021 IN NS C.ROOT-SERVERS.NET.
.. 36021 IN NS D.ROOT-SERVERS.NET.
.. 36021 IN NS E.ROOT-SERVERS.NET.
.. 36021 IN NS F.ROOT-SERVERS.NET.
;; Received 244 bytes from 209.102.192.85#53(209.102.192.85) in 10 ms

com. 172800 IN NS F.GTLD-SERVERS.NET.
com. 172800 IN NS G.GTLD-SERVERS.NET.
com. 172800 IN NS H.GTLD-SERVERS.NET.
com. 172800 IN NS I.GTLD-SERVERS.NET.
com. 172800 IN NS J.GTLD-SERVERS.NET.
com. 172800 IN NS K.GTLD-SERVERS.NET.
com. 172800 IN NS L.GTLD-SERVERS.NET.
com. 172800 IN NS M.GTLD-SERVERS.NET.
com. 172800 IN NS A.GTLD-SERVERS.NET.
com. 172800 IN NS B.GTLD-SERVERS.NET.
com. 172800 IN NS C.GTLD-SERVERS.NET.
com. 172800 IN NS D.GTLD-SERVERS.NET.
com. 172800 IN NS E.GTLD-SERVERS.NET.
;; Received 505 bytes from 192.112.36.4#53(G.ROOT-SERVERS.NET) in 43 ms

routerlogin.com. 172800 IN NS park17.secureserver.net.
routerlogin.com. 172800 IN NS park18.secureserver.net.
;; Received 123 bytes from 192.35.51.30#53(F.GTLD-SERVERS.NET) in 61 ms

routerlogin.com. 3600 IN A 64.202.189.170
routerlogin.com. 3600 IN NS PARK17.SECURESERVER.NET.
routerlogin.com. 3600 IN NS PARK18.SECURESERVER.NET.
;; Received 107 bytes from 64.202.165.120#53(park17.secureserver.net) in 38 ms

phil@hadar:/home/phil 1174> dig +trace a routerlogin.net

; <<>> DiG 9.2.3 <<>> +trace a routerlogin.net
;; global options: printcmd
.. 35942 IN NS A.ROOT-SERVERS.NET.
.. 35942 IN NS B.ROOT-SERVERS.NET.
.. 35942 IN NS C.ROOT-SERVERS.NET.
.. 35942 IN NS D.ROOT-SERVERS.NET.
.. 35942 IN NS E.ROOT-SERVERS.NET.
.. 35942 IN NS F.ROOT-SERVERS.NET.
.. 35942 IN NS G.ROOT-SERVERS.NET.
.. 35942 IN NS H.ROOT-SERVERS.NET.
.. 35942 IN NS I.ROOT-SERVERS.NET.
.. 35942 IN NS J.ROOT-SERVERS.NET.
.. 35942 IN NS K.ROOT-SERVERS.NET.
.. 35942 IN NS L.ROOT-SERVERS.NET.
.. 35942 IN NS M.ROOT-SERVERS.NET.
;; Received 260 bytes from 209.102.192.85#53(209.102.192.85) in 10 ms

net. 172800 IN NS A.GTLD-SERVERS.net.
net. 172800 IN NS G.GTLD-SERVERS.net.
net. 172800 IN NS H.GTLD-SERVERS.net.
net. 172800 IN NS C.GTLD-SERVERS.net.
net. 172800 IN NS I.GTLD-SERVERS.net.
net. 172800 IN NS B.GTLD-SERVERS.net.
net. 172800 IN NS D.GTLD-SERVERS.net.
net. 172800 IN NS L.GTLD-SERVERS.net.
net. 172800 IN NS F.GTLD-SERVERS.net.
net. 172800 IN NS J.GTLD-SERVERS.net.
net. 172800 IN NS K.GTLD-SERVERS.net.
net. 172800 IN NS E.GTLD-SERVERS.net.
net. 172800 IN NS M.GTLD-SERVERS.net.
;; Received 502 bytes from 198.41.0.4#53(A.ROOT-SERVERS.NET) in 48 ms

routerlogin.net. 172800 IN NS park17.secureserver.net.
routerlogin.net. 172800 IN NS park18.secureserver.net.
;; Received 120 bytes from 192.5.6.30#53(A.GTLD-SERVERS.net) in 50 ms

routerlogin.net. 3600 IN A 64.202.189.170
routerlogin.net. 3600 IN NS PARK17.SECURESERVER.net.
routerlogin.net. 3600 IN NS PARK18.SECURESERVER.net.
;; Received 104 bytes from 64.202.165.120#53(park17.secureserver.net) in 37 ms

phil@hadar:/home/phil 1175> dig +trace ptr -x 64.202.189.170

; <<>> DiG 9.2.3 <<>> +trace ptr -x 64.202.189.170
;; global options: printcmd
.. 35866 IN NS B.ROOT-SERVERS.NET.
.. 35866 IN NS C.ROOT-SERVERS.NET.
.. 35866 IN NS D.ROOT-SERVERS.NET.
.. 35866 IN NS E.ROOT-SERVERS.NET.
.. 35866 IN NS F.ROOT-SERVERS.NET.
.. 35866 IN NS G.ROOT-SERVERS.NET.
.. 35866 IN NS H.ROOT-SERVERS.NET.
.. 35866 IN NS I.ROOT-SERVERS.NET.
.. 35866 IN NS J.ROOT-SERVERS.NET.
.. 35866 IN NS K.ROOT-SERVERS.NET.
.. 35866 IN NS L.ROOT-SERVERS.NET.
.. 35866 IN NS M.ROOT-SERVERS.NET.
.. 35866 IN NS A.ROOT-SERVERS.NET.
;; Received 276 bytes from 209.102.192.85#53(209.102.192.85) in 10 ms

64.in-addr.arpa. 86400 IN NS chia.ARIN.NET.
64.in-addr.arpa. 86400 IN NS dill.ARIN.NET.
64.in-addr.arpa. 86400 IN NS BASIL.ARIN.NET.
64.in-addr.arpa. 86400 IN NS henna.ARIN.NET.
64.in-addr.arpa. 86400 IN NS indigo.ARIN.NET.
64.in-addr.arpa. 86400 IN NS epazote.ARIN.NET.
64.in-addr.arpa. 86400 IN NS figwort.ARIN.NET.
;; Received 196 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 62 ms

189.202.64.in-addr.arpa. 86400 IN NS cns1.secureserver.net.
189.202.64.in-addr.arpa. 86400 IN NS cns2.secureserver.net.
;; Received 99 bytes from 192.5.6.32#53(chia.ARIN.NET) in 41 ms

170.189.202.64.in-addr.arpa. 3600 IN PTR pwfwd-v01.prod.mesa1.secureserver.net.
189.202.64.in-addr.arpa. 3600 IN NS cns1.secureserver.net.
189.202.64.in-addr.arpa. 3600 IN NS cns2.secureserver.net.
;; Received 166 bytes from 64.202.167.31#53(cns1.secureserver.net) in 34 ms

phil@hadar:/home/phil 1176>
================================================== ===========================


Now notice their really weird ... STATEFUL ... redirect:

================================================== ===========================
phil@hadar:/home/phil 1176> lynx -mime_header http://routerlogin.com/
HTTP/1.1 302 Moved Temporarily
Content-Length: 0
Location: /?ABCDEFGH

phil@hadar:/home/phil 1177> lynx -mime_header http://routerlogin.com/
HTTP/1.1 302 Moved Temporarily
Content-Length: 0
Location: /?ABCDEFGH

phil@hadar:/home/phil 1178> lynx -mime_header 'http://routerlogin.com/?ABCDEFGH'
HTTP/1.1 302 Moved Temporarily
Content-Length: 0
Location: /

phil@hadar:/home/phil 1179> lynx -mime_header http://routerlogin.com/
HTTP/1.1 302 Found
Connection: close
Date: Mon, 31 Jul 2006 02:01:26 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Location: http://www.netgear.com
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 139

<html><head><title>Object moved</title></head><body>
<h2>Object moved to <a href="http://www.netgear.com">here</a>.</h2>
</body></html>
phil@hadar:/home/phil 1180>
================================================== ===========================

As you can see, when the direct goes from http://routerlogin.com/ to
http://routerlogin.com/?ABCDEFGH and back to http://routerlogin.com/
again, THEN it gets a redirect to http://www.netgear.com (missing /
is theirs). On a couple other machines I have gone to the site
http://routerlogin.com/ many many times in a row and it keeps giving
that "/?ABCDEFGH" redirect _until_ I go to where it redirected then
come back and finally get a different redirect. It apparently remembers
the IP address. But what for? No obvious reason.

You can check this at other sites, too:

http://www.dnsstuff.com/tools/lookup...n.com&type=ALL
http://www.dnsstuff.com/tools/lookup...n.net&type=ALL
http://www.dnsreport.com/tools/dnsre...outerlogin.com
http://www.dnsreport.com/tools/dnsre...outerlogin.net

So ... nothing wrong with my configuration. I wonder where YOUR DNS
lookup is getting the address 192.168.1.1. It's definitely NOT from
the authoritative DNS servers. Can you trace it down to where?

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2006-07-30-(E-Mail Removed) |
|------------------------------------/-------------------------------------|

phil-news-(E-Mail Removed) hath wroth:

>So ... nothing wrong with my configuration. I wonder where YOUR DNS
>lookup is getting the address 192.168.1.1. It's definitely NOT from
>the authoritative DNS servers. Can you trace it down to where?

It's a bit messy. Think of it as something like a wireless hot spot
splash page. No matter where you point your browser, it goes to the
setup wizard.

The way it worked on a WGR614 is that the internal DNS cache always
redirects routerlogin.com to the setup wizard. I think (not sure)
that pointing a web browser to any URL ends up at the initial setup
wizard.

routerlogin.net always goes to the general setup web page.

192.168.1.1 goes to the setup wizard. Once the user has setup and
saved the general page with a WAN connection, 192.168.1.1 now goes to
the general setup web page.

The URL:
http://192.168.1.1/basicsetting.htm
bypasses the setup wizard and goes directly to the general setup page.

When you run nslookup, host, or dig to query the nameservers, you are
bypassing the routers internal DNS cache and going to the internet to
lookup the domain. That's fine, but that's not what your router is
doing. A DNS server might resolve routerlogin.com to anything it
wants, but if the local DNS cache redirects lookups to routerlogin.com
to the setup wizard, it doesn't matter.

--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

On Sun, 30 Jul 2006 23:01:58 -0700 Jeff Liebermann <(E-Mail Removed)> wrote:
| phil-news-(E-Mail Removed) hath wroth:
|
|>So ... nothing wrong with my configuration. I wonder where YOUR DNS
|>lookup is getting the address 192.168.1.1. It's definitely NOT from
|>the authoritative DNS servers. Can you trace it down to where?
|
| It's a bit messy. Think of it as something like a wireless hot spot
| splash page. No matter where you point your browser, it goes to the
| setup wizard.

Only if the address being referenced actually goes to or through the
device that is intercepting it. But before it is set up, that is not
working.


| The way it worked on a WGR614 is that the internal DNS cache always
| redirects routerlogin.com to the setup wizard. I think (not sure)
| that pointing a web browser to any URL ends up at the initial setup
| wizard.

Only if you already have the router set up.


| routerlogin.net always goes to the general setup web page.

It actually went to www.netgear.com.


| 192.168.1.1 goes to the setup wizard. Once the user has setup and
| saved the general page with a WAN connection, 192.168.1.1 now goes to
| the general setup web page.

192.168.1.1 redirected to routerlogin.net. routerlogin.net redirected
in a round-about way to www.netgear.com.


| The URL:
| http://192.168.1.1/basicsetting.htm
| bypasses the setup wizard and goes directly to the general setup page.
|
| When you run nslookup, host, or dig to query the nameservers, you are
| bypassing the routers internal DNS cache and going to the internet to
| lookup the domain. That's fine, but that's not what your router is
| doing. A DNS server might resolve routerlogin.com to anything it
| wants, but if the local DNS cache redirects lookups to routerlogin.com
| to the setup wizard, it doesn't matter.

The router wasn't serving internet access. It was being set up to serve
a printer, a laptop, and a hop to my brother's house. Internet traffic
would not go to it or through it.

So, did some Netgear engineer ASS-U-ME that everyone would always be
putting it in a network where all internet traffic would go through the
router?

It would have been a workable scheme IF:

1. They did NOT redirect http://192.168.1.1/ to http://routerlogin.net/
2. They DID put in an A-record for routerlogin.net with 192.168.1.1.

Under such a scheme, a lookup that did go to the real internet for the
A-record of routerlogin.net would get 192.168.1.1 and the HTTP request
under the hostname routerlogin.net would go to the router as long as the
router had its default configuration and 192.168.1.0/24 was a local net
(as it would have to be for any other router that uses 192.168.1.1 in
the normal way). Had the cutsie URL http://routerlogin.net/ somehow
failed, there would at least be the fallback of using http://192.168.1.1/
to get to the setup page.

Any other manufacturers doing this nonsense? Note that I am NOT referring
to merely having a hostname in place of 192.168.1.1 as the nonsense. What
I am referring to as the nonsense is BREAKING that scheme with the redirect
from 192.168.1.1 to the hostname AND the bogus A-record in DNS.

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2006-07-31-(E-Mail Removed) |
|------------------------------------/-------------------------------------|

phil-news-(E-Mail Removed) hath wroth:

>| routerlogin.net always goes to the general setup web page.
>
>It actually went to www.netgear.com.

Ummm... try again:

nslookup routerlogin.net
Server: uranus.cruzio.com
Address: 63.249.95.9

Non-authoritative answer:
Name: routerlogin.net
Address: 64.202.189.170

Whois shows it owned by GoDaddy.com.
RDNS shows it as:
64.202.189.170 PTR record: pwfwd-v01.prod.mesa1.secureserver.net.
[TTL 3600s]

If you try:
http://64.202.189.170
You get:
This website is temporarily unavailable, please try again later.

I'm on a Linksys router which does not have the internal DNS cache
redirect routerlogin.com and routerlogin.net to who knows where.

>192.168.1.1 redirected to routerlogin.net. routerlogin.net redirected
>in a round-about way to www.netgear.com.

See above. routerlogin.com resolves to the same IP as
routerlogin.net.

>So, did some Netgear engineer ASS-U-ME that everyone would always be
>putting it in a network where all internet traffic would go through the
>router?

Yep. That's exactly what they're doing. Products must be user
friendly and beginning users should have a favorable out of box
experience. Never mind the hackers.

>Any other manufacturers doing this nonsense? Note that I am NOT referring
>to merely having a hostname in place of 192.168.1.1 as the nonsense. What
>I am referring to as the nonsense is BREAKING that scheme with the redirect
>from 192.168.1.1 to the hostname AND the bogus A-record in DNS.

Not that I know of. Personally, I think it's a good idea that was
only half way implimented. What I want is for the wireless part of
the router to be turned off until the owner sets the SSID, encryption
key, and router password. I call it "secure by default". While only
2wire.com is doing this, it sorta looks like Netgear started on the
same path, but got fouled up trying to setup internet access
automagically. I agree with you that it was badly done and it could
have been done better. Someone has to be first.

I hate to tell you this, but you're going to be running into this
manner of nonsense almost continuously. You're going to find static
routes that don't work, DHCP renewal oddities, limited routeing,
insipid firewall rule sets, lack of monitoring, etc with commodity
wireless routers. I suggest you obtain a WRT54G or similar Broadcom
router, install one of the numerous alternative Linux firmware
replacements, and deal with your creative topology and personal
preferences from either the command line or the source code.

--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

On 31 Jul 2006 02:19:40 GMT, phil-news-(E-Mail Removed) wrote in
<(E-Mail Removed)>:

>On Sun, 30 Jul 2006 18:51:11 GMT John Navas <(E-Mail Removed)> wrote:
>| Works fine here (and everywhere else I've used it):
>|
>| >nslookup routerlogin.com
>|
>| Non-authoritative answer:
>| Name: routerlogin.com
>| Address: 192.168.1.1
>|
>| You may have something wrong in your configuration.
>
>Nope.

Then why does it work for me and everyone else?

I'd be willing to bet you do.

--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>

On Mon, 31 Jul 2006 09:57:01 -0700 Jeff Liebermann <(E-Mail Removed)> wrote:
| phil-news-(E-Mail Removed) hath wroth:
|
|>| routerlogin.net always goes to the general setup web page.
|>
|>It actually went to www.netgear.com.
|
| Ummm... try again:
|
| nslookup routerlogin.net
| Server: uranus.cruzio.com
| Address: 63.249.95.9
|
| Non-authoritative answer:
| Name: routerlogin.net
| Address: 64.202.189.170
|
| Whois shows it owned by GoDaddy.com.
| RDNS shows it as:
| 64.202.189.170 PTR record: pwfwd-v01.prod.mesa1.secureserver.net.
| [TTL 3600s]
|
| If you try:
| http://64.202.189.170
| You get:
| This website is temporarily unavailable, please try again later.

However, if the virtual host "routerlogin.net" is used, it gets a
different response from the server:

================================================== ===========================
phil@canopus:/home/phil 816> lynx -mime_header 'http://64.202.189.170/'
HTTP/1.1 200 OK
Connection: close
Date: Mon, 31 Jul 2006 21:21:14 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 228


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>

This website is temporarily unavailable, please try again later.


<!-- pageok -->
<!-- 01 -->
<!-- 5.1-->
</html>phil@canopus:/home/phil 817> lynx -mime_header 'http://routerlogin.net/'
HTTP/1.1 302 Found
Connection: close
Date: Mon, 31 Jul 2006 21:21:26 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Location: http://www.netgear.com
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 139

<html><head><title>Object moved</title></head><body>
<h2>Object moved to <a href="http://www.netgear.com">here</a>.</h2>
</body></html>
phil@canopus:/home/phil 818>
================================================== ===========================


| I'm on a Linksys router which does not have the internal DNS cache
| redirect routerlogin.com and routerlogin.net to who knows where.
|
|>192.168.1.1 redirected to routerlogin.net. routerlogin.net redirected
|>in a round-about way to www.netgear.com.
|
| See above. routerlogin.com resolves to the same IP as
| routerlogin.net.

I never said it didn't. Both always have resolved to 64.202.189.170.

================================================== ===========================
phil@hadar:/home/phil 1208> dig +trace +noall +answer a routerlogin.com | fgrep routerlogin
routerlogin.com. 3600 IN A 64.202.189.170
phil@hadar:/home/phil 1209> dig +trace +noall +answer a routerlogin.net | fgrep routerlogin
routerlogin.net. 3600 IN A 64.202.189.170
phil@hadar:/home/phil 1210> dig +trace +noall +answer a www.routerlogin.com | fgrep routerlogin
www.routerlogin.com. 3600 IN CNAME routerlogin.com.
routerlogin.com. 3600 IN A 64.202.189.170
phil@hadar:/home/phil 1211> dig +trace +noall +answer a www.routerlogin.net | fgrep routerlogin
www.routerlogin.net. 3600 IN CNAME routerlogin.net.
routerlogin.net. 3600 IN A 64.202.189.170
phil@hadar:/home/phil 1212>
================================================== ===========================


|>So, did some Netgear engineer ASS-U-ME that everyone would always be
|>putting it in a network where all internet traffic would go through the
|>router?
|
| Yep. That's exactly what they're doing. Products must be user
| friendly and beginning users should have a favorable out of box
| experience. Never mind the hackers.

Excuse me, but an assumption that is NOT true does NOT make user
friendly. Tell me how you think that the CORRECT way that *I*
suggested would be in any way LESS user friendly. The way I had
suggested would work in at least more cases than the way they
have it now, and not break in any cases that work their way.

Tell me how making an HTTP request for http://192.168.1.1/ to
the router itself and getting a redirect to http://routerlogin.net/
is enhancing friendliness when in some cases that will fail to go
back to the router (because they didn't configured the DNS zone for
routerlogin.net with 192.168.1.1 for an IP address).


|>Any other manufacturers doing this nonsense? Note that I am NOT referring
|>to merely having a hostname in place of 192.168.1.1 as the nonsense. What
|>I am referring to as the nonsense is BREAKING that scheme with the redirect
|>from 192.168.1.1 to the hostname AND the bogus A-record in DNS.
|
| Not that I know of. Personally, I think it's a good idea that was
| only half way implimented. What I want is for the wireless part of
| the router to be turned off until the owner sets the SSID, encryption
| key, and router password. I call it "secure by default". While only
| 2wire.com is doing this, it sorta looks like Netgear started on the
| same path, but got fouled up trying to setup internet access
| automagically. I agree with you that it was badly done and it could
| have been done better. Someone has to be first.

I agree that the wireless part should be off until proper configuration.

I don't see how what Netgear did is the same thing. What it appears to
me that they tried to do was make something that is easier to remember
and less prone to error that the user can type into their browser. For
you and me, typing "192.168.1.1" isn't a problem. For the Average Joe
it can be, at least if they have to remember it a few minutes later and
would otherwise keep having to check the manual.

For MOST people, what they tried to do probably works. The scenario
would probably be someone with a Windows computer (their software sets
the Windows gateway to 192.168.1.1) and NOT currently on another means
of internet access I did not test a certain aspect of it, that being
a faked DNS reply from the router to give 192.168.1.1 for routerlogin.net.
If that faked DNS reply was done, it would work in a lot of scenarios.

But it would NOT work in some others where another means of internet
access is active.


| I hate to tell you this, but you're going to be running into this
| manner of nonsense almost continuously. You're going to find static
| routes that don't work, DHCP renewal oddities, limited routeing,
| insipid firewall rule sets, lack of monitoring, etc with commodity
| wireless routers. I suggest you obtain a WRT54G or similar Broadcom
| router, install one of the numerous alternative Linux firmware
| replacements, and deal with your creative topology and personal
| preferences from either the command line or the source code.

Yeah, this is actually somewhat typical nonsense. Oddly enough, it is
also easily fixable, and without having to upgrade the firmware on the
routers already in the field. That is to simply put an A-record in the
DNS zones for routerlogin.{com,net} giving 192.168.1.1. It is TWO errors
that caused this. Fixing ONE of them makes it work better. The DNS one
is the easier to fix. Get me the phone number of the person who is in
the position of authority to fix it, and I'll be glad to call him/her and
explain in detail why they should change DNS. Then it will be up to them
to choose to do things better or not.

In the mean time, yes, I will be hunting for good pricing for WRT54GL from
a reputable dealer and soon buy 2 or 3 of those. So far the best price I
have found is, oddly enough, at Dell.Com. They just have a 1-2 week ship.

FYI, I won't be stopping at loading an OpenWRT firmware. I'll be hacking
on it eventually.

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2006-07-31-(E-Mail Removed) |
|------------------------------------/-------------------------------------|

On Mon, 31 Jul 2006 19:29:57 GMT John Navas <(E-Mail Removed)> wrote:
| On 31 Jul 2006 02:19:40 GMT, phil-news-(E-Mail Removed) wrote in
| <(E-Mail Removed)>:
|
|>On Sun, 30 Jul 2006 18:51:11 GMT John Navas <(E-Mail Removed)> wrote:
|>| Works fine here (and everywhere else I've used it):
|>|
|>| >nslookup routerlogin.com
|>|
|>| Non-authoritative answer:
|>| Name: routerlogin.com
|>| Address: 192.168.1.1
|>|
|>| You may have something wrong in your configuration.
|>
|>Nope.
|
| Then why does it work for me and everyone else?
|
| I'd be willing to bet you do.

You'd lose this one. Enter "routerlogin.com" at any of the online DNS
lookup sites and see what you get.

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2006-07-31-(E-Mail Removed) |
|------------------------------------/-------------------------------------|

On 31 Jul 2006 21:49:03 GMT, phil-news-(E-Mail Removed) wrote:

>However, if the virtual host "routerlogin.net" is used, it gets a
>different response from the server:

What's a virtual host?

I'm starting to get the picture. If I try:
http://64.202.189.170/
I get the "This site is temporarily...." message.

However, if I try:
http://www.routerlogin.com
I get the Netgear web site as you point out using lynx.

Yet, www.routerlogin.com, routerlogin.com, and routerlogin.net all
point to 64.202.189.170. Weird.

>|>So, did some Netgear engineer ASS-U-ME that everyone would always be
>|>putting it in a network where all internet traffic would go through the
>|>router?
>|
>| Yep. That's exactly what they're doing. Products must be user
>| friendly and beginning users should have a favorable out of box
>| experience. Never mind the hackers.

>Excuse me, but an assumption that is NOT true does NOT make user
>friendly. Tell me how you think that the CORRECT way that *I*
>suggested would be in any way LESS user friendly. The way I had
>suggested would work in at least more cases than the way they
>have it now, and not break in any cases that work their way.

Your suggestion as to how it should operate is certainly better than
what has been implimented by Netgear. Neither method has much to do
with "user friendly". All I think they were trying to do is point the
web browser to the setup wizard if the router was NOT configured.
Where they goofed is to point also point it to the general setup page
after it was configured. That doesn't do anything useful.

>Tell me how making an HTTP request for http://192.168.1.1/ to
>the router itself and getting a redirect to http://routerlogin.net/
>is enhancing friendliness when in some cases that will fail to go
>back to the router (because they didn't configured the DNS zone for
>routerlogin.net with 192.168.1.1 for an IP address).

If it works the way you suggest (internet nameserver redirects
routerlogin.net to 192.168.1.1), then it will certainly fail if the
user changes the router IP address. However, I haven't seen any
evidence that this is done by an internet based DNS server. The
redirection seems to be done by the DNS cache inside the router. If
this is true, then a change to the router IP address would not cause
the redirection to fail.

>I agree that the wireless part should be off until proper configuration.

You're the first to agree with that.

>I don't see how what Netgear did is the same thing.

They didn't. I think they tried to do it the "right way(tm)" but got
muddled in the redirection to the setup wizard.

>What it appears to
>me that they tried to do was make something that is easier to remember
>and less prone to error that the user can type into their browser. For
>you and me, typing "192.168.1.1" isn't a problem. For the Average Joe
>it can be, at least if they have to remember it a few minutes later and
>would otherwise keep having to check the manual.

They could easily have set it up so that any URL or IP address would
be redirected to the setup wizard. Once successfully setup and saved,
things could return to normal. If they were serious about an easy way
to get to the setup, then it should have been something like:
http://setup
The caching DNS server doesn't need a FQDN to do a lookup and can
easily default to a local domain. However, if this is unpalateable,
it could have been something like:
http://setup.netgear.com
which I think the GUM (great unwashed masses) could handle.

>For MOST people, what they tried to do probably works.

The greatest good for the greatest number. Geeks, hackers, you and I
don't qualify.

>If that faked DNS reply was done, it would work in a lot of scenarios.

Yep. Good idea, bad implimentation.

>But it would NOT work in some others where another means of internet
>access is active.

Only if you insist that the lookup go to the internet. It could
easily be trapped in the local DNS cache in the router.

>Get me the phone number of the person who is in
>the position of authority to fix it, and I'll be glad to call him/her and
>explain in detail why they should change DNS. Then it will be up to them
>to choose to do things better or not.

I don't have any way to get to the vendors directly. You might try
writing a suitable bug report and posting it on the Netgear forums at:
http://forum1.netgear.com/support/
or on DSLReports at:
http://www.dslreports.com/forum/equip,9?r=946

Oh swell, the Netgear forums are now apparently dead.

"Thanks to all the NETGEAR customers who made the forum such a
success! As a result of the popularity, NETGEAR has decided to
reintroduce the forum in a new and improved format. While the
changes are underway, we’ll be using our forum resources to make
the conversion, and the existing forum will be unavailable.

In the meantime, questions that would have been directed to the
forum can be sent to NETGEAR’s email support , where they will
receive the personal attention of our agents. We hope to see you
again when the forum reopens!"

What this PR announcement forgot to mention was that the user forums
were being largely ignored by Netgear and that Netgear was only
archiving the most recent 50 or so messages, which was about 1-2 days
worth of postings. The only answers I ever received were erased
before I could read them. Nice job Netgear.

--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831-336-2558 (E-Mail Removed)
# http://802.11junk.com (E-Mail Removed)
# http://www.LearnByDestroying.com AE6KS