[leafnode-list] Re: SOLVED (was: fetchmail, fetchnews can't get thru router)

[Matthias Andree <matthias.andree@xxxxxx>]

Christian Ebert schrieb am 2008-08-10:

> >> I entered to OpenDNS servers manually in the TCP/IP field of the
> >> AirPort Network Preferences pane, and lo and behold! It works!
> >> Both fetchmail and fetchnews are lightning fast again.
> > 
> > Which leaves us with a workaround, but not an identified culprit or
> > solution.
> 
> It would be good if someone running Linux connected via Speedport
> 701 -> SpeedPortHS 300 could confirm/deny the t-online support
> claim that there are no issues with Linux and DHCP on the client
> machine.

While not running that combination, the resulting configuration I saw
doesn't hint to DHCP issues.  I cannot vouch for the DHCP server handing
out the addresses of two properly working DNS servers, and if one is
down, that might indeed cause timeouts observed, depending on how
exactly the 700V (701V?) forwards. I usually configure my Linux boxen
(no laptops though, but PCs) with a local resolver (BIND9 or djbdns) and
dnsmasq.

> Probably not. _Probably_ they are not queried automatically (by
> fetchmail, fetchnews?).

Your computer queries the SpeedPort router, which likely forwards the
requests to the two DNS servers it obtained via PPPoE via modem.

MacOS --> 192.168.2.1 Speedport EXTADDR ---> one-out-of-two-DNS

> After digging the right nameservers out of the Speedport config
> interface (STATUS::Details/Netzwerk) I entered those DNS servers
> in the Network Preferences pane, and they work.

All that you're reporting hint to the Speedport's DNS client being
b0rked. I only briefly worked with a W900V, and didn't see any issues
there.  Is the firmware the most current one?

> In my experiments before I tried some DNS server addresses from
> http://www.atelier89.de/users/dirk/t-o/010.html
> but not the right ones, or not in the right order -- my first one
> is not even mentioned there, see below; although, as I've found
> by now it /is/ included in the output of:
> 
> $ nslookup www-proxy.t-online.de
> or better
> $ nslookup www-proxy.t-ipnet.de

nslookup often causes misleading output. Use dig for debugging.

> I might revert to the OpenDNS servers if the t-online servers
> change annoyingly often.

They probably won't change except during outages.

> Basically this writes the server names to /etc/resolv.conf
> afaics:
> 
> $ cat /etc/resolv.conf
> nameserver 217.237.151.205
> nameserver 217.237.148.70
> nameserver 192.168.2.1
> 
> With IPv4 set to DHCP there's only the last, the router's, entry.
> 
> But just changing /etc/resolv.conf might not be enough as it will
> be overwritten at reboot. -- I have yet to reboot, so I don't
> actually know if the settings are preserved.
> 
> Note: I _must_ have the routers address as /last/ entry to  make
> things work.

So the Speedport goofs things up when forwarding DNS, or the DNS servers
provided for VDSL customers are different than those for other DSL
customers or whatever.

> Also the speedport config is now only reachable at
> http://192.168.2.1, and not at http://speedport.ip anymore.

Somehow logical, since the T-Online servers cannot respond on behalf of
a gazillion local routers - someone might have configured his or her
router to 192.168.0.254 (my mother, for one)...

> The t-online guys probably have covered their a**es as the
> router's DHCP config help mentions that you /can/ connect
> machines both with DHCP addresses and static addresses with the
> router in DHCP "mode". But the Speedport's manual[1] does /not/
> mention that you /have/ to configure IPv4 _manually_ on MacOS --
> and, of course, "normal" users (ie. not freaks using fetchmail or
> fetchnews) will never notice.

Depending on IPv6 configuration/use of application. If applications use
old-style gethostbyname/gethostbyaddr with AF_INET for forward/reverse
resolving, they'll at least not hit IPv6 DNS issues.

Hm. Somehow unsatisfying...

-- 
Matthias Andree
-- 
_______________________________________________
leafnode-list mailing list
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
https://www.dt.e-technik.uni-dortmund.de/mailman/listinfo/leafnode-list
http://leafnode.sourceforge.net/