PDA

View Full Version : Austin RR and www.showeq.net



datadog
11-02-2004, 06:50 PM
Anyone in the Austin area on Road Runner cable having trouble connecting here?

I have a friend that cannot access the website here from her home ISP.

We eliminated her router just to be sure it wasnt local and she is unable to connect from any PC's on her network, so its not her machine.

Traceroute from her desktop looks like this

Tracing route to showeq.net [64.91.228.225]
over a maximum of 30 hops:

1 7 ms 5 ms 5 ms 10.36.0.1
2 6 ms 7 ms 9 ms srp4-0.austtxc-rtr1.austin.rr.com [66.68.2.238]

3 13 ms 8 ms 7 ms srp0-0.austtxrdc-rtr1.austin.rr.com [66.68.1.254]
4 9 ms 7 ms 8 ms pos1-0.austtxrdc-rtr3.texas.rr.com [66.68.1.102]

5 12 ms 11 ms 12 ms son0-1-1.dllatxl3-rtr1.texas.rr.com [24.93.33.49]
6 21 ms 18 ms 17 ms son2-0-1.hstqtxl3-rtr1.texas.rr.com [24.93.34.34]
7 20 ms 17 ms 17 ms pop1-hou-P4-0.atdn.net [66.185.133.157]
8 17 ms 19 ms 18 ms bb1-hou-P2-0.atdn.net [66.185.150.148]
9 23 ms 26 ms 23 ms bb1-dls-P6-0.atdn.net [66.185.152.132]
10 22 ms 21 ms 22 ms pop1-dls-P0-0.atdn.net [66.185.133.81]
11 24 ms 23 ms 23 ms verio.atdn.net [66.185.133.94]
12 45 ms 53 ms 45 ms p16-3-0-0.r01.chcgil06.us.bb.verio.net [129.250.5.84]
13 45 ms 46 ms 46 ms p16-1-0-0.r00.chcgil06.us.bb.verio.net [129.250.5.76]
14 50 ms 51 ms 51 ms p4-1-0-0.r01.sfldmi01.us.bb.verio.net [129.250.5.109]
15 53 ms 57 ms 50 ms ge-0-3-0.a00.sfldmi01.us.ra.verio.net [129.250.28.116]
16 136 ms 54 ms 54 ms p1-0-1-3.a00.sfldmi01.us.ce.verio.net [192.217.224.182]
17 56 ms 54 ms 53 ms lw-cs1-ge01.liquidweb.com [209.59.157.2]
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21

Windows IP config info from the machine we are testing from


Windows IP Configuration


Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : austin.rr.com
IP Address. . . . . . . . . . . . : 70.112.75.215
Subnet Mask . . . . . . . . . . . : 255.255.240.0
Default Gateway . . . . . . . . . : 70.112.64.1


From testing it seems like either her IP or subnet are being ACL'd somewhere along the way. She opened a ticket with Road Runner, but they have not responded yet.

She tried telnetting to port 80 at www.showeq.net and got "Could not open connection to the host on port 80". I am pretty sure if the host was denying via host.deny she would be getting 'connection refused'.

Anyone else experiencing anything like this?

EDIT: BTW, this started sometime mid-late september. Just before Zaphod osted the 5.0.0.15 tarballs.

Freakyuno
11-03-2004, 08:42 PM
Doesnt look like a roadrunner problem at all from your trace.

At the 7th hop you have left roadrunners network, and are relying on the relay of out of network routers. It's most likely a DNS issue with a co-op they are leasing their lines from onto the backbone.

Your going to play hell getting that resolved through a ticket with tech support.

datadog
11-04-2004, 03:29 AM
I should have mentioned that DNS is resolving correctly.

