Mailing List Archive

On Thu, 19 Feb 2004, Paul Jakma wrote:

> Subject says it all. What, if anything, is still left to go in to
> 0.96.5?
Maybe:
- [quagga-dev 439] PATCH: send DISTANCE to zebra's client

> Any RIP fixes still left that Sergey (was it sergey?) was going to
> test and report on?
Hm, what about:
- [quagga-dev 437] PATCH: fix "show ip rip"
- [quagga-dev 489] PATCH: fix ripd version send
- [quagga-dev 492] PATCH: fix rip_peer_list_cmp()

Best regards,

Krzysztof Olêdzki

PS: Hello, I'm back ;-)

Krzysztof Oledzki wrote:
> - [quagga-dev 492] PATCH: fix rip_peer_list_cmp()

Change in lib/linklist.c:listnode_add_sort() is reverted already so
this patch isn't needed any more.

--
Hasso Tepper
Elion Enterprises Ltd.
WAN administrator

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Paul,

> Subject says it all. What, if anything, is still left to go in to
> 0.96.5?

What about:

- - [quagga-dev 846] Re: [patch] patch for correct ospfapi ready callbacks

I think it's correct. I don't think oipt->id_list has to be cleared when
getting non-ready, because that's the behavior of OSPF to retain the
opaque lsas until it's ready again. When OSPFD gets ready (with the
change included!) then it says 're-emitting opaque lsa' or something
along these lines, which, to my eyes, is correct.

I think the patch is an improvment over the current behavior of just
STOPPING to emmit opaque lsas of a type of which there already were
opaque lsa existing, before the ON->OFF->ON cycle.

Regards
- - Amir

- --
Amir Guindehi, nospam.amir@datacore.ch
DataCore GmbH, Witikonerstrasse 289, 8053 Zurich, Switzerland

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-nr1 (Windows 2000)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFANMutbycOjskSVCwRAvakAKCLENIdXAbHJggOmV4eNYhlOa0NkQCffOAG
CaRVUzaw9Hu2f+/7wa8Roy4=
=8mwz
-----END PGP SIGNATURE-----

Hi Krzysztof,

Sorry for calling you sergey :)

On Thu, 19 Feb 2004, Krzysztof Oledzki wrote:

> Maybe:
> - [quagga-dev 439] PATCH: send DISTANCE to zebra's client

Ok, we'll look at that.

> Hm, what about:
> - [quagga-dev 437] PATCH: fix "show ip rip"
> - [quagga-dev 489] PATCH: fix ripd version send

Aha.

> - [quagga-dev 492] PATCH: fix rip_peer_list_cmp()

Already taken care by Hasso and GDT i think.

> Best regards,
>
> Krzysztof Olêdzki

> PS: Hello, I'm back ;-)

welcome :)

--paulj

Krzysztof Oledzki wrote:
> On Thu, 19 Feb 2004, Paul Jakma wrote:
> > Subject says it all. What, if anything, is still left to go in to
> > 0.96.5?
>
> Maybe:
> - [quagga-dev 439] PATCH: send DISTANCE to zebra's client

I don't see the point.

> > Any RIP fixes still left that Sergey (was it sergey?) was going
> > to test and report on?
>
> Hm, what about:
> - [quagga-dev 437] PATCH: fix "show ip rip"

Seems to be OK.

Also, I got crash today testing ripd with current CVS. This should be
fixed before release IMHO.

Two quagga routers (A and B) in LAN. In A configuration:

interface eth0
ip address 10.10.10.11/24
!
router rip
network 10.10.10.0/24
redistribute connected metric 1

Router B:
interface eth0
ip address 10.10.10.17/24
!
router rip
!

If I enter "network 10.10.10.0/24" command in router B under "router
rip", ripd in router A crashes.

