Hi,

On 25/03/2021 09:51, Ralf Paffrath wrote:
Hi,

I had no Paul's log so I produced my own log.
Happy to send it, Fabian asked it off-list but I'll forward,
On 24 Mar 2021, at 18:09, Fabian Mauchle <fabian.mauchle@switch.ch> wrote:

Hi,

On 24.03.21, 08:49, "Fabian Mauchle" <fabian.mauchle@switch.ch> wrote:
   This first request is implicitly placed in the queue for the dynamic server (before the lookupCommand has even been called).

I have to corret myself here. Seems I've misunderstood that code block, and Pauls log (thanks!) clearly shows this. Reading it the right way, it looks quite intentional, not a bug.

The first request is _not_ placed on the dynamic servers queue.

And therefore it doesn’t break the first authentication. It is important to know that no request is lost and the first conversation is 
going via one fallback path and the next request later on via the dynamic path
In my case, it's a real that is both reachable via the fallback path and the primary path, yet the authentication fails.
But anyway we we will run into trouble. dynamic and fallback servers might include different realm blocks. So for dynamic realms which are not configured on the fallback servers the conversation might results in an Access-Reject for the first request and might results in an Access-Accept only in a second request via dynamic. 
This would break the service.

Well it breaks for me.

I must admit that when Fabian asked for a pointer in the documentation, I don't really have one. I just more or less assumed this is how it worked, because that made sense to me. If you lookup realms dynamically, they may be only reachable via a dynamic path after all. So you're not sending something to fallback if the dynamic path is not resolved yet. And yes that is slow, but noone said dynamic lookups are fast - they aren't in Radiator either. That's why you need carefull tweaking of DNS settings too.

Anyway. I'll just use my workaround,

Regards,
Paul



Best regards,
Ralf

I read that one wrong, it only triggers the dynamic lookup, but the server selection is run again after the new realm structures have been set up. On this second (and any subsequent) passes, the dynamic server is ignored until its connection is established.

On 23.03.21, 13:04, "Paul Dekkers" <paul.dekkers@surf.nl> wrote:
   and whether we can have the dynamic lookup blocking
   for the request?

I will add it as a feature request. However, this might have quite some implications: if the lookup and connection setup is slow, this might block a realm for quite some time.

   That would allow fallback "as documented".

Could you point me to that documentation? (I couldn’t spot it in the manpages; just so I can keep any documentation up to date).

Best regards,
Fabian


_______________________________________________
radsecproxy mailing list -- radsecproxy@lists.nordu.net
To unsubscribe send an email to radsecproxy-leave@lists.nordu.net

-- 
Dipl. Inform. Ralf Paffrath
Phone: Tel.: 030 884299-0 (DFN-GS Berlin: Sekretariat)
Fax: 030 88 42 99 370 | http://www.dfn.de

Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1, D - 10178 Berlin
Vorstand: Prof. Dr. Odej Kao (Vorsitzender) | Dr. Rainer Bockholt | Christian Zens
Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729NZ | USt.-ID. DE 1366/23822