Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Hard Harry]

Ok, I think its safe to say the problem is being caused by "[Message:1]no servers found in /etc/resolv.conf, will retry" but you kind of already knew that. And you have already kind of fixed the problem. The question is why the problem is happening. I can think of two possibilities:

1. The firmware is borked
If this is the case then the question is how is your firmware different then Furry's (assuming he can't replicate the issue). Is there a different hardware revision other then DIR-645 A1? Like maybe you have DIR-645 A1 EU and Furry has DIR-645 A1 NA? If so then Its possible it has a slightly different firmware, and that firmware has that bug, even with 1.03.

2. The router is unable to aquire DNS for resolv.conf at the point of the boot where it loads that into the config.
If this is the case, it could have to do with your LPTP connection. Notice the message 1 comes before Message 12. I don't have a emulator for the DIR-645 and don't have experience in the protocol, so what I am saying could be completely wrong, but its a possibility.

Only way I can think to test it is to set router to DHCP and connect it to another router? Then it can aquire DNS through DHCP and see if it saves it to resolv.conf. If it does, its either a ISP issue or a WAN config issue. If it doesn't its probably a firmware bug.

[FurryNutz]

Ok, I have a successful ping using the System Check:
http://forums.dlink.com/index.php?topic=52109.0

Here is a list of connections under Setup/Internet/Manual:


I use manual custom DNS entries. Tested DNS Relay is ON and OFF.

[ambercap]

I checked the label on the bottom, and the h/w version is A1 but the last portion of the part number ends in ...A1E. Perhaps other units have another value here as Hard Harry mentioned. The f/w version is actually printed on the label too (1.01) which I immediately upgraded to 1.03 when I bought it.

I do not see how the problem can be related to the ISP since the router does successfully receive the DNS servers via L2TP when it connects. I suspect there is a f/w bug where it fails to enter these IPs into resolv.conf. There is a good chance that using a different protocol such as PPTP, PPPoE or just DHCP will solve the problem if the bug is limited to the L2TP implementation in the f/w. In which case if other users try L2TP they would see the same problem.

I will have more time over the weekend to play with this and I'll try see if I can use one of the other PP protocols or just DHCP/static to test the DNS somehow. Perhaps I'll have to setup an internal DNS server to test this. (I see the WUI has PP options for Russia/Dual Access too.)

