So I’m pretty green with RADIUS. I’m proud of myself that I thought I actually got it working with MySQL, but now it seems that the CPE won’t connect (or the AP won’t talk to the RADIUS server anymore). Aargh.
How does one actually do MAC-based control? So far it seems that the AP relays a username, password, and device name@wimax.com from the CPE, and hides the MAC address in the “Calling-Station-Id” attribute. Anyone know how I can allow connections based on that? Seems to me that putting the same user/pass in every radio would sort of open up a whole barrel of problems. I am using Freeradius 2.1.10 on Debian with MySQL. I think a lot of things changed recently as documentation from 2.1.7 and 2.1.2 doesn’t seem to match what I have - or Debian changed things significantly.
Also, is there a way to push configuration from RADIUS? I see some folks have created a “Motorola WiMAX” dictionary that returns attributes like VLANs. I’d like to avoid having the techs set too much inside the CPE. Especially when there’s a management VLAN involved it is a royal pain in the ass. (I have to go get me a switch so I can check the config inside this CPE now because the reset tool just crashes on Win7… great… thanks Motorola)
Thanks in advance for any help
Hi salad,
i use freeradius on mysql and debian also and working fine.
the “Calling station ID” is the IP-Adress of the AP an you must put them in the NAS Table of the Radius-server.
Now the AP and CPE from Motorola/Gemtek don’t understand the accounting setting from the Radius, so if you but the same user/pass on the Radio they will successfully authenticated to your network.
In the Radiusdatabase i have put all the Mac-adress of my CPE and only this Mac-Adress can authenticated to my network (I use the Mac-Adress as username/password)
but
at the moment the AP from Motorola/Gemtek can’t push all kind of attributes.
I mean that only the index of the Service Flows and Tos can but to the CPE.
bye
Thanks for your help. I’ve done a little hack so that in MySQL radcheck and radusergroup both have the MAC address of a CPE in the ‘username’ column. I still store passwords in there instead of just accepting if the MAC is found. This way the MS-CHAPv2 auth is still performed, but FreeRADIUS will only look up a password in the first place if the Calling-Station-ID (MAC of the CPE) is in the database 
radpostauth contains the device ID set in the CPE, the MAC address of the CPE, response and date. I also have it returning parameters for service flows from radgroupreply for various packages.
What I cannot seem to get working is rejections. I see the open issue with reference # 660 in the release notes for 2.2.1:
“After any internal AAA service provisioning has been applied and a change is made to use an external AAA server, the original internal AAA provisions will remain applied.”
"Workaround – Delete all internal provisioning if operator chooses to use external AAA provisioning."
Well, that’s not working very well. If I set the Internal AAA to accept unknowns, switch to External AAA and tell it to reject unknowns, then even though FreeRADIUS sents back Access-Reject the AP lets it online. No service flows are created, but it’s still associated.
I don’t want unauthorized CPEs to connect at all. However, if I set Internal AAA to reject unknowns, then in External AAA mode the AP doesn’t even send queries to the RADIUS server!
Is there some way to delete that setting? Because the wording in the release notes doesn’t match up with the actual options in the AP…
I’m going to send this to support as well. Thanks in advance to anyone who responds
Hi salad,
fine fine.
Another happy customer on cambiun networks / gemtek / motorola stuff!!!
Yes. it is anothe bug! If oall the authentication settings are correct on the CPE, the CPe stay connected/autoriced to the AP witout an IP-Adress or service Flow.
how to you send this information to the support?
bye
Brief update on this - I opened a case with support and ended up speaking with L3 and some devs and engineers down in Chicago who confirmed this as a bug with reference number 10105 (shows in release notes for 2.2.2). Support’s advised me that this problem I was having should be fixed in 2.3 but I don’t see bug 10105 listed at all. Will be testing very soon