On Thu, 19 Oct 2017 17:57:04 +0800
Herbert Xu wrote:
> On Thu, Oct 19, 2017 at 05:26:25PM +0800, Herbert Xu wrote:
> >
> > So it's an netlink API issue. It is possible for cb->done to be
> > called without cb->dump ever being called. And xfrm_user doesn't
> > deal with that. Let me survey the
Hi,
I recently saw via-velocity skb_over_panic() on one of my locations.
The panic happened with two separate hardware devices, so it appears to
be network related, not broken hardware.
I did not get the actual over_panic printk, as I got only screen shot
of them monitor. But the visible part of
Hi,
Can you queue for active older -stables up to 3.18:
commit 3cdaa5be9e81 "ipv4: Don't increase PMTU with Datagram Too Big message"
commit cb6ccf09d6b9 "route: Use ipv4_mtu instead of raw rt_pmtu"
commit 3cdaa5be9e81 made it to 3.19.y and was later fixed additionally
with conversion to ipv4_mt
Hello,
On Wed, 8 Jul 2015 21:51:56 +0300
Timo Teras wrote:
> On Wed, 08 Jul 2015 19:39:58 +0200
> Hannes Frederic Sowa wrote:
> >
> > At least we know which interface the packet would leave. Should we
> > override this behavior on a per-interface basis?
>
> That
Hi,
On Wed, 08 Jul 2015 19:39:58 +0200
Hannes Frederic Sowa wrote:
> On Wed, 2015-07-08 at 19:17 +0300, Timo Teras wrote:
> > On Wed, 08 Jul 2015 17:52:32 +0200
> > Hannes Frederic Sowa wrote:
> >
> > > On Wed, 2015-07-08 at 16:30 +0300, Timo Teras wrote:
> &g
On Wed, 08 Jul 2015 17:52:32 +0200
Hannes Frederic Sowa wrote:
> On Wed, 2015-07-08 at 16:30 +0300, Timo Teras wrote:
> > This probably is due to the way how the xfrm+gre work together. On
> > first packet, the gre tunnel driver updates pmtu for the inner flow,
> > wh
Hi,
It seems ip_forward_use_pmtu commit log says:
Tunnel and ipsec output paths clear IPCB again, thus IPSKB_FORWARDED
won't be set and further fragmentation logic will use the path mtu
to determine the fragmentation size. They also recheck packet size
with help of path mtu discove
