Bug 105945 - Address can disappear from network interface
Summary: Address can disappear from network interface
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 7.0-CURRENT
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-28 10:40 UTC by Yar Tikhiy
Modified: 2018-01-03 05:16 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yar Tikhiy 2006-11-28 10:40:12 UTC
	
	If a cloned interface is destroyed, recreated, and assigned
	an address without a delay, the address will disappear in
	a moment.  Moreover, a delay not longer than 0.1 sec between
	destruction and recreation doesn't seem to affect the issue.

How-To-Repeat: 
dg6# cat lo.sh
ifconfig lo5 destroy
ifconfig lo5 create 127.1.1.$1/24 mtu ${1}00
ifconfig lo5
echo almost there...
echo
sleep 1
ifconfig lo5
echo

dg6# sh lo.sh 100
ifconfig: interface lo5 does not exist
lo5: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 10000
        inet 127.1.1.100 netmask 0xffffff00
almost there...

lo5: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 10000
        inet 127.1.1.100 netmask 0xffffff00

dg6# sh lo.sh 101
lo5: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 10100
        inet 127.1.1.101 netmask 0xffffff00
almost there...

lo5: flags=8048<LOOPBACK,RUNNING,MULTICAST> mtu 10100

dg6# sh lo.sh 102
lo5: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 10200
        inet 127.1.1.102 netmask 0xffffff00
almost there...

lo5: flags=8048<LOOPBACK,RUNNING,MULTICAST> mtu 10200

dg6#


As the cookie stored in mtu shows, we are not setting parameters
on the dying instance of the interface -- IP just disappears from
the new instance.
Comment 1 Bruce M Simpson 2007-02-07 04:04:45 UTC
I can reproduce these results as provided by Yar on -CURRENT from 3rd 
February 2007.

the ifconfig parser grammar will allow this behaviour.
it screams race condition -- this would allow ifconfig to set the 
address on what appears to be the dying clone.
Comment 2 kes-kes 2008-08-03 10:35:46 UTC
When I start routed address disappears from rl0 interface (2:28:19)
When I kill routed and start it again address returns to system(2:28:40)
When I kill routed and start it again address disappears from rl0 interface
This is log file of routed:

kes# cat routed.log
-- 02:28:19 --
Tracing actions started
Add interface rl0  10.0.16.1      -->10.0.0.0/16     metric=4 <RIPV2>
RCVBUF=61440
turn on RIP
Add interface rl2  10.10.16.1     -->10.10.16.0/24   <RIPV2>
Add interface rl4  10.11.16.3     -->10.11.16.0/28   <RIPV2>
Add interface lo0  127.0.0.1      -->127.0.0.1/32    <LOOPBACK> <PASSIVE>
Add interface tun0 92.113.11.189  -->195.5.5.202/32  <PT-TO-PT> <PASSIVE|BCAST_RDISC>
Add interface ng0  10.11.16.3     -->192.168.9.2/32  <PT-TO-PT> <PASSIVE|BCAST_RDISC>
start supplying routes
Add    192.168.9.2/32  -->10.11.16.3       metric=0  ng0 <IF>
Add    10.11.16.3/32   -->127.0.0.1        metric=0  ng0 <IF|LOCAL>
Add    195.5.5.202/32  -->92.113.11.189    metric=0  tun0 <IF>
Add    92.113.11.189/32-->127.0.0.1        metric=0  tun0 <IF|LOCAL>
Add    127.0.0.1/32    -->127.0.0.1        metric=0  lo0 <IF>
Add    10.11.16.0/28   -->10.11.16.3       metric=0  rl4 <IF>
Add    10.10.16.0/24   -->10.10.16.1       metric=0  rl2 <IF>
Add    10.0.0.0/16     -->10.0.16.1        metric=4  rl0 <IF>
-- 02:28:19 --
ignore RTM_NEWMADDR for AF 0
ignore RTM_NEWMADDR for AF 0
ignore RTM_NEWMADDR for AF 0
ignore RTM_NEWMADDR for AF 0
ignore RTM_NEWMADDR for AF 0
ignore RTM_NEWMADDR for AF 0
-- 02:28:20 --
ignore ARP RTM_ADD from pid 0: 10.10.16.214/32
-- 02:28:21 --
ignore RTM_MISS: 10.0.16.1
-- 02:28:21 --
ignore RTM_MISS: 10.0.16.1
ignore RTM_MISS: 10.0.16.1
-- 02:28:21 --
ignore RTM_MISS: 10.0.16.1
ignore RTM_MISS: 10.0.16.1
-- 02:28:22 --
ignore RTM_MISS: 10.0.16.1
-- 02:28:23 --
ignore RTM_MISS: 10.0.16.1
ignore RTM_MISS: 10.0.16.1
-- 02:28:23 --
ignore RTM_MISS: 10.0.16.1
ignore RTM_MISS: 10.0.16.1
-- 02:28:24 --
ignore ARP RTM_ADD from pid 0: 10.10.16.214/32
-- 02:28:24 --
ignore RTM_MISS: 10.0.16.1
ignore cloned RTM_ADD from pid 0: 10.0.16.3/32
-- 02:28:24 --
ignore RTM_MISS: 10.0.16.1
-- 02:28:24 --
ignore RTM_MISS: 10.0.16.1
ignore RTM_MISS: 10.0.16.1
-- 02:28:25 --
ignore RTM_MISS: 10.0.16.1
ignore RTM_MISS: 10.0.16.1
-- 02:28:26 --
ignore RTM_MISS: 10.0.16.1
-- 02:28:27 --
ignore RTM_MISS: 10.0.16.1
ignore RTM_MISS: 10.0.16.1
-- 02:28:27 --
ignore RTM_MISS: 10.0.16.1
ignore RTM_MISS: 10.0.16.1
-- 02:28:28 --
ignore ARP RTM_ADD from pid 0: 10.10.16.214/32
-- 02:28:28 --
ignore RTM_MISS: 10.0.16.1
-- 02:28:28 --
ignore RTM_MISS: 10.0.16.1
ignore RTM_MISS: 10.0.16.1
-- 02:28:29 --
ignore RTM_MISS: 10.0.16.1
-- 02:28:30 --
ignore RTM_MISS: 10.0.16.1
ignore RTM_MISS: 10.0.16.1
-- 02:28:30 --
send all routes and inhibit dynamic updates for 2.978 sec
exiting with signal 15

-- 02:28:40 --
Tracing actions started
Add interface rl0  10.0.16.1      -->10.0.0.0/16     metric=4 <RIPV2>
RCVBUF=61440
turn on RIP
Add interface rl2  10.10.16.1     -->10.10.16.0/24   <RIPV2>
Add interface rl4  10.11.16.3     -->10.11.16.0/28   <RIPV2>
Add interface lo0  127.0.0.1      -->127.0.0.1/32    <LOOPBACK> <PASSIVE>
Add interface tun0 92.113.11.189  -->195.5.5.202/32  <PT-TO-PT> <PASSIVE|BCAST_RDISC>
Add interface ng0  10.11.16.3     -->192.168.9.2/32  <PT-TO-PT> <PASSIVE|BCAST_RDISC>
start supplying routes
Add    192.168.9.2/32  -->10.11.16.3       metric=0  ng0 <IF>
Add    10.11.16.3/32   -->127.0.0.1        metric=0  ng0 <IF|LOCAL>
Add    195.5.5.202/32  -->92.113.11.189    metric=0  tun0 <IF>
Add    92.113.11.189/32-->127.0.0.1        metric=0  tun0 <IF|LOCAL>
Add    127.0.0.1/32    -->127.0.0.1        metric=0  lo0 <IF>
Add    10.11.16.0/28   -->10.11.16.3       metric=0  rl4 <IF>
Add    10.10.16.0/24   -->10.10.16.1       metric=0  rl2 <IF>
Add    10.0.0.0/16     -->10.0.16.1        metric=4  rl0 <IF>
-- 02:28:40 --
ignore RTM_NEWMADDR for AF 0
ignore RTM_NEWMADDR for AF 0
ignore RTM_NEWMADDR for AF 0
ignore RTM_NEWMADDR for AF 0
ignore RTM_NEWMADDR for AF 0
ignore RTM_NEWMADDR for AF 0
-- 02:28:40 --
ignore ARP RTM_ADD from pid 0: 10.10.16.214/32
-- 02:28:40 --
ignore RTM_MISS: 10.0.16.1
-- 02:28:40 --
Add    10.11.16.0/24   -->10.0.16.3        metric=5  rl0 02:28:40
-- 02:28:40 --
ignore RTM_MISS: 10.0.16.1
ignore RTM_MISS: 10.0.16.1
-- 02:28:41 --
ignore RTM_MISS: 10.0.16.1
-- 02:28:41 --
ignore RTM_MISS: 10.0.16.1
ignore RTM_MISS: 10.0.16.1
-- 02:28:42 --
ignore ARP RTM_ADD from pid 0: 10.0.16.1/32
-- 02:28:43 --
ignore ARP RTM_ADD from pid 0: 10.10.16.214/32
-- 02:28:44 --
ignore ARP RTM_ADD from pid 0: 10.0.16.3/32
-- 02:28:45 --
send all routes and inhibit dynamic updates for 3.145 sec
-- 02:28:52 --
send all routes and inhibit dynamic updates for 4.112 sec
exiting with signal 15

if need any other logs. ask me and I will send
Comment 3 Volker Werth freebsd_committer 2009-01-14 22:27:47 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-net


Over to maintainer(s).
Comment 4 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:04 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped