# Static IP stops working [Solved]

## tanwa

I have been using Gentoo for a couple week. It was working like a charm until I update this morning. Now, whenever Gentoo tries to assign this same IP I have been using to eth0, it always say " MYIP already taken by eth0." and my internet is not working. However, I can still connect to internet if I use dhcpcd to setup my eth0 instead. Here's what my /etc/conf.d/net looks like

```

modules=("ifconfig")

config_eth0=( "192.168.11.3 netmask 255.255.255.0 broadcast 192.168.11.255" )

routes_eth0=("default via 192.168.11.1")

```

My ifconfig when it's not working

```

eth0      Link encap:Ethernet  HWaddr 00:40:CA:98:2B:43

          inet6 addr: fe80::240:caff:fe98:2b43/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:42410 errors:0 dropped:0 overruns:0 frame:0

          TX packets:46650 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:8077263 (7.7 Mb)  TX bytes:5305547 (5.0 Mb)

          Interrupt:23 Base address:0x6000

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:10 errors:0 dropped:0 overruns:0 frame:0

          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:840 (840.0 b)  TX bytes:840 (840.0 b)

```

and my ifconfig when I use dhcpcd

```

eth0      Link encap:Ethernet  HWaddr 00:40:CA:98:2B:43

          inet addr:192.168.11.5  Bcast:192.168.11.255  Mask:255.255.255.0

          inet6 addr: fe80::240:caff:fe98:2b43/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:42502 errors:0 dropped:0 overruns:0 frame:0

          TX packets:46683 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:8088537 (7.7 Mb)  TX bytes:5308937 (5.0 Mb)

          Interrupt:23 Base address:0x6000

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:10 errors:0 dropped:0 overruns:0 frame:0

          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:840 (840.0 b)  TX bytes:840 (840.0 b)

```

dmesg right after I try to ifconfig eth0 down and ifconfig eth0 up gives

```

Adding 2939852k swap on /dev/hda5.  Priority:-1 extents:1 across:2939852k

fuse init (API version 7.8)

fuse distribution version: 2.7.0

eth0: no IPv6 routers present

eth0: no IPv6 routers present

```

(I did it twice)

Any suggestion?Last edited by tanwa on Sun Nov 04, 2007 6:54 pm; edited 1 time in total

----------

## tylerwylie

What happens when you statically set your IP to .4 instead of .3?

----------

## tanwa

Umm yeah it works. I change it to 192.168.11.7 because .2 and .4 are used by my roommates. They all have static ip as well. I wonder why .3 doesn't work anymore

----------

## ianw1974

Try:

```
config_eth0=( "192.168.11.3/24" )

routes_eth0=( "default gw 192.168.11.1" )
```

this is all I have configured in my /etc/conf.d/net file and no problems.  Noticed yours looked a lot different, hence why I suggest try this instead.

----------

## Hu

Perhaps some other system has claimed 192.168.11.3, so your system is refusing to use it.  What is the output of ping -c4 192.168.11.3 ; arp -n?  You will need an address to issue those commands.

----------

## tanwa

Since my last post, I have been using 192.168.11.7 without problem until I restart. Then, it's the same thing again. .7 stops working saying that it has already been taken by eth0. DHCPCD still works fine

Here's the result of "ping -c4 192.168.11.7; arp -n"

```

PING 192.168.11.7 (192.168.11.7) 56(84) bytes of data.

64 bytes from 192.168.11.7: icmp_seq=1 ttl=128 time=1.73 ms

64 bytes from 192.168.11.7: icmp_seq=2 ttl=128 time=2.75 ms

64 bytes from 192.168.11.7: icmp_seq=3 ttl=128 time=1.83 ms

64 bytes from 192.168.11.7: icmp_seq=4 ttl=128 time=1.78 ms

--- 192.168.11.7 ping statistics ---

4 packets transmitted, 4 received, 0% packet loss, time 3010ms

rtt min/avg/max/mdev = 1.731/2.025/2.754/0.424 ms

Address                  HWtype  HWaddress           Flags Mask            Iface

192.168.11.7             ether   00:13:CE:22:CF:BC   C                     eth0

192.168.11.1             ether   00:16:01:14:03:F8   C                     eth0

```

----------

## tanwa

Here's the same command comparing .3 and .7

