Dataflow issue in Linux
 

I have two computers, one with Slackware 8.1 and the other with Windows XP. The linux computer has two network cards, one of the network cards is getting an IP via DHCP and the other is acting as a gateway so I can share my internet connection with my XP machine. I am using IP tables to accomplish this.

I am getting internet dataflow through both computers but there seems to be a problem with it cutting off all the time. It almost seems like it is on a timer. I will be on my XP computer for about 5-10 minutes and data flow will completely stop. It doesn't matter if i'm idleing on the internet or downloading a file. When this happens, I switch back to my linux computer and try to ping something from that, there is also no data flow on it. The dataflow stops for about 2 minutes then everything is back to normal.

I know this must sound like a problem with my internet provider, but before I set this up, I never had problems like this. Plus, just the way it is happening.. internet works fine for 5-10 minutes, then stops for 2 minutes then starts again.

Here is my IPTABLES configuration which starts up on boot (I put it in /etc/rc.d/rc.local)

ifconfig eth1 192.168.10.101 netmask 255.255.255.0 broadcast 192.168.10.255

iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain
iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
iptables --append FORWARD --in-interface eth1 -j ACCEPT
echo 1 > /proc/sys/net/ipv4/ip_forward

Please, anyone that has any suggestions at all I would like to hear them. I am not 100% sure if this is related to IPTABLES or not. I have read the iptables documentation many times and I can't seem to find an answer.

Thanks in advance.

There is not much in the iptables code you posted to go wrong. In fact assuming that you don't change the default policy of any of the built in chains elsewhere then the FORWARD rule is redundant.

Anyway on to your problem, when this outage occurs where are you trying to ping. O would suggest that you try to ping the other end of your i/net connection (the default route for the gateway after DHCP). If you can ping this then the problem may well be at the ISP's end.

If you can't then we need to work out why it stops when it stops and why it springs back to life.

Have you tried renewing your DHCP connection on the gateway during the outage? if so did the connection come back?

It may also be worth looking at the results of an

iptables -L -v and,
iptables -t nat -L -v

just to be sure that there are no rules thown in from somewhere else (I don't run Slackware but I know Mandrake loads some sort of iptables by default).

if all that fails then you need to look at exactly what is happening before during and after the connection fails. A few things that may be worth doing are

logging packets through iptables,
running something like iptraf to watch what is going where,
checking the routing table, etc when the connection fails,
checking the local network traffic when the connection fails.

Hopefully something in all that will help, if not post back here and we'll have another go at it.

Rich

Ok, first of all thanks for the response. I was beginning to think that I would never get a reply :)

First of all. When the connection goes out, I lose everything. I can ping my DSL IP address and get a response.. but I do not get a response from anything else such as www.google.ca or the IP address for google. So it doesn't seem to be a DNS related issue.

You said "Have you tried renewing your DHCP connection on the gateway during the outage? if so did the connection come back?" ... I'm not sure how I would do this.. my gateway isn't a DHCP connection, it's assigned an IP address of 192.168.10.101 all the time. Did you mean try renewing the DHCP connection for my DSL? If so, no I have not.. i'm really not sure how :)

I ran Iptables -L -v and it came up with the following information:

Chain INPUT (policy ACCEPT 19531 packets, 2710K bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 512K packets, 200M bytes)
pkts bytes target prot opt in out source destination
692K 138M ACCEPT all -- eth1 any anywhere anywhere

Chain OUTPUT (policy ACCEPT 17908 packets, 2901K bytes)
pkts bytes target prot opt in out source destination
------------------------------------------------------------------------------------

I ran iptables -t nat -L -v and it came up with the following information:

Chain PREROUTING (policy ACCEPT 16272 packets, 894K bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 69 packets, 13650 bytes)
pkts bytes target prot opt in out source destination
15624 767K MASQUERADE all -- any eth0 anywhere anywhere

Chain OUTPUT (policy ACCEPT 124 packets, 25487 bytes)
pkts bytes target prot opt in out source destination
------------------------------------------------------------------------------------

About the rest of your suggestions. I will admit, i'm not totally comfortable with Linux just yet.. so i'm not too sure on how to do a lot of what you suggested. First of all I tried running `iptraf` but I don't appear to have it. I am not sure how to log packets through IP Tables, check routing tables or checking the local network traffic. I would appreciate it if you could give me a bit more information on how to do these things and what exactly to look for.

Thanks again for your response

A little bit more information. I tried this stuff when my connection went down:

ping www.google.ca
ping: unknown host www.google.ca

ping 142.176.30.182
PING 142.176.30.182 (142.176.30.182): 56 octets data
64 octets from 142.176.30.182: icmp_seq=0 ttl=255 time=0.6 ms
64 octets from 142.176.30.182: icmp_seq=1 ttl=255 time=0.2 ms

ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 octets data
64 octets from 192.168.10.1: icmp_seq=0 ttl=128 time=0.6 ms
64 octets from 192.168.10.1: icmp_seq=1 ttl=128 time=0.5 ms


ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 octets data
64 octets from 127.0.0.1: icmp_seq=0 ttl=255 time=0.4 ms
64 octets from 127.0.0.1: icmp_seq=1 ttl=255 time=0.2 ms