This is really frustrating =(

Tor K'tal
11-04-2004, 04:10 AM
It's an issue internally to lquidweb.com or beyond, probably intentional.


9 52 ms 60 ms 52 ms bpr1-so-6-0-0.SanJoseEquinix.savvis.net [208.173.54.9]
10 57 ms 63 ms 54 ms dcr1-so-3-2-0.SanFranciscosfo.savvis.net [208.173.54.66]
11 94 ms 103 ms 95 ms dcr1-loopback.Chicago.savvis.net [208.172.2.99]
12 116 ms 117 ms 104 ms acr1-so-0-0-0.Chicago.savvis.net [208.172.3.54]
13 117 ms 104 ms 104 ms liquid-web-inc.Chicago.savvis.net [208.172.3.174]
14 104 ms 103 ms 106 ms lw-br1-ge03.liquidweb.com [209.59.157.10]
15 124 ms 103 ms 114 ms lw-cs1-ge01.liquidweb.com [209.59.157.2]
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
up to 30... request timed out

I basicly ended up getting idential results as I'm posting this message. If I were to take a stab at it. For security reasons liquidweb prevents the query packet (it has a real protocal name that escapes me at the moment) that are used in PING and Traceroute and stuff from pathing through very deeply into their network. They may even prevent them from going all the way through even if they aren't destend for them. I just did a plane old ping to www.showeq.net (ping -t [www.]showeq.net) and got 100% packet loss, which obviously can't be true as I have started this message and if you are reading it I succeeded in posting it.

~ TK

Onimaru
11-04-2004, 11:48 AM
yeah, looks like they are blocking ICMP traffic. Which is actually a bad thing since it is used for more than just ping/traceroute, like negotiating MTU.

datadog
11-04-2004, 04:15 PM
Well, i just provided the traceroute to show that it wasnt a routing problem. She also cant telnet to port 80 (or connect via her web browswer).

As far as the traceroute goes, most firewalls dont respond to ICMP requests, which is what usually causes those asterisks you see at the end of the trace. Im not worried about that at all.

Its the web connection to http://www.showeq.net that has me stumped.

Freakyuno
11-04-2004, 06:11 PM
ICMP Echo is specifically what trace's and pings use I believe, but your right, thoes should have nothing to do with valid HTTP requests running over TCP. Have you tried putting the ip address to seq.sf.net into her browser instead?

[66.35.250.209]

You should get the entry that no web page was found, which means that you are reaching the site correctly, but that they are using host headers for virtual servers.

Onimaru
11-05-2004, 11:29 AM
If the person in question is on DSL and uses PPPoE then the chances are its because of the ICMP block. If the person is on PPPoE, make sure that their MTU is set to 1492.

datadog
11-05-2004, 01:26 PM
No PPPoE.

Standard cable modem service with Road Runner.

Again, im not concerned about the ICMP stuff, i just provided that as background.

She is unable to connect to www.showeq.net on any port or protocol. This seems to be a IP or network being blocked, I just cant figure out by who or where.

I guess I'll have to dig up a tcptraceroute utility and see what that shows.

fuqjak
11-17-2004, 03:54 PM
There was a post about problems like this on the Austin RR cable modem and Cable service forums on Yahoo. They stateed that the problem was a result of the ISP HOSTING the sight not reigstering the DNS properly or something like that (RDNS?)

I live in Austin and can't get the ShowEQ.Net address from my home connection but can get there just fine from here at work.

Fatal
11-17-2004, 04:39 PM
the fact that you can traceroute by name shows dns is working.
You are making it through the Savvis network to the hosting provider and appears to be blocked there by a firewall. I get a !A from one of my routers which means that host is administratively blocking the packet.

It looks like it should be working fine. If I had to guess, I would say the hosting company itself is blocking a large block of address space registered to RR in austin.

Cryonic
11-17-2004, 07:17 PM
Probably put in a general block to deal with spam coming from trojaned/infected systems on the RR network. Same reason that Cox put in an outbound port 25 block for their network.

Freakyuno
11-18-2004, 11:16 AM
Probably put in a general block to deal with spam coming from trojaned/infected systems on the RR network. Same reason that Cox put in an outbound port 25 block for their network.

Dont think thats the same thing at all. Almost all ISP's in the residential class block outbound port 25. (I.E SMTP protocol). It's for 2 reasons usually. One is to force you to use their mail service so they can market you through it. Secondly, it's to keep people from hosting their own mail servers.

You could really stretch, and say that they are trying to be responsible for their network and that spam email is a diffinate problem, but that would be a huge stretch, since you can smarthost to their server without even authenticating to it through AUTH LOGIN, and relay using their Exchange servers, as long as your behind a cable modem registered on their network.

Cryonic
11-18-2004, 11:33 AM
Actually the block for port 25 outbound is a recent change and even though you can still utilize their mail server, they have rules in place on it as well even though you don't need to authenticate to reduce spam from their network.

Cox was the first ISP I've ever heard of that blocked outbound port 25 from their network. Prior to that every ISP I've had (and still have since I'm not on cox) don't block any outbound ports.

wambat
01-11-2005, 01:49 PM
I am having the same issue unable to directly connect to the showeq.net website. Though the help of some people in the IRC channel I was able to connect using a proxy. Its possible for some reason I'm being blocked after getting to liqiudweb's network. I contacted them through email and recieved this reply (which I kind of expected)

"I apologize for this however I really can not discuss this servers routing or firewall without verification that you are the account holder."

I am at a loss as to where to go to from here

Wambat

Ratt
01-11-2005, 02:53 PM
I will be moving the SEQ server to another webhost in the near future, so hopefully these problems will be resolved.

KaL
01-12-2005, 01:04 PM
When I was working at an ISP, we had this happen occasionally. Some people just couldn't access certain sites.

1. Your IP address (usually a large block of IP addresses) is blocked for some reason (usually because of spam) by one of the other providers.

You would have to contact someone at the destination network and see if they could troubleshoot it with you, or if your provider is nice and offers that kind of support, they can open a trouble ticket and troubleshoot it with the destination network for you. If it turns out you *are* indeed blocked, you could ask them nicely to remove the block.

2. Your packets are returning via a different route (asymmetrical routing) and one of the hops of the return path doesn't have a route to your IP block.

Some providers have holes in their routing, due to lack of proper transit or peering coverage. Sometimes they have a glitch in their router and it's just missing a some routes. The routing is a technical problem -- easy to fix if it's just an error, but IMPOSSIBLE to get them motivated to fix if it's a peering/transit issue because that involves $$$money$$$.