Re: ospf6d exits after ospf6ctl reload

[Jeremie Courreges-Anglas]

Remi Locherer  writes:

> Hi,

Hi,

> ospf6d does not like beeing reloaded and exits.
>
> Below an example on -current running in VMM. I first noticed it
> on an OpenBSD 6.0 amd64 router on real hardware.

The issue has already been reported, it's not really new.  The code that
handles interfaces and addresses is different in ospfd and ospf6d.
I recently tried to sync that code but there were a few differences that
made it more difficult than expected.

> Remi
>
>
>
> r1# ifconfig -A
> lo0: flags=8049 mtu 32768
> index 3 priority 0 llprio 3
> groups: lo
> inet6 ::1 prefixlen 128
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
> inet 127.0.0.1 netmask 0xff00
> vio0: flags=8b43 mtu 
> 1500
> lladdr fe:e1:bb:d1:10:e1
> index 1 priority 0 llprio 3
> groups: egress
> media: Ethernet autoselect
> status: active
> inet 192.168.250.101 netmask 0xff00 broadcast 192.168.250.255
> inet6 fe80::fce1:bbff:fed1:10e1%vio0 prefixlen 64 scopeid 0x1
> inet6 2001:db8::101 prefixlen 64
> enc0: flags=0<>
> index 2 priority 0 llprio 3
> groups: enc
> status: active
> vether0: flags=8843 mtu 1500
> lladdr fe:e1:ba:d0:08:cf
> index 5 priority 0 llprio 3
> groups: vether
> media: Ethernet autoselect
> status: active
> inet6 fe80::fce1:baff:fed0:8cf%vether0 prefixlen 64 scopeid 0x5
> inet6 2001:db8:a::101 prefixlen 64
> r1#
> r1# sysctl net.inet6.ip6.forwarding
> net.inet6.ip6.forwarding=1
> r1#
> r1# cat /etc/ospf6d.conf
> router-id 192.168.250.101
>
> area 0.0.0.0 {
> interface vio0
> interface vether0 { passive }
> }
> r1#
> r1#
> r1# ospf6d -dv
> if_newaddr: ifindex 3, addr fe80::1/64, dest ::
> if_newaddr: ifindex 1, addr fe80::fce1:bbff:fed1:10e1/64
> if_newaddr: ifindex 1, addr 2001:db8::101/64
> if_newaddr: ifindex 5, addr fe80::fce1:baff:fed0:8cf/64
> if_newaddr: ifindex 5, addr 2001:db8:a::101/64
> startup
> if_set_ipv6_checksum setting cksum offset to 12
> orig_rtr_lsa: area 0.0.0.0
> if_fsm: event UP resulted in action START and changing state for interface 
> vether0 from DOWN to DOWN
> if_join_group: interface vio0 addr ff02::5
> orig_rtr_lsa: area 0.0.0.0
> orig_link_lsa: interface vio0
> if_fsm: event UP resulted in action START and changing state for interface 
> vio0 from DOWN to WAIT
> orig_intra_lsa_net: area 0.0.0.0, interface vether0
> orig_intra_lsa_net: area 0.0.0.0, interface vio0
> orig_intra_lsa_rtr: area 0.0.0.0, interface vether0: 2001:db8:a::101/64
> spf_calc: area 0.0.0.0 calculated
> *(192.168.250.101, 0x2001, 0.0.0.0) cost 0 has nexthops []
> nbr_fsm: event HELLO_RECEIVED resulted in action START_INACTIVITY_TIMER and 
> changing state for neighbor ID 192.168.250.102 from DOWN to INIT
> nbr_fsm: event 2_WAY_RECEIVED resulted in action EVAL and changing state for 
> neighbor ID 192.168.250.102 from INIT to 2-WAY
> if_act_elect: interface vio0 old dr none new dr 192.168.250.102, old bdr none 
> new bdr 192.168.250.101
> if_join_group: interface vio0 addr ff02::6
> nbr_fsm: event ADJ_OK resulted in action EVAL and changing state for neighbor 
> ID 192.168.250.102 from 2-WAY to EXSTA
> orig_rtr_lsa: area 0.0.0.0
> orig_rtr_lsa: area 0.0.0.0
> orig_link_lsa: interface vio0
> orig_link_lsa: link local address fe80::fce1:bbff:fed1:10e1
> orig_link_lsa: prefix 2001:db8::
> if_fsm: event BACKUPSEEN resulted in action ELECT and changing state for 
> interface vio0 from WAIT to BCKUP
> if_act_elect: interface vio0 old dr 192.168.250.102 new dr 192.168.250.102, 
> old bdr 192.168.250.101 new bdr 192.168.250.101
> if_fsm: event NEIGHBORCHANGE resulted in action ELECT and changing state for 
> interface vio0 from BCKUP to BCKUP
> orig_intra_lsa_net: area 0.0.0.0, interface vether0
> orig_intra_lsa_net: area 0.0.0.0, interface vio0
> orig_intra_lsa_rtr: area 0.0.0.0, interface vether0: 2001:db8:a::101/64
> orig_intra_lsa_net: area 0.0.0.0, interface vether0
> orig_intra_lsa_net: area 0.0.0.0, interface vio0
> orig_intra_lsa_rtr: area 0.0.0.0, interface vether0: 2001:db8:a::101/64
> orig_intra_lsa_rtr: area 0.0.0.0, interface vio0: 2001:db8::101/64
> nbr_fsm: event NEGOTIATION_DONE resulted in action SNAPSHOT and changing 
> state for neighbor ID 192.168.250.102 from EXSTA to SNAP
> nbr_fsm: event SNAPSHOT_DONE resulted in action SNAPSHOT_DONE and changing 
> state for neighbor ID 192.168.250.102 from SNAP to EXCHG
> nbr_fsm: event EXCHANGE_DONE resulted in action EXCHANGE_DONE and changing 
> state for neighbor ID 192.168.250.102 from EXCHG to LOAD
> spf_calc: area 0.0.0.0 calculated
> *(192.168.250.101, 0x2001, 0.0.0.0) cost 0 has nexthops []
>  (192.168.250.102, 0x2001, 0.0.0.0) cost 16777215 has nexthops []
> ospf6d: rt_calc: Intra-Area-Prefix LSA 

