[Swan-dev] Q: mobike on kernel without mobike: load or not load the connection

Paul Wouters paul at nohats.ca
Wed Jun 12 14:29:13 UTC 2019

On Wed, 12 Jun 2019, Tuomo Soini wrote:

> No. We really need to fail loading the connectin if mobike=yes is set
> and we don't support mobike. We have exactly similar behaviour with
> nic-offload. You can't even set nic-offload=no if nic-offload support
> is not build in.

The default for nic-offload=auto, and the connection will work fine
regardless of the kernel capabilities in that mode. It will get used
when available. The option nic-offload=yes was to allow you to force
it to be needed (in case you have increased bandwidth requirements
that cannot be met without offload) but that's rare and why the default
is set to auto.

mobike is never guaranteed to happen, like transport mode. The other end
can simply refuse it. So a connection with mobike=yes _can_ be working
without mobike anyway, even if our end's kernel supports it. So why
let the connection not fail when the other end rejects it, but fail it
when our end rejects it for lack of capability. I don't find that very
consistent or predictable.

compress=yes works similarly. If we don't have the compression algorithm
support the connection also doesn't fail to load, and it will fail later
when we try to install the IPCOMP SA and fail. So we even fully
negotiate compression and only later on fail at it.

> Close issue. We must fail to load connection requesting mobike if
> mobike support is not available. Or we soon get bug reports about
> mobike not working.

mobike is negotiated. It can always be "not working".

I'm okay with logging a big warning saying mobike is disabled because
local support is missing.


More information about the Swan-dev mailing list