On 9/9/15 9:20 PM, David Miller wrote:
From: Tom Herbert
Date: Wed, 9 Sep 2015 17:51:19 -0700
Consider that ip_local_out_sk calls netfilter NF_INET_LOCAL_OUT hook
before dst->output, so then netfilter would start seeing packets
with zero source address???
I have to agree with Tom here, this
From: Tom Herbert
Date: Wed, 9 Sep 2015 17:51:19 -0700
> Consider that ip_local_out_sk calls netfilter NF_INET_LOCAL_OUT hook
> before dst->output, so then netfilter would start seeing packets
> with zero source address???
I have to agree with Tom here, this is fatal.
--
To unsubscribe from this
On 9/9/15 6:51 PM, Tom Herbert wrote:
It is NAT since you are changing the source address and modifying the
transport protocol checksum below IP and transport layer. There are a
bunch of side effects that you would need to consider. This is
creating custom APIs changing the semantics of address s
On Wed, Sep 9, 2015 at 5:23 PM, David Ahern wrote:
> On 9/9/15 6:04 PM, Tom Herbert wrote:
>>
>> On Wed, Sep 9, 2015 at 2:57 PM, David Ahern
>> wrote:
>>>
>>> Remove the VRF change in udp_sendmsg to set the source address. The VRF
>>> driver already has access to the packet on the TX path via the
On 9/9/15 6:04 PM, Tom Herbert wrote:
On Wed, Sep 9, 2015 at 2:57 PM, David Ahern wrote:
Remove the VRF change in udp_sendmsg to set the source address. The VRF
driver already has access to the packet on the TX path via the dst. It
can be used to update the source address in the header. Since t
On Wed, Sep 9, 2015 at 2:57 PM, David Ahern wrote:
> Remove the VRF change in udp_sendmsg to set the source address. The VRF
> driver already has access to the packet on the TX path via the dst. It
> can be used to update the source address in the header. Since the VRF
> device is directly associa
Remove the VRF change in udp_sendmsg to set the source address. The VRF
driver already has access to the packet on the TX path via the dst. It
can be used to update the source address in the header. Since the VRF
device is directly associated with a table use fib_table_lookup rather
than the ip_rou