Hi! Will this fix be commit before 6.3 release?
Thx csszep David Gwynne <[email protected]> ezt írta (időpont: 2018. márc. 13., K 23:41): > > > On 10 Mar 2018, at 08:01, Remi Locherer <[email protected]> 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; > >