ospf6d exits after ospf6ctl reload

[Remi Locherer]

Hi,

ospf6d does not like beeing reloaded and exits.

Below an example on -current running in VMM. I first noticed it
on an OpenBSD 6.0 amd64 router on real hardware.

Remi



r1# ifconfig -A
lo0: flags=8049 mtu 32768
index 3 priority 0 llprio 3
groups: lo
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff00
vio0: flags=8b43 mtu 
1500
lladdr fe:e1:bb:d1:10:e1
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect
status: active
inet 192.168.250.101 netmask 0xff00 broadcast 192.168.250.255
inet6 fe80::fce1:bbff:fed1:10e1%vio0 prefixlen 64 scopeid 0x1
inet6 2001:db8::101 prefixlen 64
enc0: flags=0<>
index 2 priority 0 llprio 3
groups: enc
status: active
vether0: flags=8843 mtu 1500
lladdr fe:e1:ba:d0:08:cf
index 5 priority 0 llprio 3
groups: vether
media: Ethernet autoselect
status: active
inet6 fe80::fce1:baff:fed0:8cf%vether0 prefixlen 64 scopeid 0x5
inet6 2001:db8:a::101 prefixlen 64
r1#
r1# sysctl net.inet6.ip6.forwarding
net.inet6.ip6.forwarding=1
r1#
r1# cat /etc/ospf6d.conf
router-id 192.168.250.101

