routing with dhcp dnsmasq

/y0shi · 11-10-2007, 03:28 AM

I know what you are thinking, there are countless posts on this topic, but I think I did a simple but a "should-working" configuration and it is somehow not working ;-) ... (I can't find the fault)

Well I have to laptops both running slackware 12.0. One is the server and is online via ppp0 (DSL so it uses eth0 - udev rules are making sure of that) this server has another card (eth1 - pcmcia) with a crossover cable to the client.

So ifconfig of the server is:

Code:

eth0      Link encap:Ethernet  HWaddr 00:10:A4:8E:5B:98  
          inet6 addr: fe80::210:a4ff:fe8e:5b98/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4632371 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4770206 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3002710657 (2.7 GiB)  TX bytes:2936923149 (2.7 GiB)
          Interrupt:11 

eth1      Link encap:Ethernet  HWaddr 00:00:21:5C:0B:22  
          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::200:21ff:fe5c:b22/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:917282 errors:101 dropped:85 overruns:101 frame:0
          TX packets:1117148 errors:0 dropped:0 overruns:9 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:371618095 (354.4 MiB)  TX bytes:1268803876 (1.1 GiB)
          Interrupt:11 Base address:0x1400 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:132898 errors:0 dropped:0 overruns:0 frame:0
          TX packets:132898 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:32446280 (30.9 MiB)  TX bytes:32446280 (30.9 MiB)

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:85.179.x.xxx  P-t-P:213.191.x.x Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:1088763 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1200192 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:584353641 (557.2 MiB)  TX bytes:770247955 (734.5 MiB)

Then like in Pat's mail to root my rc.firewall looks like this:

Code:

# Others like "nat" must be explicitly stated.
iptables --flush
# Flush all the rules in filter and nat tables
iptables --table nat --flush
# Delete all chains that are not in default filter and nat table
iptables --delete-chain
iptables --table nat --delete-chain
# Set up IP FORWARDing and Masquerading
iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.0.0/16 -j MASQUERADE
iptables -A FORWARD -o ppp0 -p TCP --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables --append FORWARD --in-interface eth1 -j ACCEPT

there is no line about ipforwarding, because rc.ip_forward is 755.
This line with clamp-mss-to-pmtu I found somewhere on the net, but it is not helping really - I could leave this away ...

The rc.dnsmasq is also 755.
If I do something like:

Code:

cat /etc/dnsmasq.conf |grep -v "#"

there are just those two lines:

Code:

interface=eth1
dhcp-range=192.168.0.50,192.168.0.150,12h

On the client side I did nothing but a netconfig with dhcp.

So my problem is that the internet connection of the client is sometimes ok, sometimes really bad. I can have good traffic on my lan (intern) with about 5000kb/s (rsync ssh) but it is also on the same day possible that irssi is giving Server Lags of 3 to 4, while connected to a chatserver on my server (intern) and surfing with a browser is a pain.

Something is not working here and I can't find the fault, if someone could help me I would be really thankful.

y0shi

acid_kewpie · 11-10-2007, 03:42 AM

no, that's not what i'm thinking at all. i'm thinking since when did dnsmasq have anythign at all to do with routing...? you've mixed up a lot of unrelated things into a bit of a confusing mess... are you getting suitable IP addresses reguarly? if so then dnsmasq is totally irrelevant. divide and conquer!

/y0shi · 11-10-2007, 07:22 AM

well you are absolutely right, the title is stupid it should be something like: "slackware as a router using iptables and dnsmasq for dhcp" ...

would be better I think.

So I use dnsmasq as a dhcpd (on server) for my client, but to solve my connection problems it might be clever do switch to static ip on the client and stop rc.dnsmasq - I did this now.

But it seems that it has nothing to do with dnsmasq, because my connection problem persists. Is my rc.firewall correct? Is there something else to edit/configure?

Thanks in advance.

y0shi

H_TeXMeX_H · 11-10-2007, 08:52 AM

Here's how I made my computer into a router:
http://www.linuxquestions.org/questi...4/#post2908609

I hope it's detailed enough.

/y0shi · 11-10-2007, 10:25 AM

Thank you for that guide I will definitely try this out!

If I look at the output of http://www.slackware.com/~alien/efg/ it get's clear to me - the art of iptables is described far too easy in Pats mail to root ;-)

/y0shi · 11-12-2007, 03:33 AM

well i tried this guide, i dont use dnsmasq anymore simply dhcpd and the iptables script from Alien Bob, but my connection problems persist.

as an example:
i browse the net with firefox and it works kind of slow, but it works. than i open a terminal and try to login via ssh into that server'n'router, that works too, but it needs about 12 sec untill it logs in - so i have than a really slow connection also with firefox than.

the same happens with other applications i really dont think its related to ssh or something.

it is also not that my cable is too long, because i used the same cable with a normal router (some cheap box with a DSLmodem inside), now i just have a very short crossover cable in between too.

the box i use for the server'n'router is a T20 with 700Mhz and 256MB RAM and the client has even more Mhz and RAM, so this should not be the issue i think?

does anyone has experience with stuff like that?

Tanks for your time!

/y0shi · 11-12-2007, 04:22 AM

i have something to add, maybe numbers say more ...

i pinged from client (192.168.0.3) to server'n'router (192.168.0.1) and got this:

--- 192.168.0.1 ping statistics ---
996 packets transmitted, 973 received, 2% packet loss, time 995053ms
rtt min/avg/max/mdev = 0.176/5572.733/13946.233/4366.910 ms, pipe 14

as you can see sometimes it is fast as it should be (0.176) and sometimes it is slow as hell (13946.233) ...

i really have no clue

H_TeXMeX_H · 11-12-2007, 01:33 PM

Whoah ... that's very odd. Is the cable you're using new and undamaged ? Are both cards new and in working order ? (clean, no dust all over them)

/y0shi · 11-12-2007, 02:27 PM

Quote:

Originally Posted by H_TeXMeX_H

Is the cable you're using new and undamaged ? Are both cards new and in working order ? (clean, no dust all over them)

The cable is new and worked with my old router (commecial box).
One card is laptop internal (thinkpad X30) and the other one is a pcmcia card - i had the same problem with another pcmcia card i have (tested both).

Also I tested a different laptop as a server'n'router with the same pcmcia cards and it was the same - thats why I thought it isnt a hardware problem ...

If you look at http://amor.rz.hu-berlin.de/~rheinwaa/ping.png you see the ping statistics as a plot - as you can see on some times ping needs very long and on some times not, there is nothing much in between. The long ping times are to the same time where I try to access a website with pictures or so ...

H_TeXMeX_H · 11-12-2007, 03:12 PM

So the connection of the server to the internet is just fine, right ? It's only the connection of the internal network client to the server that is slow ?

It's interesting to note:

Quote:

eth1 Link encap:Ethernet HWaddr 00:00:21:5C:0B:22
inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::200:21ff:fe5c:b22/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:917282 errors:101 dropped:85 overruns:101 frame:0
TX packets:1117148 errors:0 dropped:0 overruns:9 carrier:0
collisions:0 txqueuelen:1000
RX bytes:371618095 (354.4 MiB) TX bytes:1268803876 (1.1 GiB)
Interrupt:11 Base address:0x1400

So, on the server you're receiving lots of errors, dropped packets, and even overruns from the client.

The fact that you get overruns and it drops many RX packets is really bad for the connection:
http://uwsg.iu.edu/hypermail/linux/k...05.1/1725.html

Now, they solved the problem by 'rmmod' ing some acpi modules, like 'processor'. Maybe try that on the server ? It may be all of ACPI that is the problem, in which case you may want to try APM.

/y0shi · 11-15-2007, 03:17 AM

Thanks for your reply, I was not able to test it, now I am ...
... I recompiled my kernel on server'n'router with static apm and no acpi at all.

At first it looked like performance would be better, so I opened up a rsync connection with bwlimit=999 to get some traffic and the good news is untill now there are no errors, overruns and dropped pakets, but the connection is as bad as before:

Code:

eth1      Link encap:Ethernet  HWaddr 00:00:21:5C:0B:22  
          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::200:21ff:fe5c:b22/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:168528 errors:0 dropped:0 overruns:0 frame:0
          TX packets:68709 errors:0 dropped:0 overruns:5 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:193517797 (184.5 MiB)  TX bytes:39947836 (38.0 MiB)
          Interrupt:11 Base address:0x1400

Code:

--- 192.167.0.1 ping statistics ---
291 packets transmitted, 290 received, 0% packet loss, time 290041ms
rtt min/avg/max/mdev = 82.676/4150.603/14298.066/4537.212 ms, pipe 15

So maybe acpi is responsible for the errors, but why is my connection still that bad? The connection from the server to the internet is just fine (goes over eth0, ppp0).

Oh I wanted to press `Submit Reply' but thought maybe now is something interesting about 8139too in dmesg, after changing to apm and indeed there is nor a lot of stuff ...

an excerpt:

Code:

NETDEV WATCHDOG: eth1: transmit timed out
INPUT packet died: IN=ppp0 OUT= MAC= SRC=83.52.154.27 DST=85.179.3.218 LEN=90 TOS=0x00 PREC=0x00 TTL=118 ID=11501 PROTO=UDP SPT=23374 DPT=23045 LEN=70 
eth1: Transmit timeout, status 0d 0000 c07f media 00.
eth1: Tx queue start entry 72  dirty entry 68.
eth1:  Tx descriptor 0 is 001205ba. (queue head)
eth1:  Tx descriptor 1 is 001205ba.
eth1:  Tx descriptor 2 is 001205ba.
eth1:  Tx descriptor 3 is 001205ba.
eth1: link up, 100Mbps, full-duplex, lpa 0x45E1
INPUT packet died: IN=ppp0 OUT= MAC= SRC=70.48.113.78 DST=85.179.3.218 LEN=90 TOS=0x00 PREC=0x00 TTL=114 ID=49096 PROTO=UDP SPT=61406 DPT=23045 LEN=70 
Invalid packet: IN=eth1 OUT=ppp0 SRC=192.168.0.3 DST=85.183.248.216 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=25352 DF PROTO=TCP SPT=49652 DPT=80 WINDOW=250 RES=0x00 ACK FIN URGP=0 
INPUT packet died: IN=ppp0 OUT= MAC= SRC=88.7.248.83 DST=85.179.3.218 LEN=93 TOS=0x00 PREC=0x00 TTL=117 ID=14169 PROTO=UDP SPT=13952 DPT=23524 LEN=73 
INPUT packet died: IN=ppp0 OUT= MAC= SRC=72.240.188.22 DST=85.179.3.218 LEN=131 TOS=0x00 PREC=0x00 TTL=111 ID=26492 PROTO=UDP SPT=56842 DPT=23045 LEN=111 
Invalid packet: IN=eth1 OUT=ppp0 SRC=192.168.0.3 DST=64.127.105.40 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=45903 DF PROTO=TCP SPT=33030 DPT=80 WINDOW=273 RES=0x00 ACK FIN URGP=0 
INPUT packet died: IN=ppp0 OUT= MAC= SRC=90.227.247.56 DST=85.179.3.218 LEN=71 TOS=0x00 PREC=0x00 TTL=54 ID=20328 PROTO=UDP SPT=6889 DPT=23524 LEN=51 
Invalid packet: IN=eth1 OUT=ppp0 SRC=192.168.0.3 DST=85.183.248.216 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=25353 DF PROTO=TCP SPT=49652 DPT=80 WINDOW=250 RES=0x00 ACK FIN URGP=0 
INPUT packet died: IN=ppp0 OUT= MAC= SRC=212.159.21.168 DST=85.179.3.218 LEN=93 TOS=0x00 PREC=0x00 TTL=116 ID=43367 PROTO=UDP SPT=35555 DPT=23524 LEN=73 
INPUT packet died: IN=ppp0 OUT= MAC= SRC=85.75.218.191 DST=85.179.3.218 LEN=91 TOS=0x00 PREC=0x00 TTL=118 ID=33921 PROTO=UDP SPT=10000 DPT=23524 LEN=71 
INPUT packet died: IN=ppp0 OUT= MAC= SRC=76.116.145.151 DST=85.179.3.218 LEN=93 TOS=0x00 PREC=0x00 TTL=112 ID=59884 PROTO=UDP SPT=35902 DPT=23524 LEN=73 
Invalid packet: IN=eth1 OUT=ppp0 SRC=192.168.0.3 DST=64.127.105.40 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=45904 DF PROTO=TCP SPT=33030 DPT=80 WINDOW=273 RES=0x00 ACK FIN URGP=0 
Invalid packet: IN=ppp0 OUT= MAC= SRC=85.183.248.216 DST=85.179.3.218 LEN=52 TOS=0x00 PREC=0x00 TTL=60 ID=20557 DF PROTO=TCP SPT=80 DPT=49652 WINDOW=7504 RES=0x00 ACK FIN URGP=0 
INPUT packet died: IN=ppp0 OUT= MAC= SRC=85.178.7.58 DST=85.179.3.218 LEN=116 TOS=0x00 PREC=0x00 TTL=125 ID=2725 PROTO=UDP SPT=60365 DPT=21394 LEN=96 
Invalid packet: IN=ppp0 OUT= MAC= SRC=85.183.248.216 DST=85.179.3.218 LEN=52 TOS=0x00 PREC=0x00 TTL=60 ID=20558 DF PROTO=TCP SPT=80 DPT=49652 WINDOW=7504 RES=0x00 ACK FIN URGP=0 
INPUT packet died: IN=ppp0 OUT= MAC= SRC=89.55.18.4 DST=85.179.3.218 LEN=91 TOS=0x00 PREC=0x00 TTL=122 ID=7080 PROTO=UDP SPT=20347 DPT=23524 LEN=71 
INPUT packet died: IN=ppp0 OUT= MAC= SRC=72.81.90.29 DST=85.179.3.218 LEN=93 TOS=0x00 PREC=0x00 TTL=116 ID=9640 PROTO=UDP SPT=44784 DPT=23524 LEN=73 
Invalid packet: IN=ppp0 OUT= MAC= SRC=85.183.248.216 DST=85.179.3.218 LEN=52 TOS=0x00 PREC=0x00 TTL=60 ID=20559 DF PROTO=TCP SPT=80 DPT=49652 WINDOW=7504 RES=0x00 ACK FIN URGP=0 
INPUT packet died: IN=ppp0 OUT= MAC= SRC=81.179.67.52 DST=85.179.3.218 LEN=91 TOS=0x00 PREC=0x00 TTL=119 ID=61919 PROTO=UDP SPT=14758 DPT=23524 LEN=71 
INPUT packet died: IN=ppp0 OUT= MAC= SRC=85.178.46.202 DST=85.179.3.218 LEN=71 TOS=0x00 PREC=0x00 TTL=61 ID=16745 PROTO=UDP SPT=55551 DPT=23524 LEN=51 
INPUT packet died: IN=ppp0 OUT= MAC= SRC=88.74.146.159 DST=85.179.3.218 LEN=91 TOS=0x00 PREC=0x00 TTL=55 ID=57781 PROTO=UDP SPT=13483 DPT=23524 LEN=71 
INPUT packet died: IN=ppp0 OUT= MAC= SRC=65.27.134.204 DST=85.179.3.218 LEN=70 TOS=0x00 PREC=0x00 TTL=115 ID=35783 PROTO=UDP SPT=60076 DPT=23524 LEN=50 
INPUT packet died: IN=ppp0 OUT= MAC= SRC=85.1.68.216 DST=85.179.3.218 LEN=91 TOS=0x00 PREC=0x00 TTL=116 ID=6858 PROTO=UDP SPT=42797 DPT=23524 LEN=71 
INPUT packet died: IN=ppp0 OUT= MAC= SRC=65.95.246.190 DST=85.179.3.218 LEN=90 TOS=0x00 PREC=0x00 TTL=113 ID=57061 PROTO=UDP SPT=21018 DPT=23045 LEN=70 
NETDEV WATCHDOG: eth1: transmit timed out
INPUT packet died: IN=ppp0 OUT= MAC= SRC=88.17.156.10 DST=85.179.3.218 LEN=93 TOS=0x00 PREC=0x00 TTL=118 ID=13634 PROTO=UDP SPT=18512 DPT=23524 LEN=73 
eth1: Transmit timeout, status 0d 0000 c07f media 00.
eth1: Tx queue start entry 629  dirty entry 625.
eth1:  Tx descriptor 0 is 0012006b.
eth1:  Tx descriptor 1 is 001205ea. (queue head)
eth1:  Tx descriptor 2 is 001205ea.
eth1:  Tx descriptor 3 is 00120522.
eth1: link up, 100Mbps, full-duplex, lpa 0x45E1
INPUT packet died: IN=ppp0 OUT= MAC= SRC=85.179.243.115 DST=85.179.3.218 LEN=48 TOS=0x00 PREC=0x20 TTL=123 ID=7589 DF PROTO=TCP SPT=3704 DPT=135 WINDOW=64800 RES=0x00 SYN URGP=0 
INPUT packet died: IN=ppp0 OUT= MAC= SRC=75.82.188.53 DST=85.179.3.218 LEN=91 TOS=0x00 PREC=0x00 TTL=112 ID=14706 PROTO=UDP SPT=23456 DPT=23524 LEN=71

http://pastebin.com/m226b98be

Looks like from the firewall? I now use the one by Alien Bob ...

H_TeXMeX_H · 11-15-2007, 02:58 PM

I think it may be a hardware issue. Try looking through here:
http://lkml.org/lkml/2005/2/5/141
or
http://www.ussg.iu.edu/hypermail/lin...02.0/1632.html

/y0shi · 11-19-2007, 02:39 PM

Well this is not really solved and clear to me, but I have a work around for this problem.

I simply use my pcmcia ethernet as the outgoing connection to the internet (DSL modem) and use the internal networkcard for my intranet.

All my connections seem to be perfect now ...

Tank you guys ;-)