On Mon, 31 Jul 2006 23:28:31 GMT Jeff Liebermann wrote: | On 31 Jul 2006 21:49:03 GMT, snipped-for-privacy@ipal.net wrote: | |>However, if the virtual host "routerlogin.net" is used, it gets a |>different response from the server: | | What's a virtual host?
When multiple names are hosted at a single IP address, this generally uses a method called virtual hosting. The various hostnames are then configured as virtual hosts. Since a GET or POST request only provides the URI for the request, an additional HTTP header called "Host:" is used. In the following example, what I typed is just:
============================================================================= telnet 209.102.192.73 80 GET / HTTP/1.1 Host: ka9wgn.ham.org
telnet 209.102.192.73 80 GET / HTTP/1.1 Host: kb9ydn.ham.org
=============================================================================
The blank lines are an extra newline.
Now here is what the whole session looks like. These are virtual host redirects for URLs based on ham radio call sign:
============================================================================= phil@canopus:/home/phil 824> telnet 209.102.192.73 80 Trying 209.102.192.73... Connected to 209.102.192.73. Escape character is '^]'. GET / HTTP/1.1 Host: ka9wgn.ham.org
HTTP/1.1 301 Found Date: Tue, 01 Aug 2006 02:39:46 +0000 Server: Apache/1.3.33 (Unix) PHP/4.3.10 mod_ssl/2.8.22 OpenSSL/0.9.7d Location:
formatting link
text/html; charset=iso-8859-1 Content-length: 416 Connection: close
301 KA9WGN foundKA9WGN Location:
formatting link
your browser does not automatically take you to theKA9WGN web site, try clicking on the URL shown. Connection closed by foreign host. phil@canopus:/home/phil 825> telnet 209.102.192.73 80 Trying 209.102.192.73... Connected to 209.102.192.73. Escape character is '^]'. GET / HTTP/1.1 Host: kb9ydn.ham.org
HTTP/1.1 301 Found Date: Tue, 01 Aug 2006 02:42:21 +0000 Server: Apache/1.3.33 (Unix) PHP/4.3.10 mod_ssl/2.8.22 OpenSSL/0.9.7d Location:
formatting link
text/html; charset=iso-8859-1 Content-length: 428 Connection: close
301 KB9YDN foundKB9YDN Location:
formatting link
browser does not automatically take you to theKB9YDN web site, try clicking on the URL shown. Connection closed by foreign host. phil@canopus:/home/phil 826>
=============================================================================
| | 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: |
formatting link
| I get the Netgear web site as you point out using lynx. | | Yet,
formatting link
routerlogin.com, and routerlogin.net all | point to 64.202.189.170. Weird.
And that's the problem. They could fix it by setting the IP address to be 192.168.1.1.
|>Tell me how making an HTTP request for http://192.168.1.1/ to |>the router itself and getting a redirect to
formatting link
|>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 did change the IP addresses of the routers I had. When I accessed the main address page of the routers ( http://169.254.175.166/ ) it would still do the redirect to
formatting link
so if someone did change it on theirs, they might find they cannot get in. However, if they access it as
formatting link
then it works.
One option for Netgear is to make the web server their DNS points to for routerlogin.net do a web redirect to http://192.168.1.1/basicsetting.htmand that would work as long as the IP address remains the same.
A nice goal would be to make there be a way to always access the router no matter how it has been configured, without necessarily erasing NVRAM with a long reset. I'd have to put some thought into that. But it seems like a solution is to employ IP aliasing where the router would have the original IP address plus whatever new one it is set to. That can cause problems because the change of IP may be motivated to keep
192.168.1.1 open for other equipment to be configured by plugging into a switch rather than pulling connections out of the existing LAN. This might be done with a link local address (link local is 169.254.0.0/16).
Personally, I think they should have stuck with http://192.168.1.1/ and let cool names like "routerlogin.net" just have that IP address.
|>I agree that the wireless part should be off until proper configuration. | | You're the first to agree with that.
I'd make an exception with a "radio setup button" that can temporarily turn the radio on to allow configuring by radio for the very few users that don't have any ethernet (e.g. the router is connects to broadband and is an access point for a laptop that has wireless and no ethernet). The controlling machine would have to be told to run in "setup master" mode, which would start by doing a Diffie-Hellman key exchange to start some encryption. As long as there was no man-in-the-middle attack, it can then proceed to either auto-configure or allow access as 192.168.1.1 over the air. If nothing connected to this router within 1 minute, the "radio setup" mode would be abandoned. If something does connect, then nothing is would be allowed to (it would not do another DH key exchange unless the button is pressed again). Not perfect security, but perhaps adequate.
|>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: |
formatting link
| which I think the GUM (great unwashed masses) could handle.
Either of those could work, though the "setup" alone method would need to have the DNS interception active, either in the router (this could miss those with other net connections) or in the Windows software they provide (potentially dangerous as it might leave permanent changes in the registry that could be wrong). I think the name they chose is OK. They just didn't deploy it well.
|>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.
Right. But we at least should not have been interfered with. By that, the URL http://192.168.1.1/ should just work as expected, and not try to redirect to
formatting link
unless routerlogin.net goes to IP address 192.168.1.1 in all points of view. Making both URLs work is not hard: just ignore the virtual host name (in which case ANY name that goes to 192.168.1.1 would work).
|>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.
If the internet path is in that direction, yes, it could. And it should for those with no current internet access at all. If the internet access goes some other way and DNS is not intercepted, then at least having 192.168.1.1 in the registered name server for that hostname would still get them accessing 192.168.1.1. Then it is a matter of making sure packets addressed to 192.168.1.1 get to 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: |
formatting link
| or on DSLReports at: |
formatting link
| | 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!"
Intel did that. I gave up trying to find their forums about a few months.
| 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.
Sounds like a need for independent forums. Too bad Netgear to not likely inform anyone where that would be. Might well be more than one, too.