Routing bugs: zebra/quagga are unusable

[Adrian Bocaniciu <a.bocaniciu@xxxxxxxxxxxx>]

	I have installed DragonFly-stable from 2005-01-02.  Immediately 
afterwards I have tested DragonFly to see if a well-known FreeBSD 4.x 
fatal bug, which has been removed from FreeBSD 5.3, still survives in DF.

	The 4.x bug probably still exists, but it is now masked by much more 
severe bugs.  AFAIK, the only way to use a DragonFly computer as an OSPF 
router, is to install either net/quagga (currently 0.96.5) or net/zebra 
(currently 0.94).

	With both packages, i.e. either with quagga or with zebra, any attempt 
to start ospfd results in a segmentation fault.  Moreover, if a vlan 
interface does exist when ospfd is started, DragonFly panics because of 
an attempt to read a non-existent page while in supervisor mode.

	In this second case, the behavior resembles that of FreeBSD 4.x, but 
with FreeBSD 4.x the supervisor page fault happened when ospfd was 
active and either an IP alias address was deleted or an interface was 
destroyed.  With DF, it is enough for a vlan interface to exist.

	Another DF bug is that the command "ifconfig vlan create", appears to 
succeed as it should, but it gives an error return code and an error 
message, e.g. "Interface vlan0 does not exist".  Maybe the interface is 
not fully created and this is related to the ospfd crash.  (ospfd was 
launched after the vlan0 interface was further configurated with tag, 
parent device and IP address, apparently without problems).

	Another problem is that net/quagga does not compile, because at the 
isisd compilation there is a name conflict with some "true" and "false" 
local variables.  This bug should normally be solved in quagga, they 
should not have used these names.  After removing isisd targets from the 
Makefiles, quagga can be compiled and installed, but ospfd does not 
work, the same as with zebra.

	If there is a person, which is familiar with the implementation of the 
routing sockets in the kernel, there are chances to find quickly the 
reason for the supervisor page fault, as it is very easily reproducible.

	Otherwise, I will investigate this bug nyself, as solving it is a 
sine-qua-non condition for being able to use DragonFly.  Unfortunately I 
am very busy right now, so if nobody else can look into this, I will be 
able to work at it only next month.


	IMO, this is a major problem for DF, as a large percentage of the 
computers that might use DF need to function as routers and using the 
obsolete routed or worse, static routes, does not count as a solution.

	Best regards !