bill at billmax.com
Mon Dec 2 22:51:36 CET 2013
I did eventually find a thread that mentions the busted schema and
querrys and I made the necessary changes. All is well.
As for "fix the NAS", so noted.
See below for one more comment...
On 12/2/2013 3:35 PM, Alan DeKok wrote:
> Bill Schoolfield wrote:
>> (1) My mysql based ippool is out of sync with the ips actually in use.
>> This is leading to ip conflicts and immediate drops after successful login.
> Blame the NAS. FreeRADIUS just assigns IPs, stores that assignment in
> the DB., and tells the NAS the user has that IP. If there's an expiry,
> it sends a Session-Timeout and asks the NAS to enforce it.
> i.e. the *only* way for things to get out of sync is if the NAS isn't
> hanging up on user sessions.
>> (2) take a look at the sql errors. It apparently doesn't like
>> "expiry_time IS NULL" in the update.
> Use a recent version of the server. The queries you post below were
> fixed in December 2010.
>> For (1) how can I get the ippool in sync? Is the only way to reset the
>> radippool table and drop all the connections from the NAS?
> Fix the NAS. Or, ensure that FreeRADIUS is sending Session-Timeouts,
> and that the NAS is enforcing them.
>> For (2) is this an error a by product of the immediate disconnect? Is
>> the mysql version of sqlippool known to work.
> It works if you use the correct queries.
>> Also for number (2) one problem I see is the schema doesn't account for
>> callingstationid that are this large. I assume I''ll need to change the
>> schema for this.
> That's simple enough to do.
I did this but noticed that # characters are being stored in the db as =23
Here is a calling station value in the db:
In the radius -X output the above shows up as
Why is this?
> Alan DeKok.
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
More information about the Freeradius-Users