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: GigabitEthernet 5/0/3.3170044:317-44=23587435726=23804GE1 TOROON44BBN-TOROON4415W=23=23pppoe d8:6c:e9:10:32:c5=23 In the radius -X output the above shows up as GigabitEthernet 5/0/3.3170044:317-44#587435726#804GE1 TOROON44BBN-TOROON4415W##pppoe d8:6c:e9:10:32:c5# Why is this? Bill
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html