Re: [WireGuard] [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

Hey Hannes, David, On Mon, Nov 14, 2016 at 7:33 PM, Hannes Frederic Sowa wrote: > I meant to say, we don't require the IPv6 "API" to behave in a similar > way like the IPv4 one. We do this function pointer trick to allow > _in-kernel_ tree modules to use the function

Re: [WireGuard] [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

On 11/14/16 10:33 AM, Hannes Frederic Sowa wrote: > I just also quickly read up on the history (sorry was travelling last > week) and wonder if you ever saw a user space facing bug or if this is > basically some difference you saw while writing out of tree code? I checked the

Re: [WireGuard] [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

On 11/14/16 9:44 AM, Hannes Frederic Sowa wrote: > On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote: >> This puts the IPv6 routing functions in parity with the IPv4 routing >> functions. Namely, we now check in v6 that if a flowi6 requests an >> saddr, the returned dst actually corresponds

Re: [WireGuard] [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

On 11/13/16 4:28 PM, Jason A. Donenfeld wrote: > This puts the IPv6 routing functions in parity with the IPv4 routing > functions. Namely, we now check in v6 that if a flowi6 requests an > saddr, the returned dst actually corresponds to a net device that has > that saddr. This mirrors the v4 logic

[WireGuard] RFE: A notion of VERSION (was: Debugging AllowedIps)

Hi Jason, On Mon, Nov 14, 2016 at 11:28 AM, John Huttley wrote: > RFE: when the module loads and prints its test at startup, please print its > version and compile flags as well. > I second that! There is not (yet) a notion of VERSION in the code, better not wait till