Le 14/03/2016 18:57, Mahesh Bandewar a écrit :
On Sun, Mar 13, 2016 at 8:53 PM, David Miller wrote:
[snip]
Furthermore, when you walk across the ns boundary, that old device has
to disappear. That's why that is the device assigned to skb->dev.
The layer boundaries are not that well maintain
On Sun, Mar 13, 2016 at 8:53 PM, David Miller wrote:
>
> Please stop pretending that this device switching is ok, it's not.
+1
This is what I have been complaining about since v1...
On Sun, Mar 13, 2016 at 5:01 PM, Mahesh Bandewar wrote:
>>> If I understand correctly (and as Cong already said), information are
>>> leaking
>>> between netns during the input phase. On the tx side, skb_scrub_packet() is
>>> called, but not on the rx side. I think it's wrong. There should be an
>
On Sun, Mar 13, 2016 at 8:53 PM, David Miller wrote:
> From: Mahesh Bandewar
> Date: Sun, 13 Mar 2016 19:29:58 -0700
>
>> On Sun, Mar 13, 2016 at 6:50 PM, David Miller wrote:
>>> It doesn't matter whether doing so or not makes sense.
>>>
>>> You're going to have to find a way to do both, and als
From: Mahesh Bandewar
Date: Sun, 13 Mar 2016 19:29:58 -0700
> On Sun, Mar 13, 2016 at 6:50 PM, David Miller wrote:
>> It doesn't matter whether doing so or not makes sense.
>>
>> You're going to have to find a way to do both, and also I'm concerned
>> about how you're leaking the source namespac
On Sun, Mar 13, 2016 at 6:50 PM, David Miller wrote:
> From: Mahesh Bandewar
> Date: Wed, 9 Mar 2016 13:49:49 -0800
>
>> This does happen as expected for egress traffic however on ingress
>> traffic, the IPvlan packet-handler changes the skb->dev and this
>> forces packet to be processed with th
From: Mahesh Bandewar
Date: Wed, 9 Mar 2016 13:49:49 -0800
> This does happen as expected for egress traffic however on ingress
> traffic, the IPvlan packet-handler changes the skb->dev and this
> forces packet to be processed with the IPvlan slave and it's
> associated ns. This causes above men
>> If I understand correctly (and as Cong already said), information are
>> leaking
>> between netns during the input phase. On the tx side, skb_scrub_packet() is
>> called, but not on the rx side. I think it's wrong. There should be an
>> explicit
>> boundary.
>
> That is not what I am complaining
> If I understand correctly (and as Cong already said), information are
> leaking
> between netns during the input phase. On the tx side, skb_scrub_packet() is
> called, but not on the rx side. I think it's wrong. There should be an
> explicit
> boundary.
>
I think we used to do dev_forward_skb() i
On Thu, Mar 10, 2016 at 1:47 AM, Nicolas Dichtel
wrote:
> Le 09/03/2016 22:49, Mahesh Bandewar a écrit :
>>
>> From: Mahesh Bandewar
>>
>> One of the major request (for enhancement) that I have received
>> from various users of IPvlan in L3 mode is its inability to handle
>> IPtables.
>>
>> While
Le 09/03/2016 22:49, Mahesh Bandewar a écrit :
From: Mahesh Bandewar
One of the major request (for enhancement) that I have received
from various users of IPvlan in L3 mode is its inability to handle
IPtables.
While looking at the code and how we handle ingress, the problem
can be attributed t
From: Mahesh Bandewar
One of the major request (for enhancement) that I have received
from various users of IPvlan in L3 mode is its inability to handle
IPtables.
While looking at the code and how we handle ingress, the problem
can be attributed to the asymmetry in the way packets get processed
12 matches
Mail list logo
