On Wed, Dec 23, 2009 at 4:01 PM, drew wymore <[email protected]> wrote: > On Wed, Dec 23, 2009 at 3:32 PM, Denis Heidtmann > <[email protected]>wrote: > >> Well, the old dsl modem was getting flaky, so Qwest replaced it with a >> PK5000 (rental). The new one is wireless, so that is good. But an >> issue showed up. I have a work-around, but I am curious if anyone >> here has ideas as to why Qwest programmed it as they apparently did. >> >> The issue: >> I set up the DHCP server parameters to use static dns addresses of >> 69.64.224.66 and 69.64.224.67. >> Sent a DHCP request, the modem responds with its own IP (192.168.0.1) >> as the primary DNS and what I had entered as the secondary. A DNS >> request to 192.168.0.1 fails. A DNS request sent to 69.64.224.67 or >> 69.64.224.66 works fine. >> >> I have had many email exchanges with Actiontec about this. Trying to >> get them to say why this made sense did not get very far. Their very >> first response seems to be the most clear: >> >> "Honestly not sure why its programmed this way. >> The DNS is resolved by the WAN connection with Qwest so the primary >> DNS is 205.171.3.65 and secondary is 205.171.2.65 The PK5000 holds >> these settings in memory and relays them by using its Gateway IP as >> the primary. Same is true if you set static DNS servers in memory. >> The PK5000 and in fact all Qwest DSL Gateways, show the gateway IP as >> the primary DNS." >> >> Yet later response from Actiontek said: >> >> "The PK5000 itself is NOT a DNS server or redirection device. There is >> no programming in fact to do a DNS redirection internally. It cannot >> do that at all. >> It simply takes the DNS servers configured statically in the DHCP >> server settings, or takes the DNS servers provided by the ISP and >> broadcasts them as part of its DHCP server services." >> >> The best guess I can come up with is that it works when Qwest is the >> ISP. I am not using Qwest. >> >> > It shouldn't matter who you are using. Every actiontec I've ever used has > tried to do this gateway redirection resolution juju and sometimes it works, > sometimes it fails. It shouldn't however, if configured with static DNS on > the internal nat'd side instead of getting it through the WAN side DHCP > service, then it should work correctly on the LAN side. If it's not working > like that, that indeed is rather weird. > I have made assumptions that the bogus dns address is in fact returned by the PK5000. Initially I set in the PK5000: DSL configuration STATIC Primary DNS 69.64.224.66 Secondary DNS 69.64.224.67
If /etc/network/interfaces contains iface eth0 inet dhcp, then /etc/resolv.conf ends up after boot with 192.168.0.1 as the primary and 69.64.224.67 as the secondary. I have assumed that the PK5000 is responsible for this. Maybe not. What other stuff on my system could be doing this? Is there a way to test it to confirm that it is in fact returning these addresses? A visiting geek here fixed things by installing resolvconf and changing /etc/network/interfaces to contain: iface eth0 inet static address 192.168.0.70 netmask 255.255.255.0 gateway 192.168.0.1 dns-nameservers 69.64.224.66 69.64.224.67 Now the dns addresses are correct, at the cost of a static IP. (This is not a problem for my one-machine system.) Mike asked: It sounds like you're more interested in knowing why the Actiontek DSL modem is setup this way than a workaround. True. I have a work-around. I am asking the WHY question. Is there any way that this (presumed) behaviour can be considered correct? -Denis _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
