On Sat, 2020-11-21 at 14:03 -0800, Jakub Kicinski wrote:
> Applied to net with the typo fixed, thanks!
Thanks!
Is there any chance it'll be in 5.10 or will it have to wait for the 5.11
merge window?
Also it should be applied to all supported/stable kernels. I guess that'll
have to wait until it'
On Fri, 2020-11-20 at 12:15 +0300, Sergei Shtylyov wrote:
> > Investigation on the matter shows that UDP and ICMP traffic from the
> ^ "no" missing?
Yes indeed. Thanks and sorry for the typo.
Regards,
--
Yves-Alexis
t.
Tested-by: Matti Vuorela
Signed-off-by: Yves-Alexis Perez
Link:
https://lore.kernel.org/linux-usb/caan0qaxmysj9vx3zemkviv_b19ju-_exn8yn_usefxpjs6g...@mail.gmail.com/
Link: https://github.com/libimobiledevice/libimobiledevice/issues/1038
Cc: sta...@vger.kernel.org
---
drivers/net/usb/ipheth.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Thu, 2018-11-29 at 15:52 -0800, David Miller wrote:
> From: Kees Cook
> Date: Thu, 29 Nov 2018 15:31:25 -0800
>
> > Did you ever solve this?
>
> I think it was fixed by:
>
> commit 45611c61dd503454b2edae00aabe1e429ec49ebe
> Author: Bernd Eckst
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, 2018-11-23 at 13:51 +0100, Bernd Eckstein wrote:
> This causes the following problems:
> - double free of the skb or potential memory leak
> - in dmesg: 'recvmsg bug' and 'recvmsg bug 2' and eventually
> general protection fault
For what i
On Wed, 2018-02-07 at 20:46 +0100, Yves-Alexis Perez wrote:
> Maybe. I tried with removing the MTU setting, and I get (on ping again)
>
> févr. 07 20:44:01 scapa kernel: mtu: 1266
>
> which means I would get -EINVAL on standards kernels, which is not really good
> eithe
On Wed, 2018-02-07 at 13:50 -0500, Mike Maloney wrote:
> On Wed, Feb 7, 2018 at 12:23 PM, Yves-Alexis Perez
>
> Hi Yves-Alexis -
>
> I apologize for the problem. It seems to me that tunneling with an
> outer MTU that causes the inner MTU to be smaller than the min, is
> po
On Wed, 2018-02-07 at 18:05 +0100, Yves-Alexis Perez wrote:
> I'll try to printk the mtu before returning EINVAL to see why it's lower than
> 1280, but maybe the IP encapsulation is not correctly handled?
I did:
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
in
On Wed, 2018-02-07 at 17:38 +0100, Yves-Alexis Perez wrote:
> Starting with 4.14.16, IPv6 traffic is broken. When trying a simple ping
> to an IPv6 address I get:
>
> ping: sendmsg: Invalid argument
I forgot an important bit of information: due to the way routers usually broke
path M
Hi Mike,
I noticed a regression in 4.14.16 stable kernel (I assume it's also
present in mainline).
I'm using an IPsec setup where I tunnel all my IP trafic to a gateway.
The tunnel can use either IPv6 or IPv4 (depending on what's available
locally) and will route both IPv4 and IPv6 (my gateway wi
10 matches
Mail list logo
