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. Paul _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