PING 216.239.37.101 (216.239.37.101): 56 octets data
ping: unknown host 216.329.37.101
------------------------------------------------------------------------------------

Also, it seems to have gotten worse lately, it sometimes isn't coming back up and/or is taking a lot longer then normal. Restarting the linux box always fixes the problem.. but it will just happen again in a few minutes. Thats why I find it hard to believe that it is an ISP issue. Restarting the linux box wouldn't solve the problem all the time if that were the case.

Also, when it's down, if I try to connect to my linux box from my client.. I can still connect, but it takes a lot longer then normal.. usually connects right away.. but when its down it takes a good 30 seconds to connect to my internal IP.

OK, that last post helps I think, but i'll run through yur replies one by one.
1. you can ping your the other end of the DSL conection but bot google - this points to a DNS problem as you said ;-) basically ping needs an IP so when you ping google the first thing it does it talk to your DNS to get it's IP. (thought I had a winner there until post number 2 I am assuming that 216.239.37.101 is the IP for google.ca, it is different when I try but they will certainly be load sharing so this is not entirely unexpected).

2. with regard to renewing your DHCP connection I am indeed refering to the connection to your ISP, as to how it kinda depends on what version of DHCP you are running. To start with though if you have not specifically setup the dhcp client then it may well have been done with linuxconf. If that is the case then you ca go into linuxconf, disable the card, get out of linuxconf and let it restart the network services and then go back into linuxconf and reenable the card. Having said all that if you can still ping the other end of the the DSL link (I am assuming that 142.176.30.182 is the ip of the other end of your link) then doing all that may not help at all.

3. iptables stuff all looks fine, nothing much there to cause a problem, in fact at this stage I would not worry too much about iptables. It may be worth having a script to quickly disable it however so that when the link goes down you can disable it and run the tests knowing that it is not causing any ill effects. A script like this

#!/bin/sh

iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

iptables -F
iptables -t nat -F

if you are not sure of exactly how to create the script let me know.

anyway run that and the firewall will be gone. You will obviously lose your MASQ capablilty as well so all tests will have to be from the linux box (incedently you may want another script that has the normal settings so you can crank it back up when you are finished).

4. iptraf is a great little program that can get downloaded from http://cebu.mozcom.com/riker/iptraf . It may not help but it is worth a try. ideally run it when the system is working normally to see what the traffic is doing so when the link goes down the results will be a little more meaningful.

the other thing you may want to try is simply killing the eth0 with ifconfig eth0 down and then reenabling it with ifconfig eth0 up.


it also may be worth seeing how far into your ISP's network you can get when there is a problem. try doing a traceroute to that google address

$traceroute www.google.ca

there will no doubt be a few steps to get out of your
ISP before getting to the actual address (takes 22 steps from where I am :-) so write some of these down and try to ping them when the problem occurs. If you can make it some way into there network then it starts to look less and less like a problem at or end.

Note when the connection is down it is unlikely that you will have any access to the DNS so IP's will be important.

with regard to your local connection running slow this depends on how and what connection you ar trying to make. If you are conecting to a local webserver then there may be name lookup issues or maybe even a default route problem (that is it may be trying the defunct connection before failing back to the local network).

Seehow you go with that lot and let me know if you are still having problems

Rich

There is a renew problem with some dsl systems.
The ones that use a carrier signal on top of the telephone line, are subject to several types if interference, the worst being too many carriers on one cable. They lock each other out and force a reconnect.
The dsl handshake can take 40-90 seconds to complete on a good connection.

I suggest you contact your dsl provider and get your connection signal checked... if yours is this type.

Regards,
Peter

Here is a traceroute to google.com's IP address when my internet is working:

traceroute to 216.239.37.101 (216.239.37.101), 30 hops max, 38 byte packets
1 islandtelecom31-254.islandtelecom.com (142.176.31.254) 362.663 ms 143.548 ms 289.859 ms
2 142.166.182.99 (142.166.182.99) 11.121 ms 12.145 ms 12.483 ms
3 142.166.181.69 (142.166.181.69) 12.791 ms 10.565 ms 12.180 ms
4 142.166.181.45 (142.166.181.45) 16.191 ms 14.683 ms 15.224 ms
5 dis11-montreal02-pos2-0.in.bellnexxia.net (206.108.111.173) 29.618 ms 28.560 ms 27.881 ms
6 core4-montreal02-pos6-1.in.bellnexxia.net (206.108.99.177) 28.339 ms 30.014 ms 26.919 ms
7 core1-newyork83-pos0-0.in.bellnexxia.net (206.108.99.190) 35.537 ms 36.885 ms 34.963 ms
8 bx2-newyork83-pos3-0.in.bellnexxia.net (206.108.103.194) 35.508 ms 35.799 ms 35.669 ms
9 206.108.108.126 (206.108.108.126) 35.576 ms 36.479 ms 36.397 ms
10 dcr1-so-4-0-0.NewYork.cw.net (206.24.207.33) 34.839 ms 37.068 ms 35.560 ms
11 dcr2-loopback.Washington.cw.net (206.24.226.100) 42.403 ms 39.740 ms 41.077 ms
12 bhr1-pos-0-0.Sterling1dc2.cw.net (206.24.238.34) 41.180 ms 42.324 ms 41.915 ms
13 csr11-ve240.stng01.exodus.net (216.33.98.146) 41.229 ms 43.199 ms 43.213 ms
14 209.225.34.218 (209.225.34.218) 42.453 ms 43.817 ms 41.912 ms
15 vabi1-1-1.net.google.com (216.239.48.94) 47.144 ms 45.821 ms 44.062 ms
16 to 30 were just had * * * on each line.

