hi, just lookign at latest GIT pull onto my config.... the server fails due to a call in policy.d/eap - cache_eap module. okay. cache_eap moduel in mods-available but not live. fixed. then I get /etc/raddb/policy.d/eap[37]: "cache" modules aren't allowed in 'authenticate' sections -- they have no such method. /etc/raddb/policy.d/eap[37]: Failed to parse "cache_eap" entry. /etc/raddb/policy.d/eap[36]: Failed to parse "if" subsection. the policy has: # Populate cache with responses from the EAP module # eap.authenticate { eap { handled = 1 } if (handled) { cache_eap handled } cache_eap } so, its calling this cache method in the authenticate section. meant to? I guess so. .... for now policy removed. alan
Hi,
$ git pull
oh. exciting times. now have a different server startup failure - which wasnt seen last night: Tue Feb 12 08:21:21 2013 : Debug: server buffered-sql { # from file /etc/raddb/sites-enabled/buffered-sql Tue Feb 12 08:21:21 2013 : Debug: modules { Tue Feb 12 08:21:21 2013 : Debug: Module: Checking preacct {...} for more modules to load Tue Feb 12 08:21:21 2013 : Debug: Module: Loading virtual module acct_unique Tue Feb 12 08:21:21 2013 : Debug: Module: Checking accounting {...} for more modules to load Tue Feb 12 08:21:21 2013 : Debug: (Loaded rlm_sql, checking if it's valid) Tue Feb 12 08:21:21 2013 : Debug: Module: Linked to module rlm_sql Tue Feb 12 08:21:21 2013 : Debug: Module: Instantiating module "staffbase" from file /etc/raddb/mods-enabled/staffbase Tue Feb 12 08:21:21 2013 : Debug: rlm_sql (staffbase): Creating new attribute staffbase-SQL-Group Tue Feb 12 08:21:21 2013 : Error: rlm_sql (staffbase): Failed to create attribute staffbase-SQL-Group Tue Feb 12 08:21:21 2013 : Error: /etc/raddb/mods-enabled/staffbase[22]: Instantiation failed for module "staffbase" Tue Feb 12 08:21:21 2013 : Error: /etc/raddb/sites-enabled/buffered-sql[120]: Failed to find "staffbase" in the "modules" section. Tue Feb 12 08:21:21 2013 : Error: /etc/raddb/sites-enabled/buffered-sql[114]: Errors parsing accounting section. 'staffbase' is just a named SQL instance (postgresql), which we call instead of 'sql' in buffered-sql module alan
A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
$ git pull
oh. exciting times. now have a different server startup failure - which wasnt seen last night: ... Tue Feb 12 08:21:21 2013 : Debug: Module: Instantiating module "staffbase" from file /etc/raddb/mods-enabled/staffbase Tue Feb 12 08:21:21 2013 : Debug: rlm_sql (staffbase): Creating new attribute staffbase-SQL-Group Tue Feb 12 08:21:21 2013 : Error: rlm_sql (staffbase): Failed to create attribute staffbase-SQL-Group
Bug fixed and error messages update to give more information. Alan DeKok.
Hi,
Bug fixed and error messages update to give more information.
looks good.....and is running now. however, I note in the debug log, lots of these sorts of entries: Tue Feb 12 16:25:26 2013 : Error: rlm_eap (EAP): No EAP session matching state 0x4344573643464e11 I *believe* that this is just a fresh new incoming EAP session....and so therefore there would be no state that is matched...so, not really an Error at all? Have I presumed correct with this - or is it the client trying to do a fast reauth that may have been cached? alan
A.L.M.Buxey@lboro.ac.uk wrote:
however, I note in the debug log, lots of these sorts of entries:
Tue Feb 12 16:25:26 2013 : Error: rlm_eap (EAP): No EAP session matching state 0x4344573643464e11
That *may* come from the changes to the EAP cache. It's supposed to track re-transmits through a different proxy path. The old code would give this error message. The new code should allow EAP to continue. But it's possible that the code gets confused.
I *believe* that this is just a fresh new incoming EAP session...
Which means there should be no State attribute at *all*.
and so therefore there would be no state that is matched...so, not really an Error at all? Have I presumed correct with this - or is it the client trying to do a fast reauth that may have been cached?
The fast re-auth re-starts EAP. Alan DeKok.
Hi,
I *believe* that this is just a fresh new incoming EAP session...
Which means there should be no State attribute at *all*.
i'll have to check the code path to see when the state is applied....eg is it added to the packet when the packet is proxied locally from the outer virtual server to the inner-tunnel ? if so... alan
A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
I *believe* that this is just a fresh new incoming EAP session... Which means there should be no State attribute at *all*.
i'll have to check the code path to see when the state is applied....eg is it added to the packet when the packet is proxied locally from the outer virtual server to the inner-tunnel ? if so...
No. It should only be in the outer session. Alan DeKok.
participants (2)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok