# [SOLVED] Can't Connect with Static IP

## anuraaga

Hello,

I've been trying to set up a direct network between two computers, one Windows and the other with Gentoo Linux by hooking them together with a crossover cable. Unfortunately, no matter how hard I try the computers cannot ping each other when I set them up with static IP addresses. I tried setting a static IP address by editing /etc/conf.d/net and specifying an IP address of 192.168.0.2 (the windows box is set up with 192.168.0.3) as well as manually running ifconfig eth0 192.168.0.1 to no avail. Even various permutations of adding network routes was not successful. It is definitely not a problem with the cable because I even tried with a hub and standard patch cables without success (in the end this has to be a crossover cable network though because the Gentoo box is mounted on a mobile robot that moves around). In fact, the strangest thing is when I tried with an Ubuntu livecd, it worked without any issues.  The output of ifconfig and routes for Gentoo and Ubuntu were identical, so this has left me scratching my head. As I was in a rush, I went ahead and installed Ubuntu onto the machine after backing up the Gentoo disk to an image file, but I'd like to revert back to Gentoo if possible since there isn't much space on the computer's hard drive and Ubuntu has eaten almost all of it up.  Anyone ever experience issues with static IPs in Gentoo?  The only thing I can think of is either a problem patch in gentoo-sources or a bugfix patch in ubuntu's kernel sources.  The box had no problem connecting to a standard network with DHCP though - the problem only surfaces when trying to set up a private network directly with another computer using either a crossover cable or a hub with static IPs.Last edited by anuraaga on Sat Sep 13, 2008 1:37 pm; edited 1 time in total

----------

## NeddySeagoon

anuraaga,

Welcome to Gentoo.

I've always found that static networking 'just works' on Gentoo. I'm using baselayout2 and my net file contains.

```
config_eth_lan="192.168.100.18/24"

routes_eth_lan="default via 192.168.100.1

                192.168.10.0/24 via 192.168.100.1"
```

The syntax for baselayout1 is different but a manual setup, such as you tried should work too.

For a two system network, you don't need a routes statement at all. as the route within your local segment is created for you.

This suggests that you have a incorrect or missing piece of the kernel. Please post your lspci so we can look at your hardware.

----------

## anuraaga

Thanks for the tip. While I had a feeling it has to have something to do with the kernel configuration, it took your suggestion of doing a lspci to get the ball rolling. Running the command showed the system to have a Realtek RTL8168 gigabit network card.  Looking at my kernel configuration, I noticed I was using the built in RTL8169 driver.  A quick look at the Realtek article on Gentoo-Wiki made it seem like this driver should work with the RTL8168, but there was also an alternate driver provided by Realtek, and I decided it would be worth trying this out.  And what do you know, static networking started to work.  So while the RTL8169 driver that's included with the kernel may seem to work with the RTL8168 under most normal usage scenarios (DHCP, switches, internet), I guess it must have been incompatible with this particular use case of setting up static networking between two computers with a crossover cable.  I'm sure an lsmod on the ubuntu install would have shown it using the appropriate RTL8168 driver instead of the kernel-built in one.  

This would be an interesting issue to bring to the kernel driver maintainer's attention, unfortunately I have no idea how to do that   :Embarassed: 

----------

## NeddySeagoon

anuraaga,

Post a bug to https://bugs.gentoo.org and follow it up as comments are added.

Its quite possible you will be asked for more data than you initially provide on the bug.

The maintainers will be interested in your lspic and lspci -n output for your network interface.

Match them by the numbers at the left, e.g.

```
02:01.0 Ethernet controller: 3Com Corporation 3C920B-EMB Integrated Fast Ethernet Controller [Tornado] (rev 40)

02:01.0 0200: 10b7:9201 (rev 40)
```

The 10b7:9201 are the vendor and device IDs, which are unique to the chip type in your card.

----------

## jeffk

Please let us know what the filed bug id is (or I could file one). I have a Realtek RTL8111/8168B onboard, and it worked perfectly well with a single IP DHCP during buildout setup. Now I'm onsite trying to deploy with multiple static IP's, and I have the following unexpected bugs:

1) Only the first IP is reachable from the outside (e.g. SSH), but the local machine can ping itself to those IPs (UPDATE fixed).

2) DNS name resolving does not work at all, even with the /etc/resolv.conf containing the ISPs and/or OpenDNS nameservers(UPDATE fixed):

```
# lspci | grep 816

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
```

```
# ethtool eth0

Settings for eth0:

   Supported ports: [ TP ]

   Supported link modes:   10baseT/Half 10baseT/Full 

                           100baseT/Half 100baseT/Full 

                           1000baseT/Full 

   Supports auto-negotiation: Yes

   Advertised link modes:  10baseT/Half 10baseT/Full 

                           100baseT/Half 100baseT/Full 

                           1000baseT/Full 

   Advertised auto-negotiation: Yes

   Speed: 100Mb/s

   Duplex: Full

   Port: Twisted Pair

   PHYAD: 0

   Transceiver: internal

   Auto-negotiation: on

   Supports Wake-on: pumbg

   Wake-on: g

   Current message level: 0x00000033 (51)

   Link detected: yes

server1 kernels # emerge -s realtek

Searching...    

[ Results for search key : realtek ]

[ Applications found : 0 ]
```

```
server1 kernels # lsmod | grep 816

r8169                  24132  0 
```

OK, I'll cut this reply short because it's working now for some unknown reason. Maybe running ethtool had something to do with it. Not exactly confidence-inspiring in a remotely manged computer, but I'll keep an eye on this issue, obviously. Or buy a non flaky NIC.

I'd sure like Realtek to enhance the Linux kernel driver with all the information it needs to work properly. That a different driver is available for download on their page would be highly annoying if it applied to 2.6.27 as well.

----------

