FreeBSD bugs ;)

Alexander V. Chernikov melifaro at ipfw.ru
Sun Jan 22 14:41:40 CET 2012


Ondrej Zajicek wrote:
> On Thu, Jan 19, 2012 at 03:34:30PM +0400, Alexander V. Chernikov wrote:
>>>> So you removed it? Or renamed?
>>> I  removed  it,  so another interface took it's interface id, but bird
>>> kept associating previous name (vlan's) with this id. - renaming fails
>>> in principally the same way: bird keeps previous name ;)
>>>
>>>> It is supposed to work (it is handled as removing and readding the interface),
>>>> but probably not tested.
>>> Well,  I was supposed to be awfully rich by now, but it wasn't tested,
>>> hence it didn't work :>
>> Attached patch seems to work on FreeBSD.
>> For OpenBSD rtsock events seems to be the same (and interface renaming
>> is not supported there at all).
>> I don't have any NetBSD instance to test on, unfortunately
>>
>> Patch is not finished: interface renaming has to be handled in
>> appropriate protocols. In OSPF, for example, it is a bit tricky due to
>> the fact that interface can belong to several areas
> 
> I guess that seamless renaming is not really important, so it could be
> handled just by IF_CHANGE_TOO_MUCH (i.e. virtual iface down and up),
> that would work for any protocol. (or, because ifaces in BIRD are
> generally keyed by name, just remove the old one before creating the new
> one) BTW, AFAIK Linux does not allow iface renaming unless the iface is
> down.
I've already got some rename-handling code in OSPF but it is not fully
tested.. Maybe it is really better not to bother about keeping interface
UP.
> 
> struct_iface should not be freed when interface disappears. There are
> users for that (most recently link-local sticky neighbors, but AFAIK
> there are others i don't remember now). Perhaps these structures should
So the right way is to change such users behavior ? We definitely know
interface is destroyed by OS and we can't predict if it ever comes up
again and name / iface index / addresses are the same. Moreover, imagine
bird running on some kind of PPTP server with several thousand interface
UP which are destroyed/created with different interface indexes, names
and addreses with the rate of several interfaces per second. (and bird
announce all such interfaces (which has public/32 aadresses via OSPF) -
this is typical configuration for PPTP/PPPOE server farm). This is, of
course, not very similar to RS usage pattern, but bird claims to be
'sully functional dynamic IP routing daemon', right? :)

For NEF_STICKY we can either set iface pointer to NULL (and teach
neighbor-api consumers to check this, which is fair) or simply get some
gloval static "DUMMY" interface structure and change interface pointer
to it.
> be reference counted, but keeping them with IF_SHUTDOWN is OK. One
> thing that was a cause for a bug related to renaming is that shutdown
> ifaces kept their iface index and are returned by if_find_by_index().
> Simple fix for that would probably make destroying and creating ifaces
> work.

> 
> RTM_IFANNOUNCE seems useful. Am i understand that correctly that any
> iface changes are notified using RTM_IFINFO, just create and destroy of
> ifaces are notified using RTM_IFANNOUNCE? And also that when newly
Yes. This is stated in route(4):
     #define RTM_IFINFO      0xe    /* iface going up/down etc. */
     #define RTM_IFANNOUNCE  0x11   /* iface arrival/departure */

To be more precise:
ifconfig vlan999 create inet 1.2.3.4/29

triggers the following:

got message of size 24 on Sun Jan 22 17:11:43 2012
RTM_IFANNOUNCE: interface arrival/departure: len 24, if# 15, what: arrival

got message of size 184 on Sun Jan 22 17:11:43 2012
RTM_DELETE: Delete Route: len 184, pid: 0, seq 0, errno 0,
flags:<UP,GATEWAY,STATIC>
locks:  inits:
sockaddrs: <DST,GATEWAY,NETMASK>
 default default default

got message of size 108 on Sun Jan 22 17:11:43 2012
RTM_DELADDR: address being removed from iface: len 108, metric 0, flags:
sockaddrs: <NETMASK,IFP,IFA,BRD>
 default vlan999:0.0.0.0.0.0 default default

got message of size 116 on Sun Jan 22 17:11:43 2012
RTM_NEWADDR: address being added to iface: len 116, metric 0, flags:
sockaddrs: <NETMASK,IFP,IFA,BRD>

 255.255.255.248 vlan999:0.0.0.0.0.0 1.2.3.4 1.2.3.7

got message of size 232 on Sun Jan 22 17:11:45 2012
RTM_ADD: Add Route: len 232, pid: 0, seq 0, errno 0, flags:<UP>
locks:  inits:
sockaddrs: <DST,GATEWAY,NETMASK>
 1.2.3.0  (255) ffff ffff f8ff

