eth0 fixed IP. eth1 DHCP gateway. Need access to eth0

fopetesl · 01-12-2010, 10:42 AM

Thanks, zhjim. Things have changed some since last post.
After a lot of follow up to your post I'm nearly there - but not quite.
I needed to update the OS since 5.10 is long in the tooth also motherboards have changed much.

I have just installed Debian Lenny with LXDE desktop on a Jetway NF94 Mini-ITX system.
The only LINUX distro (so far) to recognise the on-board Realtek 8111C NIC and set it up correctly so's I can Internet connect.

This after three days, (really), of trying other distros which failed significantly.
However all is not hunky dory: I still cannot get the PCI NIC to communicate on the static IP for local connection.
BTW, eth1 is DHCP'd to the altered Router address on 192.168.2.1 so there are two different networks.
Using LXDE there seems no way to control network setup from the GUI so I set /etc/network/interfaces to add eth0:

Code:

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth1
iface eth1 inet dhcp

# The secondary network interface
allow-hotplug eth0
iface eth0 inet static
address 192.168.1.20
netmask 255.255.255.0

also checking for eth0:

Code:

...:# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:e0:4c:01:0a:eb  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:17 Base address:0xf600

..and..

Code:

# lshw -C network
  *-network:0 DISABLED    
       description: Ethernet interface
       product: RTL-8139/8139C/8139C+
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 8
       bus info: pci@0000:00:08.0
       logical name: eth0
       version: 10
       serial: 00:e0:4c:01:0a:eb
       size: 10MB/s
       capacity: 100MB/s
       width: 32 bits
       clock: 33MHz
       capabilities: pm bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=8139too driverversion=0.9.28 duplex=half latency=32 link=yes maxlatency=64 mingnt=32 module=8139too multicast=yes port=MII speed=10MB/s

BTW I have rebooted after editing ../interfaces but still eth0 disabled.

Some progress but still not solved. I did this:

Code:

..:/home/almeter# ifconfig eth0 192.168.1.20 netmask 255.255.255.0
...:/home/almeter# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:e0:4c:01:0a:eb  
          inet addr:192.168.1.20  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::2e0:4cff:fe01:aeb/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:27 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:6020 (5.8 KiB)
          Interrupt:17 Base address:0xf600

..and then this...

Code:

...:/home/almeter# route add -host 192.168.1.6 dev eth0
...:/home/almeter# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.6     *               255.255.255.255 UH    0      0        0 eth0
192.168.2.0     *               255.255.255.0   U     0      0        0 eth1
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
default         home            0.0.0.0         UG    0      0        0 eth1

..and tested..

Code:

:.../home/almeter# ping -I eth0 192.168.1.6
PING 192.168.1.6 (192.168.1.6) from 192.168.1.20 eth0: 56(84) bytes of data.
From 192.168.1.20 icmp_seq=1 Destination Host Unreachable
From 192.168.1.20 icmp_seq=2 Destination Host Unreachable
From 192.168.1.20 icmp_seq=3 Destination Host Unreachable

So where is the problem?
The NIC Link light is flashing but no response.

Confirm driver is loaded:

Code:

00:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
	Subsystem: Realtek Semiconductor Co., Ltd. RT8139
	Flags: bus master, medium devsel, latency 32, IRQ 17
	I/O ports at f600 [size=256]
	Memory at fdfff000 (32-bit, non-prefetchable) [size=256]
	[virtual] Expansion ROM at 20020000 [disabled] [size=64K]
	Capabilities: [50] Power Management version 2
	Kernel driver in use: 8139too
	Kernel modules: 8139too, 8139cp

BTW, I have tested the hardware with UBUNTU 5.10 and the network runs fine.

zhjim · 01-12-2010, 05:28 PM

Nice to see this thread up again. Makes my skill or was it my day

I'll take a closer look on it tomorrow at work. Having the VM there which resembled your setup.
Just for a quick shot: Hardware normaly does not mind as does the OS but your hardware is not following the rules. Bad one.

I'll check on you tomorrow.

fopetesl · 01-15-2010, 02:42 AM

Quote:

Originally Posted by zhjim

Just for a quick shot: Hardware normaly does not mind as does the OS but your hardware is not following the rules. Bad one.

