[strongSwan] failing to decrypt esp
Martin Willi
martin at strongswan.org
Mon Mar 11 12:56:36 CET 2013
Hi Chad,
> I traced the root issue to an alignment problem in the strongswan macro
> NLMSG_LEN.
NLMSG_LENGTH is not a strongSwan macro, but one defined by the netlink.h
Linux header.
> The len value passed in was never aligned and therefore the kernel
> is off by two bytes when it computes the attribute list length causing it to
> not complete all the commands.
I don't think that aligning the length is required for a simple payload.
However, when adding attributes after the payload, it is required that
we update the length of the added attribute, plus any alignment we added
before the attribute.
The patch at [1] fixes this, let me know if this works on your
architecture. Probably it's about time to refactor that code...
> One question, why does strongswan redefine the netlink headers
Unfortunately, Linux headers shipped by some distributions are not only
horribly outdated, but often just unusable. Therefore we ship a copy of
some headers. Of course you can build against your own headers using the
--with-linux-headers ./configure option.
> and why not use the libnetlink functions like addattr_l() such as
> iproute2 instead of rolling your own?
The libnetlink functions you refer here to are an integral part of
iproute2. In most builds there is no shared library we could use. Using
third party libraries or sources has pros and cons, we use our own
Netlink code wich gives us much more flexibility.
Regards
Martin
[1]http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=d3f5a05e
More information about the Users
mailing list