On Wed, Jun 06, 2012 at 03:56:54PM -0300, Sergio Belkin wrote:
> Good idea, I've tried appending  %{EAP-Type) that to detail.log but
> sending nothing
> eg:
> 
> auth-detail-AP-XXX-DEFAULT--20120606
> 
> Between "-" and "-" is nothing (Neither TTLS nor PEAP appears)

You've not really explained what you've done.

However, I *guess* that you have added %{EAP-Type} to the filename
(detailfile) in the detail config.

Look, though, where detail is getting called, and where eap is
called, in the authorize section. It goes in order. The eap module
sets EAP-Type, detail is called before.

So you need to call the log after eap. But the gotcha is that eap
will short circuit the return in the challenges, so you won't call
the detail module if you put it after eap.

I'd suggest you let all the incoming logs go to a single location
where they are, then you add a new detail (or linelog) module to
post-auth. That can use %{EAP-Type}, as it's *after* EAP has
happened.

Alternatively, you can use my other suggestion anywhere you like.
If you pick data out of EAP-Message yourself, you get to do what
you want with it (and keep the shards when it shatters).

Totally untested unlang.

if (%{EAP-Message} =~ /^0x........19/) {
  detail_log_peap
}
elsif (%{EAP-Message} =~ /^0x........15/) {
  detail_log_ttls
}
else {
  detail_log_other
}

Note that things *will* hit detail_log_other. EAP Identity, for
instance, before the eap type has been agreed. If you do this in
the inner server, be prepared for unexpectedness. In short,
understand EAP first.

I just chuck the raw data out with detail and leave it be. The
useful stuff is pristinely formatted with gentle loving care by
the linelog module, where it sits in a nice greppable format for
me. One log entry, in post-auth, after the useful stuff happened.
Any more detail needed? Just go to the dirty detail log and dig it
out. Happens so rarely it wouldn't matter if it was in binary
format and had to be read with a hex editor in Windows...


> > Add 'preprocess' to the top of the authorize{} section in your
> > inner-tunnel-peap / inner-tunnel files. That's the module that
> > checks huntgroups.
> 
> Thanks guys it dit it! I just realize that modules must be appended in
> inner-tunnel files to load them :)

Yeah, that's why it's called a virtual server. It's treated the
same as the default server, the flow is the same. No module
listed there? It doesn't happen.

Matthew


-- 
Matthew Newton, Ph.D. <m...@le.ac.uk>

Systems Architect (UNIX and Networks), Network Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <ith...@le.ac.uk>
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to