# Hardware fault or my stupidity? SOLVED

## MrSums

I'm trying to replace my aging Netwinder server with a Gentoo-based home-build. I'm using a reclaimed mini-itx based machine into which I've added an extra ethernet card. Installed gentoo with very basic defaults and no X server. Included webmin so I can change setting remotely if I can ever get the **** thing to work properly

At present, everything boots up nicely and I have eth0 grabbing the internet connection from my cable modem. eth2 is set up as static 192.168.1.1. For some reason eth1 is not recognised by the system and udev insist on setting it up as eth2. Maybe this is the problem?

On boot up, the server can see internet and firing up lynx allows basic browsing. My desktop I have set up as static 192.168.1.9 and this can access the server via webmin and can ping the addresses of both eth0 and eth2 on the server. However, the desktop cannot ping external addresses (such as my isp's nameservers) or otherwise access the internet at all.

ifconfig of the server: *Quote:*   

> 
> 
> eth0      Link encap:Ethernet  HWaddr 00:40:63:C0:94:25
> 
>           inet addr:82.1.2x.xx  Bcast:255.255.255.255  Mask:255.255.252.0
> ...

 

output of route: *Quote:*   

> 
> 
> Kernel IP routing table
> 
> Destination     Gateway         Genmask           Flags   Metric   Ref    Use Iface
> ...

 

output of rc-update show: *Quote:*   

> 
> 
> minitx ~ # rc-update show
> 
>              apache2 |      default                  
> ...

 

I have also tried with dnsmasq instead of named and dhcpd, but doesn't seem to matter. I am at a complete loss having spent days running through various how-tos - if I cant ping a numbered address (which I can if I use the old server/desktop combination) then there seems to be something VERY wrong - either with hardware (how do I check?) or with my capabilities somewhere.

Appreciate any help

Robert

----------

## jongeek

You may need to enable ip forwarding. It is not turned on by default. Try

```

cat /proc/sys/net/ipv4/ip_forward

```

What does it show ? If the output is 0, you can turn it on temporarily (until next reboot) with

```

echo 1 > /proc/sys/net/ipv4/ip_forward

```

It can be enabled permanently with

```

echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf

sysctl -p

```

The /etc/init.d/bootmisc script loads the settings in /etc/sysctl.conf at boot time.

Let us know how that works. You may also need to enable NAT (network address translation) using iptables. But check the IP forwarding first.

----------

## MrSums

ip forwarding already enabled:

 *Quote:*   

> minitx ~ # cat /proc/sys/net/ipv4/ip_forward 
> 
> 1

 

and I checked that sysctl is enabled in the kernel: *Quote:*   

> 
> 
> minitx ~ #  cat /usr/src/linux/.config | grep SYSCTL
> 
> CONFIG_SYSVIPC_SYSCTL=y
> ...

 

extract from /etc/sysctl.conf: *Quote:*   

> 
> 
> # /etc/sysctl.conf
> 
> #
> ...

 

[everything else in that file is commented out]

Insofar as iptables is concerned, I have not enabled the firewall as yet - I thought that would be simplest, but is there something in there I need?

----------

## jongeek

You need to have NAT setup in order for your internal machines to access the internet. iptables provides this functionality in addition to packet filtering, etc. Go ahead and emerge iptables if you haven't already. You also need kernel support, enable NAT under "networking|networking options|network packet filtering|IP: netfilter configuration|Full NAT" in the kernel configurator (make menuconfig). There are also a lot of kernel options controlling packet filtering, etc., but the Full NAT is what you need for this issue. If you don't have that stuff built in already, go ahead and do so and reboot to the new kernel. I can provide my kernel config file if you'd like an example, though it has a lot of non-NAT packet filtering stuff enabled as well. Then,

Using the network config you described, this ought to do the trick:

```

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to-source 82.1.2x.xx

```

Basically this says any packet coming from the internal subnet (-s 192.168.1.0/24), and going out to the internet (-o eth0), will have its source address translated to 82.1.2x.xx (-j SNAT --to-source 82.1.2x.xx). The kernel will keep track of these outbound packets, and when they come back from the internet, it will map the source address from 82.1.2x.xx back to the 192.168.1.x internal address. 

More info can be found at:

http://www.netfilter.org/

http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO.html

----------

## MrSums

Brilliant - thanks very much. Tried with your suggestion - which worked - then followed the link and replaced with  *Quote:*   

> 
> 
> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

 

which I think is probably better, long term. However, if I can crave your indulgence a little more, I then ran a speed check on the connection from my desktop machine which normally gets around 8mb download speeds - but only gets around 1.2mb through the new server. Would this be due to improper setup of iptables?

This is the output of iptables-save: *Quote:*   

> 
> 
> # Generated by iptables-save v1.4.0 on Thu Feb 19 21:18:23 2009
> 
> *nat
> ...

 

Thanks again - appreciate your help

Robert

----------

## jongeek

I think you're correct about using MASQUERADE instead of SNAT. I use a static address at work, and a DHCP address at home that only changes a couple of times a year, so I use SNAT, but MASQUERADE is more appropriate for DHCP.

What ethernet cards are in your machines ? Do the desktop and the new gateway have the same speed ethernet cards ? There is certainly some overhead to using netfilter, but I didn't think it would be enough to slow things down that much. Are you giving your speeds in Mbps or MBps ? I max out at ~800 KBps (~6 Mbps ?), and I get the same download speeds whether going through my Gentoo router/gateway, or hooked directly to the cable modem.

You can also add this rule to your iptables rules for troubleshooting. It helps to see if packets that you want are being dropped due to a misconfigured iptables setup.

```

iptables -A INPUT -j LOG --log-prefix 'UNKNOWN : '

```

Put this rule before before your REJECT line, so everything that gets dropped is logged. This can result in a lot of noise in your system logs, but is also a good way to see if script kiddies are knocking on your door.  :Smile:  I combine this with a custom syslog configuration that puts all message prefixed with UNKNOWN: in a separate logfile so it does not clutter up my system logs.

Also, try running some system monitoring stuff (top, vmstat, I'm sure there are lots of other that I don't know about or can't think of off the top of my head) on your gateway machine to monitor the system load. This will tell you if your machine's hardware is being maxed out by the packet transfer overhead. nettop can also help you out with this.

Not much else comes to mind, though. Maybe someone else with more network engineering experience can chime in ?

----------

## MrSums

Is the order of the rules important? - ie should the  *Quote:*   

> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 

  rule be at the top, rather than somewhat lower?

I checked the results on the same speed-checker, the speed is a quarter of what it should be (around 8Mbps)

The interface cards as the same speeds - both 100mbs. The only difference is one is on-board the itx motherboard and the other is an add-on. To enable them I load modules: *Quote:*   

> 8139cp
> 
> 8139too

 

I did notice that on eth0 that the frame: number was no longer zero: *Quote:*   

> 
> 
> eth0      Link encap:Ethernet  HWaddr 00:40:63:C0:94:25  
> 
>           inet addr:82.1.2x.xx Bcast:255.255.255.255 Mask:255.255.252.0
> ...

 

I can't find what the means, but there are no other errors reported

----------

## agent_jdh

One way to get round the firewalling issue is to use shorewall - excellent documentation and really easy to set up.

----------

## jongeek

I don't know what the frame: means either.    :Sad: 

Can you run the speed test from the gateway itself ? The results would be interesting.

@agent_jdh: shorewall looks interesting. I've been too lazy to look for anything other than straight command-line iptables. Then again, my needs are pretty simple with respect to packet filtering. But I'm going to check it out. Thanks !

----------

## eccerr0r

A framing error is when a packet gets sent to the machine but the frame decoder got confused about the frame, usually when packet start/stop conditions occur when they aren't expected.  A lot of the times it's bad wiring or noise, or possibly the driving end (note: this hardware driving end, not packet origination driving end) is producing incorrect packet start/stop conditions.

----------

## MrSums

I've just run a speed test on the server with it set up as a standard non-gui machine connected via the old server. It is currently downloading a test file at 250KiB/sec which I think equates to the 1.2Mbps.

So clearly there is a problem with the card - actually the on-board ethernet

[Some while later] Over dinner I thought it might not be the card, so I've just tried it again with another ethernet cable. Speed has at least doubled - this estimate puts it at around 4Mbps.

I will re-configure it all again later as a server, but with new cable and report back

----------

## Gef

 *MrSums wrote:*   

> For some reason eth1 is not recognised by the system and udev insist on setting it up as eth2. Maybe this is the problem?

 

You can edit /etc/udev/rules.d/70-persistent-net.rules or delete it and let udev rewrite it during next boot.

----------

## ScarletPimpFromHell

The most common speed related error is actually a mismatched duplex setting on either the NIC (Network Interface Card) or the switch port. Basically a network card can operate in full or half duplex. 

When full duplex is being used both machines connected to the cable can transmit and receive simultanously. In half duplex mode one machine transmits and the other one receives. In this mode if both machines transmit at the same time a collision occurs. The NIC will attempt to autonegociate the mode of operation with the other machine attached to the link, but if negociations fail the default mode is 100Mb/s @ half duplex.

I can see by you ifconfig dump neither eth0 or eth2 are clocking up errors, there has also been bugger all traffic on the link, so in all probability there just hasn't been enough traffic to cause a collision. I'm making the assumption that both NICS are operating in 100Mb/s half duplex mode. You should check your cable mode attached to eth0 and the switch port attached to eth2 and make sure that they are both configured for auto-negociate.

----------

## MrSums

Turns out the cable thing was a red herring and didn't help - speed still the same. Then I remembered that the cable people said if I want more than 10Mbps I need to change my cable modem and linked that with the fact that the old server has a 10BaseT ethernet board on eth0. So I set *Quote:*   

> mii-tool -A 10baseT-FD eth0

 

and voila - speed is actually slightly higher than for old server.

Then I saw previous post, which is absolutely on the nail in terms of mis-match, but not the duplex issue apparently.

This forum rocks - and you guys are stars.

Thanks

Robert

----------

