the WARNING message when client doesn't respond any more...
... that went into 2.1.10 is a great piece of functionality, and can help a lot in debugging. However, it would be even more useful if this information made it into radius.log (since otherwise it won't surface unless in debugging mode), sth like: Auth: Login ABORTED: [userfoo] (from client bar-v4 port 19181) ceased EAP conversation prematurely. Our helpdesk (and we're certainly not the only ones) would appreciate if we could easily figure out and say: "Your client software apparently doesn't like us. Go away and configure it according to the documentation!" Of course the information in the middle of an EAP session is incomplete (no inner identity!), but if at least the outer identity and Calling-Station-Id could be logged alongside, that would be great. (I guess it's asked too much get a handle for this situation and get the ability to execute custom SQL statements for that... right?) Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
Stefan Winter wrote:
... that went into 2.1.10 is a great piece of functionality, and can help a lot in debugging.
However, it would be even more useful if this information made it into radius.log (since otherwise it won't surface unless in debugging mode), sth like:
Auth: Login ABORTED: [userfoo] (from client bar-v4 port 19181) ceased EAP conversation prematurely.
Sure. Send a patch. :) The issue is that it's annoying to check this for every single EAP conversation.
Our helpdesk (and we're certainly not the only ones) would appreciate if we could easily figure out and say: "Your client software apparently doesn't like us. Go away and configure it according to the documentation!" Of course the information in the middle of an EAP session is incomplete (no inner identity!), but if at least the outer identity and Calling-Station-Id could be logged alongside, that would be great.
Sure.
(I guess it's asked too much get a handle for this situation and get the ability to execute custom SQL statements for that... right?)
That would require a lot more work. The message appears at a time when the request is marked "done", and is no longer being processed. Alan DeKk.
Hi,
Sure. Send a patch. :)
I'd love to. Added a radlog() for various levels, but it still only goes shows up in the debug output. Even L_INFO, L_ERR, even L_CONS - "something" prevents them from being dispatched to radius.log. They all show up with -X though. I've checked the code in rlm_sql - which I know gets into radius.log with its L_INFO, and I don't see what I'm doing wrong/different from those. The only obvious difference is that rlm_eap/mem.c check_handler is a static function, while the functions in rlm_eap.c are not. Maybe someone else feels like digging deeper...
The issue is that it's annoying to check this for every single EAP conversation.
If your core business is getting EAP authentications right for a large user base, that annoyance seems acceptable ;-)
(I guess it's asked too much get a handle for this situation and get the ability to execute custom SQL statements for that... right?) That would require a lot more work. The message appears at a time when the request is marked "done", and is no longer being processed.
Thought that much. It's not vitally important. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
Stefan Winter wrote:
I'd love to. Added a radlog() for various levels, but it still only goes shows up in the debug output.
:) See rlm_eap.c && mem.c. The references to "handler_tree" are protected by an "if (fr_debug_flag)". Fix that "if" (or delete it), and it should work. Alan DeKok.
participants (2)
-
Alan DeKok -
Stefan Winter