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 attributes.

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.

Heikki Vatiainen
radiator mailing list

Reply via email to