```

PING 192.168.11.3 (192.168.11.3) 56(84) bytes of data.

64 bytes from 192.168.11.3: icmp_seq=1 ttl=64 time=0.804 ms

64 bytes from 192.168.11.3: icmp_seq=2 ttl=64 time=0.890 ms

64 bytes from 192.168.11.3: icmp_seq=3 ttl=64 time=0.927 ms

64 bytes from 192.168.11.3: icmp_seq=4 ttl=64 time=0.813 ms

--- 192.168.11.3 ping statistics ---

4 packets transmitted, 4 received, 0% packet loss, time 3000ms

rtt min/avg/max/mdev = 0.804/0.858/0.927/0.059 ms

Address                  HWtype  HWaddress           Flags Mask            Iface

192.168.11.1             ether   00:16:01:14:03:F8   C                     eth0

192.168.11.3             ether   00:1C:B3:BB:54:B4   C                     eth0

192.168.11.7             ether   00:13:CE:22:CF:BC   C                     eth0

```

----------

## tanwa

 *ianw1974 wrote:*   

> Try:
> 
> ```
> config_eth0=( "192.168.11.3/24" )
> 
> ...

 

This gives the same result.

----------

## Hu

Something strange is happening.  Other systems are claiming those addresses.  How is your DHCP server configured?  I suspect it has been set to issue addresses in the same range you are trying to assign static addresses.  This is generally a bad idea.

----------

## tanwa

I use dhcpcd to configure my dhcp connection. Just to remind you that the problem is not when i'm using dhcp. It's when I'm using static ip that it's not working. It actually works when I use dhcp, which I have never used until I ran into this problem. All the others computer on the network have static ip as well, but they are working fine (both of them use Windows)

Here's my ifconfig when i'm using dhcp

```

th0      Link encap:Ethernet  HWaddr 00:40:CA:98:2B:43

          inet addr:192.168.11.5  Bcast:192.168.11.255  Mask:255.255.255.0

          inet6 addr: fe80::240:caff:fe98:2b43/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:89922 errors:0 dropped:0 overruns:0 frame:0

          TX packets:101992 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:10819831 (10.3 Mb)  TX bytes:14849711 (14.1 Mb)

          Interrupt:23 Base address:0x6000

```

----------

## Hu

That is not what I asked.  I asked to see the configuration of your DHCP server.  When you are on DHCP, the server is choosing an unused address and everything works.  When you force an IP address, you are colliding with someone else.  My suspicion is supported by the fact that you keep getting low numbered addresses when you go to DHCP.  It is traditional that a DHCP server have a dedicated portion of the IP space well away from the range of static IP addresses.  The DHCP server then issues addresses from its dedicated range.

----------

## tanwa

My Apology right there. How do you find out the config of DHCP server?

----------

## tylerwylie

 *tanwa wrote:*   

> My Apology right there. How do you find out the config of DHCP server?

 Well are you using a router that's running DHCP? Or is it being handled by something else?

----------

## tanwa

Yes, it is being handled by the router.

Here's, i think, what you are asking for

```

     DHCP

IP Address    24.216.70.197 

Subnet Mask    255.255.252.0 

Default Gateway    24.216.68.1 (Via DHCP)

DNS1(Primary)   24.217.1.162 (Via DHCP)

DNS2(Secondary)   24.217.0.5 (Via DHCP)

DNS3   24.217.0.55 (Via DHCP)

Host Name    AP0016011403F8 (Manual Setup)

Domain Name    

MTU Size    1500

DHCP Server Address    68.114.37.6

Lease Acquired Time    2004/09/30 18:41:42

Lease Period    2004/09/30 19:41:42

192.168.11.3     00:1C:B3:BB:54:B4     Macintosh     47:25:51     Auto

192.168.11.5 (*)    00:40:CA:98:2B:43    UNKNOWN-USER    40:34:27    Auto

192.168.11.6    00:30:65:2C:78:54    UNKNOWN-USER    23:38:19    Auto

192.168.11.7    00:13:CE:22:CF:BC    UNKNOWN-USER    47:41:4    Auto

192.168.11.8    00:90:96:F2:74:99    FunkMachine    34:42:28    Auto

192.168.11.9    00:1B:77:24:3C:D3    XPS    32:22:40    Auto

192.168.11.10    00:1B:EA:BF:0E:BF    UNKNOWN-USER    47:45:40    Auto

192.168.11.11    00:12:F0:04:13:A3    rim    32:23:4    Auto

