If other side of a socket is sending data faster than
BIRD is processing, BIRD does not schedule any other
callbacks (events, timers, rx/tx callbacks).
KRF_INSTALLED flag was not cleared during reconfiguration
that lead to not removing routes during reconfigure when
export rules changed.
We also should not try to remove routes we didi not installed,
on Linux this leads to warnings (as kernel checks route source
field and do not allow to remove non-bird routes) but we should
not rely on it.
Here is a patch fixing a bug that causes breakage of a local routing
table during shutdown of Bird. The problem was caused by shutdown
of 'device' protocol before shutdown of 'kernel' protocol. When
'device' protocol went down, the route (with local network prefix)
From different protocol (BGP or OSPF) became preferred and installed
to the kernel routing table. Such routes were broken (like
192.168.1.0/24 via 192.168.1.2). I think it is also the cause
of problem reported by Martin Kraus.
The patch disables updating of kernel routing table during shutdown of
Bird. I am not sure whether this is the best way to fix it, I would
prefer to forbid 'kernel' protocol to overwrite routes with
'proto kernel'.
The patch also fixes a problem that during shutdown sometimes routes
created by Bird remained in the kernel routing table.
Also, removed the `if (s)' test, because I believe that as the whole
socket interface doesn't accent NULL pointers, sk_reallocate() shouldn't
be the only exception.
you can delete the socket from anywhere in the hooks and nothing should break.
Also, the receive/transmit buffers are now regular xmalloc()'ed buffers,
not separate resources which would need shuffling around between pools.
sk_close() is gone, use rfree() instead.
for even only medium sized route table output. Fix a strange garbled
output problem in the client. The latter seems to be caused by some
library doing tcflush while there is still command output pending. So
the best fix here is to do fflush and then tcdrain. Note that this
problem occurs only under certain load situations and is not too easy to
reproduce.
(by Andreas)
Please try compiling your code with --enable-warnings to see them. (The
unused parameter warnings are usually bogus, the unused variable ones
are very useful, but gcc is unable to control them separately.)
of calling the protocols manually.
Implemented printing of dynamic attributes in `show route all'.
Each protocol can now register its own attribute class (protocol->attr_class,
set to EAP_xxx) and also a callback for naming and formatting of attributes.
The callback can return one of the following results:
GA_UNKNOWN Attribute not recognized.
GA_NAME Attribute name recognized and put to the buffer,
generic code should format the value.
GA_FULL Both attribute name and value put to the buffer.
Please update protocols generating dynamic attributes to provide
the attr_class and formatting hook.
address, not per interface (hence it's ifa->flags & IA_UNNUMBERED) and
should be set reliably. IF_MULTIACCESS should be fixed now, but it isn't
wise to rely on it on interfaces configured with /30 prefix.
(the current version UNIX-specific) anyway, so it's useless to try splitting it
to sysdep and generic part. Instead of this, configure script decides (based on
system type and user's wish) what (if any) client should be built and what
autoconfiguration it requires. Also, the client provides its own die/bug/...
functions.
used for automatic generation of instance names.
protocol->name is the official name
protocol->template is the name template (usually "name%d"),
should be all lowercase.
Updated all protocols to define the templates, checked that their configuration
grammar includes proto_name which generates the name and interns it in the
symbol table.
multicast abilities depending on definedness of symbols and use hard-wired
system-dependent configuration defines instead.
Please test whereever you can.
with protocols wanting to use the same port on the same interface
during reconfiguration time.
How to use locks: In the if_notify hook, just order locks for the
interfaces you want to work with and do the real socket opening after the
lock hook function gets called. When you stop using the socket, close
it and rfree() the lock.
Please update your protocols to use the new locking mechanism.
but the core routines are there and seem to be working.
o lib/ipv6.[ch] written
o Lexical analyser recognizes IPv6 addresses and when in IPv6
mode, treats pure IPv4 addresses as router IDs.
o Router ID must be configured manually on IPv6 systems.
o Added SCOPE_ORGANIZATION for org-scoped IPv6 multicasts.
o Fixed few places where ipa_(hton|ntoh) was called as a function
returning converted address.
The changes are just too extensive for lazy me to list them
there, but see the comment at the top of sysdep/unix/krt.c.
The code got a bit more ifdeffy than I'd like, though.
Also fixed a bunch of FIXME's and added a couple of others. :)
addresses per interface (needed for example for IPv6 support).
Visible changes:
o struct iface now contains a list of all interface addresses (represented
by struct ifa), iface->addr points to the primary address (if any).
o Interface has IF_UP set iff it's up and it has a primary address.
o IF_UP is now independent on IF_IGNORED (i.e., you need to test IF_IGNORED
in the protocols; I've added this, but please check).
o The if_notify_change hook has been simplified (only one interface pointer
etc.).
o Introduced a ifa_notify_change hook. (For now, only the Direct protocol
does use it -- it's wise to just listen to device routes in all other
protocols.)
o Removed IF_CHANGE_FLAGS notifier flag (it was meaningless anyway).
o Updated all the code except netlink (I'll look at it tomorrow) to match
the new semantics (please look at your code to ensure I did it right).
Things to fix:
o Netlink.
o Make krt-iface interpret "eth0:1"-type aliases as secondary addresses.
operations on 2.1/2.2 kernels. This allows passing of real interface
indexes instead of referencing interfaces by their IP addresses which
fails badly in presence of unnumbered interfaces.
Unfortunately, this structure is not visible with glibc 2.0 as it provides
its own networking headers :-( Both libc5 and glibc 2.1 should be OK.