...
(multicast. ipv6, ipv6 mcast)

Destroying interface gives nearly the same:

got message of size 232 on Sun Jan 22 17:21:16 2012
RTM_DELETE: Delete Route: len 232, pid: 0, seq 0, errno 0, flags:
locks:  inits:
sockaddrs: <DST,GATEWAY,NETMASK>
 1.2.3.0  (255) ffff ffff f8ff

got message of size 116 on Sun Jan 22 17:21:16 2012
RTM_DELADDR: address being removed from iface: len 116, metric 0,
flags:<UP,HOST>
sockaddrs: <NETMASK,IFP,IFA,BRD>
 255.255.255.248 vlan999:0.0.0.0.0.0 1.2.3.4 1.2.3.7

got message of size 168 on Sun Jan 22 17:21:16 2012
RTM_IFINFO: iface status change: len 168, if# 15, link: unknown,
flags:<BROADCAST,MULTICAST>

got message of size 192 on Sun Jan 22 17:21:16 2012
RTM_DELETE: Delete Route: len 192, pid: 0, seq 0, errno 0,
flags:<UP,GATEWAY,STATIC>
locks:  inits:
sockaddrs: <DST,GATEWAY,NETMASK>
 default 1.2.3.4 default

got message of size 116 on Sun Jan 22 17:21:16 2012
RTM_DELADDR: address being removed from iface: len 116, metric 0, flags:
sockaddrs: <NETMASK,IFP,IFA,BRD>
 255.255.255.248 vlan999:0.0.0.0.0.0 1.2.3.4 1.2.3.7

got message of size 272 on Sun Jan 22 17:21:16 2012
RTM_DELETE: Delete Route: len 272, pid: 0, seq 0, errno 0,
flags:<HOST,STATIC>
locks:  inits:
sockaddrs: <DST,GATEWAY,NETMASK>
 fe80::beae:c5ff:fe2e:4d74%15 0.0.0.0.0.0 ffff:ffff:ffff:ffff::

got message of size 140 on Sun Jan 22 17:21:16 2012
RTM_DELADDR: address being removed from iface: len 140, metric 0, flags:
sockaddrs: <NETMASK,IFP,IFA>
 ffff:ffff:ffff:ffff:: vlan999:0.0.0.0.0.0 fe80::beae:c5ff:fe2e:4d74%15

got message of size 344 on Sun Jan 22 17:21:16 2012
RTM_DELETE: Delete Route: len 344, pid: 0, seq 0, errno 0, flags:<DONE>
locks:  inits:
sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA>
 fe80::%15  (255) ffff ffff ffff ffff ffff ffff ffff vlan999:0.0.0.0.0.0
fe80::beae:c5ff:fe2e:4d74%15

got message of size 24 on Sun Jan 22 17:21:16 2012
RTM_IFANNOUNCE: interface arrival/departure: len 24, if# 15, what: departure



OpenBSD and NetBSD behaves the same way (ordering of IF_ANNOUNCE /
IF_IFINFO / RTM_ADD / RTM_DEL is the same)

> created iface is announced by RTM_IFANNOUNCE, there is almost none
> information in that announcement to really create the iface in BIRD?
> Perhaps it is supposed to request RTM_IFINFO about that iface by some
> sysctl? Or we could at least trigger early iface scan.
Well, we can simply listen to the next routing socket messages (or
really trigger iface scan as a quick fix)
> 
> Some other comments below.
> 
>> +    /* Interface is renamed. */
>> +    if (strcmp(iface->name, ifam->ifan_name))
>> +    {
>> +      DBG("KRT: Interface %s renamed to %s\n", iface->name, ifam->ifan_name);
>> +      memcpy(&f, iface, sizeof(struct iface));
>> +      /* Assume both strings are IFNAMSIZ length */
>> +      memcpy(f.name, ifam->ifan_name, IFNAMSIZ);
>> +      if_update(&f);
>> +    }
> 
> This does not work well. Because if_update would match iface by name,
> this would create a new iface structure so there would be two, until
> the old one would be removed during another iface scan. As a consequence,
> if_what_changed() would never return IF_CHANGE_NAME.
Already notices that, thanks.
> 
>> @@ -588,6 +642,8 @@ krt_read_msg(struct proto *p, struct ks_msg *msg, int scan)
>>      case RTM_DELETE:
>>        krt_read_rt(msg, (struct krt_proto *)p, scan);
>>        break;
>> +    case RTM_IFANNOUNCE:
>> +      krt_read_ifannounce(msg);
>>      case RTM_IFINFO:
>>        krt_read_ifinfo(msg);
>>        break;
> 
> Missing break here?
Yes.
> 




More information about the Bird-users mailing list