vtysh checks that the zebra.vty socket uid is == to its own euid, this is
bogus - let the kernel decide whether permissions match, vtysh shouldnt
try second guess. (this becomes noticeable when neither zebra nor vtysh
are run as root :) )
paul [Fri, 16 May 2003 17:19:48 +0000 (17:19 +0000)]
From: Gilad Arnold <gilad.arnold@terayon.com>
Subject: [zebra 19084] Re: suspected memory leakage upon static route
I believe this is a more complete patch, it also addresses
allocating/freeing of nexthop->ifname string buffer (1) using
XSTRDUP/XFREE macros (thus correctly updating memory statistics), and
(2) for all nexthop->type cases that carry an ifname string.
paul [Wed, 14 May 2003 18:29:13 +0000 (18:29 +0000)]
From: Gilad Arnold <gilad arnold at terayon com>
Subject: [zebra 19080] suspected memory leakage upon static route deletion
upon deletion of a static route entry, at the end of
zebra/zebra_rib.c/static_delete_ipv4(), there's a call to XFREE to
deallocate the 'struct static_ipv4'. However, in the case of a static with
ifname as nexthop (type==STATIC_IPV4_IFNAME), this struct holds a pointer to
a dynamically allocated ifname string buffer (si->gate.ifname, see its
allocation within static_add_ipv4() using XSTRDUP). IMO, the attached patch
is required.
Notes: the same applies to IPv6 statics as well (fix included in patch);
and, I admit I haven't yet tested that, but it seems simple enough to be
working... ;->
paul [Sat, 10 May 2003 18:33:28 +0000 (18:33 +0000)]
Hopefully fix the 'bgp dump routes-mrt' command to actually dump routes.
Should recognise the absence of an interval now and schedule one-shot dump.
hopefully.
"configure.ac" script ignores absent socket directory. So do all demons
(with just a puzzling complaint to _stderr_ only!). I added /tmp and
/var/tmp to the list of possible dirs. They should be present in most
configurations.
paul [Tue, 6 May 2003 23:38:23 +0000 (23:38 +0000)]
Reverting the NSSA maxage walker loop addition for now, until all the other
problems with NSSA are resolved, and we can determine whether this had any
point.
paul [Tue, 6 May 2003 23:31:38 +0000 (23:31 +0000)]
NSSA /might/ be missing this. I'm not sure.
It didnt solve a particular problem of Hasso's, but i'm committing it just
for posterities sakes, so i dont lose it (i'll revert it immediately).
paul [Wed, 23 Apr 2003 17:01:31 +0000 (17:01 +0000)]
From: Hasso Tepper
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.
paul [Sat, 19 Apr 2003 15:55:08 +0000 (15:55 +0000)]
Hasso Tepper
http://hasso.linux.ee/zebra/ht-distribute-18042003.patch
Allows to extract.pl to pickup "distribute-list ..." commands for vtysh
(ripngd and ripd).
paul [Sat, 19 Apr 2003 15:54:03 +0000 (15:54 +0000)]
Hasso Tepper
http://hasso.linux.ee/zebra/ht-ifrmap-14042003.patch
Allows to extract.pl to pickup "route-map xxx in/out dev" commands for vtysh
(ripngd). As lib/if_rmap.[c|h] are used in ripngd only, I moved them to the
ripngd/ directory.
paul [Sat, 19 Apr 2003 15:49:49 +0000 (15:49 +0000)]
Hasso Tepper
http://hasso.linux.ee/zebra/ht-routemap-18042003_5.patch
Trivial fixes to sync daemon's route-map commands to have same syntax. Fixes
a lot of errors with "match ..." and "set ..." commands when using vtysh.
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.
paul [Sat, 19 Apr 2003 00:11:28 +0000 (00:11 +0000)]
From: Israel Keys <ikeys@agile.tv>
Subject: [zebra 18677] zebra initialisation bug and patch
Hi All,
I have found a bug in zebra that prevents its routing table and
interface database from being initialised properly. The problem occurs
when a request is made via the netlink socket but the kernel produces a
EWOULDBLOCK/EAGAIN when the result is trying to be retrieved via a
recvmsg(). Zebra does not do anything about this and continues to
function (with an empty routing table and interface list) as if nothing
has happened. With no such information the routing protocol dosn't work!
Two functions are called during the initialisation of Zebra:
interface_lookup_netlink() and netlink_route_read() - obtaining the
interfaces and routing table from the kernel respectively. These are the
only time these functions are called.
These functions, interface_lookup_netlink() and netlink_route_read(),
use netlink_parse_info() to recieve the data from the netlink socket.
The problem is, netlink_parse_info() returns (without error) when its
call to recvmsg() results in an errno EWOULDBLOCK/EAGAIN. This behaviour
is expected by other funtions calling netlink_parse_info() -
netlink_parse_info is simply recalled at a later stage. However, on
initialisation it is never recalled.
Since zebra is expected to nothing else during initialisation it was
easiest to temporarily change the netlink socket to BLOCK and wait
indefinently until the kernel responds with the required information.
Attached is a patch with these changes.
Comments and questions are welcome.
Please inform me if this patch is added to the Zebra source.
paul [Sun, 13 Apr 2003 20:20:53 +0000 (20:20 +0000)]
Author: amir
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->...
paul [Mon, 7 Apr 2003 06:11:09 +0000 (06:11 +0000)]
[zebra 18626] move zebra socket paths to configure.ac
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.
paul [Mon, 7 Apr 2003 06:02:17 +0000 (06:02 +0000)]
Remove auto* files from the repository.
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.
paul [Fri, 4 Apr 2003 02:44:16 +0000 (02:44 +0000)]
2003-04-04 Paul Jakma <paul@dishone.st>
* 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
paul [Thu, 3 Apr 2003 01:27:01 +0000 (01:27 +0000)]
From: David Watson <dwatson@eecs.umich.edu>
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
paul [Fri, 28 Mar 2003 01:51:40 +0000 (01:51 +0000)]
Do not configure ospf for secondary prefixes.
Preliminary fix to at least allow heartbeat to work with ospfd when
Heartbeat failover address has same prefixlength as main address.
paul [Fri, 28 Mar 2003 01:50:03 +0000 (01:50 +0000)]
Amir Guindehi <amir@datacore.ch>:
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.
paul [Mon, 17 Mar 2003 23:54:15 +0000 (23:54 +0000)]
Amir Guindehi <amir@datacore.ch>
--------------------------------
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.
paul [Tue, 18 Feb 2003 23:26:37 +0000 (23:26 +0000)]
1. ospf_opaque_type10_lsa_term (area) - was being called after
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.
paul [Tue, 18 Feb 2003 23:25:44 +0000 (23:25 +0000)]
fixes an assert which doesnt seem to take into account that route_node_get
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).
projects / mirror_frr.git / log