tteras/strongswan/src/libhydra/plugins/kernel_netlink, branch master tteras' strongSwan tree libhydra: Move all kernel plugins to libcharon 2016-03-03T16:36:11+00:00 Tobias Brunner tobias@strongswan.org 2016-02-12T14:21:54+00:00 dec9e1957feb56c854bc24a657a6a378d74317f6 






kernel-netlink: Allow Netlink send buffer size to be configured via compile option
2016-02-12T14:08:34+00:00

Tobias Brunner
tobias@strongswan.org

2016-02-12T14:08:34+00:00

70934d94367d485cb599071671941b5d0c5c19fb

The receive buffer size can already be changed via strongswan.conf if
necessary.





The receive buffer size can already be changed via strongswan.conf if
necessary.







kernel-netlink: Allow IPsec policies to replace shunt policies
2015-11-10T15:42:53+00:00

Tobias Brunner
tobias@strongswan.org

2015-10-05T12:36:29+00:00

4aff44520295bcc547e729d1df33212496758227

Shunt policies don't have a reqid set, so we allow unequal reqids in
this particular case (i.e. if one of the reqids is 0).





Shunt policies don't have a reqid set, so we allow unequal reqids in
this particular case (i.e. if one of the reqids is 0).







kernel-netlink: Make absolutely sure we always delete the right policy cache entry
2015-11-10T15:42:53+00:00

Tobias Brunner
tobias@strongswan.org

2015-09-16T15:01:00+00:00

33400876d403de2e0e970a875d5af92a18708866












kernel-interface: Pass the same data to del_policy() that was passed to add_policy()
2015-11-10T15:42:52+00:00

Tobias Brunner
tobias@strongswan.org

2015-09-16T14:44:09+00:00

a6e0f14fd2bf8b23fbfd808acc595e97d5e23a49

The additional data can be helpful to identify the exact policy to
delete.





The additional data can be helpful to identify the exact policy to
delete.







kernel-netlink: Remove the unused policy_history flag
2015-11-10T14:42:16+00:00

Tobias Brunner
tobias@strongswan.org

2015-09-16T13:05:10+00:00

e2658390931608dd26390afec08e595a2feeed8b

This was used with pluto, which had its own policy tracking.





This was used with pluto, which had its own policy tracking.







kernel-netlink: Properly set port mask for ICMP type/code if only set on one side
2015-08-31T13:30:57+00:00

Tobias Brunner
tobias@strongswan.org

2015-08-26T15:46:10+00:00

7b20ab0a9403c9cbeb7009a5cf77d7f3f6d3f5dd

If only one traffic selector had a port (type/code) the other side had
the port mask set to 0, which canceled out the applied type/code.

It also fixes the installation of ICMP type/code on big-endian hosts.

Fixes #1091.
References #595.





If only one traffic selector had a port (type/code) the other side had
the port mask set to 0, which canceled out the applied type/code.

It also fixes the installation of ICMP type/code on big-endian hosts.

Fixes #1091.
References #595.







kernel-netlink: Only flush SAs of types we actually manage
2015-08-21T16:27:05+00:00

Tobias Brunner
tobias@strongswan.org

2015-08-13T08:34:47+00:00

82b5d1c01832a79c65b002b1677aac7ed015cb52












kernel-netlink: Avoid route dump if routing rule excludes traffic with a certain mark
2015-08-18T10:06:08+00:00

Tobias Brunner
tobias@strongswan.org

2015-08-05T14:51:38+00:00

6bd1216e7a8a41eb6c103c27a05f50871e1aef99

If the routing rule we use to direct traffic to our own routing table
excludes traffic with a certain mark (fwmark = !<mark>) we can simplify
the route lookup and avoid dumping all routes by passing the mark to the
request.  That way our own routes are ignored and we get the preferred
route back without having to dump and analyze all routes, which is quite a
burden on hosts with lots of routes.





If the routing rule we use to direct traffic to our own routing table
excludes traffic with a certain mark (fwmark = !<mark>) we can simplify
the route lookup and avoid dumping all routes by passing the mark to the
request.  That way our own routes are ignored and we get the preferred
route back without having to dump and analyze all routes, which is quite a
burden on hosts with lots of routes.







kernel-netlink: When adding a policy do an update if it already exists
2015-08-13T08:49:16+00:00

Tobias Brunner
tobias@strongswan.org

2015-06-03T15:31:30+00:00

dc2fa791e4b914a0099469749648483acdef6fbb

This may be the case when SAs are reestablished after a crash of the
IKE daemon.

We could actually always do updates.  The kernel doesn't care, the only
difference is the possible EEXIST if XFRM_MSG_NEWPOLICY is used.  The
advantage of not doing this, though, is that we get a warning in the log
if a policy already exists, as that should usually not be the case.





This may be the case when SAs are reestablished after a crash of the
IKE daemon.

We could actually always do updates.  The kernel doesn't care, the only
difference is the possible EEXIST if XFRM_MSG_NEWPOLICY is used.  The
advantage of not doing this, though, is that we get a warning in the log
if a policy already exists, as that should usually not be the case.