Mailing List Archive

hitting assert on line 141 ospf_interface.c
I'm getting the following assertion error
------------------
ospfd: ospf_interface.c:141: ospf_add_to_if: Assertion `!
rn->info || rn->info == oi' failed.
Aborted
-----------------

when I run
-----------------
ifconfig eth0:1 192.168.100.1 netmask 255.255.255.0
-----------------

I configured with
-----------------
./configure --prefix=/usr/local/quagga --disable-ipv6 --
disable-bgpd --disable-ripd --disable-ripngd --disable-
ospf6d --disable-bgp-announce --enable-netlink --enable-
nssa --enable-opaque-lsa
-----------------

I am running a patched version of redhat 9.0 with the
2.4.22 kernel

While I feel a good programmer, this is a little over my
head.....

pat
Re: hitting assert on line 141 ospf_interface.c [ In reply to ]
On Tue, 14 Oct 2003, Patrick Felt wrote:

> I'm getting the following assertion error
> ------------------
> ospfd: ospf_interface.c:141: ospf_add_to_if: Assertion `!
> rn->info || rn->info == oi' failed.
> Aborted
> -----------------
>
> when I run
> -----------------
> ifconfig eth0:1 192.168.100.1 netmask 255.255.255.0

what are the other interfaces and addresses?

can you provide a step-by-step guide as to how to replicate?

> pat

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Say "twenty-three-skiddoo" to logout.
Re: hitting assert on line 141 ospf_interface.c [ In reply to ]
On Tue, 14 Oct 2003, Patrick Felt wrote:

> I have ospfd running (not in daemon mode). When I run: ifconfig
> eth0:1 192.168.100.1 netmask 255.255.255.0 I get the assert. When
> I get home from work today I'll do some more testing on it to see
> if I can get it to reproduce without freeswan running.

yes please. would be very useful to get a test case.

> Somehow I think it probably has something to do with how the
> route_node_get searches the list... possibly it find the ipsec0
> (since it has the same prefix on it)...

exact same prefix, or merely within the same subnet? If the latter,
it should not trigger because the prefix we index the table with is
deliberarely set to /32, see ospf_add_to_if:

p.prefixlen = IPV4_MAX_PREFIXLEN

so, that assert shouldnt hit unless we have exact same prefix on
multiple interfaces /and/ returned node does not have same oi.

ie 192.168.0.1/24 and 192.168.0.2/24 should result in seperate
entries in the route table used to index oi's, namely one node for
192.168.0.1/32 and 192.168.0.2/32 - AIUI.

> In gdb it appears the the ifconfig command is sending 172.16.1.2 to
> the route_node_get() function.
>
> but the assert (and I am not entirely sure how asserts
> work) says
>
> assert(! rn->info || rn->info == oi)
>
> should this be something like
>
> assert((!rn->info) || rn->info == oi) (is the not
> converthing the == into a !=) ??

urg... if that's the problem i'm going to go stand in a corner. can
you test that out? Though i think the ! has precedence over the
comparison, so it shouldnt be.

The problem occurs i think for one or both of the following reasons:

- same prefix attached multiple times to interfaces.

or

- zebra is sending new interface events /twice/ for the same
prefix/interface.

For the latter case, we can mitigate the effect of zebra doing this
by making ospf_if_new() do the route_node lookup /before/ creating a
new oi. (or call ospf_add_to_if first), eg... what about the diff
below? (not really that clean, but will do to test).

Index: ospf_interface.c
===================================================================
RCS file: /var/cvsroot/quagga/ospfd/ospf_interface.c,v
retrieving revision 1.16
diff -u -r1.16 ospf_interface.c
--- ospf_interface.c 1 Aug 2003 00:24:13 -0000 1.16
+++ ospf_interface.c 14 Oct 2003 18:10:57 -0000
@@ -125,6 +125,16 @@
oi->v_ls_ack = 1;
}

+struct ospf_interface *
+ospf_if_table_lookup (struct interface *ifp, struct prefix *prefix)
+{
+ struct prefix p;
+
+ p = *prefix;
+
+ return (route_node_get (IF_OIFS (ifp), &p))->info;
+}
+
void
ospf_add_to_if (struct interface *ifp, struct ospf_interface *oi)
{
@@ -138,7 +148,7 @@
/* rn->info should either be NULL or equal to this oi
* as route_node_get may return an existing node
*/
- assert (! rn->info || rn->info == oi);
+ assert (!rn->info || rn->info == oi);
rn->info = oi;
}

@@ -164,9 +174,14 @@
{
struct ospf_interface *oi;

- oi = XCALLOC (MTYPE_OSPF_IF, sizeof (struct ospf_interface));
- memset (oi, 0, sizeof (struct ospf_interface));
-
+ if ((oi = ospf_if_table_lookup (ifp, p)) == NULL)
+ {
+ oi = XCALLOC (MTYPE_OSPF_IF, sizeof (struct ospf_interface));
+ memset (oi, 0, sizeof (struct ospf_interface));
+ }
+ else
+ return oi;
+
/* Set zebra interface pointer. */
oi->ifp = ifp;
oi->address = p;

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
I cannot believe that God plays dice with the cosmos.
-- Albert Einstein, on the randomness of quantum mechanics
Re: hitting assert on line 141 ospf_interface.c [ In reply to ]
> can you provide a step-by-step guide as to how to
replicate?

sure. No problem.

show int
------------------------
int eth0 is up ...
inet 192.168.1.253/24 ...
inet 10.0.2.1/24 ... eth0:0
int eth0:0 is down
index -1 inactive int
int gre0 is down
...
int ipsec0 is up
inet 192.168.1.253/24
int ipsec1 is down
...
int ipsec2 is down
...
int ipsec3 is down
...
int lo is up
inet 127.0.0.1/8
int pattomatt is up < is a gre tunnel >
inet 172.16.1.2/32 p2p 172.16.1.1

I have ospfd running (not in daemon mode). When I run:
ifconfig eth0:1 192.168.100.1 netmask 255.255.255.0
I get the assert. When I get home from work today I'll do
some more testing on it to see if I can get it to reproduce
without freeswan running. Somehow I think it probably has
something to do with how the route_node_get searches the
list... possibly it find the ipsec0 (since it has the same
prefix on it)... In gdb it appears the the ifconfig
command is sending 172.16.1.2 to the route_node_get()
function.

but the assert (and I am not entirely sure how asserts
work) says

assert(! rn->info || rn->info == oi)

should this be something like

assert((!rn->info) || rn->info == oi) (is the not
converthing the == into a !=) ??

pat


> On Tue, 14 Oct 2003, Patrick Felt wrote:
>
> > I'm getting the following assertion error
> > ------------------
> > ospfd: ospf_interface.c:141: ospf_add_to_if: Assertion
`!
> > rn->info || rn->info == oi' failed.
> > Aborted
> > -----------------
> >
> > when I run
> > -----------------
> > ifconfig eth0:1 192.168.100.1 netmask 255.255.255.0
>
> what are the other interfaces and addresses?
>
> can you provide a step-by-step guide as to how to
replicate?
>
> > pat
>
> regards,
> --
> Paul Jakma paul@clubi.ie paul@jakma.org Key ID:
64A2FF6A
> warning: do not ever send email to spam@dishone.st
> Fortune:
> Say "twenty-three-skiddoo" to logout.
>