| Age | Commit message (Collapse) | Author |
|---|
|
Subject: [zebra 18767] possible SIGSEGV
Fix incorrect memset
|
|
To: zebra@zebra.org
Subject: [zebra 18648] [PATCH] Selforiginated Type-7 LSA's are not flushed
from lsdb
|
|
Date: 2003-04-10 14:32:31 +0200 (Thu, 10 Apr 2003)
New Revision: 212
Modified:
zebra-ag/trunk/ospfd/ospf_lsa.c
Log:
I've fixed a small opaque lsa bug which got triggered when deleting opaque
lsa of type 11. It used area->ospf->.. when area was null. This was replaced
by a ospf = ospf_lookyp(); ospf->...
|
|
Add ospfclient to ospfclient/.cvsignore
|
|
|
|
add NSSA debug statement
|
|
|
|
moved definition of the various socket paths from the
per daemon header files into configure.ac. it will set the paths to
be in the directory specified by --localstatedir=<prefix> or
otherwise will try to guess as best it can ( a la pid file path
detection - which probably should try reference ${prefix} too).
the present hardcoded socket path, /tmp, isnt really correct. should
be in /var somewhere really.
|
|
Developers working with the repository should have the appropriate tools.
Out-of-sync files cause far too many problems with users as well as auto*
scripts not being half as portable across systems as they ought to be.
make-dist exists for a reason.
Todo: make the CVS snapshot script do make-dist, and use the resulting
tarball as the snapshot.
|
|
|
|
|
|
|
|
|
|
* Sync to Zebra CVS
* Fix lib/thread.h leak
* Fix small Opaque LSA leak
* Do not configure OSPF interfaces for secondary addresses
* vtysh fixes from Hasso
* Dave Watson's missing ntohs fix
|
|
Subject: [zebra 18573] PATCH ospfd: byte order error in assert statement
I found a bug in the ospfd code tickled this morning by a Type 1
LSA with exactly 62 entries (LSA length of 768, or 0x0300).
A missing ntohs in ospf_lsa.c:ospf_lsa_different() causes an assert
statement to fail, stopping ospfd.
> assert (l1->data->length > OSPF_LSA_HEADER_SIZE);
So, a length of type 768 turns into a length of 3 which is
obviously less than 20.
David
|
|
Preliminary fix to at least allow heartbeat to work with ospfd when
Heartbeat failover address has same prefixlength as main address.
|
|
I got it to compile. The problem was that major functions newly need a
struct ospf *ospf as the first argument. I tried to take the nearest
struct ospf *ospf around the function needing it, because i was not sure
if all those pointers to struct ospf * all point to the same (global)
struct ospf * which you also get when you call ospf_get().
I used area->ospf where I had the area, I used oi->ospf, where I had an
interface, I used lsa->oi->ospf where I had an lsa and i used ospf_get()
where I had nothing. I hope that's correct and works. We will see.
It compiles now without errors. Daemon is tested and works. The opaque lsa
part is not yet tested. I will do that as soon as srrd is ready.
|
|
|
|
|
|
* sync to latest zebra CVS
* spec file: updated and added define for ospf-api/client
NB: OSPF-API has been broken by the zebra.org changes, which
has added struct ospf * as a new arg to many functions
|
|
Fix up build for OSPF-API (dependent on opaque-lsa)
Add disable-ospfapi.
Fix up net-snmp detection.
|
|
|
|
|
|
--------------------------------
I've attached a small patch for zebra-pj, which adds the installation of
libospf.a libzebra.a, libospfapi.a and the needed headers for ospfapi
clients. the headers get installed to /usr/include/ospfd/* and
/usr/include/ospfapi.
|
|
No doubt builds will now break for everyone. (works here - autoconf 2.13)
|
|
|
|
|
|
|
|
ospf_lsdb_free had been called. (efence caught this one).
This bug is present in zebra.org CVS
2. It fixes my previous ospf_network_match_iface patch ([zebra 17352])
- i lost a couple of checks in ospf_network_run() by mistake. this
patch isnt in zebra.org CVS, but it would be nice to have it once it
works.
This hopefully fixes the 'assert rn->info' problems people had with
zebra-pj yesterday.
|
|
may return an existing node. (if the code wants a /new/ node why not use
route_node_set? if it doesnt mind - then the assert is wrong).
this bug is in zebra.org CVS. (must be an extremely rare/unlikely bug
though).
|
|
|
|
|
|
|
|
if (ospf_debug_packet & OSPF_DEBUG_RECV)
which was causing unconditional ospf_ip_header_dump (ibuf).
(introduced with kevin millers patch)
|
|
|
|
[zebra 17352] ospf network matching (aka need for peer /32 for PtP)
change behaviour of network <prefix> area N statement wrt to PtP.
|
|
[zebra 17290] [PATCHES] - Fixes for problems in 0.93b
portfix patch
|
|
From: Masahiko Endo <endo@suri.co.jp>
Reply-To: zebra@zebra.org
To: zebra@zebra.org
Cc: kunihiro@zebra.org, yokota@kddlabs.co.jp
Subject: [zebra 16823] [PATCH] Bugfix and new feature in Opaque-LSA
handling.
----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
Changes 2002.12.20
1. Bug fixes
1.1 When an opaque LSA is being removed from (or added to) the LSDB,
it does not mean a change in network topology. Therefore, SPF
recalculation should not be triggered in that case.
There was an assertion failure problem "assert (rn && rn->info)"
inside the function "ospf_ase_incremental_update()", because
the upper function "ospf_lsa_maxage_walker_remover()" called it
when a type-11 opaque LSA is removed due to MaxAge.
1.2 Type-9 LSA is defined to have "link-local" flooding scope.
In the Database exchange procedure with a new neighbor, a type-9
LSA was added in the database summary of a DD message, even if
the link is different from the one that have bound to.
2. Feature enhancements
2.1 Though a "wildcard" concept to handle type-9/10/11 LSAs altogether
has introduced about a year ago, it was only a symbol definition
and actual handling mechanism was not implemented. Now it works.
|
|
Date: Fri, 20 Dec 2002 17:58:43 +0900
From: Masahiko Endo <endo@suri.co.jp>
Reply-To: zebra@zebra.org
To: zebra@zebra.org
Cc: kunihiro@zebra.org
Subject: [zebra 16824] [PATCH] nsm_kill_neighbor
[ The following text is in the "ISO-2022-JP" character set. ]
[ Your display is set for the "ISO-8859-1" character set. ]
[ Some characters may be displayed incorrectly. ]
Hi Ishiguro-san,
Here is my problem analysis against the case that the ospfd crashes
when an interface is brought down.
When the ospfd receives a ZEBRA message "ZEBRA_INTERFACE_DOWN" from
zebra daemon, the ospfd performs bunch of ospf-interface cleanup for
the notified zebra-interface.
There are cases that neighbor instance "nbr", which will be removed
afterward, may scheduled in the NSM thread event queue. And when the
NSM event thread is fired, dereference for this already freed "nbr"
pointer causes SIGSEGV.
Please take a look at following timeline of processing sequences.
|
|
[zebra 16681] OSPF NSSA Patches
|
|
|
|
|
|
|
|
[zebra 15715] FIX for ospf md5 authentication problem, finally!
fix copy of ospf packet buffer
|
|
to be derived from time() to speed up synching after restart of ospfd
|
|
|
