after the test setup survived the night (i dont know if there were
problems during the night, but if there where, they self-healed, which
is almost as good.) this morning the there were again several hosts
without and SA in ESTABLISHED state (according to ipsec statusall).
it centered around
On Wed, May 25, 2011 at 8:49 AM, Andreas Schuldei
schuldei+strongs...@spotify.com wrote:
now i uploaded new logs from taylor and aldona. the two dropped their
SA sometimes after 2011-05-24T21:48:21 (that is the last good SA
negotiation i can see in the logs) and didnt manage to establish a new
On Tue, May 24, 2011 at 8:48 AM, Andreas Schuldei
schuldei+strongs...@spotify.com wrote:
On Mon, May 23, 2011 at 11:44 PM, Andreas Steffen
andreas.stef...@strongswan.org wrote:
Hello Andreas,
debugging these many connections might be easier using the
condensed /var/log/auth.log which has the
seem to be experiencing problems with charon in strongswan 4.4.1.
One problem is that charon sometimes failes to reinitiate SAs once
they expire. I set up a testbed with 17 hosts to reproduce and track
down the issue, as it takes some time for it to manifest.
since every host has several
/taylor.sto.spotify.net-charon.log.gz
On Mon, May 23, 2011 at 2:46 PM, Andreas Schuldei
schuldei+strongs...@spotify.com wrote:
hi!
I seem to be experiencing problems with charon in strongswan 4.4.1.
One problem is that charon sometimes failes to reinitiate SAs once
they expire. I set up a testbed
, Andreas Schuldei
schuldei+strongs...@spotify.com wrote:
hi!
I seem to be experiencing problems with charon in strongswan 4.4.1.
One problem is that charon sometimes failes to reinitiate SAs once
they expire. I set up a testbed with 17 hosts to reproduce and track
down the issue, as it takes
