Message ID | F41877A268BCDE49BAEE2286FA8C269F6FECFBBF@LETV-MBX-IDC09.letv.local |
---|---|
State | RFC, archived |
Delegated to: | David Miller |
Headers | show |
On Wed, Nov 23, 2016 at 11:45 PM, Liyang Yu (于立洋1) <yuliyang1@le.com> wrote: > Yeah,I means that recreate the tunnel again, > But I don’t think the patch can fix the bug. It only can make the first packet received successed. And the follow packet will droped also. > In function __gre_xmit line 366 > tunnel->o_seqno++; > > If you restart from UINT_MAX, the 'o_seqno' of second packet will return to 0 again. The first packet after restart: o_seqno == UINT_MAX, the other end: i_seqno = 0 The second packet after restart: o_seqno == 0, the other end: i_seqno = 1 So traffic should be back to normal. UINT_MAX is also what RFC suggests.
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c index 5719d6b..2738ff2 100644 --- a/net/ipv4/ip_tunnel.c +++ b/net/ipv4/ip_tunnel.c @@ -277,6 +277,7 @@ static struct net_device *__ip_tunnel_create(struct net *net, tunnel = netdev_priv(dev); tunnel->parms = *parms; tunnel->net = net; + tunnel->o_seqno = UINT_MAX; err = register_netdevice(dev); if (err)