aboutsummaryrefslogtreecommitdiffstats
path: root/src/libcharon
Commit message (Collapse)AuthorAgeFilesLines
* vici: Cancel processor before calling library_deinit()Martin Willi2014-10-101-0/+1
| | | | | For non-direct libstrongswan users, the deinitialization segfaults because of the missing worker thread cancellation.
* vici: Reduce debug level during thread spawningMartin Willi2014-10-101-0/+2
| | | | We want to avoid libvici users to get a cluttered stderr for no real error.
* vici: Don't include-depend on libstrongswan for boolean typesMartin Willi2014-10-102-4/+2
| | | | | | | | As we want to avoid the libstrongswan include dependencies for libvici, avoid the use of the bool type. Unfortunately this change may break the ABI for vici_dump(). As this function is mostly for debugging purposes, we do it nonetheless; my apologies if somebody already relies on the ABI stability of that function.
* vici: Document the ruby gem and add some simple examplesMartin Willi2014-10-101-0/+58
|
* vici: Add some simple libvici examples to the READMEMartin Willi2014-10-101-2/+116
|
* vici: Document the available vici command and event messagesMartin Willi2014-10-101-1/+509
|
* vici: Use "gem"-assisted vici ruby gem building and installationMartin Willi2014-10-104-1/+29
|
* vici: Add a ruby gem providing a native vici interfaceMartin Willi2014-10-103-0/+586
|
* vici: Return a success result for the clear-creds commandMartin Willi2014-10-101-4/+1
| | | | | Even if the command actually can't fail, this looks more aligned to similar commands.
* vici: Fix message encoding type values in documentationMartin Willi2014-10-101-6/+6
|
* ikev1: Add fragmentation support for Windows peersVolker Rümelin2014-10-103-13/+58
| | | | | | | | I still think ipsec/l2tp with fragmentation support is a useful fallback option in case the Windows IKEv2 connection fails because of fragmentation problems. Tested with Windows XP, 7 and 8.1.
* eap-radius: Add option to set interval for interim accounting updatesTobias Brunner2014-10-101-0/+10
| | | | | | Any interval returned by the RADIUS server in the Access-Accept message overrides the configured interval. But it might be useful if RADIUS is only used for accounting.
* message: Limit maximum number of IKEv2 fragmentsTobias Brunner2014-10-101-1/+11
| | | | | | | | The maximum for IKEv1 is already 255 due to the 8-bit fragment number. With an overhead of 17 bytes (x64) per fragment and a default maximum of 10000 bytes per packet the maximum memory required is 14 kB for a fragmented message.
* packet: Define a global default maximum size for IKE packetsTobias Brunner2014-10-104-18/+4
|
* message: Ensure a minimum fragment lengthTobias Brunner2014-10-101-8/+18
|
* ikev2: Send retransmits using the latest known addressesTobias Brunner2014-10-101-1/+3
| | | | | | | For instance, if a DPD exchange is initiated by the gateway when a mobile client is roaming and it then gets a new IP address and sends an address update via MOBIKE, the DPD retransmits would still be sent to the old address and the SA would eventually get closed.
* ikev2: Send and receive fragmented IKE messagesTobias Brunner2014-10-101-44/+169
| | | | | If a fragmented message is retransmitted only the first packet is passed to the alert() hook.
* ike: IKE_SA may fragment IKEv2 messagesTobias Brunner2014-10-101-1/+1
|
* ike: Do not cache MID of IKEv2 fragmentsTobias Brunner2014-10-101-2/+3
| | | | | This fails if there are unencrypted payloads before an encrypted fragment payload in the first fragment.
* message: Fragment and reassemble IKEv2 messagesTobias Brunner2014-10-102-133/+366
|
* message: Handle encrypted fragment payload similar to the encrypted payloadTobias Brunner2014-10-101-16/+91
|
* ikev2: Add encrypted fragment payloadTobias Brunner2014-10-105-12/+455
|
* encrypted_payload: Encrypted payload can be constructed from plaintextTobias Brunner2014-10-102-0/+38
|
* encrypted_payload: Expose generate() to generate the plaintextTobias Brunner2014-10-102-1/+17
|
* encrypted_payload: Extract some utility functionsTobias Brunner2014-10-101-74/+110
|
* message: Split generate() in multiple functionsTobias Brunner2014-10-101-67/+122
|
* ikev2: Negotiate support for IKEv2 fragmentationTobias Brunner2014-10-102-1/+24
|
* ikev2: Add notify for IKEv2 fragmentationTobias Brunner2014-10-102-7/+15
|
* ikev1: Move defragmentation to message_tTobias Brunner2014-10-103-169/+240
|
* ike: Move fragmentation to ike_sa_tTobias Brunner2014-10-103-62/+94
| | | | | | | | | The message() hook on bus_t is now called exactly once before (plain) and once after fragmenting (!plain), not twice for the complete message and again for each individual fragment, as was the case in earlier iterations. For inbound messages the hook is called once for each fragment (!plain) and twice for the reassembled message.
* message: fragment() generates message and fragments and caches themTobias Brunner2014-10-103-58/+109
|
* message: Make packet argument optional in generate()Tobias Brunner2014-10-101-1/+4
|
* ikev1: Move fragment generation to message_tTobias Brunner2014-10-104-136/+247
|
* ike: Rename encryption_payload to encrypted_payloadTobias Brunner2014-10-109-101/+97
|
* ikev1: Fix handling of UNITY_LOAD_BALANCETobias Brunner2014-10-071-3/+3
| | | | | The re-authentication is now handled within the original IKE_SA if it has not yet been established, so we don't want to destroy it.
* ikev1: Don't queue more than one mode config or XAuth taskTobias Brunner2014-10-071-7/+22
| | | | | | | | At the time we reset an IKE_SA (e.g. when re-authenticating a not yet established SA due to a roaming event) such tasks might already be queued by one of the phase 1 tasks. If the SA is initiated again another task will get queued by the phase 1 task. This results in e.g. multiple mode config requests, which most gateways will have problems with.
* ext-auth: Add an ext-auth plugin invoking an external authorization scriptMartin Willi2014-10-066-0/+492
| | | | Original patch courtesy of Vyronas Tsingaras.
* updown: Use process abstraction to invoke updown scriptMartin Willi2014-10-061-246/+215
|
* stroke: Allow specifying the ipsec.secrets location in strongswan.confShea Levy2014-10-021-2/+10
|
* ikev1: Be more verbose if a peer config would match, but is unusable for ModeMartin Willi2014-09-251-0/+12
|
* ikev2: Reorder task activation for established IKE SAsTobias Brunner2014-09-251-11/+11
| | | | We now prefer MOBIKE tasks over delete tasks then the rest.
* Revert "ikev2: Insert MOBIKE tasks at the front of the queue"Tobias Brunner2014-09-251-6/+1
| | | | | | | | This reverts commit 3293d146289d7c05e6c6089ae1f7cdbcea378e63. The position of tasks in the queue does not actually determine the order in which they are activated. Instead this is determined by the statements in task_manager_v2_t.initiate().
* plugin-loader: Support a reload() callback for static featuresMartin Willi2014-09-221-1/+1
|
* vici: Add a command to reload strongswan.confMartin Willi2014-09-221-0/+12
|
* encoding: Accept all exchange types for non IKEv1/IKEv2 major versionsMartin Willi2014-09-221-5/+11
|
* ikev2: Don't treat initial messages as MOBIKE exchangesTobias Brunner2014-09-161-6/+9
| | | | | The MOBIKE task is active during the initial exchanges but we don't want to treat them as actual MOBIKE exchanges (i.e. there is no path probing).
* ikev1: Don't cache last block of INFORMATIONAL messages as IVTobias Brunner2014-09-121-2/+2
| | | | | | | | | We don't expect a response with the same MID, but apparently some devices (e.g. FRITZ!Box) do that for DPDs, while still treating the response as a new exchange. By storing the last message block as IV we can't decrypt the first block of such a response. Fixes #661.
* ikev1: Log IV when encrypting messagesTobias Brunner2014-09-121-0/+1
|
* ikev1: Skip unusable IPComp proposalsTobias Brunner2014-09-121-1/+1
| | | | Fixes #661.
* ikev1: Properly handle different proposal numbering schemesTobias Brunner2014-09-121-5/+10
| | | | | | | | | | | | | | | | | | While the examples in RFC 2408 show proposal numbers starting at 1 and increasing by one for each subsequent proposal this is not mandatory. Actually, IKEv1 proposals may start at any number, the only requirement is that the proposal numbers increase monotonically they don't have to do so consecutively. Most implementations follow the examples and start numbering at 1 (charon, racoon, Shrew, Cisco, Windows XP, FRITZ!Box) but pluto was one of the implementations that started with 0 and there might be others out there. The previous assumption that implementations always start numbering proposals at 0 caused problems with clients that start numbering with 1 and whose first proposal consists of multiple protocols (e.g. ESP+IPComp). Fixes #661.
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-28 05:07:06 +0000