summaryrefslogtreecommitdiff
path: root/zebra
AgeCommit message (Collapse)Author
2003-06-05Patch from Cougar - sort iflist by name.hasso
2003-06-05Unbreak router advertisment feature when using capabilities.hasso
2003-06-042003-06-04 Paul Jakma <paul@dishone.st>paul
* Merge of zebra privileges
2003-05-28IPv4 part of "make reject|blackhole routes work without nexthop|interface".hasso
2003-05-25Fix missing else in static_add_ipv4() which was causing case of (!ifname)paul
to always be considered to be a blackhole route. (if gate is passed in, it cant be).
2003-05-25Add back support for null0 interface blackhole routes.paul
2003-05-25Last fixes from 6Wind patch.hasso
2003-05-25Route (reject|blackhole) support from 6Wind patch.hasso
2003-05-25"ip forwarding" command. Patch from Jim Crumpler.hasso
2003-05-24Jim Crumpler:paul
working ipforward_solaris.c
2003-05-24From: Hasso Tepper <hasso@estpak.ee>paul
ensure only interfaces that are inactive or do not exist can be deleted
2003-05-23From: Hasso Tepper <hasso@estpak.ee>paul
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
2003-05-23Undo Hasso last patch, about to apply a slightly updated patch.paul
2003-05-23From: Hasso Tepper <hasso@estpak.ee>paul
http://hasso.linux.ee/zebra/ht-no_interface-23052003.patch Add the 'no interface' command to all the daemons and vtysh.
2003-05-16Update Changelogspaul
2003-05-16From: Gilad Arnold <gilad.arnold@terayon.com>paul
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.
2003-05-14From: Gilad Arnold <gilad arnold at terayon com>paul
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... ;->
2003-04-19From: Israel Keys <ikeys@agile.tv>paul
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. --israel
2003-04-09Amir - rev 198paul
Log: Removed unused variable in interface.c
2003-04-09Amir - revision 197paul
Log: I've fixed a small bug in connected_down_ipv4(): I changed if (ifc_pointopoint (ifc)) into if (ifc_pointopoint (ifc) && dest) like show in connected_up_ipv4() After changing this 'ip address x/y'; 'no ip address x/y' works without crash when done in sequence.
2003-04-09Add Makefile.in to the remaining .cvsignore'spaul
Add ospfclient to ospfclient/.cvsignore
2003-04-07[zebra 18626] move zebra socket paths to configure.acpaul
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.
2003-04-07Remove auto* files from the repository.paul
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.
2003-03-252003-03-25 Paul Jakma <paul@dishone.st>paul
* 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
2003-03-18Fix build for net-snmppaul
2003-03-17Update auto files.paul
No doubt builds will now break for everyone. (works here - autoconf 2.13)
2003-03-01Sync to Zebra.org 20030301paul
2003-02-07Sync to latest Zebra CVSpaul
2003-01-22Matthew Grant <grantma@anathoth.gen.nz>paul
[zebra 17290] [PATCHES] - Fixes for problems in 0.93b portfix patch
2003-01-22Matthew Grant <grantma@anathoth.gen.nz>paul
Subject: [zebra 17290] [PATCHES] - Fixes for problems in 0.93b Added ifupstaticfix
2003-01-19Add work around for RFC3021 patch and its problem with certain IPv6 interfacespaul
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.
2003-01-17From havanna_moon@gmx.net Fri Jan 17 23:37:49 2003paul
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. F.ex. (AFAIK): ospf_spf_calculate_timer -> "Routes Step 1, areas SPF" ospf_ase_calculate_timer -> "Routes Step 2, externals" Could this be added to the unofficial patch collection? Could someone with BGP keepalive problems run their bgpd with this patch and post the results? TIA, HTH, HAND, regards yon Example output: -------------------------------- ospfd# show thread cpu Runtime(ms) Invoked Avg uSecs Max uSecs Type Thread 14.829 31 478 585 T ospf_ase_calculate_timer 82.132 9838 8 291 EX ospf_nsm_event 0.029 1 29 29 E ospf_default_originate_timer 0.254 9 28 34 T ospf_db_desc_timer 0.026 7 3 11 T ospf_wait_timer 669.015 523 1279 490696 R vty_read 4.415 45 98 173 TE ospf_network_lsa_refresh_timer 15.026 31 484 588 T ospf_spf_calculate_timer 29.478 1593 18 122 E ospf_ls_upd_send_queue_event 0.173 1 173 173 T vty_timeout 4.173 242 17 58 E ospf_ls_ack_send_event 637.767 121223 5 55 T ospf_ls_ack_timer 39.373 244 161 2691 R zclient_read 12.169 98 124 726 EX ospf_ism_event 0.226 2 113 125 R vty_accept 537.776 14256 37 3813 W ospf_write 4.967 41 121 250 T ospf_router_lsa_timer 0.672 1 672 672 E zclient_connect 7.901 1658 4 26 T ospf_ls_req_timer 0.459 2 229 266 E ospf_external_lsa_originate_timer 3.203 60 53 305 T ospf_maxage_lsa_remover 108.341 9772 11 65 T ospf_ls_upd_timer 33.302 525 63 8628 W vty_flush 0.101 1 101 101 T ospf_router_lsa_update_timer 0.016 1 16 16 T ospf_router_id_update_timer 26.970 407 66 176 T ospf_lsa_maxage_walker 381.949 12244 31 69 T ospf_hello_timer 0.114 22 5 14 T ospf_inactivity_timer 34.290 1223 28 310 T ospf_lsa_refresh_walker 470.645 6592 71 665 R ospf_read 3119.791 180693 17 490696 RWTEX TOTAL ospfd# bgpd# sh t c TeX Runtime(ms) Invoked Avg uSecs Max uSecs Type Thread 21.504 476 45 71 T bgp_keepalive_timer 17.784 1157 15 131 T bgp_reuse_timer 29.080 193 150 249 T bgp_scan 23.606 995 23 420 E bgp_event 317.734 28572 11 69 T bgp_routeadv_timer 0.084 1 84 84 E zlookup_connect 0.526 1 526 526 E zclient_connect 1.348 13 103 147 T bgp_start_timer 19.443 142 136 420 T bgp_connect_timer 16.032 772 20 27 T bgp_import 447.141 32322 13 526 TEX TOTAL bgpd# bgpd# show thread cpu rw Runtime(ms) Invoked Avg uSecs Max uSecs Type Thread 155.043 7 22149 150659 R bgp_accept 129.638 180 720 53844 R vty_read 1.734 56 30 129 R zclient_read 0.255 2 127 148 R vty_accept 58.483 983 59 340 R bgp_read 171.495 29190 5 245 W bgp_write 13.884 181 76 2542 W vty_flush 530.532 30599 17 150659 RW TOTAL bgpd# --------------------------------
2002-12-13 Kevin C Miller <kevinm@andrew.cmu.edu>paul
[zebra 16681] OSPF NSSA Patches
2002-12-13Michal Ludvig <michal@logix.cz>paul
[zebra 16525] PATCH: Bugfixes for KAME systems
2002-12-13[zebra 14631] Generic PtP and RFC3021 interface addressing supportpaul
2002-12-13zebra link state detection supportpaul
2002-12-13patch from Frank van Maarseveen <F.vanMaarseveen@inter.NL.net>paul
[zebra 14599] PATCH: permit [no]multicast command for (yet) inactive interfaces
2002-12-13Initial revisionpaul