Posted: Mon Nov 03, 2008 11:02 Post subject: can't access several sites since using dd-wrt
Hi,
Last weekend, I installed an Alix-based router with DD-WRT v24 sp1 in our company. It replaces an old full-size Linux server used as a router.
I got it up and running in no time, but there is a problem... I can't access several sites via http, and overall access time is slow. DNS is okay, I can nslookup every address in question.
for example, microsoft.com:
When I try to open it in Firefox, it stays at 'waiting for microsoft.com'. It shows no error message, tough.
Routenverfolgung zu microsoft.com [207.46.232.182] über maximal 30 Abschnitte:
1 <1 ms <1 ms <1 ms 192.168.100.3
2 46 ms 46 ms 47 ms host-77-244-96-2.intrapark.net [77.244.96.2]
3 47 ms 46 ms 46 ms 067-097-244-077.ip-addr.inexio.net [77.244.97.67
]
4 55 ms 49 ms 48 ms 78.141.176.1
5 48 ms 47 ms 48 ms ge-3-1-1.fra20.ip.tiscali.net [213.200.64.57]
6 140 ms 141 ms 141 ms xe-2-0-0.was12.ip.tiscali.net [89.149.185.9]
7 141 ms 141 ms 141 ms 213.200.66.134
8 140 ms 140 ms 141 ms 207.46.41.61
9 142 ms 143 ms 142 ms ge-7-1-0-0.blu-64c-1b.ntwk.msn.net [207.46.33.10
]
10 212 ms 211 ms 211 ms ge-7-1-0-0.wst-64cb-1b.ntwk.msn.net [207.46.34.1
77]
11 212 ms 212 ms 211 ms ge-6-1-0-0.tuk-64cb-1b.ntwk.msn.net [207.46.35.3
3]
12 211 ms 211 ms 212 ms ten1-2.tuk-76c-1a.ntwk.msn.net [207.46.44.50]
13 211 ms 211 ms 211 ms po15.tuk-65ns-mcs-1a.ntwk.msn.net [207.46.35.138
]
14 * * * Zeitüberschreitung der Anforderung.
15 * * * Zeitüberschreitung der Anforderung.
16 *
as you can see, the traceroute fails.
Pinging also fails.
May there be a problem with dd-wrt? I don't think that there is a problem with my ISP exactly the same time I change routers.
I already tried disabling the SPI firewall, no success. Other access restrictions are not in place.
If you have a PPPOE connection it could be a MTU size issue. _________________ "You think you´re real smart. But you´re not smart; you´re dumb. Very dumb. But you´ve met your match in me. "
Colonel Flagg
I tried different DNS servers. Both as forwarder in our company server, and directly on the clients. But this isn't the issue, as nslookup clearly works.
Yes, it's a PPPOE connection. I didn't touch the MTU settings; it's still default 1492. Shall I try setting it to 'automatic'?
It seams like you have a ver long answer time from your ISP in the traceroute. A normal tima should be about 2-3 ms not 46 ms, every answer should then increase 0-3 ms per routerjump.
I think you should check de communication betwen yor dd-wrt router and your ISPs equipment. _________________ __________________________________
Using dd-wrt on WRT54GL and x86
I know I have seen similar problem exactly relating to wrong MTU value.
Normally with PPPoE 1492 is the correct value but with some ISPs this varies... If you don't know correct value then you can tey testing it with trial & error, set it to say 1500 first, test can you get into site now, then increase it to 1600 and try again, so on until you have found the highest value you can still reach the site you can't currently...
While it might not be MTU value I do know this is exactly what I have seen before.
Galne wrote:
It seams like you have a ver long answer time from your ISP in the traceroute. A normal tima should be about 2-3 ms not 46 ms, every answer should then increase 0-3 ms per routerjump.
I think you should check de communication betwen yor dd-wrt router and your ISPs equipment.
Now these times depends totally on nodes in between... Nothing says next hop will take 3ms more...
I know I have seen similar problem exactly relating to wrong MTU value.
Normally with PPPoE 1492 is the correct value but with some ISPs this varies... If you don't know correct value then you can tey testing it with trial & error, set it to say 1500 first, test can you get into site now, then increase it to 1600 and try again, so on until you have found the highest value you can still reach the site you can't currently...
You mean lowering it?
Default for Ethernet is 1500 and it may be higher when using jumboframes (Gigabit and 10Gigabit), but if his ISP requires higher than 1500 every customer at that ISP would have difficulties.
Smaller MTU simply means more non-fragmented packets.
Indeed, my bad. I did meant to lower it, I did throw the example value at random, ofcourse it needs to be lower than the 1500 or 1492 PPPoE default, like say 1300 and try from that...
bjoeg wrote:
Smaller MTU simply means more non-fragmented packets.
Whatever it is technically, practically this is still just the case I have seen many times before, some operators just need to have some odd MTU value instead of "default maximum" which is that 1492 for PPPoE...