Program received signal SIGSEGV, Segmentation fault.
rip_send_packet (buf=0x80cd4e0 "\002\002", size=44, to=0xbffff9ec,
ifp=0x80cd0f8, connected=0x0) at ripd.c:1258
1258 if (connected->flags & ZEBRA_IFA_SECONDARY)
(gdb) bt
#0 rip_send_packet (buf=0x80cd4e0 "\002\002", size=44, to=0xbffff9ec,
ifp=0x80cd0f8, connected=0x0) at ripd.c:1258
#1 0x0804cc1c in rip_output_process (ifp=0x80cd0f8, ifaddr=0x0,
to=0xbffff9ec, route_type=0, version=2 '\002', connected=0x0,
saddr=0xbffff98c) at ripd.c:2316
#2 0x0804bc81 in rip_request_process (packet=0xbffff9fc, size=24,
from=0xbffff9ec, ifp=0x80cd0f8) at ripd.c:1512
#3 0x0804c273 in rip_read (t=0xbffffcc0) at ripd.c:1874
#4 0x0805e473 in thread_call (thread=0xbffffcc0) at thread.c:850
#5 0x0804a079 in main (argc=1, argv=0xbffffd94) at rip_main.c:287

--
Hasso Tepper
Elion Enterprises Ltd.
WAN administrator

On Sun, 22 Feb 2004, Hasso Tepper wrote:

> Krzysztof Oledzki wrote:
> > On Thu, 19 Feb 2004, Paul Jakma wrote:
> > > Subject says it all. What, if anything, is still left to go in to
> > > 0.96.5?
> >
> > Maybe:
> > - [quagga-dev 439] PATCH: send DISTANCE to zebra's client


Fixing bug #79 would be nice as well. I posted a message describing it on
this list and got no response. Over a week later I entered in on
bugzilla.quagga.net. Another ten days and it's still unconfirmed.

I don't want to seem ungrateful, nobody around here owes me anything. I
just thought quagga was the future direction of zebra, so I'm quite
surprised to see that somewhere along the line quagga introduced a bug and
the development community doesn't seem interested.

Thanks,

--- David

quagga@d.sparks.net wrote:
> Fixing bug #79 would be nice as well. I posted a message
> describing it on this list and got no response. Over a week later
> I entered in on bugzilla.quagga.net. Another ten days and it's
> still unconfirmed.
>
> I don't want to seem ungrateful, nobody around here owes me
> anything. I just thought quagga was the future direction of zebra,
> so I'm quite surprised to see that somewhere along the line quagga
> introduced a bug and the development community doesn't seem
> interested.

Are you sure it's introduced in quagga? There aren't much changes in
bgpd code in quagga. Can you test with latest zebra (0.94)?

--
Hasso Tepper
Elion Enterprises Ltd.
WAN administrator

On Mon, 23 Feb 2004, Hasso Tepper wrote:

> quagga@d.sparks.net wrote:
> > Fixing bug #79 would be nice as well. I posted a message
> > describing it on this list and got no response. Over a week later
> > I entered in on bugzilla.quagga.net. Another ten days and it's
> > still unconfirmed.
> >
> > I don't want to seem ungrateful, nobody around here owes me
> > anything. I just thought quagga was the future direction of zebra,
> > so I'm quite surprised to see that somewhere along the line quagga
> > introduced a bug and the development community doesn't seem
> > interested.
>
> Are you sure it's introduced in quagga? There aren't much changes in
> bgpd code in quagga. Can you test with latest zebra (0.94)?

I tested it with the .94 release and got the same results.

Zebra bgpd uses the appropriate next-hop of the peer that announced the
route. Quagga seems to always use next-hop-self, and setting " ip
next-hop peer-address" didn't appear to change anything.

This is being used as a route server, so BGP multiple views and
transparent-as are turned on. That's probably the only "unusual" thing
about the setup.

The test configuration file is available to anyone interested, just to
make sure I'm not doing something st00pid

Thanks,

--- David

On Wed, 25 Feb 2004, David Miller wrote:

> On Mon, 23 Feb 2004, Hasso Tepper wrote:
>
> > quagga@d.sparks.net wrote:
> > > Fixing bug #79 would be nice as well. I posted a message
> > > describing it on this list and got no response. Over a week later
> > > I entered in on bugzilla.quagga.net. Another ten days and it's
> > > still unconfirmed.
> > >
> > > I don't want to seem ungrateful, nobody around here owes me
> > > anything. I just thought quagga was the future direction of zebra,
> > > so I'm quite surprised to see that somewhere along the line quagga
> > > introduced a bug and the development community doesn't seem
> > > interested.
> >
> > Are you sure it's introduced in quagga? There aren't much changes in
> > bgpd code in quagga. Can you test with latest zebra (0.94)?
>
> I tested it with the .94 release and got the same results.

