FreeBSD bugs ;)

[Ondrej Zajicek]

On Sun, Jan 22, 2012 at 05:41:40PM +0400, Alexander V. Chernikov wrote:
> 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.

BTW, i already have some minor fixes in iface scanning code in GIT i
discovered yesterday. I would merge your patch and my comments to
fix these bugs.

> > 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.

This is just technical issue whether a struct iface has to be removed
immediately (synchronously) when an iface disappears, or a bit later
when it would be removed anyway. For example, OSPF would probably hold
some references for these structures until next recalculation. I guess
that it is much simpler and convenient to add reference counting to
struct iface than to modify all these users. It is true that currently
we just never free these structs, which is bad but not particularly
problematic. But fixing this is a different issue. So we could probably
fix renaming/creating/removing ifaces now and i will add these reference
counting later.

> 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.

Well, BIRD would have probably a problem in such settings, because there
are too many parts of the code that would run in O(n^2) time (where n is
a number of ifaces).

> 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.

This is an issue for link-local sticky neighbors, which obviously needs
a way to specify an interface. We could use explicit string, but that
would make it two times more complicated. It is a kind of sticky iface
entry.

> > 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

Thanks

BTW, i also noticed that 'ifconfig re0 down' on BSD would first trigger
RTM_DELADDR (for an address of iface), then RTM_IFINFO (for iface down),
but in the next scan, the address is still reported. That seems
a bit inconsistent to me, but not a big issue (interfaces disappears in
BIRD and then reappears, but as the iface is down, it is not propagated
anywhere).

> 
> 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
> 
...

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20120122/a23040ed/attachment-0001.asc>