192.168.11.12    00:17:AB:D8:67:58    Wii    47:35:25    Auto

192.168.11.16    00:1A:73:90:C9:7A    Arturo-PC    35:20:5    Auto

```

I'm using .5, as you can see. .7 is not used by anyone and .3 is used by a laptop of my friend a long time ago, and the laptop is not even around anymore.

----------

## tylerwylie

 *tanwa wrote:*   

> Yes, it is being handled by the router.
> 
> Here's, i think, what you are asking for
> 
> ```
> ...

 Try clearing the .3 from the router's DHCP handout, or reserve it and see if you get that issue still.

----------

## Hu

I was hoping you were using a Linux-based DHCP server, such as dhcpd.  The listing of issued addresses strengthens my suspicion, but without a listing of what addresses the server will hand out, I cannot be sure.  That looks like output from some consumer-grade router, so the information I want may not even be available.  Just to restate my suspicion about the problem:

DHCP servers typically have some range of addresses for which the server is authoritative, and it can issue leases on those addresses at its discretion.  The output you provided strongly suggests that the router's DHCP server considers itself authoritative for 192.168.11.3-16, and probably quite a few more addresses on either side of that.  Since the router is authoritative, it issues addresses at its discretion, meaning that if your system is not using, say 192.168.11.3, then it will issue that to someone else.  When your system boots up, it tries to claim 192.168.11.3 because that is what you told it to do in /etc/conf.d/net.  This causes a conflict, because the DHCP server issued the address to somebody else.  In the event of a conflict, your system chooses not to attain an address, rather than disrupt an existing system.

The fix is to stop assigning static IP addresses in the range that the DHCP server owns.  You could do this by changing to a static address in some other part of the range, such as 192.168.11.254, or by going to DHCP-driven configuration permanently.  I assume you are resisting this because you need some guarantee of which address goes to which system.  Some DHCP servers have the concept of reserving an address for a particular MAC address, so that a system with a MAC of 00:11:22:33:44:55 always gets 10.1.1.2 and no other system is ever given that address.  I do not know whether your DHCP server supports this concept.  If it does, it will likely have "reservation" somewhere in the documentation for that feature.

Before you ask, I do not know why 192.168.11.3 suddenly broke for you if it really is used only by a laptop which has not been on the network in a long time.

----------

## tanwa

Thank to you all. I think I finally understand what causes this problem now   :Very Happy:  I was thinking the update might have caused it for a while.

----------

## tylerwylie

 *Hu wrote:*   

> I was hoping you were using a Linux-based DHCP server, such as dhcpd.  The listing of issued addresses strengthens my suspicion, but without a listing of what addresses the server will hand out, I cannot be sure.  That looks like output from some consumer-grade router, so the information I want may not even be available.  Just to restate my suspicion about the problem:
> 
> DHCP servers typically have some range of addresses for which the server is authoritative, and it can issue leases on those addresses at its discretion.  The output you provided strongly suggests that the router's DHCP server considers itself authoritative for 192.168.11.3-16, and probably quite a few more addresses on either side of that.  Since the router is authoritative, it issues addresses at its discretion, meaning that if your system is not using, say 192.168.11.3, then it will issue that to someone else.  When your system boots up, it tries to claim 192.168.11.3 because that is what you told it to do in /etc/conf.d/net.  This causes a conflict, because the DHCP server issued the address to somebody else.  In the event of a conflict, your system chooses not to attain an address, rather than disrupt an existing system.
> 
> The fix is to stop assigning static IP addresses in the range that the DHCP server owns.  You could do this by changing to a static address in some other part of the range, such as 192.168.11.254, or by going to DHCP-driven configuration permanently.  I assume you are resisting this because you need some guarantee of which address goes to which system.  Some DHCP servers have the concept of reserving an address for a particular MAC address, so that a system with a MAC of 00:11:22:33:44:55 always gets 10.1.1.2 and no other system is ever given that address.  I do not know whether your DHCP server supports this concept.  If it does, it will likely have "reservation" somewhere in the documentation for that feature
> ...

 ++.

By the address he is getting (.11) I think he is using a buffalo and would also recommend flashing the firmware, if he wants complete control over his router.  DD-WRT is really nice.  I think buffalo's default firmware will do DHCP reservations per mac or hostname as well, like DD-wrt.

I think that would be the ideal solution, setting up a reservation on the server so you can keep your computer on DHCP.

----------

