On Wed, Mar 14, 2018 at 07:07:36PM +0000, csszep wrote: > Hi! > > Will this fix be commit before 6.3 release? >
Yes something like this will need to be put into 6.3 since this is currently a regression from 6.2. > David Gwynne <d...@openbsd.org> ezt írta (id??pont: 2018. márc. 13., K 23:41): > > > > > > On 10 Mar 2018, at 08:01, Remi Locherer <remi.loche...@relo.ch> wrote: > > > > > > > > > With below diff the setup works as expected: tcpdump shows OSPF hellos > > > on gif0 and ospfd sees the neighbour. > > > > > > I don't think it's the correct fix though. > > > > functionally it is the correct fix. > > > > when i reworked gif(4) in src/sys/net/if_gif.c r1.108, i merged the ipv4 > > and ipv6 input paths. the ipv6 input code had this check, but ipv4 did not. > > now it is applied to ipv4, but it is obviously wrong for both address > > families. > > > > please commit the removal of this check, ok by me. > > > > thank you to everyone for the but report and debugging. i'm sorry for > > taking so long to figure this out. > > > > dlg > > > > > > > > > > > Index: if_gif.c > > > =================================================================== > > > RCS file: /cvs/src/sys/net/if_gif.c,v > > > retrieving revision 1.112 > > > diff -u -p -r1.112 if_gif.c > > > --- if_gif.c 28 Feb 2018 23:28:05 -0000 1.112 > > > +++ if_gif.c 9 Mar 2018 20:52:46 -0000 > > > @@ -745,8 +745,8 @@ gif_input(struct gif_tunnel *key, struct > > > } > > > > > > /* XXX What if we run transport-mode IPsec to protect gif tunnel ? > > */ > > > - if (m->m_flags & (M_AUTH | M_CONF)) > > > - return (-1); > > > + //if (m->m_flags & (M_AUTH | M_CONF)) > > > + // return (-1); > > > > > > key->t_rtableid = m->m_pkthdr.ph_rtableid; > > > > -- :wq Claudio
