if (ospf_debug_packet & OSPF_DEBUG_RECV)
which was causing unconditional ospf_ip_header_dump (ibuf).
(introduced with kevin millers patch)

[zebra 17352] ospf network matching (aka need for peer /32 for PtP)
change behaviour of network <prefix> area N statement wrt to PtP.

[zebra 17290] [PATCHES] - Fixes for problems in 0.93b

portfix patch

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.

----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
Changes 2002.12.20

1. Bug fixes

  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.

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.

[zebra 16681] OSPF NSSA Patches