Well, I've had another half day at it with no progress. And the 8139 still works fine with Ubuntu 5.10!
Tried to install the driver for the 8111C on 5.10 but even though the installation came up with no errors it doesn't want to play.
Arrrgggh!!

zhjim · 01-15-2010, 03:17 AM

I'm a bit puzzled; are all your nics showing?

Some point that might be the reason why eth0 does not come up on its own is that you put it on hotplug. I normaly put all my interfaces onto the auto line. (First one in your config)

Code:

auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth1
iface eth1 inet dhcp

# The secondary network interface
allow-hotplug eth0
iface eth0 inet static
address 192.168.1.20
netmask 255.255.255.0

I checked on the man interfaces page but the only think I found out is that allow-hotplug definitions are used with the ifup commmand. So this sure is the reason why eth0 not coming up on its own.
Also this should hold true with eth1 but maybe dhcp makes the difference here.

Does eth1 come up automatic?

What I see has changed to the previous setup is that eth1 now is on its own subnet (192.168.2.0)

Maybe we should retreat from pinging the 192.168.1.6 host and see if we can reach a service running on it. Or are you absolute sure that it accepts icmp request? Maybe there is a webserver we can check for

Code:

telnet 192.168.1.6 80

or

Code:

w3m 192.168.1.6

or use lynx or links to check on the webserver. Telnet is just good for testing connections. netcat also great but I never realy played with this.

Just to some up some things.
Good state is that the two nics are on different subnets. So we should have no need to fiddle with the routes.
The config of the machine seems fine we are on the network side of the problem (in my opinion).
Is it possible for you to see if you can ping your machine from the 192.168.1.6? Maybe there is something thats not playing along.

fopetesl · 01-15-2010, 04:41 AM

Quote:

Originally Posted by zhjim

I'm a bit puzzled; are all your nics showing?

Yes. they both come up at boot time now with what appear to be the correct settings, i.e. the 8139 eth0 with Debian Lenny is exactly as it appears in Ubuntu 5.10.
In 5.10 I can ping/telnet 192.168.1.6 with 100% success.
In Lenny the link(?)LED flashes but gets no response.

The 8111C eth1 on Lenny is on a different subnet after a suggestion last year (following your lead) that this is the easiest way to achieve two discrete Ethernet connections.

If I can find time later, probably over the weekend, I'll download Etheral and see if eth0 is actually doing anything logical.

FYI, 192.168.1.6 has a stripped down TCP/IP stack running on a microcontroller and in this sense is just an idiot machine responding to action commands. So it has no 'sevices' as such.

Getting 192.168.1.6 to ping 192.168.1.20 would be somewhat difficult since I'd have to write ICMP code into the microcontroller. I'm something of a novice at this so would take some time.
However I'll try your idea later from another computer and see if I can ping 192.168.1.20

Thanks, zhjim for your persistence.

zhjim · 01-25-2010, 04:01 AM

Quote:

Originally Posted by fopetesl

Yes. they both come up at boot time now with what appear to be the correct settings, i.e. the 8139 eth0 with Debian Lenny is exactly as it appears in Ubuntu 5.10.
In 5.10 I can ping/telnet 192.168.1.6 with 100% success.
In Lenny the link(?)LED flashes but gets no response.

So we are having a distribution problem here. Hm seems very odd to me. As Ubuntu is just a stripped down/up version of debian this makes it even more odd.
To be honest might just stick with Ubuntu as it's working?????

Quote:

Originally Posted by fopetesl

If I can find time later, probably over the weekend, I'll download Etheral and see if eth0 is actually doing anything logical.

Maybe just ap-get tcpdump to have some sniffer going. ehteral as nice as it is has some kind of learning curve and tcpdump is just plain stuff in sight.

Code:

tcpdump -n

should get you going. (-n is for only numeric and no dns resolved)

Quote:

Originally Posted by fopetesl

FYI, 192.168.1.6 has a stripped down TCP/IP stack running on a microcontroller and in this sense is just an idiot machine responding to action commands. So it has no 'sevices' as such.

Getting 192.168.1.6 to ping 192.168.1.20 would be somewhat difficult since I'd have to write ICMP code into the microcontroller. I'm something of a novice at this so would take some time.
However I'll try your idea later from another computer and see if I can ping 192.168.1.20

Forgot about that. And as you sad this is total overhead also as you can ping from ubuntu.