Whoops, it looks like I have to take this back. I was sure I saw it
yesterday, but subsequent testing won't confirm it.

The complaints of quagga next-hops appear to apply equally to zebra v.94.

I've reverted to zebra .92a until the situation is resolved.

Thanks,

--- David


> Zebra bgpd uses the appropriate next-hop of the peer that announced the
> route. Quagga seems to always use next-hop-self, and setting " ip
> next-hop peer-address" didn't appear to change anything.
>
> This is being used as a route server, so BGP multiple views and
> transparent-as are turned on. That's probably the only "unusual" thing
> about the setup.
>
> The test configuration file is available to anyone interested, just to
> make sure I'm not doing something st00pid
>
> Thanks,
>
> --- David
>
> _______________________________________________
> Quagga-dev mailing list
> Quagga-dev@lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-dev
>

Krzysztof Oledzki wrote:
> Hm, what about:
> - [quagga-dev 437] PATCH: fix "show ip rip"

Commited.

> - [quagga-dev 489] PATCH: fix ripd version send

Commited.

--
Hasso Tepper
Elion Enterprises Ltd.
WAN administrator

Sorry for the delay, but I have a patch for the following problem
reported by Kryzstof.

> Date: Sun, 22 Feb 2004 23:45:39 +0200
> To: quagga-dev@lists.quagga.net
> Cc: Krzysztof Oledzki <oleq@ans.pl>
> Subject: [quagga-dev 929] Re: whats missing for 0.96.5?
>
> Krzysztof Oledzki wrote:
>
> Program received signal SIGSEGV, Segmentation fault.
> rip_send_packet (buf=0x80cd4e0 "\002\002", size=44, to=0xbffff9ec,
> ifp=0x80cd0f8, connected=0x0) at ripd.c:1258
> 1258 if (connected->flags & ZEBRA_IFA_SECONDARY)
> (gdb) bt
> #0 rip_send_packet (buf=0x80cd4e0 "\002\002", size=44, to=0xbffff9ec,
> ifp=0x80cd0f8, connected=0x0) at ripd.c:1258
> #1 0x0804cc1c in rip_output_process (ifp=0x80cd0f8, ifaddr=0x0,
> to=0xbffff9ec, route_type=0, version=2 '\002', connected=0x0,
> saddr=0xbffff98c) at ripd.c:2316
> #2 0x0804bc81 in rip_request_process (packet=0xbffff9fc, size=24,
> from=0xbffff9ec, ifp=0x80cd0f8) at ripd.c:1512
> #3 0x0804c273 in rip_read (t=0xbffffcc0) at ripd.c:1874
> #4 0x0805e473 in thread_call (thread=0xbffffcc0) at thread.c:850
> #5 0x0804a079 in main (argc=1, argv=0xbffffd94) at rip_main.c:287


Here's the patch:
-----------------------------------------------------------------------

Changelog comment:
- rip_send_packet can get null connected address
when called in response to a unicast rip-request. Handle correctly


RCS file: ripd.c,v
retrieving revision 1.17
diff -uwb -r1.17 ripd.c
--- ripd.c 2004/03/03 19:48:48 1.17
+++ ripd.c 2004/03/17 21:41:31
@@ -1253,9 +1253,10 @@
strcpy(dst, inet_ntoa(sin.sin_addr));
}
zlog_info("rip_send_packet %s > %s (%s)",
- inet_ntoa(connected->address->u.prefix4), dst, ifp->name);
+ (connected ? inet_ntoa(connected->address->u.prefix4) : ""),
+ dst, ifp->name);
}
- if (connected->flags & ZEBRA_IFA_SECONDARY)
+ if (connected && connected->flags & ZEBRA_IFA_SECONDARY)
{
/*
* ZEBRA_IFA_SECONDARY is set on linux when an interface is configured