On Mon, 21 Jan 2019 at 15:53, D. Hugh Redelmeier wrote:
>
> | From: Andrew Cagney
>
> | While chunk_t is intended for
> | bytes and shunk_t is intended for characters, they do both provide
> | pointer+length abstractions. This begs the question: should they be
> | merged
This came up in an offline discussion. While chunk_t is intended for
bytes and shunk_t is intended for characters, they do both provide
pointer+length abstractions. This begs the question: should they be
merged? It turns out that they have a critical difference:
- chunk_t points at writable
Picking up an offline discussion.
Long ago the domain structure looked like:
base - the initial OS install
east,west,nic,... cloned from base
it had several problems:
- rebuilding base was exceptionally unreliable, network intensive, and
failures were non-obvious
- only one OS was allowed
-
On Sat, 19 Jan 2019 at 03:51, D. Hugh Redelmeier wrote:
>
> | From: Andrew Cagney
>
> | I'm sure this has come up before - the discussion concluded that a
> | cast within a static initializer probably isn't technically static.
>
> A compound literal starts with w
Hugh,
I'm sure this has come up before - the discussion concluded that a
cast within a static initializer probably isn't technically static.
Through trial and error (read, being repeatedly pinged for the same
mistake on IRC cf eb3ba97984910933b3ce9ff3155c2932b48597a0), I've
found the following
On Fri, 4 Jan 2019 at 21:57, D. Hugh Redelmeier wrote:
>
> | From: Andrew Cagney
> | Date: Thu, 3 Jan 2019 00:03:48 -0500
>
> sorry for the slow response.
>
>
> | On Wed, 2 Jan 2019 at 15:55, D. Hugh Redelmeier
> wrote:| >
> | > commit 20f4002247ba4540cdc3
On Thu, 3 Jan 2019 at 10:18, Paul Wouters wrote:
On Thu, 3 Jan 2019, Andrew Cagney wrote:
pluto: rename and remodularize emit_v2N*
Why? We had emit_v2V() emit_v2N() emit_v2UNKNOWN() et.al.,
now we don't?
The goal was to be able to pass a struct as well so we don't have to
build
On Thu, 3 Jan 2019 at 10:12, Paul Wouters wrote:
>
> On Thu, 3 Jan 2019, Andrew Cagney wrote:
>
> > While fixing this is straight forward - a function to format the pair
> > - there is an edge case (isn't there always). Consider this log line:
> >
> > initiat
Currently endpoints are formatted as:
ADDRESS:PORT
vis:
1::1:500
1.0.0.1:500
but for IPv6 the correct format is
[ADDRESS]:PORT
vis:
[1::1]:500
While fixing this is straight forward - a function to format the pair
- there is an edge case (isn't there always). Consider this
On Wed, 2 Jan 2019 at 15:55, D. Hugh Redelmeier wrote:
>
> New commits:
> commit 20f4002247ba4540cdc3b4ebe6f7c73828682649
> Author: D. Hugh Redelmeier
> Date: Wed Jan 2 15:54:08 2019 -0500
>
> pluto: rename and remodularize emit_v2N*
Why? We had emit_v2V() emit_v2N() emit_v2UNKNOWN()
Yea, known bug. I noticed rekeying DH wasn't tested so Paul tested it :-)
Somewhere on a todo - I'm pretty sure that is the first of a number of issues.
On Wed, 2 Jan 2019 at 02:50, D. Hugh Redelmeier wrote:
>
> I'm testing some changes. I got a core on east. It doesn't look related
> to my
On Thu, 27 Dec 2018 at 23:56, D. Hugh Redelmeier wrote:
>
> I write libreswan code on a machine that isn't set up to run libreswan.
> I've always used "make base" to compile the code to see what the compiler
> dislikes.
>
> Recently, "make base" fails, after building everything (I think):
>
>
On Wed, 26 Dec 2018 at 14:38, Paul Wouters wrote:
>
> New commits:
> commit 2232f43c8523d46db4b12a06090c8bbbf94481b2
> Author: Paul Wouters
> Date: Wed Dec 26 14:37:51 2018 -0500
>
> Revert "testing: delete some stray ikev2=never lines"
>
> This reverts commit
On Sun, 23 Dec 2018 at 13:38, Paul Wouters wrote:
>
> On Sun, 23 Dec 2018, Andrew Cagney wrote:
>
> > Do you have this commit?
>
> Yes. I have yesterday's tree on vpn.nohats.ca.
>
> Paul
>
> > commit 069f2ef7fc27183d94da64d778ca395171d5a843
> > Author: A
Do you have this commit?
commit 069f2ef7fc27183d94da64d778ca395171d5a843
Author: Andrew Cagney
Date: Tue Nov 27 21:01:17 2018 -0500
ikev2: ISAKMP_v2_{SA_INIT,AUTH} -> ISAKMP_v2_IKE_{SA_INIT,AUTH}
Use names in RFC 7296.
Both lswlog_enum_short() and enum_short_name() call strip_pre
Just because the RFC states that critical shouldn't be set in a reply,
that isn't reason for removing our ability to do it and on a
per-notify basis - after all that is what fuzz testing is all about.
On Fri, 21 Dec 2018 at 11:35, Paul Wouters wrote:
>
> New commits:
> commit
On Tue, 18 Dec 2018 at 21:04, D. Hugh Redelmeier wrote:
>
> I ran the following as user "build":
>
> make kvm-purge &&
> make kvm-install &&
> make kvm-check KVM_TESTS=" testing/pluto/certoe-01-whack"
>
> It failed:
> qemu-img convert \
>
We had an off list discussion ...
On Tue, 27 Nov 2018 at 08:23, Paul Wouters wrote:
>
> On Fri, 23 Nov 2018, Andrew Cagney wrote:
>
> > Time to paint a boat shed. These are my suggestions:
> >
> > base: it replaces "all"
> > crypt: anything t
(do not try this at home)
Something, in the current set of updates for fedora 28 is causing
pluto to run out of memory
- on testing.libreswan.org, and after a suspicious pause, mprotect()
failed with ENOMEM
- having upgraded a local VM, I'm now seeing it locally - but killed by OOM.
Given the
On Thu, 13 Dec 2018 at 12:47, D. Hugh Redelmeier wrote:
>
> | From: Andrew Cagney
> |
> | As I understand it, the reason for --debug private is to enable a
> | feature where logging included the formation needed to decrypt
> | streams. For instance, ikev2_log_parentSA()
As I understand it, the reason for --debug private is to enable a
feature where logging included the formation needed to decrypt
streams. For instance, ikev2_log_parentSA() was logging a line
containing:
- the IKE SPIs
- the crypto algorithm
- the keying material
that could be fed to
On Sun, 9 Dec 2018 at 12:59, D. Hugh Redelmeier wrote:
>
> I find this macro almost impenetrable.
>
> I think that this is mainly due to it being contorted to make it look like
> the head of a for statement: the code to be iterated over follows the
> macro invocation.
Passing code to a macro is
I think I've restored ikev2-32-nat-rw-rekey's behaviour.
commit 48ab456071939535f9f915622162bbcc056fe2ea (origin/master,
origin/HEAD, master)
Author: Andrew Cagney
Date: Mon Dec 3 11:01:34 2018 -0500
ikev2: schedule "replace" as explicit "rekey" (new event),
"rep
My personal preference would be to just drop the three digit numeric
prefixes, however ...
The internal state numbers are exposed on a public interface vis:
104 "westnet-eastnet" #1: STATE_MAIN_I1: initiate
I think two things should change:
- drop the internal state name from the output vis:
On Thu, 29 Nov 2018 at 13:10, Andrew Cagney wrote:
>
> The key word is 'immediate'. For instance, the next commit cleaned up
> rehash_state() - dropped a no-longer-used parameter and tweaked the
> type of another. I've a nice queue. However each requires careful
> testing
2018 at 17:56, D. Hugh Redelmeier wrote:
>
> | commit 0f76a30e058b89c01417df6b937d928de0a446f6
> | Author: Andrew Cagney
>
> | Avoid immediate code churn by #defining isa_[ir]cookie.
>
> Avoiding code churn has some disadvantages. In general, I would avoid
> avoiding
e state table?
- since the old IKE SA needs replacing, then why not just replace it
> And #4 deletes when retransmit expires, say 60sec default.
> I think keyingtries is to supposed to keep it going, create #5 and so on.
>
> -antony
>
>
> On Mon, Nov 26, 2018 at 10:26:25AM -0
The old code was doing roughly:
#1 established as IKE SA
#2 established as CHILD SA
and then
| handling event EVENT_SA_REPLACE for parent state #1
| #3 schedule initiate IKE Rekey SA none to replace IKE# 1
- can't as network is down but keeps retrying
| inserting event EVENT_SA_EXPIRE,
Time to paint a boat shed. These are my suggestions:
base: it replaces "all"
crypt: anything that might accidentally leak crypto material and,
typically, is TMI
more: stuff that normally isn't helpful
private: crypto compliance stuff that really should be switched to a log flag
I don't think
On Wed, 21 Nov 2018 at 12:45, Antony Antony wrote:
>
> On Wed, Nov 21, 2018 at 10:44:14AM -0500, Andrew Cagney wrote:
> > Yea, two changes:
> >
> > - move the function to demux.[hc]
> > The function, while currently IKEv2 specific, belongs in demux.[hc] as
>
he prefix.
>
> Sent from mobile device
>
> Begin forwarded message:
>
> From: Andrew Cagney
> Date: November 21, 2018 at 08:54:09 GMT+7
> To: swan-com...@lists.libreswan.org
> Subject: [Swan-commit] Changes to ref refs/heads/master
> Reply-To: swan-dev@lists.
On Wed, 21 Nov 2018 at 00:54, Paul Wouters wrote:
>
> On Tue, 20 Nov 2018, Andrew Cagney wrote:
>
> > While it works it heads for an interface explosion as we'll want at least:
> > dbg_crypt()
> > dbg_more()
> > So instead I'll repurpose DBGF() to be
On Thu, 15 Nov 2018 at 10:58, Andrew Cagney wrote:
>
> To move this discussion along a little, I added the function(1):
>
> void dbg(const char *fmt, ...) PRINTF_LIKE(1);
>
> and tried using it in "ikev2_tc.c" vis:
>
> dbg("connection \&q
>name, c->name);
my idea is to next add:
dbg_crypt()
and then dump DBGF().
Andrew
(1) the name is short; coding style dogma has lower case functions,
and upper case macros (the latter has to scream danger!), DBG() was
taken and I don't see this as a performance issue
On W
On Sun, 4 Nov 2018 at 14:44, Andrew Cagney wrote:
> In the logs, first the CP payload's first address 192.0.3.1 is used
> (matching above):
>
> | #2 road-eastnet[1] parsing ISAKMP_NEXT_v2CP payload
> ...
> "road-eastnet"[1] 192.1.2.23 #2: received INTERNAL_IP4_ADD
I'm puzzled by some of pluto's inner workings when running
interop-ikev2-strongswan-39-mobike-responder. On the face of it
(console), everything looks straight forward:
road# ipsec auto --up road-eastnet
...
002 "road-eastnet"[1] 192.1.2.23 #2: received INTERNAL_IP4_ADDRESS 192.0.3.1
002
On Sat, 3 Nov 2018 at 10:40, D. Hugh Redelmeier wrote:
> commit 62a04f2022e4b450d87b0f9eacb1ea7840c2701f
> Author: D. Hugh Redelmeier
> Date: Sat Nov 3 10:28:49 2018 -0400
>
> lib/libswan/asn1.c: eliminate loop from is_printablestring()
>
> A bounded version of strspn(3) would be the
Wouters wrote:
>
> Oh, yes. The initiator MAY send a TSi that is the trigger packet that lead to
> its proposal, which might be 0/0 to 0/0. It allows the responder to narrow to
> the trigger packet
>
> Sent from mobile device
>
> > On Nov 2, 2018, at 09:18, Andrew Cagney
On Thu, 1 Nov 2018 at 17:36, Andrew Cagney wrote:
>
> Reading https://tools.ietf.org/html/rfc7296#section-2.9 I get the
> feeling that the traffic selectors in the TSi/TSr payloads are always
> paired - TSi[n] goes with TSr[n]. The examples, for instance, do
> this. And without
Reading https://tools.ietf.org/html/rfc7296#section-2.9 I get the
feeling that the traffic selectors in the TSi/TSr payloads are always
paired - TSi[n] goes with TSr[n]. The examples, for instance, do
this. And without matching pairs things struggle to make sense.
However, I couldn't find text
On Tue, 23 Oct 2018 at 12:22, Andrew Cagney wrote:
>
> On Tue, 23 Oct 2018 at 04:38, Paul Wouters wrote:
> >
> > On Mon, 22 Oct 2018, Andrew Cagney wrote:
> >
> > > Do we still need to build the klips kernel module while testing (I'm
> > > guessing it is
I've pushed two changes to shrink the VMs:
- swapping is disabled on all VMs - can't see the point
will only kick in after a kvm-demolish
- test (east, west, ...; not the build) RAM reduced to 256m from 512
will kick in after the next build
this should help when trying to run tests in parallel
I've created a page dedicated to improving the testsuite's performance
(time to run) https://libreswan.org/wiki/Test_Suite_-_Performance it
includes stuff like
- boot time, major drag is currently network config at ~7s
- test time, there's a graph
- disk I/O - Hugh?
- memory?
- cpu?
- includes
> Hugh,
>
> thanks for sharing the numbers.
>
> I am curious to see how fast it would be if you used tmpfs.
> and possibly more "test-runners".
>
> KVM_PREFIX= t1. t2. t3. t4.
> KVM_WORKERS=2
> KVM_POOLDIR=/tmp/swanpool
Setting:
KVM_LOCALDIR=/tmp/swanpool
and not KVM_POOLDIR will ...
> to
I also fixed a bug where strongswan wasn't upgraded after a kvm-purge.
On Wed, 24 Oct 2018 at 12:29, Paul Wouters wrote:
>
> On Tue, 23 Oct 2018, Andrew Cagney wrote:
>
> >> I see new messages like
> >> +strongswan 5.6.3 must be installed
>
>
Heads up,
I finally moved the KVM wiki page to https://libreswan.org/wiki/Test_Suite_-_KVM
I've tried to leave the old page with generic stuff about how the
directories are enabled et.al.
The performance stuff is in
https://libreswan.org/wiki/Test_Suite_-_Performance but currently it
is very KVM
On Tue, 23 Oct 2018 at 22:37, D. Hugh Redelmeier wrote:
>
> I see new messages like
> +strongswan 5.6.3 must be installed
>
> +no config named 'westnet-eastnet-ikev1'
>
> Does that mean that I don't have (some part of) Strongswan installed on
> the virtual machines?
>
> Strongswan is covered in
>
On Tue, 23 Oct 2018 at 04:38, Paul Wouters wrote:
>
> On Mon, 22 Oct 2018, Andrew Cagney wrote:
>
> > Do we still need to build the klips kernel module while testing (I'm
> > guessing it is no longer used).
>
> No. In fact, when we compile without USE_KLIPS, building t
The tests seem to have two new failures. For instance in
testing/pluto/ikev2-04-basic-x509-nhelpers0/west.console.txt
- it can't find a certificate
@@ -52,23 +51,18 @@
002 "westnet-eastnet-ikev2" #1: initiating v2 parent SA
133 "westnet-eastnet-ikev2" #1: initiate
133 "westnet-eastnet-ikev2"
On Sun, 21 Oct 2018 at 11:48, D. Hugh Redelmeier wrote:
>
> My previous message to the list described the times taken to run our
> test suite on three different machines.
>
> This one focuses on tests failing due to unexpected IKE retransmissions.
>
> This is so common that I have a procedure for
There are graphs at the bottom of
https://libreswan.org/wiki/Test_Suite that should help
The model is roughly:
boot-workers | test-runners
How many tests did you run in parallel? Per above graphs, testing in
parallel has a far bigger effect then booting in parallel. This is
because time
Do we still need to build the klips kernel module while testing (I'm
guessing it is no longer used).
On Sun, 21 Oct 2018 at 16:23, Paul Wouters wrote:
>
> On Sun, 21 Oct 2018, D. Hugh Redelmeier wrote:
>
> > We no longer test KLIPS. Not only that, the tests have been deleted, not
> > just
I'd strip -Werror=missing-field-initializers from the warning flags when
trying to build with an old compilers.
The " sk = { ... }" variant of that code's been around for some time and
F28's compiler is happy.
On Sat, 20 Oct 2018 at 10:55, Antony Antony wrote:
> it seems only CentOS 7 CentOS 6
On Thu, 18 Oct 2018 at 13:55, Antony Antony wrote:
>
> On Thu, Oct 18, 2018 at 11:00:26AM -0400, Andrew Cagney wrote:
> > In IKEv2, at any point, two Message IDs are being juggled:
> > - the ID of SA's last message request
> > - the ID of SA's last message response
In IKEv2, at any point, two Message IDs are being juggled:
- the ID of SA's last message request
- the ID of SA's last message response
hence, a single .st_msgid which can be traced back to IKEv1 isn't
sufficient. Instead IKEv2 should be using the fields:
/* message ID sequence for
On Wed, 17 Oct 2018 at 09:37, Andrew Cagney wrote:
>
> http://testing.libreswan.org/results/testing/
>
> Turns out we weren't alone:
>
> https://patchwork.kernel.org/patch/10565905/
> https://bugzilla.redhat.com/show_bug.cgi?id=1633267
>
> the fix is also in the 4.
Following on from a discussion last week - this is an overview of all
the different places that messages can be sent.
In the below:
- 'whack at level RC' means send the output to whack with RC encoded
as an NNN prefix - yes those magic prefixes
- 'if connected, whack' means apply some heuristic
http://testing.libreswan.org/results/testing/
Turns out we weren't alone:
https://patchwork.kernel.org/patch/10565905/
https://bugzilla.redhat.com/show_bug.cgi?id=1633267
the fix is also in the 4.18.14(?) kernel.
Thanks to the boot tuneup it is also getting through the tests quicker
(12 vs
with no encryption.
It's just that it never worked.
Should the second line be dropped?
Andrew
On Thu, 4 Oct 2018 at 18:02, Andrew Cagney wrote:
>
> > In the current code NEXT in the first payload is patched up so the
> > second proposal is be visible. Am trying east:phase2=esp
>
> In the current code NEXT in the first payload is patched up so the
> second proposal is be visible. Am trying east:phase2=esp
Yea, that went a little too well :-(
I'm testing the attached to mitigate this new problem, hopefully it
goes ok and can push.
I think getting rid of the extra payload
On Fri, 28 Sep 2018 at 19:02, D. Hugh Redelmeier wrote:
> Current oddity: the payload size is padded before fragmentation and
> after. I imagine that only after is correct.
Kind of. It does the following:
- the SK payload length without integrity and padding is saved
const unsigned int
For instance,
http://testing.libreswan.org/results/testing/v3.22-1007-g86105a8-master/ah-pluto-01/
(its seemingly being doing it for a while):
west.conf has:
conn westnet-eastnet-ah
also=west-east-base
also=westnet
also=eastnet
phase2=ah
but in west's logs I see:
|
On Tue, 2 Oct 2018 at 19:50, Paul Wouters wrote:
>
> On Mon, 1 Oct 2018, Andrew Cagney wrote:
>
> > I'm not seeing these FIPS falures?
>
> Odd.
>
> I see:
>
> [root@west ~]# /usr/bin/fipscheck /usr/local/libexec/ipsec/pluto
> [root@west ~]# echo $?
> 1
&
On Sun, 30 Sep 2018 at 19:33, Paul Wouters wrote:
> #all failing to show keys :(
> ikev2-55-ipseckey-01
> ikev2-55-ipseckey-02
> ikev2-55-ipseckey-03
> ikev2-55-ipseckey-04
> ikev2-55-ipseckey-05
> ikev2-55-ipseckey-06
> ikev2-55-ipseckey-08
I think that's because nic never creates them. An
I'm not seeing these FIPS falures?
On Sun, 30 Sep 2018 at 19:33, Paul Wouters wrote:
> #FIPS check fialing?
> algparse-01
> algparse-02-fips
> #FIPS startup failures
> fips-03-ikev1-md5
> fips-04-ikev2-md5
> fips-06-ikev1-3des-sha1
> fips-07-ikev2-3des-sha256
> fips-09-ikev2-gcm
>
On Sat, 29 Sep 2018 at 16:29, Andrew Cagney wrote:
>
> FYI, I'm considering a second tweak: While not necessary, it would
> prevent some unnecessary decryption.
>
> Instead of only saving the incoming packet when the current state has
> the reply flag set; add an .st_drop_
On Mon, 1 Oct 2018 at 10:08, Andrew Cagney wrote:
>
> On Sun, 30 Sep 2018 at 15:52, D. Hugh Redelmeier wrote:
> >
> > Tuomo just committed 8db3582c4cb021ce762c9832a5314d28018f10aa:
> > addr_lookup.c: fix coding style
> >
> > These changed indentati
On Sun, 30 Sep 2018 at 15:52, D. Hugh Redelmeier wrote:
>
> Tuomo just committed 8db3582c4cb021ce762c9832a5314d28018f10aa:
> addr_lookup.c: fix coding style
>
> These changed indentations of IF statements that were split across lines.
>
> For example:
> @@ -181,7 +181,7 @@ static ssize_t
.
That would hopefully be conservative enough to not be screwed by xauth
exchanges reversing the initiator / responder polarity with
back-to-back packets.
-
On Fri, 28 Sep 2018 at 17:53, Andrew Cagney wrote:
>
> I pushed a change that should stop IKEv1 responding when the decrypted
> packet has
On Fri, 28 Sep 2018 at 19:02, D. Hugh Redelmeier wrote:
> These previously existing functions are used four times in
> ikev2_send.c. Why were they not used in ikev2_parent.c too?
Being conservative. Come up with an interface, try it on new or
replaced code (here encrypted notifies), push it,
I pushed a change that should stop IKEv1 responding when the decrypted
packet has problems (but hasn't been verified).
It seems to fix the test case.
On Fri, 28 Sep 2018 at 12:45, Andrew Cagney wrote:
>
> On Fri, 28 Sep 2018 at 12:03, Paul Wouters wrote:
> >
> > On Fri, 2
Er, don't we already have functions to boilerplate at least SK payloads?
typedef struct v2sk_payload {
struct ike_sa *ike;
pb_stream pbs;
/* pointers into payload buffer (not .payload) */
uint8_t *iv;
uint8_t *cleartext; /* where cleartext starts */
uint8_t *integrity;
}
On Fri, 28 Sep 2018 at 12:03, Paul Wouters wrote:
>
> On Fri, 28 Sep 2018, Andrew Cagney wrote:
>
> > with the above two applied, here's what's going wrong (other than it's
> > IKEv1 and we're stuffed)?
> >
> > - since the IKEv1 initiator is in STATE_MAIN_I4 th
hed and
> therefor a retransmit.
Paul did some triage and, indeed, traced it back to:
commit 49cfd21870994d1afc038ecd0830c9ad0a14e6d1
Author: Andrew Cagney
Date: Tue May 29 09:24:49 2018 -0400
ikev1 retransmits: only save the received packet when responding
Should eliminate problems such
l (I really have my doubts, IKEv1 and IKEv2 are managing to
generate these substructures just fine); it is orthogonal to the
next-payload chain.
On Wed, 26 Sep 2018 at 13:44, Andrew Cagney wrote:
>
> On Mon, 24 Sep 2018 at 00:44, D. Hugh Redelmeier wrote:
>
> > Some problems ar
A status update ...
On Tue, 25 Sep 2018 at 10:25, Andrew Cagney wrote:
> So what can be done? Several changes to the framework (I assume we
> don't want to disable electric fence) are:
>
> - on the theory that the HOST's KVM is too old, upgrade testing to
> something more recent,
On Mon, 24 Sep 2018 at 00:44, D. Hugh Redelmeier wrote:
> Some problems are created by underdocumented designs. For example,
> when you implemented NP backpatching, it appears that you didn't know
> about the tree-structure-in-time of the PBSes. Backpatching code that
> reflected that is
Here's a simplistic breakdown of why
http://testing.libreswan.org/results/testing/ is having bad results:
electric fence +160:
from previous analysis when using f22 we know that that electric fence
makes crypto slower triggering timeouts; with f28 it seems to be a lot
worse
f28 on testing(f22)
On Sat, 22 Sep 2018 at 14:34, D. Hugh Redelmeier wrote:
>
> since libreswan 3.26 + 83e33a69b27f6c5d5f4aff2fc94a1357d5126ed1 I
> get these syslog messages very often:
> http://paste.debian.net/hidden/a99f6aa9/ - that's annoying ;)
>
> I've just pushed fa004e7d4b83fbeaa8d0f6d8430a96aed97a97b9
>
On Sat, 22 Sep 2018 at 14:19, D. Hugh Redelmeier wrote:
>
> | From: Andrew Cagney
>
> | > There are no good exception mechnisms.
> |
> | There is, its called abort(). Part of libreswan's start up is dealing
> | with any mess from a previous abort.
>
> Abort
On Sat, 22 Sep 2018 at 12:07, D. Hugh Redelmeier wrote:
>
> | From: Andrew Cagney
>
> | I'm wondering why we bother to write code like:
> |
> | return ikev1_out_generic(np, _keyex_desc, outs, ) &&
> | out_zero(g->len, , "fake g^x") &a
> | PS: I'm tempted to make the HOW a float so 'times' can also be sent
> | over, later ...
>
> PLEASE: NO TO FLOATS. They are the wrong abstraction.
(sarcasm) You mean hack the code so the other end has to distinguish
between deltatime_t and unsigned? Next thing we know we'll be
changing the
I've posted test results for post 3.26 on
http://testing.libreswan.org/results/testing/
Is it good enough to switch our guests to f28?
Andrew
___
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev
FYI,
This has been enabled.
Andrew
On Mon, 27 Aug 2018 at 16:32, Paul Wouters wrote:
>
> On Thu, 23 Aug 2018, Andrew Cagney wrote:
>
> > $ grep '(null)' testing/pluto/*/OUTPUT/*.console.txt | cut -d/ -f3,5-
> > addconn-02/east.console.txt:conn: "test" m
Traceback (most recent call last):
File "./dist_certs.py", line 661, in
main()
File "./dist_certs.py", line 655, in main
pexpect.run("%s/strongswan-ec-gen.sh"%outdir)
File "/usr/lib/python2.7/site-packages/pexpect/__init__.py", line 213, in run
env=env, _spawn=spawn)
File
I've just pushed the change:
web: use the full SHA as the .json file name
which changes the name of each json commit file, which was based on
the abbreviated commit hash, from either (yes either!):
RESULTS/commits/54f6cd6.json
RESULTS/commits/54f6cd6e8.json
to the canonical:
I've pushed the change for 'pluto'.
I didn't touch the kind of isolated directories:
lib/libcrypt/ - serpent and twofish - build problems
linux/ - shared with klips - requires thorougher testing
On Thu, 6 Sep 2018 at 11:57, D. Hugh Redelmeier wrote:
>
> | From: Andrew Cagney
>
&
Is there any existing code in libreswan (or a library) for
constructing DERs? The ASN.1 construct:
* Dss-Sig-Value ::= SEQUENCE {
* r INTEGER,
* s INTEGER
* }
needs to be output perfectly (if it isn't authentication fails).
Do we have
On Fri, 7 Sep 2018 at 08:54, D. Hugh Redelmeier wrote:
>
> IKEv1 packet.h routines will fill in the next payload field automatically.
> This was done by extending what Andrew had already done for v2.
thanks
> It is intended for this to be set up correctly but removing the
> pre-computing code
As in:
/home/libreswan/wip-alg/include/lset.h:32:31: error: left shift count
>= width of type [-Werror=shift-count-overflow]
#define LELEM(opt) ((lset_t)1 << (opt))
^
/home/libreswan/wip-alg/include/lset.h:34:31: note: in definition of
macro ‘LRANGES’
#define
On Wed, 5 Sep 2018 at 23:54, D. Hugh Redelmeier wrote:
>
>
> | commit 8ae190998e1aa32aa8903d541b7c0365934d4735
> | Author: Andrew Cagney
> | Date: Wed Sep 5 17:16:17 2018 -0400
> |
> | bsd: sed -i -e 's/u_int\([0-9]*\)_t/uint\1_t/g' -e
> 's/u_int\([^0-9]\)/unsig
On Thu, 6 Sep 2018 at 01:00, D. Hugh Redelmeier wrote:
>
> DHR, fyi, 6d0aea9400 isn't portable
> the timeval fields are long long on 32-bit machines
>
> Thanks. You are right about the tv_sec field.
>
> I happened to look at select(2) when I wrote 6d0aea9400. It says that the
> fields are
My f28.nic vm freed up so I could capture the below. The failure is
now
http://testing.libreswan.org/results/v3.25-526-g477b6a5-f28/dnsoe-01/OUTPUT/nic.console.diff
[root@nic dnsoe-01]# systemctl status nsd-keygen.service
● nsd-keygen.service - NSD Control Key And Certificate Generator
2-leak-01-db_v2_prop_conj/east.pluto.log:"westnet-eastnet-ipv4-psk-ikev2"
#1: IKE SA responder matching remote ESP/AH proposals responder SA
processing returned (null)
which looks like something for me to fix.
On Thu, 10 May 2018 at 10:49, Andrew Cagney wrote:
>
> Pluto, on occasi
(I screwed up and accidentally replied off list, I've expanded my initial reply)
On Tue, 21 Aug 2018 at 14:10, D. Hugh Redelmeier wrote:
>
> I was reading this function (but not looking at the contexts from which it
> may be called)
>
> What is the meaning of proposal->integ != NULL?
> Is it
On Tue, 21 Aug 2018 at 20:16, D. Hugh Redelmeier wrote:
> - a smattering of tests require retransmission of some message, and if
> that gets logged on the console, the test is considered to have failed
>
> These failures are mostly unrepeatable. So running the test again
> usually succeeds.
>
nat-double-01
2005-11-02 7836dfce2 nat-transport-03
2007-05-18 0c2c1b5af whackrecord-01
On Wed, 15 Aug 2018 at 15:50, Paul Wouters wrote:
>
> On Tue, 14 Aug 2018, Andrew Cagney wrote:
>
> >>> Paul Wouters
> >>>
> >>> 2008-02-17 0239d2c4a bad-nexthop-01
To clarify one thing, there are three separators involved:
'-' separates algorithms within a proposal
';' within a proposal, separates DH from the rest (kind of legacy)
',' separates proposals
On Sun, 19 Aug 2018 at 14:57, Paul Wouters wrote:
>
> On Sun, 19 Aug 2018, Andrew Cagney
(While the existing parser is no where near supporting this, the
impair algparse option, does tickle some of the problems we'll
encounter if we were to try implementing this, here are my notes).
Currently it isn't possible to descripe a single proposal with
multiple algorithms. This both limits
BTW, this doesn't break new ground. It just adds more colour to our
already rainbow coloured bike shed. For instance v2_notification,
ISAKMP_v2_SA_INIT (how messed up is that one), and of course
ikev[12]_*.[hc] containing ikev[12]_*() code.
Lots of colour is good.
On Sun, 19 Aug 2018 at 12:34,
601 - 700 of 1126 matches
Mail list logo
