I have BAM and the licence manager working and the AP’s are obtaining a license yet the SM’s will not authenticate. I have gone through the manaul time and time again, still cannot find anythign in regards to where I am supposed to put the shared secret into RADIUS itself.

To sum it up

Canopyapi.xml has the

<canopyUserPassword xsi:type=“xsd:string”>ourvalue</canopyUserPassword>


The user file for radius has the username set the same as this


The SM has the same value also in the full access password.

Then onto the shared secret value

The canopyapi.xml has

<sharedSecret xsi:type=“xsd:string”>ourothervalue</sharedSecret>


The users file has the same sharedsecret value

There is apparently a third location the radius server itself needs to contain this value.

Moto Support REFUSES to even suggest where this value is to go.

Anyway, does anyone have any idea where this is supposed to go…I am at my wits end on this.

I can provide logs from the system to show what exactly is occuring if need be.

Thanks for help in advance

Well after putting radius in to debug mode with the command

radiusd -xxyz -l stdout

I found that it was reporting

Ignoring request from unknown client xx.xx.xx.xx:xxxxxxx

I double and triple checked my clients.conf file which the BAM install guide reports as being located in /etc/raddb was all correct

So I did a locate on clients.conf & users file well the version of freeradius that I installed form the Linux Ent v.3 cd uses the /usr/local/etc/raddb directory

So I edited the files in there and BAM I have communication now.

The SM is still not authenticating so I need to do more hunting to determine why, the debug of radius starts outputing the following.

— Walking the entire request list —
Sending Access-Reject of id 3 to xx.xx.xx.xx:42318
Waking up in 4 seconds…
rad_recv: Access-Request packet from host xx.xx.xx.xx:42319, id=3, length=84
Waking up in 4 seconds…
Thread 3 got semaphore
Thread 3 handling request 6, (2 handled so far)
User-Name = “########864f
User-Password = “ourvalue”
NAS-IP-Address = xx.xx.xx.xx
Called-Station-Id = “########780c
NAS-Port = 2
NAS-Port-Type = Wireless-Other
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 6
modcall[authorize]: module “preprocess” returns ok for request 6
modcall[authorize]: module “chap” returns noop for request 6
modcall[authorize]: module “mschap” returns noop for request 6
rlm_realm: No ‘@’ in User-Name = “########864f”, looking up realm NULL
rlm_realm: No such realm “NULL”
modcall[authorize]: module “suffix” returns noop for request 6
rlm_eap: No EAP-Message, not doing EAP
modcall[authorize]: module “eap” returns noop for request 6
users: Matched entry ########864f at line 1
modcall[authorize]: module “files” returns ok for request 6
modcall: group authorize returns ok for request 6
rad_check_password: Found Auth-Type Local
auth: type Local
auth: user supplied User-Password matches local User-Password
Sending Access-Accept of id 3 to xx.xx.xx.xx:42319
Finished request 6
Going to the next request
Thread 3 waiting to be assigned a request
— Walking the entire request list —
Cleaning up request 5 ID 3 with timestamp 4257630a
Waking up in 2 seconds…
— Walking the entire request list —
Cleaning up request 6 ID 3 with timestamp 4257630c
Nothing to do. Sleeping until we see a request.

Looks like it has something to do with the realm…

Anyone have any ideas?

My bet is that you followed the documentation to the letter. There in lies the problem. Set the attribute in the radreply or radgroupreply (depending on what you use or the users file to the following:

Motorola-Canopy-Shared-Secret = <hex auth key used in sm or 0 if default>

So something like
Motorola-Canopy-Shared-Secret = 0
for an sm using the default auth key.

Wow…could it be this easy…yup!

Worked perfectly, so the whole shared secret that “the manual” says to put in the canopyapi.xml file and to have it match what is in the users file is completly wrong. (might I add that it doesnt actually say that the shared secret goes into the users file, it just says and let me quote) “Shared secret between the BAM and the RADIUS Server. This secret is also specified on the RADIUS server.” How vague can you be, where on the radius server!

what this should say is!

Do not place this value in the canopyapi.xml place this value in the users file for the value of shared secret, this must also match what the SM has for the shared secret. This value is also refered to as the Authentication key in the SM. The defualt vlaue for this is “0” so make sure you place “0” in the users file!

was that really so much more difficult than what you wrote???

Also for note, Tech support you should really hon your skills with your own product. over the last few days I have been told by three people that the Authentication key in the SM has NOTHING to do with the BAM authentication. And what do you know, it has EVERYTHING to do with it.

That was the only right thing about your manual thus far, as far as how that authentication key plays a part took the previous poster to assist, not the manual.

Can you please get your act together and support “your” product so we can feel good about spending (in our case) alot of money!!!

3 days and not one thing productive came from calling tech support.

Sorry to be so bitter about canopy support folks, but wow am I one pissed customer!

long time ago i had also installed radius for bam after much headaches. but took it out as only start bits were being generated. as there were no stop bits it was of no use as we could not bill the customers as per usage by time. has anyone any idea how this can be done?



We are using 3rd party billing software, the software runs on scripts to write to the users file of the radius server, this writes the authentication paramaters i.e. Mac & Password. As well as the throttle paramaters.

That is first phase, the second phase is we have another server that via SNMP assesses the SM throughput at specific time intervals, should the SM exceed the alllotted amount bandwidth in the yet undetermined time frame …so on and so forth. it will then re-write the throotle values and issue a SSE deauth and then SSE auth command for that SM.

Also this third bandwidth server in the mix in phase 1 will be checking bandwidth usage anyway, not throttling yet, but billing should they exceed there monthly quotas.

As far as usage by time…I have not built on a time frame usage, these customer are recieving a broadband connection no time contraints, but deff bandwidth constraints!

May I ask what billing software you use as this is something I am currently researching…