I could also try inserting DNS entries directly into various parts of the config.xml to see if it makes a difference (a bit of a hack here since I don't fully understand how the config entries work together). I could post my config somewhere but it exceeds 20K so I can't just copy and paste it here in the forum.

[ambercap]

I was thinking about the problem and had an idea. I then read http://forums.dlink.com/index.php?topic=46615.0 which reinforced what I was thinking, namely:

Perhaps the DNS IPs are inserted into resolv.conf after they are obtained via L2TP after all, but when the kernel tries to use these to resolve names for requests issued by the router itself, the connection to the DNS server is routed directly via the WAN interface rather than the LAN interface (192.168.0.1). As a result the DNS packet bypasses the L2TP stack and is therefore not routed to the ISP! The only way the DNS server can be reached is via L2TP as it is outside of the cable company's network.

What I will try is to enable DNS relay, then set the secondary DNS to 192.168.0.1 (overriding the value obtained via L2TP). Client DNS requests will be forwarded to the primary DNS as before. The router's own request (via the kernel) to the primary DNS will fail, so the kernel will try the secondary DNS of 192.168.0.1 and connect to the router's own DNS daemon (relay), which in turn will resolve via the primary DNS which should succeed.

Will try it this weekend. I'll also attach a sniffer to the WAN port to try confirm if this is what is happening.

The only thing bugging me about this theory is that if the router tries to connect to various external IPs (such as to ping an IP, update via NTP, or email via SMTP), that works just fine, so connections to these IPs are definitely going via the L2TP encapsulation. In which case why not the same for DNS? Either a route is being added just for DNS (as suggested by Gamification in his post), bypassing L2TP, or these other programs all force the use of the LAN interface guaranteeing connection via L2TP (something the kernel can't do for name resolution - that requires adding a route definition).

[FurryNutz]

I checked my label this morning and I only see A1 on mine. So there maybe some differences between A1 and A1E.

One thing I would recommend after you do your testing, I would phone contact DLink support for your region and talk to someone, say level 2 or higher, higher being preferred as this is somewhat of a low level FW issue that can't be resolved probably by level 1 support.

Please let us know what they say.

I checked the label on the bottom, and the h/w version is A1 but the last portion of the part number ends in ...A1E. Perhaps other units have another value here as Hard Harry mentioned. The f/w version is actually printed on the label too (1.01) which I immediately upgraded to 1.03 when I bought it.

I do not see how the problem can be related to the ISP since the router does successfully receive the DNS servers via L2TP when it connects. I suspect there is a f/w bug where it fails to enter these IPs into resolv.conf. There is a good chance that using a different protocol such as PPTP, PPPoE or just DHCP will solve the problem if the bug is limited to the L2TP implementation in the f/w. In which case if other users try L2TP they would see the same problem.

I will have more time over the weekend to play with this and I'll try see if I can use one of the other PP protocols or just DHCP/static to test the DNS somehow. Perhaps I'll have to setup an internal DNS server to test this. (I see the WUI has PP options for Russia/Dual Access too.)

I could also try inserting DNS entries directly into various parts of the config.xml to see if it makes a difference (a bit of a hack here since I don't fully understand how the config entries work together). I could post my config somewhere but it exceeds 20K so I can't just copy and paste it here in the forum.

[ambercap]

I did not have time to setup a sniffer on the WAN port, but I did manage to telnet into the router!

This is what I see in /etc/resolv.conf:

Code: [Select]

# Auto-Generated
nameserver 192.168.101.102
nameserver 192.168.101.101
nameserver 194.90.1.5
nameserver 212.143.212.143
search

The first 2 IPs are dummy values that it sticks in - they should not be there! In the config file these are listed under udhcpc (which is the BusyBox micro DHCP cllient). The next two IPs are correct.

However ping of a host name fails.

This is the routing table:

Code: [Select]

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
212.143.205.233 *               255.255.255.255 UH    0      0        0 ppp0
212.143.205.253 172.21.160.1    255.255.255.255 UGH   0      0        0 eth2.2
192.168.2.0     *               255.255.255.0   U     0      0        0 br0
172.21.160.0    *               255.255.224.0   U     0      0        0 eth2.2
239.0.0.0       *               255.0.0.0       U     0      0        0 br0
The first route is to the L2TP peer via ppp0.
i don't know what the second one is for but 172.21.160.1 is the router IP defined for udhcpc. I think this might be the DHCP assigned external IP from the cable company before L2TP is connected.
The route for both is via eth2.2 (WAN port).
The internal network is reached via br0.
Not sure what network 239.* is for.

The name resolution is failing because of the 1st 2 entries.
If I delete the bad entries, then name resolution starts working!!
So now Dynamic DNS is working too!

I'm not sure how to make the fix permanent though (a router reboot, and probably just reconnecting L2TP might put back the bad values again). I'll have to watch it and see what happens.

[FurryNutz]

Can you detail us how you telnet in and how are you changing the values?

[ambercap]

The telnet daemon starts up about a minute after the router is rebooted, but if no attempt is made to telnet in it shuts down again about a minute later, so you have to reboot the router first.
  Via the web UI, Tools tab, System, click Reboot Device to reboot the router.

Then telnet to the internal IP - for example:
 telnet 192.168.0.1
After about 5 seconds press Ctrl-C to abort and try again continuously until the connection succeeds.

The only username it will accept is 'Alphanetworks'. The password is the signature in the config.bin file (save Configuration from web UI). (Open the config with a hex editor and look for signature=...). On linux (I'm using Mac OSX) you can enter this to see the signature:

hdr_len=$((0x$(xxd -s 4 -l 4 -p config.bin)))
dd ibs=1 skip=28 count=${hdr_len} if=config.bin 2>/dev/null | tr '\0' '\n'

For f/w 1.03 the password is 'wrgn39_dlob.hans_dir645_V1'.

Once you are logged in telnet seems to keep running as long as you are busy with it.

To edit resolv.conf I just echo'ed the required lines as follows:

echo "nameserver 194.90.1.5" > /var/etc/resolv.conf
echo "nameserver 212.143.212.143" >> /var/etc/resolv.conf
echo "search" >> /var/etc/resolv.conf

[FurryNutz]

Wow, thank you for sharing. You've done alot of work.

I think I would phone contact Dlink and see if this can be resolved. I don't know if this would be an issue on the other ISP connections or is limited to L2TP. You would have to take this to a different location and to an ISP that uses PPPoE or DHCP to see if this behavior follows or not. Really seems like an issue on the L2TP connection. DLink should be made aware of it. Ask for level 3 I think.

I'll try this out on my 645 since I have a DHCP connection with my iSP and see if I can reproduce the same thing.

Keep us posted.

[Hard Harry]

Yea, I agree with Furry, at this point I would suggest contacting Dlink. I would say email them first at customerservice@dlink.com  (Furry, could you confirm this is valid/best way to electronically contact them?). I think most of this stuff would go over most Tier1 (no offense to Dlink support). That way if/when you do call, at least you will have a ticket open or something to reference.

[FurryNutz]

I don't recommend email contact as that, at least in my experience, is basic or level 1 support. This needs Level 3 at least. Phone contact is best in this case.

What hex editor in OSX are you using? I'm using OSX 10.6.8.

[Hard Harry]

Good to know.

I found something interesting though. Looks like the Europe model firmware is different.Latest is 1.02 b11. It can be found here. Maybe the firmware is specifically written to work better with some of the ISP you find more commonly in Europe? I tried looking on the Israel site, but they don't have firmware listed. Odd. Either way I say contact support to confirm the best firmware for your particular model.

[ambercap]

For hex editing on OSX Mountain Lion (v10.8.2), I'm using 0xED (v1.1.3).

[FurryNutz]

Awesome, used 010 Editior, demo.
I found this for v1.02 FW:
FW v1.02> signature=wrgn39_dlob.hans_dir645

And it works, I was able to telnet in and see the directories. Very interesting.

Anyways, keep us posted on how it goes and what DLink says. I highly recommend Phone contact and get level 3 if you can support.

[ambercap]

OK I had a closer look at what is going on.

First the router makes a DHCP request (using the utility udhcpc (Micro DHCP Client)) on its WAN port.
The cable company's DHCP server (172.18.144.176) responds with this offering:
  IP: 172.21.181.174/19
  Gateway: 172.21.160.1
  DNS: 192.168.101.102, 192.168.101.101

Note the their DNS servers have private IPs and do not resolve the entire internet - they are internal DNS servers that only have a handful of entries to serve the cable company. The hosts served up by these DNS servers include only the cable company itself, as well as the L2TP gateway IPs of the various ISPs such as:
  cable.netvision.net.il 212.143.209.13.
All other hosts (such as google, dlink, etc.) resolve as 172.18.130.37 which is a web server at the cable company that serves a page advertising the various ISPs in order to get internet service.

The router therefore creates the routing rules I posted earlier and adds the DNS servers to the resolv.conf file.

At this point the L2TP dialer script is run and establishes a connection via the gateway mentioned above (212.143.209.13), and receives a new "L2TP DHCP" response giving:
  IP: 217.132.242.23/32
  Peer IP: 212.143.205.233
  DNS: 194.190.1.5, 212.143.212.143

The router then appends the new DNS servers to resolv.conf instead of replacing the previous values. So there are 4 DNS servers (even though the kernel by default will never attempt more than 3).

The problem is the first 2 DNS servers are not proper DNS servers and resolve everything to that internal web server of the cable company (172.18.130.37). Well actually, now that everything is going via L2TP, the router can no longer even reach these DNS servers so name resolution fails. It tries the first 2 servers only and never tries the 3rd one (the good one), since by default the maximum resolve attempts is 2.