Quote:

Originally Posted by fopetesl

Thanks, zhjim for your persistence.

Can't leave a problem unsolved

fopetesl · 01-25-2010, 10:57 AM

Well I now know what is the problem.
This morning I installed Wireshark and monitored the relevant traffic on eth0.
First on a laptop set up as 192.168.1.6 and then on the Microcontroller.
The laptop reponds correctly and I can ping happily - though the microcontroller doesn't.

It is my code on the microcontroller returning a 'damaged' ARP response.

What seems to have brought this problem to light is that Lenny now seems to send out "Broadcast ARP Who has 192.168.1.6? Tell 192.168.1.20" request when a LAN cable is plugged in and links though I couldn't manage to trap this initial request.
On the laptop then forever sends ICMP ping requests which succeed.

On the controller though Lenny seems to resolve that the link is half duplex and resorts to sending the "ARP Who has this..." even though it does recieve an ARP response which has the correct MAC address and recognises this but the rest of the packet is filled with 0xff instead of the correct response so Lenny obviously discards it.

I kludged my way around this by writing a file into /init.d/ which has the instruction

Code:

sudo arp -s 192.168.1.6 01:02:03:04:05:ff

so forever after Lenny doesn't ask "Who has 192..", etc. (& remembered to update-rc.d also)
It works because the microcontroller has MAC address hard coded and so far invariable though not strictly cosher.

Now I have to try and find time to fix the microcontroller code.

Thanks for your suggestions, zhjim. We eventually got there

zhjim · 01-25-2010, 12:17 PM

Finally got it

Great.

Quote:

Originally Posted by fopetesl

What seems to have brought this problem to light is that Lenny now seems to send out "Broadcast ARP Who has 192.168.1.6? Tell 192.168.1.20" request when a LAN cable is plugged in and links though I couldn't manage to trap this initial request.
On the laptop then forever sends ICMP ping requests which succeed.

So we indead had a distro problem. But more cause the new ones changed.
But this still has me ask why Ubuntu 5 does not care about the bad arp package. Might be an older kernel version.

Quote:

Originally Posted by fopetesl

I kludged my way around this by writing a file into /init.d/ which has the instruction

Code:

sudo arp -s 192.168.1.6 01:02:03:04:05:ff

so forever after Lenny doesn't ask "Who has 192..", etc. (& remembered to update-rc.d also)
It works because the microcontroller has MAC address hard coded and so far invariable though not strictly cosher.

Nice and elegant solution. And as every device should have an unique MAC this wount shed blood xD

Quote:

Originally Posted by fopetesl

Thanks for your suggestions, zhjim. We eventually got there

That would be great. Also I must admit a broken ARP package was the last thing I would have thought about. Anyways one down next to come

See ya

fopetesl · 01-29-2010, 10:50 AM

Now still with Debian Lenny

However to get internet access I now have to disable(?) eth0:

Code:

$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth1
iface eth1 inet dhcp

# The secondary network interface
#allow-hotplug eth0  # <<<<<<<<<<<<< THIS LINE COMMENTED OUT!
iface eth0 inet static
address 192.168.1.20
netmask 255.255.255.0
gateway 192.168.1.6

If I uncomment the allow-hotplug eth0 then eth0 works fine. BUT although I can ping google.com (via eth1) I cannot get internet access with Iceweasel. Working route:

Code:

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.2.0     *               255.255.255.0   U     0      0        0 eth1
default         home            0.0.0.0         UG    0      0        0 eth1

..also working internet but no eth0

Code:

$ ifconfig
eth1      Link encap:Ethernet  HWaddr 00:30:18:a8:41:9b  
          inet addr:192.168.2.11  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::230:18ff:fea8:419b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2250 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1198 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:716801 (700.0 KiB)  TX bytes:252870 (246.9 KiB)
          Interrupt:19 Base address:0x2000 

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:28 errors:0 dropped:0 overruns:0 frame:0
          TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1944 (1.8 KiB)  TX bytes:1944 (1.8 KiB)

I also have a script in /etc/init.d/

Code:

$ cat /etc/init.d/arpsetup 
#! /bin/sh
sudo /usr/sbin/arp -s 192.168.1.6 00:04:a3:00:a9:f9
sudo /usr/bin/setterm -blank 0

obviously enabled with update-rc.d arpsetup defaults.
Now the non-working setup.

