From owner-cvs-all  Thu Dec 23 10:43: 2 1999
Delivered-To: cvs-all@freebsd.org
Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4])
	by hub.freebsd.org (Postfix) with ESMTP
	id 04CCA14FC7; Thu, 23 Dec 1999 10:42:57 -0800 (PST)
	(envelope-from freebsd@gndrsh.dnsmgr.net)
Received: (from freebsd@localhost)
	by gndrsh.dnsmgr.net (8.9.3/8.9.3) id KAA53936;
	Thu, 23 Dec 1999 10:42:52 -0800 (PST)
	(envelope-from freebsd)
From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>
Message-Id: <199912231842.KAA53936@gndrsh.dnsmgr.net>
Subject: Re: cvs commit: ports/net/zebra Makefile ports/net/zebra/files md5
In-Reply-To: <19991223181337.L48740@florence.pavilion.net> from Josef Karthauser at "Dec 23, 1999 06:13:37 pm"
To: joe@pavilion.net (Josef Karthauser)
Date: Thu, 23 Dec 1999 10:42:52 -0800 (PST)
Cc: joe@FreeBSD.org (Josef Karthauser), cvs-committers@FreeBSD.org,
	cvs-all@FreeBSD.org
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk

> On Thu, Dec 23, 1999 at 10:04:59AM -0800, Rodney W. Grimes wrote:
> > 
> > It rather bothers me that zebra startup says it started ``ospfd''
> > when I have bgpd configured :-)
> > 
> 
> 'Tis done.  BTW Do you ospfd at all?  I find that can't establish relationships
> with machines on the local network unless there is a default route statically
> set.  The zebra guys seemed to imply that it was a bug in multicast routing
> under FreeBSD.  Any ideas? (Do I need MROUTING defined?)

I am actually chassing down that trail right now.  Should have sent you
a copy of my more complete message I sent to andreas@FreeBSD.org, the
MAINTAINER per Makefile of the code.  I talked about this particular
problem and a few others, like the fact that it often leaves the kernel
routing table populated if ospfd dies for a strange reason.

I doubt very much this is a bug in multicast routing, as gated 3.x and 4.x
work just fine.

I have it tracked down far enough I am sprinking more debug code in the
ospfd sources to nail it.  I can say for sure ospfd is not putting out
a hello packet to the wire unless a default route exists, which means
it is probably calling the kernel with bad values, or failing to make
the send call at all.

Good startup:
Z: ospf_ase_routing(): start
Z: ospf_spf_calculate_timer: Stop  
Z: make_hello: options: 2, int: de0
OSPF DD: Negotiation done (Slave).
Elect BDR = 0.0.0.0
Elect DR  = 198.145.92.9

Bad startup:
Z: ospf_ase_routing(): start
Z: ospf_spf_calculate_timer: Stop
Z: make_hello: options: 2, int: de0
Z: processing hello from de0, type 2
Z: Hello: my options: 2, his options 2
Z: processing hello from de0, type 2

I never see the packet hit the wire from ``make_hello'' in the bad
case.  And why a default route would make a difference god only knows,
but I am sure I will find it soon enough...

But now that you have updated to 83a, I'll have to save off my debug,
pull the new version, and see if it is still there then go back at
it.

-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)               rgrimes@gndrsh.dnsmgr.net


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message