Having spent a week, lmastering linux, SQL, perl, cgi and lmgrd licensing I managed to get this much talked about BAM to work…
In the initial stage I thought i was missing the rest of it… .I saw a primitively designed page, I thought i was in some SAFE mode… but it turned out this was the BAM.
I am not impressed, its not very user friendly. and has no functionality or features. Maybe my expectations were to high, but a few more tables to load data into, like
SM --> site
location
contact
contact number
IP address <link>
customer name
AP —> again more information would be nice
a more useful query system (once you get the data in there)
if motorola were to publish the API’s and promise to keep backward compatibility in future software releases we the user community could probably come up with one hell of Management System
Tx
I agree. Doing IP allocation by DHCP is crap, and forcing us to do PPPoE is crap, too. Bleah.
I’m still trying to get my head around how to really make this stuff work for me the way I want it to. 
PPPoE is looking better all the time, with BAM just doing some QoS stuff.
I definitely want more features built into the BAM. Hell, I’ll write the DB code for you to stick the names, addresses, service profiles, locations, etc, for the users. I don’t like a big list of MAC addresses (and I’m not alone). Because of the BAM, I have to record (elsewhere!) the MAC tables --> Customer Names table. That way, I know which radio I’m dealing with in the BAM. Please put Name/Phone/Location fields in the BAM and have it searchable by Name/Phone. Right now I pre-program radios for the installers, but sometimes I forget to stick a MAC in the BAM. When the installer calls and the radio doesn’t sync, I get the MAC address and then have to look through the BAM (with its crappy layout and font settings), so find the MAC that may or may not be there. I would really like to type in the last name of the customer to see if the entry is there. The unauthorized radio’s page could simply see the MAC’s and then look up the name of the customer and print that instead of just a MAC entry. It seems that Motorola really appeals to crazy computer geeks/mainframe techs. The installers are horribly written (ie. simple shell scripts that may or may not work), and the GUI’s don’t make it easy for people who don’t eat, sleep, and breathe computers (I do).
Pete, what are you doing to hand IP addresses to clients? That’s my major concern at the moment… DHCP is not a good way to address what is essentially a big, mostly uncontrolled ethernet segment.
I use DHCP + PPPoE. If my clients want a non-routable (10.64.x.x) IP, they do DHCP. If they want a Real IP, they can do PPPoE and be assigned a routable IP address. Everyone has access to both options. DHCP is a fine solution. It lets customers use as many machines as they would like, and everything is easy to track. Why is this not a good idea?
Pete wrote: DHCP is a fine solution. It lets customers use as many machines as they would like, and everything is easy to track. Why is this not a good idea?
Pretty simple. The network is like a big ethernet segment... all they have to do is set an authoritative DHCP server up on it (by accident, perhaps?) and whammo... they're handing out IP addresses to people on your network.
I have had that happen once on one of our DSLAMs. The person plugged a DLink router in backwards and it was handing out IPs to customers. I just typed the router’s IP in and brought up the web interface to turn off DHCP. I then turned off peer-to-peer on the DSLAM so that people could not directly communicate with eachother. If not that, I could just ping the DHCP server, get the MAC, trace it to a port and disable that user. Rogue DHCP servers haven’t been very hard to track thus far. Here is a suggestion for the future: Block inbound DHCP DISCOVER packets into the radio’s. That way, nobody can run a server… or they can, but it will never see the client requests. I hear what your saying though, and it is somewhat risky to run a DHCP network over the air, but we only have a handful of people on Canopy (+/- 30), and so far, everyone has phoned in to get help setting up their routers, so I can make sure everything is plugged in for them.
vj wrote: Having spent a week, lmastering linux, SQL, perl, cgi and lmgrd licensing I managed to get this much talked about BAM to work.....
In the initial stage I thought i was missing the rest of it.. .I saw a primitively designed page, I thought i was in some SAFE mode... but it turned out this was the BAM.
Your "mastery" of linux etc. in just one week is, unfortunately, less than complete. Contract a SQL developer or admin. to add the fields and build the interface you want for your db. If you want a gui (with all respect, your use of the term "safe mode" implies you're a Windows user with no exposure to a command line), expect to pay more.
vj wrote: if motorola were to publish the API's and promise to keep backward compatibility in future software releases we the user community could probably come up with one hell of Management System
The "API" is already exposed in the existing database structure - you merely want to add user-defined information fields that are associated with the existing MAC entries. A simple task for a db developer, and likely within the grasp of a db admin, although that'd be like using a steamroller to crack walnuts...
I then turned off peer-to-peer on the DSLAM so that people could not directly communicate with eachother.
A feature that Canopy AP's are missing. A feature Trango, Alvarion and all other AP's that come to mind have.
Matthew