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).
paul [Mon, 27 Jan 2003 12:00:55 +0000 (12:00 +0000)]
Revert comment out of:
if (ospf_debug_packet & OSPF_DEBUG_RECV)
which was causing unconditional ospf_ip_header_dump (ibuf).
(introduced with kevin millers patch)
paul [Sun, 19 Jan 2003 20:52:55 +0000 (20:52 +0000)]
Add work around for RFC3021 patch and its problem with certain IPv6 interfaces
addresses.
It seems so far that netlink only ever returns IFA_ADDRESS for IPv6 interfaces
and never IFA_LOCAL, regardless of whether it is PtP or not. Need to investigate
precisely how IPv6 and netlink are supposed to behave wrt broadcast vs
PtP links.
paul [Sat, 18 Jan 2003 01:16:20 +0000 (01:16 +0000)]
This patch adds Yon's CLI 'walk back up tree' patch. Following are email
describing original patch and a shorter email describing changes to an
updated patch, the one which is applied:
From havanna_moon@gmx.net Sat Jan 18 00:37:13 2003
Date: Mon, 9 Dec 2002 05:32:58 +0100 (CET)
From: Yon Uriarte <havanna_moon@gmx.net>
To: "the list(tm) Zebra" <zebra@zebra.org>
Subject: [zebra 16671] [PATCH] CLI extensions.
Hi,
this patch adds 2 improvements to the CLI (lib/command.c):
#1) When in subconfig mode (router XXX, interface XXX, ...) commands that
fail for that node are tried on the main CONFIG_NODE. This is great for
configuring interfaces or changing the sub-config mode quickly, without
the need to type 'exit' between commands:
ospfd(config)# int eth1
ospfd(config-if)# ip ospf cost 9
ospfd(config-if)# ip ospf prio 101
ospfd(config-if)# router ospf
ospfd(config-router)# network 1.1.1.0/24 area 51
ospfd(config-router)# int eth2
ospfd(config-if)# ip ospf authentication message-digest
ospfd(config-if)# ^Z
ospfd#
Is this IOS-like or does IOS try to walk up the tree of config sub-modes
instead of directly trying the command on CONFIG_NODE?
CAVEATS: "?" and "TAB" don't work. IIRC IOS doesnt show that help
neither.
NON-CAVEATS: This wont break much, as config_from_file() already does
try a failed command on the parent node of the actual vty->node. If
changing the code to walk the node tree instead of directly trying
the command on the ENABLE_NODE the same semantics would be in use
and no future bugs could creep in.
#2) When in config or subconfig mode use the "do " prefix to execute
commans of the ENABLE_NODE. "?" and "TAB" work. The space after the
"do" is needed:
ospfd(config-router)# do<?>
% There is no matched command.
ospfd(config-router)# do <?>
clear Reset functions
configure Configuration from vty interface
copy Copy configuration
debug Debugging functions (see also 'undebug')
disable Turn off privileged mode command
end End current mode and change to enable mode.
exit Exit current mode and down to previous mode
help Description of the interactive help system
list Print command list
no Negate a command or set its defaults
quit Exit current mode and down to previous mode
show Show running system information
terminal Set terminal line parameters
who Display who is on vty
write Write running configuration to memory, network, or terminal
ospfd(config-router)# do sho<TAB>
ospfd(config-router)# do show me<TAB>
ospfd(config-router)# do show memory r<TAB>
ospfd(config-router)# do show memory rip
RIP structure : 0
RIP route info : 0
RIP interface : 0
RIP peer : 0
RIP offset list : 0
RIP distance : 0
ospfd(config-router)# ^Z
ospfd#
CAVEATS: I don't have access to an IOS with this feature, so I implemented
it from the comments on this mailing list (in fact my personal motivation
was to implement feature #1, which I missed on zebra. But #2 sounded like
a nice one to have, and xemacs was already parked on command.c ...).
Is this IOS-like or are there differences?
I will happily change this patch to mimick IOS or the mailing-list
consensus on CLI-usability.
regards,
yon
From havanna_moon@gmx.net Sat Jan 18 01:13:11 2003
Date: Sat, 11 Jan 2003 23:36:51 +0100 (CET)
From: Yon Uriarte <havanna_moon@gmx.net>
To: zebra@zebra.org
Subject: [zebra 17218] Re: [PATCH] CLI extensions.
Hi,
[redacted]
> I prefer the IOS way for the node "up walking".
This patch should walk the tree upwards:
bgpd(config)# router bgp 1
bgpd(config-router)# address-family ipv4 multicast
bgpd(config-router-af)# access-list 1 remark hola que tal
bgpd(config)#
I cant test all combinations, so I cant rule out some bugs. I'd love to
get (long and explicit) bug reports.
paul [Sat, 18 Jan 2003 00:39:19 +0000 (00:39 +0000)]
Finish off merge off CLI extensions, see below for description. Merge should
be off:
From havanna_moon@gmx.net Sat Jan 18 00:37:13 2003
Date: Mon, 9 Dec 2002 05:32:58 +0100 (CET)
From: Yon Uriarte <havanna_moon@gmx.net>
To: "the list(tm) Zebra" <zebra@zebra.org>
Subject: [zebra 16671] [PATCH] CLI extensions.
Hi,
this patch adds 2 improvements to the CLI (lib/command.c):
#1) When in subconfig mode (router XXX, interface XXX, ...) commands that
fail for that node are tried on the main CONFIG_NODE. This is great for
configuring interfaces or changing the sub-config mode quickly, without
the need to type 'exit' between commands:
ospfd(config)# int eth1
ospfd(config-if)# ip ospf cost 9
ospfd(config-if)# ip ospf prio 101
ospfd(config-if)# router ospf
ospfd(config-router)# network 1.1.1.0/24 area 51
ospfd(config-router)# int eth2
ospfd(config-if)# ip ospf authentication message-digest
ospfd(config-if)# ^Z
ospfd#
Is this IOS-like or does IOS try to walk up the tree of config sub-modes
instead of directly trying the command on CONFIG_NODE?
CAVEATS: "?" and "TAB" don't work. IIRC IOS doesnt show that help
neither.
NON-CAVEATS: This wont break much, as config_from_file() already does
try a failed command on the parent node of the actual vty->node. If
changing the code to walk the node tree instead of directly trying
the command on the ENABLE_NODE the same semantics would be in use
and no future bugs could creep in.
#2) When in config or subconfig mode use the "do " prefix to execute
commans of the ENABLE_NODE. "?" and "TAB" work. The space after the
"do" is needed:
ospfd(config-router)# do<?>
% There is no matched command.
ospfd(config-router)# do <?>
clear Reset functions
configure Configuration from vty interface
copy Copy configuration
debug Debugging functions (see also 'undebug')
disable Turn off privileged mode command
end End current mode and change to enable mode.
exit Exit current mode and down to previous mode
help Description of the interactive help system
list Print command list
no Negate a command or set its defaults
quit Exit current mode and down to previous mode
show Show running system information
terminal Set terminal line parameters
who Display who is on vty
write Write running configuration to memory, network, or terminal
ospfd(config-router)# do sho<TAB>
ospfd(config-router)# do show me<TAB>
ospfd(config-router)# do show memory r<TAB>
ospfd(config-router)# do show memory rip
RIP structure : 0
RIP route info : 0
RIP interface : 0
RIP peer : 0
RIP offset list : 0
RIP distance : 0
ospfd(config-router)# ^Z
ospfd#
CAVEATS: I don't have access to an IOS with this feature, so I implemented
it from the comments on this mailing list (in fact my personal motivation
was to implement feature #1, which I missed on zebra. But #2 sounded like
a nice one to have, and xemacs was already parked on command.c ...).
Is this IOS-like or are there differences?
I will happily change this patch to mimick IOS or the mailing-list
consensus on CLI-usability.
paul [Sat, 18 Jan 2003 00:12:02 +0000 (00:12 +0000)]
Date: Fri, 20 Dec 2002 17:28:45 +0900
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.
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.
paul [Fri, 17 Jan 2003 23:48:42 +0000 (23:48 +0000)]
From endo@suri.co.jp Fri Jan 17 23:36:30 2003
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.
paul [Fri, 17 Jan 2003 23:47:00 +0000 (23:47 +0000)]
From havanna_moon@gmx.net Fri Jan 17 23:37:49 2003
Date: Sat, 11 Jan 2003 23:26:28 +0100 (CET)
From: Yon Uriarte <havanna_moon@gmx.net>
To: "the list(tm) Zebra" <zebra@zebra.org>
Subject: [zebra 17217] [PATCH] show thread CPU
Hi,
a little patch from the 'stupid preprocessor tricks' collection to record
thread statistics.
Usage: "show thread cpu [r][w][t][e][x]"
Output Fields: self explaining I hope. Type is one of RWTEX for:
Read, Write (fd threads), Timer, Event, Execute.
Overhead vs. vanilla zebra: almost nothing. Vanilla CVS zebra already
collects thread run times.
Caveats: Under linux getrusage has a granularity of 10ms, which is almost
useless in this case. Run ./configure, edit config.h and comment out
"#define HAVE_RUSAGE", this way it will use getimeofday which has a much
better granularity. IMHO this is better, as cooperative threads are
effectively running during all that wall time (dont care if CPU
utilization was 3% or 99% during the time the thread was running (an
effective rusage combined with getimeofday could give that info)).
Maybe someone can give tips for other platforms on API granularity.
TODO: change some of the calls to thread_add_$KIND to
funcname_thread_add_$KIND with a meaningfull funcname, so users will get a
better idea of what's going on.