Subject: [zebra 19263] Another memory leak!! is zebra OSPF
This memory leak gets into picture whenever any interface goes down.
Problem found and desctription: Whenever the interface goes down, the
"def_params" (member of ospf_if_info) structure memory is not freed.
Fix made: added the following line to free the "def_params" memory of
ospf_if_info before calling the "XFREE(MTYPE_OSPF_IF_INFO, ifp->info);"
The added line is:
ospf_del_if_params ((struct ospf_if_params *) IF_DEF_PARAMS (ifp));
Subject: [zebra 19262] Re: Memory leak in OSPF
Fix applied for Kamatchi's original report was to remove the auth_crypt
initialisation from the wrong function. This should fix that.
Subject: [zebra 19259] Memory leak in OSPF
The detail of the memory leak follows:
File name: ospf_interface.c
Function name: ospf_if_new_hook().
Type of leak: Overwriting the already allocated memory.
Problem found and description:
The ospf_new_if_params() fn allocates a memory for "auth_crypt" which
is overwritten, down in the fn (ospf_if_new_hook) by explicitely allocating
a memory for the same "auth_crypt".
Fix: remove allocation from ospf_new_if_params()
the class of machines which zebra runs on than the original defaults which
were taken from IOS (and even IOS uses much lower times these days). Lower
values greatly help with convergence.
Ideally, we'd use even lower times, but thread_add_timer() api will need to
be modified to use milliseconds. (eg JunOS uses 100ms for delay, and 700ms
for hold time, iirc from Hasso).
Add the 'no interface' command to all the daemons and vtysh. now it's
possible to delete interface from routeing daemons as well only if it
doesn't exist in os.
http://hasso.linux.ee/zebra/ht-no_interface_fix.patch
Subject: [zebra 19091] [PATCH] NSSA fixes try2
NSSA didn't work without problems even after my previous fixes. Seems
that I tracked down problems finally.
This one fixes "router xxx" node commands in vtysh. Don't get "unknown
command" error when entering "passive-interface eth0" command while
ospfd and ospf6d running etc.
Subject: [zebra 17365] [PATCH] Ospf area id's DECIMAL -> ADDRESS
It was annoying for me to view area id's like 335544330 (20.0.0.10 in
address format) in configuration. Most of other network devices are
using address-like id's and so does zebra when using "show ip ospf *"
commands.
You can still enter id's in decimal format, but they are just shown in
address format.
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->...
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
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
