On 23/02/2021 16:12, Sabrina Dubroca wrote:
> LGTM. We also need to do the same thing in ip_vti and ip6_vti. Do you
> want to take care of it, or should I?
>
See the thread
https://lore.kernel.org/netdev/1552865877-13401-1-git-send-email-bram-yv...@mail.wizbit.be/
(I'm assuming
>>> and just run ping on it. ping sets DF, we want an exception
>>> to be created, but this test prevents it.
>>>
>>>
>> As I said dropping the test currently doesn't make sense to me.
>> I would expect that the 'ignore_df' flag is not set on the device, and
>> if it's set then I would
On 7/08/2020 16:47, Sabrina Dubroca wrote:
> 2020-08-04, 14:32:56 +0200, Bram Yvakh wrote:
>
>> On 4/08/2020 11:37, Sabrina Dubroca wrote:
>>
>>> diff --git a/net/xfrm/xfrm_interface.c b/net/xfrm/xfrm_interface.c
>>> index b615729812e5..ad
nore_df' is set then the size of the packet should not be checked
since the packet may be fragmented at will.
(I also suppose that means that setting 'ignore_df' is not an option (or
no longer) an option for xfrmi?)
I'm also not sure what the exact case is/was that lead to
Bram Yvahk wrote:
> Steffen Klassert wrote:
>> On Sun, Mar 17, 2019 at 11:37:55PM +0000, Bram Yvahk wrote:
>>> We've experienced an issue with VTI when the path-mtu is smaller than
> the size
>>> of the "client" packet.
>>>
>>> What h
Steffen Klassert wrote:
> On Sun, Mar 17, 2019 at 11:37:55PM +0000, Bram Yvahk wrote:
>> We've experienced an issue with VTI when the path-mtu is smaller than
the size
>> of the "client" packet.
>>
>> What happens: IPv4 packet from the client (i.e.
>
> What I would've expected to happen is that 'Gateway A' would send out
> two fragmented IPv6 packets containing the encrypted data. 'Gateway A'
> is the originator of the IPv6 ESP packet so it can fragment these.
> This similar to how it's done for IPv4. When the ESP is fragmented
> then the IPv
Bram Yvahk wrote:
> (What I think should happen in this particular case: do not send a
> PKT_TOOBIG to the client but instead transmit fragmented IPv6 ESP
> packets to accommodate the path-mtu)
A follow-up to clarify my thinking (since my original mail might not
be clear enough).
Let
When playing a bit with IPv6 and XFRM I ran into a possible
issue/edge case.
In my testing I used linux 4.14.95, I was planning on testing this
with latest kernel and investigating this a bit more deeply but so
far I've not yet been able to do so... Only reason why I'm already
submitting this mess
After running into some issues with VTI code (see my VTI patches) I
decided to take a peek at the xfrmi code. I believe it has the same
problems as the VTI code for which I submitted patches.
I was planning on testing this with latest kernel but so far I've not
yet been able to do so... Only reas
Bram Yvahk wrote:
> Only send a 'need to frag' ICMP message when the "Don't Fragment" bit
> is set. If it's not set then the packet can/will be fragmented.
>
> This fixes sending an 'need to frag' message on a client that did not
> set t
; and continues in sending packets that are too big.
This is addressed in the second patch.
Bram Yvahk (2):
vti: fragment IPv4 packets when DF bit is not set
vti6: process icmp msg when IPv6 is fragmented
net/ipv4/ip_vti.c | 43 +++-
net/ipv6/ip6_vti.c | 83
rror.
Signed-off-by: Bram Yvahk
---
net/ipv6/ip6_vti.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c
index 47f178c..9582ffd 100644
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -590,7 +590,7 @@ vti6_tnl
0 -M dont -c5 192.168.235.2
PING 192.168.235.3 (192.168.235.3) 1300(1328) bytes of data.
From 192.168.236.254 icmp_seq=1 Frag needed and DF set (mtu = 1214)
Signed-off-by: Bram Yvahk
---
net/ipv4/ip_vti.c | 43 ++
Francois Romieu wrote:
> Bram <[EMAIL PROTECTED]> :
> [...]
> > The device now works! But, it still comes up as eth2 instead of eth0,
> > even though it's first detected as eth0. There are no other network
>
> Check the udev rules and/or your init scripts ?
which ends with messages from me
unloading and reloading the r8169 module again. If you need anything else,
just let me know.
Best regards,
Bram
dmesg.bz2
Description: Binary data
16 matches
Mail list logo