area 0.0.0.0 {
interface vio0
interface vether0 { passive }
}
r1#
r1#
r1# ospf6d -dv
if_newaddr: ifindex 3, addr fe80::1/64, dest ::
if_newaddr: ifindex 1, addr fe80::fce1:bbff:fed1:10e1/64
if_newaddr: ifindex 1, addr 2001:db8::101/64
if_newaddr: ifindex 5, addr fe80::fce1:baff:fed0:8cf/64
if_newaddr: ifindex 5, addr 2001:db8:a::101/64
startup
if_set_ipv6_checksum setting cksum offset to 12
orig_rtr_lsa: area 0.0.0.0
if_fsm: event UP resulted in action START and changing state for interface 
vether0 from DOWN to DOWN
if_join_group: interface vio0 addr ff02::5
orig_rtr_lsa: area 0.0.0.0
orig_link_lsa: interface vio0
if_fsm: event UP resulted in action START and changing state for interface vio0 
from DOWN to WAIT
orig_intra_lsa_net: area 0.0.0.0, interface vether0
orig_intra_lsa_net: area 0.0.0.0, interface vio0
orig_intra_lsa_rtr: area 0.0.0.0, interface vether0: 2001:db8:a::101/64
spf_calc: area 0.0.0.0 calculated
*(192.168.250.101, 0x2001, 0.0.0.0) cost 0 has nexthops []
nbr_fsm: event HELLO_RECEIVED resulted in action START_INACTIVITY_TIMER and 
changing state for neighbor ID 192.168.250.102 from DOWN to INIT
nbr_fsm: event 2_WAY_RECEIVED resulted in action EVAL and changing state for 
neighbor ID 192.168.250.102 from INIT to 2-WAY
if_act_elect: interface vio0 old dr none new dr 192.168.250.102, old bdr none 
new bdr 192.168.250.101
if_join_group: interface vio0 addr ff02::6
nbr_fsm: event ADJ_OK resulted in action EVAL and changing state for neighbor 
ID 192.168.250.102 from 2-WAY to EXSTA
orig_rtr_lsa: area 0.0.0.0
orig_rtr_lsa: area 0.0.0.0
orig_link_lsa: interface vio0
orig_link_lsa: link local address fe80::fce1:bbff:fed1:10e1
orig_link_lsa: prefix 2001:db8::
if_fsm: event BACKUPSEEN resulted in action ELECT and changing state for 
interface vio0 from WAIT to BCKUP
if_act_elect: interface vio0 old dr 192.168.250.102 new dr 192.168.250.102, old 
bdr 192.168.250.101 new bdr 192.168.250.101
if_fsm: event NEIGHBORCHANGE resulted in action ELECT and changing state for 
interface vio0 from BCKUP to BCKUP
orig_intra_lsa_net: area 0.0.0.0, interface vether0
orig_intra_lsa_net: area 0.0.0.0, interface vio0
orig_intra_lsa_rtr: area 0.0.0.0, interface vether0: 2001:db8:a::101/64
orig_intra_lsa_net: area 0.0.0.0, interface vether0
orig_intra_lsa_net: area 0.0.0.0, interface vio0
orig_intra_lsa_rtr: area 0.0.0.0, interface vether0: 2001:db8:a::101/64
orig_intra_lsa_rtr: area 0.0.0.0, interface vio0: 2001:db8::101/64
nbr_fsm: event NEGOTIATION_DONE resulted in action SNAPSHOT and changing state 
for neighbor ID 192.168.250.102 from EXSTA to SNAP
nbr_fsm: event SNAPSHOT_DONE resulted in action SNAPSHOT_DONE and changing 
state for neighbor ID 192.168.250.102 from SNAP to EXCHG
nbr_fsm: event EXCHANGE_DONE resulted in action EXCHANGE_DONE and changing 
state for neighbor ID 192.168.250.102 from EXCHG to LOAD
spf_calc: area 0.0.0.0 calculated
*(192.168.250.101, 0x2001, 0.0.0.0) cost 0 has nexthops []
 (192.168.250.102, 0x2001, 0.0.0.0) cost 16777215 has nexthops []
ospf6d: rt_calc: Intra-Area-Prefix LSA (192.168.250.102, 1) references 
non-existent Network LSA (192.168.250.102, 1)
orig_intra_lsa_net: area 0.0.0.0, interface vether0
orig_intra_lsa_net: area 0.0.0.0, interface vio0
orig_intra_lsa_rtr: area 0.0.0.0, interface vether0: 2001:db8:a::101/64
orig_intra_lsa_rtr: area 0.0.0.0, interface vio0: 2001:db8::101/64
orig_rtr_lsa: area 0.0.0.0
orig_rtr_lsa: transit net, interface vio0
nbr_fsm: event LOADING_DONE resulted in action NOTHING and changing state for 
neighbor ID 192.168.250.102 from LOAD to FULL
orig_intra_lsa_net: 

Re: CVS: cvs.openbsd.org: src

[Claudio Jeker]

