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 _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
