kern/106722: [net] [patch] ifconfig may not connect an interface to known network

[Gleb Smirnoff]

  Just for the reference, here is a backtrace that shows how EEXIST is
returned:

rtrequest1(1,e6560aec,e6560ae0,e6560aec,30,...) at rtrequest1+0x658^M
rtinit(c3e21500,1,1) at rtinit+0x193^M
in_addprefix(c3e21500,1,e6560b68,0,1,...) at in_addprefix+0xa1^M
in_ifinit(c3c4ec00,c3e21500,c3eb6e50,0) at in_ifinit+0x761^M
in_control(c3f37bac,8040691a,c3eb6e40,c3c4ec00,c3e9b740) at in_control+0x93e^M
ifioctl(c3f37bac,8040691a,c3eb6e40,c3e9b740,0,...) at ifioctl+0x1cf^M
soo_ioctl(c3e5a828,8040691a,c3eb6e40,c414e000,c3e9b740) at soo_ioctl+0x2db^M
kern_ioctl(c3e9b740,3,8040691a,c3eb6e40) at kern_ioctl+0x296^M
ioctl(c3e9b740,e6560d00) at ioctl+0xf1^M
syscall(e6560d38) at syscall+0x242^M
Xint0x80_syscall() at Xint0x80_syscall+0x20^M

  The patch proposed vy Vladimir really looks like a hack. It covers only a
case when old route was a gateway one. So, even with patch the following
won't work:

route add 10.0.0.0/24 -iface lo0
ifconfig IFACE 10.0.0.1/24 alias

Also, I am afraid of the side effects, when patched kernel will substitute
route in a case when it should return error.

AFAIK, the problem needs a more generic approach. I see two approaches.

1) Introduce RTM_CHANGEADD, a command that will forcibly add route,
deleting all conflicting ones. Use this command in in_addprefix().

2) In rt_flags field we still have several extra bits. We can use
them to specify route source - RTS_CONNECTED, RTS_STATIC, RTS_XXX,
where XXX is a routing protocol. When issuing RTM_ADD a route with
a preferred source (e.g. CONNECTED vs STATIC) will override the old
one.

freebsd-net subscibers, what do you think?

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE