Prevent 127.0.0.1 from redirecting to myhome.westell.com?

Hi Orzel,

The standard way to view webpages you put in your Sites folder is to open a web browser and go to http://your.computer.address/~yourusername/

Can you access the page(s) in your site folder using the above link? Obviously, change the yourusername bit with your short username. Additionally, ensure that the slash is at the end.

Kryten

You have a routing problem. 127.0.0.1 should route to your loopback interface and not your default gateway. Please go into /Applications/Utilities/Terminal and enter:

$ netstat -rn

and post the results.

Okay, it's not a routing problem. Or rather, your routing tables look fine. There's one more thing I'd like to see:

$ route get 127.0.0.1

before I start to think this is a browser problem. There's no reason for the browser to invoke any sort of name lookup. Perhaps clearing the cache, and failing that, resetting the browser entirely will do the trick. I will try to think of other reasons, other than lo0 being down, for a connection not to go though the loopback interface.

try adding 127.0.0.1 and 192.168.168.1 in that order to the DNS box in sharing preferences>network>configure.

if that doesnt work try using open dns numbers in the first position(s) between 127.0.0.1 and the router address.

I love bizarre problems. Your router is already set to 192.168.1.1, we saw that in the netstat output. We also see that your loopback interface appears to be fine. There is absolutely no reason I know of for a simple request along the loopback interface to go out to a router if the interface is up, and yours is. So this is getting to be interesting, and a chance to learn something new.

If you wouldn't mind, could we check if the requests are even hitting the loopback interface? Could you:

$sudo tcpdump -ilo0

and then enter http://127.0.0.1/ in your browser. We ought to see something in the tcpdump output. What we see or don't see will tell us a lot.

One more thing, in another window could you:

$ping -c2 127.0.0.1

and see if there if any traffic in the tcpdump window?

The ping looks normal, except for being surrounded by traffice to and from port 1010 (surf) and netinfo. I don't know anything about surf (other than it's implicated in the Doly trojan horse) and I suspect it's the cause of your troubles. The http dialog starts well, too, but there's only 827 bytes transferred before a torrent of traffic between surf and netinfo. I suspect it's netinfo which is calling for the lookup. Your DNS server is coming back with it's own domain and netinfo is prepending your hostname.

What I can't tell you is why your http traffic is being diverted. If I were a suspicious sort, I would suspect the Doly trojan horse. But in my experience people usually do these things to themselves in the name of protection. Perhaps it's some sort of web filtration service. What's happened is that you've changed DNS servers, and this one isn't coming back with a NO answer, it's returning it's own domain. I know of several that do - opendns for one, so they can post their own web page when a host can't be found.

If you want to find out who's doing this enter:

$lsof -i:1010

and you should get the process I suspect is diverting your traffic. (Then again, I may be way off, this is uncharted territory.)

No problem, this is interesting. To get deeper, the only way I know is to sniff the packets and see what's going on. What I'm saying is that the initial route is happening just as it should: a dialog is taking place on the lo0 interface. But somewhere in that dialog must be something which causes a redirect, which causes a lookup. The lookup (may be in your machine, check /etc/resolv.conf) is coming back valid, partial, and causing the failure.

Might be something really simple, maybe a configuration in apache. I wouldn't worry about Doly, it only affected Windows. I know this is more output, but I'd do:

$sudo tcpdump -ilo0 -A -s0 'port 80'

and examine the http that follows. That should lead to something interesting.

I'm glad your satisfied. I still think there's a problem, and that there shouldn't be any name lookup for requests along the loopback interface, but the bottom line is that it's working. And that's great.