Code:

$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:30:18:a8:41:9a  
          inet addr:192.168.1.20  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::230:18ff:fea8:419a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10 errors:0 dropped:0 overruns:0 frame:0
          TX packets:51 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:600 (600.0 B)  TX bytes:9749 (9.5 KiB)
          Interrupt:18 

eth1      Link encap:Ethernet  HWaddr 00:30:18:a8:41:9b  
          inet addr:192.168.2.11  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::230:18ff:fea8:419b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:381 errors:0 dropped:0 overruns:0 frame:0
          TX packets:61 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:28842 (28.1 KiB)  TX bytes:8722 (8.5 KiB)
          Interrupt:19 Base address:0x2000 

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:28 errors:0 dropped:0 overruns:0 frame:0
          TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1944 (1.8 KiB)  TX bytes:1944 (1.8 KiB)

Code:

$ ping -c 4 192.168.1.6
PING 192.168.1.6 (192.168.1.6) 56(84) bytes of data.
64 bytes from 192.168.1.6: icmp_seq=1 ttl=255 time=1004 ms
64 bytes from 192.168.1.6: icmp_seq=2 ttl=255 time=1005 ms
64 bytes from 192.168.1.6: icmp_seq=3 ttl=255 time=1005 ms

--- 192.168.1.6 ping statistics ---
4 packets transmitted, 3 received, 25% packet loss, time 3011ms
rtt min/avg/max/mdev = 1004.104/1004.790/1005.135/1.255 ms, pipe 2

Note though we have success it's taking a bl**dy long time to get a response. A thousand time longer!

Code:

$ ping -c 4 google.co.uk
PING google.co.uk (66.102.9.105) 56(84) bytes of data.
64 bytes from lm-in-f105.1e100.net (66.102.9.105): icmp_seq=1 ttl=55 time=75.9 ms
64 bytes from lm-in-f105.1e100.net (66.102.9.105): icmp_seq=2 ttl=55 time=70.8 ms
64 bytes from lm-in-f105.1e100.net (66.102.9.105): icmp_seq=3 ttl=55 time=72.4 ms
64 bytes from lm-in-f105.1e100.net (66.102.9.105): icmp_seq=4 ttl=55 time=71.9 ms

--- google.co.uk ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3010ms
rtt min/avg/max/mdev = 70.871/72.818/75.967/1.907 ms

Code:

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.2.0     *               255.255.255.0   U     0      0        0 eth1
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
default         home            0.0.0.0         UG    0      0        0 eth1
default         192.168.1.6     0.0.0.0         UG    0      0        0 eth0

I don't know whether it's significant but it takes several seconds to fill in the last line of the route, i.e. eth0

Googling got me nothing. Why does eth0 stop eth1 internet access?

Edit: I removed the second 'default' gateway:

Code:

$ route del default gw 192.168.1.6

and now I can access the internet but I can no longer ping 192.168.1.6

How to add a gateway that isn't a 'default' since the second one seems to override the first?

zhjim · 02-01-2010, 03:45 AM

You should not need a default gateway for the 192.168.1.0/24 network. Delete the gateway line from /etc/network/interfaces.

Code:

$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth1
iface eth1 inet dhcp

# The secondary network interface
#allow-hotplug eth0  # <<<<<<<<<<<<< THIS LINE COMMENTED OUT!
iface eth0 inet static
address 192.168.1.20
netmask 255.255.255.0
# gateway 192.168.1.6 del me or comment out

Not sure about it but a gateway is always default. (not true) Think about what a getway stands for. It leads to unkown places. Everytime a packet is sent on the road and it's target IP is not inside the localnet it gets transfered to the gateway.
And as you already have a route for the 192.168.1.0/24 network...
If you still need the gateway to 192.168.1.6 change the order of eth1 and eth0 in /etc/network/interfaces Put eth0 first. Thus its gateway gets declared first.

About your script to set up the hwaddr of 192.168.1.6.
maybe it could help tell arp which interface it ought to answer on.

Code:

arp -i eth0 -s 192.168.1.6  00:04:a3:00:a9:f9

Can you check when the script is actually called? Maybe it gets overwritten sometime. Normaly such thing would go into /etc/rc.local.
Do a ls /etc/rc2.d and note the numbers of prefixing the script.