When the internet is not working, I try a traceroute on the same IP and it doesn't go anywhere at all.. just takes a long time and shows * * * all down the screen.

------------------------------------------------------------------------------------

I got iptraf. Ran it. I notice that even when my internet connection is working it keeps repeating an error at the bottom:
"UDP (144 bytes) from 142.176.17.8:53 to 142.176.30.182:52694 on eth0 - ICMP dest unrch (port) (172 bytes) from 142.176.30.182 to 142.176.17.8 on eth0".

Not sure if that may be causing a problem or not. It is giving me the error for 142.176.17.8 and 142.176.17.9 which are my primary and secondary DNS servers for my DSL connection. What else can I do with this traffic monitor? What specifically should I be on the look out for? And under the traffic monitor, it has a section called FLAGS.. what are those? I notice that my 142.176.30.182:62764 says RESET a lot.


------------------------------------------------------------------------------------

When my connection went down I tried ifconfig eth0 down then ifconfig eth1 up. It just went to the next line, didn't say anything.. but it appears that it took it down and didn't put it back up. Because when I tried to ping something like www.google.ca it said that my network was unreachable right away.

------------------------------------------------------------------------------------

peter_robb: Sounds interesting.. however i've had my DSL for two years now and hadn't run across this problem. As soon as I hooked it up to my linux box etc this problem started happening. So it is a possibility, but doesn't seem very likely. If I can narrow the problem down further, I may have to get them over here to give it a check.. not about to do that just yet though :)

------------------------------------------------------------------------------------

I suppose I could try hooking my DSL back up directly to my Windows XP machine like it use to be and see if the problem still happenes... if it doesn't.. then it's unlikely a problem with my provider.

That's a better bit of info...
The iptraf records are showing that your udp packets to the dns server are being bounced back as unreachable.
Do you have any another dns servers to choose from? This will slow down connections to resolve names, eg traceroute.

The FLAGS are bits in the TCP/IP packet headers that say what kind of packet it is, eg SYN for new, SYN ACK for anew handshake, FIN for a termination etc.

And your comment about reliability under Win is good. One less thing to worry about...
Are you using a firewall at all? You will need to now...
And I suggest you keep a good eye on the iptraf output. Watch for the events just before things go broke...

Regards,
peter

Well, I dont have any other DNS servers that I know of that I can use. Do you think that this is actually causing the problem? Or just not helping?

I dont have a firewall running yet.. I have enough problems as is :). Why do you say I need one now? because I posted my IP address?

Yeah, here and in your other post re your domain name...

Best to add some filtering to be safe.

It now appears you have a static ip number for your domain, so change the -j MASQUERADE to "-j SNAT yr.ip.num.ber" in the POSTROUTING chain.
Less kernel work to do in netfilter.

Also check how long are the dhcp leases your are being given.

The dns problem either says you can't find your isp's servers, or they won't talk back to you fast enough. Most browsers etc use names rather than numbers to reach other servers, so a stuffed dns will usually break a connection.
Going directly via number should work if you can talk to your isp's gateway...

Regards,
Peter

ok, lots of good stuff from peter_robb, as far as alternative DNS settings check the web pages of other ISP's in your area in there support sections they will often list there own DNS servers.

On firewalling there is a great little script published by a local (to me) magazine called Atomic. They have in there download section a link called atomic wall or something like that. The site is http://www.atomicmpc.com.au

this script was detailed in the mag so you may have to work bits out for yourself but it is resonably well documented. I cam certainly offer any help you need setting it up.

I would also probably still still stick with the -j MASQUERADE option just in case your ip does change, coz if they change it then you will lose your sharing straigt away.

On the iptraf interpretation the bit after the colon is the port that is trying to be sent/received to/from and you can work out what it is by cat'ing /etc/services, this may give you a clue as to what is going on.

most services need you to connect on a specific port (eg. port 53 for domain (DNS)) but from a random high port number on your machine.

When the conection goes down try to ping each point in your traceroute one after the other starting with the one closest to you and working down the list. You have een able to ping the other end of your DSL link in the past so you should be that far, but it would be interesting to see how far you can get 142.166. set of ip's. Remember that when the connection is bad named will not work (because you can't access your DNS) so you need to use the ip's directly.

trying the connection in XP is also a good idea, will focus us on where the problem lies.

Rich

Guys, knock on wood.. it seems to be working alright.. i've been on it for a good 3-4 hours without a problem yet. So let us keep our fingers crossed!