ospfd: restore nexthop IP for p2p interfaces

commit c81ee5c... "ospfd: Optimize and improve SPF nexthop calculation"
subtly changed semantics of routes calculated over pointopoint links by
removing the nexthop IP address and instead using an ifindex route.

This breaks calculation of AS-Ext routes with a forwarding address since
in ospf_ase_complete_direct_routes() this will be hit:
    if (op->nexthop.s_addr == 0)
      op->nexthop.s_addr = nexthop.s_addr;
thus turning the route unusable by having an invalid nexthop.

Fix by restoring the nexthop IP on routes over PtP links.  This also
allows running multi-access (Ethernet) interfaces in PtP mode again.

This bug is a regression against 0.99.21 and only present in 0.99.22.

Signed-off-by: Christian Franke <chris@opensourcerouting.org>
[patch description and code comments rewritten]
Acked-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Acked-by: James Li <jli@cumulusnetworks.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>

ospfd/ospf_spf.c

@@ -568,8 +568,22 @@ ospf_nexthop_calculation (struct ospf_area *area, struct vertex *v,
               */
 	      if (oi->type == OSPF_IFTYPE_POINTOPOINT)
 		{
-		  added = 1;
-		  nexthop.s_addr = 0; /* Nexthop not required */
+		  /* Having nexthop = 0 is tempting, but NOT acceptable.
+		     It breaks AS-External routes with a forwarding address,
+		     since ospf_ase_complete_direct_routes() will mistakenly
+		     assume we've reached the last hop and should place the
+		     forwarding address as nexthop.
+		     Also, users may configure multi-access links in p2p mode,
+		     so we need the IP to ARP the nexthop.
+		  */
+		  struct ospf_neighbor *nbr_w;
+
+		  nbr_w = ospf_nbr_lookup_by_routerid (oi->nbrs, &l->link_id);
+		  if (nbr_w != NULL)
+		    {
+		      added = 1;
+		      nexthop = nbr_w->src;
+		    }
 		}
 	      else if (oi->type == OSPF_IFTYPE_POINTOMULTIPOINT)
 		{