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
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 ?
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
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 ++
; 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
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
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
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
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
>
> 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
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.
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
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
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
16 matches
Mail list logo