On Mon, Mar 13, 2017 at 06:03:56PM +0100, Rafael Zalamena wrote:
> On Fri, Mar 10, 2017 at 04:14:44PM +0100, Paul de Weerd wrote:
> > Hi Rafael, others,
> > 
> > It looks like your commit to ip_mroute.[ch] from January 11th broke
> > multicast forwarding.  I found another thread that may suffer from the
> > same problem: http://marc.info/?l=openbsd-bugs=148605155027668=2 -
> > I'm CC:'ing the OP from that thread here (hope you don't mind :).
> > 
> > On Wed, Jan 11, 2017 at 06:17:35AM -0700, Rafael Zalamena wrote:
> > | CVSROOT:  /cvs
> > | Module name:  src
> > | Changes by:   rzalam...@cvs.openbsd.org   2017/01/11 06:17:35
> > | 
> > | Modified files:
> > |   sys/netinet: ip_mroute.c ip_mroute.h 
> > | 
> > | Log message:
> > | Remove mfc hash tables and use the OpenBSD routing table for multicast
> > | routes. Beside the code simplification and removal, we also get to see
> > | the multicast routes now in the route(8) utility.
> > | 
> > | ok mpi@
> 
> After exchanging a few e-mails with Paul we identified and fixed the
> problem reported.
> 
> The problem was that the mfc_find() function was matching default route
> as a multicast route, so it was never notifying the multicast routing
> daemon that we had a new IGMP message. Without sending the IGMP messages
> to the userland, igmpproxy never had a chance to install the needed
> routes for the rest to work.
> 
> The diff below makes mfc_find() route search more strict.
> 
> ok?

Reads fine by me. OK claudio@

I think you can move the RTF_HOST check outside of the while loop since
rtable_iterate will only return routes with the same addr/mask and therfor
RTF_HOST flag. Minor optimization, probably not worth the effort though.
 
> Index: sys/netinet/ip_mroute.c
> ===
> RCS file: /home/obsdcvs/src/sys/netinet/ip_mroute.c,v
> retrieving revision 1.110
> diff -u -p -r1.110 ip_mroute.c
> --- sys/netinet/ip_mroute.c   9 Feb 2017 15:36:46 -   1.110
> +++ sys/netinet/ip_mroute.c   13 Mar 2017 11:25:13 -
> @@ -157,11 +157,14 @@ mfc_find(struct ifnet *ifp, struct in_ad
>   if (rt == NULL)
>   return (NULL);
>  
> - /* Return first ocurrence if interface is not specified. */
> - if (ifp == NULL)
> - return (rt);
> -
>   do {
> + /* Don't consider non multicast routes. */
> + if (ISSET(rt->rt_flags, RTF_HOST | RTF_MULTICAST) !=
> + (RTF_HOST | RTF_MULTICAST))
> + continue;
> + /* Return first occurrence if interface is not specified. */
> + if (ifp == NULL)
> + return (rt);
>   if (rt->rt_ifidx == ifp->if_index)
>   return (rt);
>   } while ((rt = rtable_iterate(rt)) != NULL);
> 

-- 
:wq Claudio

Re: CVS: cvs.openbsd.org: src

[Paul de Weerd]

I can confirm Rafael's diff fixes the issues I was having with
multicast.

Thank you very much, Rafael!

Paul

On Mon, Mar 13, 2017 at 06:03:56PM +0100, Rafael Zalamena wrote:
| On Fri, Mar 10, 2017 at 04:14:44PM +0100, Paul de Weerd wrote:
| > Hi Rafael, others,
| > 
| > It looks like your commit to ip_mroute.[ch] from January 11th broke
| > multicast forwarding.  I found another thread that may suffer from the
| > same problem: http://marc.info/?l=openbsd-bugs=148605155027668=2 -
| > I'm CC:'ing the OP from that thread here (hope you don't mind :).
| > 
| > On Wed, Jan 11, 2017 at 06:17:35AM -0700, Rafael Zalamena wrote:
| > | CVSROOT:  /cvs
| > | Module name:  src
| > | Changes by:   rzalam...@cvs.openbsd.org   2017/01/11 06:17:35
| > | 
| > | Modified files:
| > |   sys/netinet: ip_mroute.c ip_mroute.h 
| > | 
| > | Log message:
| > | Remove mfc hash tables and use the OpenBSD routing table for multicast
| > | routes. Beside the code simplification and removal, we also get to see
| > | the multicast routes now in the route(8) utility.
| > | 
| > | ok mpi@
| 
| After exchanging a few e-mails with Paul we identified and fixed the
| problem reported.
| 
| The problem was that the mfc_find() function was matching default route
| as a multicast route, so it was never notifying the multicast routing
| daemon that we had a new IGMP message. Without sending the IGMP messages
| to the userland, igmpproxy never had a chance to install the needed
| routes for the rest to work.
| 
| The diff below makes mfc_find() route search more strict.
| 
| ok?
| 
| Index: sys/netinet/ip_mroute.c
| ===
| RCS file: /home/obsdcvs/src/sys/netinet/ip_mroute.c,v
| retrieving revision 1.110
| diff -u -p -r1.110 ip_mroute.c
| --- sys/netinet/ip_mroute.c   9 Feb 2017 15:36:46 -   1.110
| +++ sys/netinet/ip_mroute.c   13 Mar 2017 11:25:13 -
| @@ -157,11 +157,14 @@ mfc_find(struct ifnet *ifp, struct in_ad
|   if (rt == NULL)
|   return (NULL);
|  
| - /* Return first ocurrence if interface is not specified. */
| - if (ifp == NULL)
| - return (rt);
| -
|   do {
| + /* Don't consider non multicast routes. */
| + if (ISSET(rt->rt_flags, RTF_HOST | RTF_MULTICAST) !=
| + (RTF_HOST | RTF_MULTICAST))
| + continue;
| + /* Return first occurrence if interface is not specified. */
| + if (ifp == NULL)
| + return (rt);
|   if (rt->rt_ifidx == ifp->if_index)
|   return (rt);
|   } while ((rt = rtable_iterate(rt)) != NULL);

-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
 http://www.weirdnet.nl/ 

Re: make single-suffix inference rules ignored for paths with slashes

[Marc Espie]

I've looked at this. So far no real clue.
The maddening thing is that the code that triggers single suffix in
the non directory case is the same in freebsd's bmake and ours,
so obviously it doesn't trigger when there's an extra directory, as
the paths don't match.

I'll have to check if there's some sanitization of prefix that I haven't
found yet.

Still the most convoluted part of that program... :(

Re: CVS: cvs.openbsd.org: src

[Rafael Zalamena]

On Fri, Mar 10, 2017 at 04:14:44PM +0100, Paul de Weerd wrote:
> Hi Rafael, others,
> 
> It looks like your commit to ip_mroute.[ch] from January 11th broke
> multicast forwarding.  I found another thread that may suffer from the
> same problem: http://marc.info/?l=openbsd-bugs=148605155027668=2 -
> I'm CC:'ing the OP from that thread here (hope you don't mind :).
> 
> On Wed, Jan 11, 2017 at 06:17:35AM -0700, Rafael Zalamena wrote:
> | CVSROOT:/cvs
> | Module name:src
> | Changes by: rzalam...@cvs.openbsd.org   2017/01/11 06:17:35
> | 
> | Modified files:
> | sys/netinet: ip_mroute.c ip_mroute.h 
> | 
> | Log message:
> | Remove mfc hash tables and use the OpenBSD routing table for multicast
> | routes. Beside the code simplification and removal, we also get to see
> | the multicast routes now in the route(8) utility.
> | 
> | ok mpi@

After exchanging a few e-mails with Paul we identified and fixed the
problem reported.

The problem was that the mfc_find() function was matching default route
as a multicast route, so it was never notifying the multicast routing
daemon that we had a new IGMP message. Without sending the IGMP messages
to the userland, igmpproxy never had a chance to install the needed
routes for the rest to work.

The diff below makes mfc_find() route search more strict.

ok?

Index: sys/netinet/ip_mroute.c
===
RCS file: /home/obsdcvs/src/sys/netinet/ip_mroute.c,v
retrieving revision 1.110
diff -u -p -r1.110 ip_mroute.c
--- sys/netinet/ip_mroute.c 9 Feb 2017 15:36:46 -   1.110
+++ sys/netinet/ip_mroute.c 13 Mar 2017 11:25:13 -
@@ -157,11 +157,14 @@ mfc_find(struct ifnet *ifp, struct in_ad
if (rt == NULL)
return (NULL);
 
-   /* Return first ocurrence if interface is not specified. */
-   if (ifp == NULL)
-   return (rt);
-
do {
+   /* Don't consider non multicast routes. */
+   if (ISSET(rt->rt_flags, RTF_HOST | RTF_MULTICAST) !=
+   (RTF_HOST | RTF_MULTICAST))
+   continue;
+   /* Return first occurrence if interface is not specified. */
+   if (ifp == NULL)
+   return (rt);
if (rt->rt_ifidx == ifp->if_index)
return (rt);
} while ((rt = rtable_iterate(rt)) != NULL);