| Age | Commit message (Collapse) | Author | 
 | 
Add ospfclient to ospfclient/.cvsignore
 | 
 | 
 | 
 | 
Add dependency on rebuild target for vtysh_cmd.c to Makefile.am
 | 
 | 
 | 
 | 
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
 | 
 | 
 | 
 | 
 | 
 | 
Fix from hasso tepper <hasso@linux.ee>
 | 
 | 
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.
 | 
 | 
 | 
 | 
Restore Amir's netsnmp build fix.
 | 
 | 
still perplexed why removing configure.in breaks certain autoconf sites.
 | 
 | 
 | 
 | 
 | 
 | 
--------------------------------
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)
 | 
 | 
 | 
 | 
 | 
 | 
use configure.in
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
dependencies in the main zebra package
 | 
 | 
2.52
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
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).
 |