Request is supposed to be proxied to Realm SOMEREALM. Not doing EAP.
Hello, With proxying turned on, when an "outsider" connects to an AP of ours, the debug log shows: ... eap: Request is supposed to be proxied to Realm SOMEREALM. Not doing EAP. [ eap ] = noop ... Conversely, everything in the authorize section that follows: eap { ok = return } is executed for each roundtrip between the client and the remote server; in the case of EAP, that may mean a dozen of DB queries, a dozen of lines logged thru a linelog instance, and so on. Is this the behavior to be expected? (another way to ask: may I assume I didn't err in my config?) TIA, Axel
Axel Luttgens wrote:
With proxying turned on, when an "outsider" connects to an AP of ours, the debug log shows:
... eap: Request is supposed to be proxied to Realm SOMEREALM. Not doing EAP. [ eap ] = noop ...
That's expected.
Conversely, everything in the authorize section that follows:
eap { ok = return }
is executed for each roundtrip between the client and the remote server; in the case of EAP, that may mean a dozen of DB queries, a dozen of lines logged thru a linelog instance, and so on.
Which is how you configured it.
Is this the behavior to be expected?
Yes. EAP uses multiple packet exchanges.
(another way to ask: may I assume I didn't err in my config?)
Put all of the DB lookups into the inner-tunnel virtual server. If you need to use non-EAP authentication methods, you can protect them with an "if" condition: if (!EAP-Message) { # complex DB stuff here } Alan DeKok.
Le 9 sept. 2014 à 15:14, Alan DeKok a écrit :
Axel Luttgens wrote:
[...] Is this the behavior to be expected?
Yes. EAP uses multiple packet exchanges.
In fact, I wasn't surprised by those roundtrips, but by the hardcoded behavior of the eap module: to return a noop in that precise case. After all, it has done "something", by recognizing the request as an EAP one but then taking the decision to not interfere with a subsequent proxy operation; in some sense, it has taken over the request. I was thus wondering whether a noop was the most appropriate return code; on the other hand, I had a doubt, because I could also have induced it myself, by some misconfiguration. But that noop return code is thus expected behavior. And you have even anticipated some subsequent questions I intended to ask. :-)
Put all of the DB lookups into the inner-tunnel virtual server.
Wow, this is indeed a nice way to handle the problem for an EAP-only context! Wondering when I'll finally get sufficiently acquainted with FR for being able to devise such things myself... :-(
If you need to use non-EAP authentication methods, you can protect them with an "if" condition:
if (!EAP-Message) { # complex DB stuff here }
Unfortunately, yes, I'll need non-EAP methods as well. Again, that test based on the absence of an EAP-Message attribute is representative of that kind of simple criterion I am too often looking for... Incidentally, may that "# complex DB stuff here" just be an invocation of the sql module? As in: if (!EAP-Message) { sql } It seems to work, but aren't there some side-effects to be expected? Finally, there's the problem of logging. I need to keep some trace of access requests, but wouldn't be really happy to have 10 lines written to the log for each connection attempt... Which kind of criterion, if any, could be easily used for writing one line per connection only? Many thanks, Axel
It seems to work, but aren't there some side-effects to be expected?
No. Unless you want to use that module at that point in the server for an EAP request.
Finally, there's the problem of logging. I need to keep some trace of access requests, but wouldn't be really happy to have 10 lines written to the log for each connection attempt..
If you want to log every access request then you will get many many lines of log. That's RADIUS. I think you have semantic issues here. Alan -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Le 10 sept. 2014 à 08:40, Alan Buxey a écrit :
It seems to work, but aren't there some side-effects to be expected?
No. Unless you want to use that module at that point in the server for an EAP request.
Indeed, thanks. I'll have to think a bit more about that point.
Finally, there's the problem of logging. I need to keep some trace of access requests, but wouldn't be really happy to have 10 lines written to the log for each connection attempt..
If you want to log every access request then you will get many many lines of log. That's RADIUS. I think you have semantic issues here.
Well... that's why I carefully tried to distinguish "connection attempt" and "access requests", but then my fingers somehow ripped. I should have written: I need to keep some trace of connection attempts, but wouldn't be really happy to have 10 lines written to the log for each of these attempts. Regards, Axel
Axel Luttgens wrote:
In fact, I wasn't surprised by those roundtrips, but by the hardcoded behavior of the eap module: to return a noop in that precise case.
The fact that modules have specific return codes is surprising? Would you expect them to have random return codes? Or to return the same code no matter what happens?
After all, it has done "something", by recognizing the request as an EAP one but then taking the decision to not interfere with a subsequent proxy operation; in some sense, it has taken over the request. I was thus wondering whether a noop was the most appropriate return code; on the other hand, I had a doubt, because I could also have induced it myself, by some misconfiguration.
If you read the eap module configuration, there is *nothing* which says "change the return code". So you *cannot* make it return "noop" by some misconfiguration. It sounds like you think the modules are magic. They're not.
Incidentally, may that "# complex DB stuff here" just be an invocation of the sql module? As in:
It can be whatever you want. i.e. things to do when NOT using EAP. That's sort of what I said.
It seems to work, but aren't there some side-effects to be expected?
There are no magical side-effects. Pretty much all of the server behavior is explicit.
Finally, there's the problem of logging. I need to keep some trace of access requests, but wouldn't be really happy to have 10 lines written to the log for each connection attempt... Which kind of criterion, if any, could be easily used for writing one line per connection only?
See the post-auth section. That's what it's for. And it's documented, too. Alan DeKok.
(This is a first reaction. I'll reply a bit more seriously as soon as I have the opportunity. In the meantime, thanks for re-reading the whole thread and, possibly, the previous ones as well) Le 10 sept. 2014 à 14:08, Alan DeKok a écrit :
Axel Luttgens wrote:
In fact, I wasn't surprised by those roundtrips, but by the hardcoded behavior of the eap module: to return a noop in that precise case.
The fact that modules have specific return codes is surprising?
Yes, of course! When writing a piece of code, I never care of return codes: they are just un-meaningful data returned for the sake of perturbing programmers. No more, no less. I feel sooo good for having my prose so well understood.
Would you expect them to have random return codes?
Try to upgrade your OS, or to ask Google for a precise info; the randomness of the results is more than often somehow perturbing. On the other hand, deliberately add randomness in your code: the user now knows that the random outcome is deliberate, and thus feels much better. And, thanks to the programmer's wisdom and for our relief, entropy is in fact decreasing. So, yes, I clearly wish modules had random return codes.
Or to return the same code no matter what happens?
From the point of view of entropy, that wouldn't be very useful. On the other hand, returning systematically the same code might be reassuring; but then, returning no code at all, as I sure clearly stated in some of my earlier posts, would be faaaar easier: nothing to worry anymore.
After all, it has done "something", by recognizing the request as an EAP one but then taking the decision to not interfere with a subsequent proxy operation; in some sense, it has taken over the request. I was thus wondering whether a noop was the most appropriate return code; on the other hand, I had a doubt, because I could also have induced it myself, by some misconfiguration.
If you read the eap module configuration, there is *nothing* which says "change the return code". So you *cannot* make it return "noop" by some misconfiguration.
Who said I tried to explicitly and specifically change eap module's return code? This isn't possible, since it's a module, hence magical (and random).
It sounds like you think the modules are magic. They're not.
Aren't they magic? I'm feeling sooo disappointed now. You are cheating, aren't you? They *must* be magic. Otherwise, they couldn't be modules.
Incidentally, may that "# complex DB stuff here" just be an invocation of the sql module? As in:
It can be whatever you want. i.e. things to do when NOT using EAP. That's sort of what I said.
Sort of... Do you mean randomness? (sorry, can't be serious here, since the present post is voluntarily a biased one)
It seems to work, but aren't there some side-effects to be expected?
There are no magical side-effects. Pretty much all of the server behavior is explicit.
No magic thus. Feeling sooo disappointed.
Finally, there's the problem of logging. I need to keep some trace of access requests, but wouldn't be really happy to have 10 lines written to the log for each connection attempt... Which kind of criterion, if any, could be easily used for writing one line per connection only?
See the post-auth section. That's what it's for.
You see? Plain magic: auth_log in the authorize section is supposed, by default, to be meaningful, a linelog instance in that same section, is just plain nonsense. Must be a matter of some module not returning a random code.
And it's documented, too.
Yeah, and I think I even managed to have that part working without too much randomness. That must be the least magical piece of the whole affair, and thus the least interesting one. Axel
It sounds like you think the modules are magic. They're not.
Aren't they magic? I'm feeling sooo disappointed now. You are cheating, aren't you? They *must* be magic. Otherwise, they couldn't be modules.
I agree. If they're not magic, explain the magic field in module_t. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Axel Luttgens wrote: ... something unreasonable. Your messages have consistently implied that the server is bizarre, confusing, and stupid. Maybe this is normal for you, but it's not polite to act that way in public. If you dislike my responses, you're free to go somewhere else, an spend $$$$ on a commercial server which does less, and has less support. Stop it. This is your only warning. Alan DeKok.
Hi,
With proxying turned on, when an "outsider" connects to an AP of ours, the debug log shows:
... eap: Request is supposed to be proxied to Realm SOMEREALM. Not doing EAP. [ eap ] = noop ...
normal
Conversely, everything in the authorize section that follows:
eap { ok = return }
is executed for each roundtrip between the client and the remote server; in the case of EAP, that may mean a dozen of DB queries, a dozen of lines logged thru a linelog instance, and so on.
correct...as its not part of an EAP conversation....so it will get hit. the question is whether you want or need it to be hit...especially for 'outsiders'. if using EAP, then the outerID is rubbish really - put all the exotic stuff in your inner-tunnel (so 'outsiders' dont hit it....and if you need some other stuff in the default 'authorize' section then use unlang eg if("%{User-Name}" ~= /@realm/ ) { ldap } sort of thing alan
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan Buxey
-
Alan DeKok -
Arran Cudbard-Bell -
Axel Luttgens