Hi Heikki,
just read the patches changelog, the EAP related things sound good!
I'll get back to you when I got a change to update our 802.1x Radius
servers to it.
Thanks, Alex
On 2017-04-20 10:26, Heikki Vatiainen wrote:
On 24.1.2017 14.58, Hartmaier Alexander wrote:
On 2017-01-24 12:57, He
On 24.1.2017 14.58, Hartmaier Alexander wrote:
On 2017-01-24 12:57, Heikki Vatiainen wrote:
I think we'll need to think about an interface for this. This
discussion has been useful to understanding the custom use cases, so
rather than moving it, I' say it's better to provide a documented call
On 2017-01-24 12:57, Heikki Vatiainen wrote:
On 24.1.2017 13.39, Hartmaier Alexander wrote:
Could you move the storage of reply attributes into the resume context
to a point after PostAuthHook is called so this isn't required?
I think we'll need to think about an interface for this. This
disc
On 24.1.2017 13.39, Hartmaier Alexander wrote:
Could you move the storage of reply attributes into the resume context
to a point after PostAuthHook is called so this isn't required?
I think we'll need to think about an interface for this. This discussion
has been useful to understanding the c
On 2017-01-24 12:11, Heikki Vatiainen wrote:
On 24.1.2017 12.18, Hartmaier Alexander wrote:
Yes, that's correct. The information saved for resume has the same
lifetime. Also, if it happens that a session is resumed by TLS layer
but Radiator has no information about the resumed session, the
auth
On 24.1.2017 12.18, Hartmaier Alexander wrote:
Yes, that's correct. The information saved for resume has the same
lifetime. Also, if it happens that a session is resumed by TLS layer
but Radiator has no information about the resumed session, the
authentication will fail.
I can't confirm that be
Hi Heikki,
On 2017-01-23 14:35, Heikki Vatiainen wrote:
On 20.1.2017 11.33, Hartmaier Alexander wrote:
Can you confirm that Radiator stores the information saved by
eap_save_resume_context for the same duration as OpenSSL is told to
do so?
In Radius/TLS.pm line 818 it looks like EAPTLS_Sessio
On 20.1.2017 11.33, Hartmaier Alexander wrote:
Can you confirm that Radiator stores the information saved by
eap_save_resume_context for the same duration as OpenSSL is told to do so?
In Radius/TLS.pm line 818 it looks like EAPTLS_SessionResumptionLimit is
used to set this timeout too.
Yes, th
On 2017-01-19 16:30, Heikki Vatiainen wrote:
On 19.1.2017 13.00, Hartmaier Alexander wrote:
we still have an issue with session resumption where the EAP context
doesn't contain the custom variables we've stored in the
EAPTLS_CertificateVerifyHook of the initial, non-resumed,
authentication.
I
On 19.1.2017 13.00, Hartmaier Alexander wrote:
we still have an issue with session resumption where the EAP context
doesn't contain the custom variables we've stored in the
EAPTLS_CertificateVerifyHook of the initial, non-resumed, authentication.
I hope I can clarify this. Please note that EAP
Hi,
we still have an issue with session resumption where the EAP context
doesn't contain the custom variables we've stored in the
EAPTLS_CertificateVerifyHook of the initial, non-resumed, authentication.
How does EAPContextTimeout, which has been reduced from 1000 to 120
seconds in version 4
On 2016-12-16 12:40, Heikki Vatiainen wrote:
On 16.12.2016 11.46, Hartmaier Alexander wrote:
Sadly the sh** didn't stop there, OpenSSL segfaults when
Net::SSLeay::session_reused gets passed an undefined value:
For Net::SSLeay this is just a pass through call to OpenSSL's
respective function
On 16.12.2016 11.46, Hartmaier Alexander wrote:
Sadly the sh** didn't stop there, OpenSSL segfaults when
Net::SSLeay::session_reused gets passed an undefined value:
For Net::SSLeay this is just a pass through call to OpenSSL's respective
function. I think the caller is responsible for not han
On 2016-12-15 13:46, Heikki Vatiainen wrote:
On 15.12.2016 14.04, Hartmaier Alexander wrote:
If you get context from $p, it does not matter if, for example,
EAP_UseState was enabled or note. It's easier and more reliable to get
it from $p.
I've removed EAP_UseState from our config since every
On 15.12.2016 14.04, Hartmaier Alexander wrote:
If you get context from $p, it does not matter if, for example,
EAP_UseState was enabled or note. It's easier and more reliable to get
it from $p.
I've removed EAP_UseState from our config since everything works as
before. Can the nested auth of P
On 2016-12-13 14:45, Heikki Vatiainen wrote:
On 13.12.2016 12.32, Hartmaier Alexander wrote:
I strongly advice to get context like this:
my $context = $p->{EAPContext};
Ok, I've changed our hooks to use this again like before, seems to not
make a difference both ways.
If you get context from
On 13.12.2016 12.32, Hartmaier Alexander wrote:
I strongly advice to get context like this:
my $context = $p->{EAPContext};
Ok, I've changed our hooks to use this again like before, seems to not
make a difference both ways.
If you get context from $p, it does not matter if, for example,
EAP_
Answers below
On 2016-12-13 07:59, Heikki Vatiainen wrote:
On 1.12.2016 17.02, Hartmaier Alexander wrote:
We're fighting duplicate requests due to slow responses because of
PEAP-TLS many exchanged packets.
Is FarmSize still unusable when enabling EAP_UseState because the EAP
context data isn
On 1.12.2016 17.02, Hartmaier Alexander wrote:
We're fighting duplicate requests due to slow responses because of
PEAP-TLS many exchanged packets.
Is FarmSize still unusable when enabling EAP_UseState because the EAP
context data isn't shared between the forked childs?
This has not changed. E
On 30.11.2016 19.09, Hartmaier Alexander wrote:
Correct me if I'm wrong but can a resumed session every be not accepted?
It's possible. EAP-TLS can check if the user is still available in the
user database or has their account been, for example, removed.
PEAP requires the server and client
On 12.12.2016 17.45, Hartmaier Alexander wrote:
please respond how to:
Hello Alex, I'll reply to your previous messages about these, but I'll
add quick notes below. Sometimes time just flies, I'm sorry for the slow
response.
- log auth vs. session resumption
- handle session resumption i
Hi,
please respond how to:
- log auth vs. session resumption
- handle session resumption in PostAuthHooks
- if the last_reply_attrs don't include the attributes added by a
PostAuthHook
- usability of FarmSize with PEAP-TLS when enabling EAP_UseState
Thanks, Alex
On 2016-12-01 16:02, Har
Hi,
We're fighting duplicate requests due to slow responses because of
PEAP-TLS many exchanged packets.
Is FarmSize still unusable when enabling EAP_UseState because the EAP
context data isn't shared between the forked childs?
Can Gossip be used to share this state between the childs or the
On 30.11.2016 16.34, Petr Adamec wrote:
I have probably the same problem. It sounds like
https://lists.open.com.au/pipermail/radiator/2015-August/020360.html
My solution is to downgrade to 4.16
Hello Petr,
can you see if 'EAPTLS_SessionContextId %u%1' parameter I wrote about
yesterday woul
On 2016-11-30 17:45, Heikki Vatiainen wrote:
On 30.11.2016 18.02, Hartmaier Alexander wrote:
Let me clarify our setup:
EAPTLS_CertificateVerifyHook parses the cert issuer and subject and
populates
$context->{customer} = $customer;
[cut]
Thanks, this clarifies the situation. You need to sa
On 30.11.2016 18.02, Hartmaier Alexander wrote:
Let me clarify our setup:
EAPTLS_CertificateVerifyHook parses the cert issuer and subject and
populates
$context->{customer} = $customer;
[cut]
Thanks, this clarifies the situation. You need to save information
across resumed authentications
On 2016-11-30 16:35, Heikki Vatiainen wrote:
On 30.11.2016 17.21, Hartmaier Alexander wrote:
we only do machine cert authentication. Can I log the SessionContextId
for debugging purposes to really make sure it's not the issue?
This defaults to Handler. In other words, if a full authentication
On 30.11.2016 17.21, Hartmaier Alexander wrote:
we only do machine cert authentication. Can I log the SessionContextId
for debugging purposes to really make sure it's not the issue?
This defaults to Handler. In other words, if a full authentication was
processed by Handler A, the resumption w
Hi Heikki,
we only do machine cert authentication. Can I log the SessionContextId
for debugging purposes to really make sure it's not the issue?
This also happens for smartphones, mainly Apple and Android.
I wonder if the reduced EAPContextTimeout from 1000 to 120 seconds might
cause this when
Hi Petr,
not sure was the problem only started after upgrading to 4.17 which
hasn't been release in 2015 when you reported your issue.
Best regards, Alex
On 2016-11-30 15:34, Petr Adamec wrote:
Hi,
I have probably the same problem. It sounds like
https://lists.open.com.au/pipermail/radiat
On 30.11.2016 16.27, Hartmaier Alexander wrote:
we have random EAP authentication errors since the upgrade to 4.17.
I figured it might have something to do with the EAP session resumption
changes in 4.17.
For tweaking resumption behaviour, can you try adding the parameter
shown below to EAPTL
Hi,
thanks for the quick response!
In the meantime I tried the new EAP_UseState, didn't fix the problem
but also didn't have any negative effect. Do you recommend to already
use it?
Disabling EAP session resumption seems to have fixed the issue
(EAPTLS_SessionResumption 0).
On 2016-11-30 15:
Hello,
> On 30 Nov 2016, at 16:27, Hartmaier Alexander
> wrote:
>
> we have random EAP authentication errors since the upgrade to 4.17.
> I figured it might have something to do with the EAP session resumption
> changes in 4.17.
>
interesting, could you please send a trace 5 debug log for few
Hi,
I have probably the same problem. It sounds like
https://lists.open.com.au/pipermail/radiator/2015-August/020360.html
My solution is to downgrade to 4.16
Best regards
Petr Adamec
Dne 30.11.2016 v 15:27 Hartmaier Alexander napsal(a):
> Hi,
> we have random EAP authentication errors since t
34 matches
Mail list logo
