On 28.04.2017 22:36, Michael Tipton wrote:
However I am seeing some weird behavior, I am seeing another request for
the anonymous user that is accepted after the actual user is sent the
first accept. Any ideas why this maybe happening?
The first Access-Accept is for the inner authentication that is
tunnelled within TTLS. Once the inner authentication finishes, then
there are the final handshakes and the actual Access-Accept is sent to
the RADIUS client. This is the message that has the MS-MPPE-*-Key
The other issue I am having is that the accounting data
(start/stop/alive) are logging as the anonymous username. I have tried
using EAPAnonymous %0 option, I've tried adding in just a accounting
handler, I've tried the eap_anon_hook.pl <http://eap_anon_hook.pl>, as
well as the eap_acct_username.pl <http://eap_acct_username.pl> scripts
to no avail.
You could try returning Class with Access-Accept. The client should use
add Class with the returned value to all accounting messages it sends.
This is likely easier than using SQL. I think we'll need to change the
sample configuration files to hint this as a solution.
My Access-Accepts are sending the correct username, however, it appears
the device is not using that as some do when it is passed the right
username in the access-accept for the rest of accounting.
You are correct that the device should do it:
Support for Class is likely to be better, so I'd try that next instead
of hooks or other solutions:
You could also consider adding AccountingHandled flag parameter to the
accounting Handler. Now the client device is resending its accounting
requests since Radiator is not responding to them.
I have attached my handlers, as well as a level 6 trace debug. Any help
would be greatly appreciated!
Please let us know how it goes.
radiator mailing list