I also had this problem, despite my statically assigned ip addresses,
and thought my static address had been replaced.
Though, Anand is right, I was using:
$ ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:D0:B7:17:9A:8F
inet addr:169.254.116.34 Bcast:0.0.0.0 Mask:255.255.0.0
that is only showing one ip address, but if trying:
$ ip addr show eth1
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:d0:b7:17:9a:8f brd ff:ff:ff:ff:ff:ff
inet 169.254.116.34/16 scope link eth1
inet 192.168.1.1/24 brd 192.168.1.255 scope global eth1
we see both addresses. So the error message:
$ ifconfig eth1 192.168.1.1
SIOCSIFADDR: File exists
becomes sort of self explanatory...
Confused script
---------------
But then why was I having problems with network access?
Answer: my iptables script.
My firewall setup script harvests current ip addresses from the
system by sed:ing ifconfig output (maybe typical for others with
problems?), for example:
INT_IP=`ifconfig eth1 | sed -n -e "2 s/.*inet\
addr:\([0-9]*\.[0-9]*\.[0-9]*\.[0-9]*\)\ .*/\1/p"`
As ifconfig after zeroconf install returns the 169.254 address, iptables
was being setup with the wrong ip addresses and the "real" addresses
were blocked, so no wonder that network access was hard.
Anand: if it is possible for you to adjust your stuff to make ifconfig
by default return the "real" address, I think that would be a good
idea. Otherwise, everybody else just have to learn to stop using
ifconfig in firewall scripts etc...
Another thing, I also see something like a 10 second delay when doing
ifup eth1. Is this normal?
Samba
-----
After correcting my forewall script to use 'ip addr show' instead, I
discovered that I was also having problems with samba's Netbios name
service while having zeroconf enabled.
My server's hostname would not become available to PCs on the network.
The reason seems to be that samba uses the wrong subnetmask for
interfaces that also have a zeroconf address. See debug logs from
nmbd below:
Samba without zeroconf (FALLBACK=YES)
-------------------------------------
ip addr show:
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:d0:b7:17:9a:8f brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 brd 192.168.1.255 scope global eth1
log.nmbd:
[2006/03/17 13:23:55, 2] lib/interface.c:add_interface(81)
added interface ip=192.168.1.1 bcast=192.168.1.255 nmask=255.255.255.0
[2006/03/17 13:23:55, 2] nmbd/nmbd_subnetdb.c:make_subnet(173)
making subnet name:192.168.1.1 Broadcast address:192.168.1.255 Subnet
mask:255.255.255.0
Samba with zeroconf
-------------------
ip addr show:
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:d0:b7:17:9a:8f brd ff:ff:ff:ff:ff:ff
inet 169.254.116.34/16 scope link eth1
inet 192.168.1.1/24 brd 192.168.1.255 scope global eth1
log.nmbd:
[2006/03/17 13:49:21, 2] lib/interface.c:add_interface(81)
added interface ip=169.254.116.34 bcast=169.254.255.255 nmask=255.255.0.0
[2006/03/17 13:49:21, 2] lib/interface.c:add_interface(81)
added interface ip=192.168.1.1 bcast=192.168.255.255 nmask=255.255.0.0
[2006/03/17 13:49:21, 2] nmbd/nmbd_subnetdb.c:make_subnet(173)
making subnet name:192.168.1.1 Broadcast address:192.168.255.255 Subnet
mask:255.255.0.0
[2006/03/17 13:49:21, 2] nmbd/nmbd_subnetdb.c:make_subnet(173)
making subnet name:169.254.116.34 Broadcast address:169.254.255.255 Subnet
mask:255.255.0.0
In the latter case you can see that both addresses on eth1 will get a
samba "internal" subnetmask of 255.255.0.0 while the real address really
should have 255.255.255.0.
This governs how Samba will do broadcasts, which will now fail, at least
on systems like mine that is not open for broadcasts on the B-net.
I guess not so many people have seen this as most people with problems
probably disable zeroconf, but you should probably take a look at it,
right? (Maybe this is a Samba bug, I can't judge.)
Best regards
Mike Wilson
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
