[lug] RH 7.1 ppp/network setup

[D. Stimits]

After a very long day of working on this, I discovered the entire
problem is because the RH install decided that my eth0 must be a default
route, which it was not. The trick was to make sure eth0 was NOT brought
up as a default route.

D. Stimits, stimits at idcomm.com


"D. Stimits" wrote:
> 
> I'm trying to upgrade a machine from RH 6.2 to 7.1, and coming up with
> some sort of network configuration problem. Actually, a couple of
> problems, possibly related, maybe not.
> 
> The setup: internal net ethernet card with non-routable 10.x.x.x
> address, static, which works fine. 56k modem which connects fine also (I
> use wvdial), but fails to be able to set default route, so I must do a
> manual route add default ppp0 whenever it comes up. Related to this is
> this /var/log/messages line:
> pppd[16790]: not replacing existing default route to eth0
> [10.255.255.254]
> 
> I tried adding to /etc/ppp/options the line "defaultroute", but no
> effect. Further investigation leads to an interesting block of code in
> the script at /etc/sysconfig/network-scripts/, file ifup-ppp:
> if [ "${DEFROUTE}" != no ] ; then
>   # pppd will no longer delete an existing default route
>   # so we have to help it out a little here.
>   route del default >/dev/null 2>&1
>   opts="$opts defaultroute"
> fi
> 
> Since adding "defaultroute" to /etc/ppp/options does not work, I wonder
> if this block might be called correctly but still not work (I'm unsure
> if it is being called and acted on as "true", or failing). I'm not sure
> where DEFROUTE is being set from, since I grep'd a few places around
> /etc/ and didn't find it anywhere else.
> 
> I haven't used dhcp before, but maybe this would be the answer? In the
> past I've just let the ppp scripts handle route and ip address.
> Suggestions on how to get the default route to work with ppp0 on RH 7.1?
> 
> Another issue might be related to machine naming, and I might have to
> give up my attempt to rename things (this is a clean install, "rename"
> is relative to the other hard drive). There is a very long delay after
> starting Netscape 4.77 before it can even read a local file, named with
> absolute file path. I turned off the "smart browsing" and other features
> that I can think of which might try to do a dns lookup to the outside. I
> own (rent?) the domain battlefieldlinux.com, which has full DNS in the
> "real pseudo-world" of Internet, including www., ftp., and other
> aliases, and am wondering if domain naming might be causing this slow
> startup. My internal network did have machine names that were for
> another domain that got snatched away a day before I tried to get the
> domain (battlefieldlinux.com was a 2nd choice...I kind of like it better
> than my first choice now), so the internal names were for machine names
> on domains that actually exist on the Internet; I changed them to all be
> battlefieldlinux.com now, and I'm not sure if this is causing DNS lookup
> delays. So on the inside I have a scheme like "abc.battlefieldlinux.com"
> and "xyz.battlefieldlinux.com", which don't exist on the outside.
> However, my /etc/hosts file explicitly lists the internal net names, and
> I am set to search /etc/hosts before DNS. I have tried this with and
> without /etc/resolv.conf changes for various combinations of domain
> search orders, with no change. I also tried variations in
> /etc/host.conf, including with "trim .battlefieldlinux.com", which also
> had no effect. Possibility 1 that I can think of is that somewhere it is
> seeing a domain name (even though it is only reading a local directory
> listing...the files in /usr/share/doc/) and trying to look it up before
> it runs, and has to time out first. Possibility 2 is similar, but
> instead of this being a problem due to domain name, it could be that it
> is trying to look up something through the internal 10.x.x.x eth0, which
> it should never do. Does anyone have a suggestion on browser delay fixes
> or testing? (strace didn't show much, top and ps are also boring, almost
> no cpu goes to it during the delay)
> 
> D. Stimits, stimits at idcomm.com
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug