connection is intermittent - what files should I check?

[PeterBallard]

Hi all,

I had a hard disk drive crash recently, and re-installed RedHat 9 and reconfigured for my (static IP) account with swiftel. But now, my connection is intermittent: about 10% of the time when I click a link (or try some other access) I get told (immediately) that my PC doesn't know the IP address. (A DNS problem perhaps?). The problem is Linux-based because in Windows things work perfectly.

Fortunately, I recovered nearly all my files from my hard disk crash, so I can compare files to how they were before the crash (when things worked). I am guessing there is a file in /etc which is misconfigured. Can anyone suggest which files I should check?

--
Peter

[dapama]

Check the contents of /etc/resolv.conf

You should have at least two nameserver entries. I'm in Melbourne and use the following:

nameserver 218.214.17.1
nameserver 218.214.228.97

[PeterBallard]

Check the contents of /etc/resolv.conf

You should have at least two nameserver entries. I'm in Melbourne and use the following:

nameserver 218.214.17.1
nameserver 218.214.228.97

Thank you, but that does not seem to be the problem. I get intermittent connectivity whether or nor I have a secondary DNS server. Furthermore, in Windows, I have only a single DNS server and I have no connectivity problems when in Windows.

I have discovered one difference from before my crash (when connectivity was fine). Before my crash, when I typed "route -n", I got the following table:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
202.154.95.169 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.161.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet1
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.72.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet8
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 202.154.95.169 0.0.0.0 UG 0 0 0 ppp0

The two "vmnet"s were to do with VMWare, which I stopped using ages ago. (I don't think they're significant, but I've included them in case they are). Remove those two, and my old IP table looked like this:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
202.154.95.169 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 202.154.95.169 0.0.0.0 UG 0 0 0 ppp0

Now, when I type "route -n", my IP table looks like this:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
202.154.95.169 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 lo
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 202.154.95.169 0.0.0.0 UG 0 0 0 ppp0

Notice the difference in the 2nd line: the IP address has changed (192.168.1.0 to 169.254.0.0), and the "Iface" entry has changed from "eth0" to "lo". I suspect this difference is the problem... but can anyone tell me what the difference means, and how to fix it?

Thanks in advance,

Peter

(I'm also open to email at pballard@ozemail.com.au, but put "Peter" in 1st line to get thru spam filter)

[Incabulos]

I'd remove vmware from your startup/boot scripts if you are not using it, the kernel modules that provide the virtualised network interfaces ( ie vmnet0, 8 )will be memory resident and make troubleshooting other network issues a bit less clear cut.
I believe under redhat this is accomplished by

'service vmware stop' to stop the current instance and

'chkconfig --del vmware' to prevent start at bootup.

I'm guessing from the 'ppp0' interface in your provided routing table that you are running your adsl box in bridged mode and using pppoe authentication from your redhat desktop, which probably connects to the adsl box via ethernet on eth0?


Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
202.154.95.169 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 lo
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 202.154.95.169 0.0.0.0 UG 0 0 0 ppp0


Your routing table default route is the last line, ie, you reach nonlocal networks via the gateway 202.154.95.169. The way to reach this gateway is given by the first line, the UH flag shows that it is directly attached via ppp0, the virtual interface set up by the pppoe process after successful authentication with swiftdsl. Can you ping this address?

The second line looks incorrect, as 'lo' refers to the loopback interface, which is where the loopback address 127.0.0.1 is bound to, as per the third line. You wont be able to reach any networked systems with a 168.254.x.x address with this line present. Nonetheless, it shouldnt stop your network from working.

Make sure your firewall isnt blocking packets you might need allowed through, I think by default RH has this firewall activated. You can query its rules via

'iptables -L' which lists all rules, or
'iptables-save' which dumps all rules to console in config file format.

'service iptables stop' will disable all rules temporarily so you can test if your connection is up.

Try pinging addresses like 139.130.4.5 ( Telstras main DNS server ), if you can get a response from this it means your connection is up and DNS is likely the issue ( perhaps port 53 blocked by your firewall ).

[PeterBallard]

Thanks for your various suggestions, but still no solution. vmware was already disabled, and my firewall looks fine.

One "interesting" thing is that, if I do "route -n", I sometimes get this:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
202.154.95.169 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 lo
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 202.154.95.169 0.0.0.0 UG 0 0 0 ppp0

...but occasionally, for no apparent reason, I get only the two "lo" lines, i.e. this:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 lo
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo

In the former case, my connection works. But in the latter case, the external connection doesn't work (of course).

As a general rule: if I am doing continual accesses, the line IP table stays good. If I am idle for a while, the IP table may or may not degenerate into the 2nd case. Whether or not it does seems to be more or less random.

But then, if the IP table does go into the "bad" case, a few repeated "route -n" commands always (or almost always) fixes it.

So it seems that my IP table is intermittent. And like I said, I can't figure out why. Any ideas, anyone?

--
Peter

[Incabulos]

It seems likely that your connection setup somewhere has a 'disconnect if idle' setting that causes pppd to terminate when inactive.

Look in the ppp.conf file for idle timeout fields or similar. This could also be set on the router itself, but is probably more likely on the device running ppp, your linux box.

As a workaround you could have a seperate terminal or virtual console repeatedly pinging something to keep the session from being seen as inactive.

[PeterBallard]

It seems likely that your connection setup somewhere has a 'disconnect if idle' setting that causes pppd to terminate when inactive.

Look in the ppp.conf file for idle timeout fields or similar. This could also be set on the router itself, but is probably more likely on the device running ppp, your linux box.


Aha, thanks for that! I'm pretty sure I've solved the problem. It was the timeout option ("-T") with pppoe. The pppoe man page says "You should set the PPPoE timeout to be about four times the LCP echo interval." My LCP echo interval was 80 (seconds) so I needed to set the timeout to (about) 320, but for some reason it was set to 20.

I corrected it by fixing the PPPOE_TIMEOUT field in the file /etc/sysconfig/networking/profiles/default/ifcfg-ppp0

I remember setting this value when I first setup ADSL. But when I re-set it up post-crash, I never had to set it. That's the problem with Linux: setting things up isn't nicely automated.