| Age | Commit message (Collapse) | Author |
|---|
|
OS-dependent functions renamed to be more consistent,
prepared to merge krt-set and krt-scan headers.
Name changes:
struct krt_if_params -> struct kif_params
struct krt_if_status -> struct kif_status
struct krt_set/scan_params -> struct krt_params
struct krt_set/scan_status -> struct krt_status
krt_if_params_same -> kif_sys_reconfigure
krt_if_copy_params -> kif_sys_copy_config
krt_set/scan_params_same -> krt_sys_reconfigure
krt_set/scan_copy_params -> krt_sys_copy_config
krt_if_scan -> kif_do_scan
krt_set_notify -> krt_do_notify
krt_scan_fire -> krt_do_scan
krt_if_ -> kif_sys_
krt_scan_ -> krt_sys_
krt_set_ -> krt_sys_
|
|
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.
|
|
|
|
|
|
and other non-portable functions on all systems.
|
|
turned on, but after some testing I'll gag it.
|
|
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. :)
|
|
|
|
o Now compatible with filtering.
o Learning of kernel routes supported only on CONFIG_SELF_CONSCIOUS
systems (on the others it's impossible to get it semantically correct).
o Learning now stores all of its routes in a separate fib and selects
the ones the kernel really uses for forwarding packets.
o Better treatment of CONFIG_AUTO_ROUTES ports.
o Lots of internal changes.
|
|
|
|
|
|
to the krt_capable mechanism as well.
|
|
(via Netlink). Tweaked kernel synchronization rules a bit. Discovered
locking bug in kernel Netlink :-)
Future plans: Hunt all the bugs and solve all the FIXME's.
|
|
The new kernel syncer is cleanly split between generic UNIX module
and OS dependent submodules:
- krt.c (the generic part)
- krt-iface (low-level functions for interface handling)
- krt-scan (low-level functions for routing table scanning)
- krt-set (low-level functions for setting of kernel routes)
krt-set and krt-iface are common for all BSD-like Unices, krt-scan is heavily
system dependent (most Unices require /dev/kmem parsing, Linux uses /proc),
Netlink substitues all three modules.
We expect each UNIX port supports kernel routing table scanning, kernel
interface table scanning, kernel route manipulation and possibly also
asynchronous event notifications (new route, interface state change;
not implemented yet) and build the KRT protocol on the top of these
primitive operations.
|
|
routes) from kernel routing tables unless the "persist" switch is set.
|
|
|
|
|
|
|
|
o Interface syncing is now a part of krt and it can have configurable
parameters. Actually, the only one is scan rate now :)
o Kernel routing table syncing is now synchronized with interface
syncing (we need the most recent version of the interface list
to prevent lots of routes to non-existent destinations from
appearing). Instead of its own timer, we just check if it's
route scan time after each iface list scan.
o Syncing of device routes implemented.
o CONFIG_AUTO_ROUTES should control syncing of automatic device routes.
o Rewrote krt_remove_route() to really remove routes :)
o Better diagnostics.
o Fixed a couple of bugs.
|
|
and does things "the right way". Few things are still missing (device
routes etc.), I'll add them later in the evening.
|
|
by other programs or the kernel itself is not supported yet, but it's not
needed for development of other protocols.
|
|
the kernel routing table as opposed to modifying it which is approximately
the same on non-netlink systems, I've split the kernel routing table
routines to read and write parts. To be implemented later ;-)
|
