Can someone explain what CEPM firmware management does?

CentOS release 6.4 (Final) (FreePBX Distro)

We use a variety of snom phones, but mainly 870 models.

I am trying to figure out what the firmware management portion of CEPM does and how it works. The documentation is rather sparse on the matter and not altogether lucid on the procedure.

The firmware management page displays three working columns. Column 1, labelled Available Firmwares, contains a list of four version numbers: 0.00,1.00…1.02.

Column 2 contains a text box and is labelled Firmware Slot 1.

Column 3 also contains a text box and is labelled Firmware Slot 2.

When firmware version 0.00 is pulled over to either Slot 1 or Slot 2 then the following is displayed as an AJAX overlay:

Custom Firmware Upload your firmware to /tftpboot/brand/slotnumber Leave version file in folder

I inferred from this that one must create a directory under the provisioning directory called ./snom/1 or ./snom/2 depending upon which ‘SLOT’ column is selected. However, as one must create these directories (since neither exists on my system and more about that later) the instruction to ‘leave’ version file in folder is a little mystifying. I inferred that this instruction really means ‘copy’ a version file having unknown contents from somewhere unspecified. On a leap of faith (since the available documentation is completely silent on the matter) I copied the version file from ./snom/0 into ./snom/2.

Next I used wget to retrieve the desired firmware updates from snom and placed these in ./snom/2.

Next I pushed the submit button on the CEPM firmware management page. The manual states this:

• To install the firmware press the submit button at the bottom of the page. Submit • While the firmware is downloading and installing you will see the page refresh with the downloading message.

This simply does not happen in my case. What happens is that the directories ./snom/1 and ./snom/2 disappear together with their contents and the page refreshes to show the original three columns and nothing else. There is no clue given as to where the directories have gone or how to proceed past this point.

Does the firmware management function work? Is there some step I am missing?

00.0 is used for you to add custom fimrware. It requires you to install your own firmware in snom/1 inside tftpboot directory.

If you pick any of the other versions and drag them to slot 1 or 2 and submit the page it will download the firmware and show you a list of version numbers for each model.

Then inside a template under snom you can pick which firmware slot that template uses.

So, do I correctly infer from your reply that one can ONLY use slot 1 for version 0.00 which is ONLY used for custom firmware. Is that correct?

Well, I followed your instructions to the best of my understanding. I created a directory called /tftpboot/snom/1. I copied /tftpboot/snom/0/version into /tftpboot/snom/1. I then copied the new firmware files (snom870- into /tftpboot/snom/1 as well. I dragged version 0.00 into the slot 1 text box on the firmware management page and pressed submit. The page instantly re-displayed the original contents and the directory /tftpboot/snom/1 disappeared.

When I go to the snom template my only choice for the firmware version is ‘recommended’ which does not map to anything meaningful to me.

No you are not listening. The 0.00 can be on any slot. Its just a way of activating the slot to let you put your own custom firmware in place. You dont have to create any directories they are all auto created when you drag a firmware version over.

I am reading but I do not understand where does one put the files? The instructions generated on the page say:

Custom Firmware
Upload your firmware to /tftpboot/brand/slotnumber
Leave version file in folder

Well how is this done? If the directory does not exist and I am not to create it and given there is no place to provide a url anywhere, exactly how does one ‘upload’ the custom firmware and where is is kept on the host system?

P.S. When I drag 0.00 over to Slot 2 and press submit there is no directory called /tftpboot/snom/2 created and if either /tftpboot/snom/1 or /tftpboot/snom/2 or both directories exist then they are deleted.

Then open a bug report please.

I tried to add a bug report but I cannot see what happened to it. I did not get any errors but the submission screen would not close after I submitted it and I had to press cancel to leave.

Evidently the submit button is deliberately disabled and one must press ALT+SHIFT+S to actually submit a form. Really???

No the submit button works. I use it daily.

What browser are you using. Between your EPM issue and not being able to submit a ticket sounds like you have something jacked on your browser. I can not replicate either of your issues.

FirefoxESR 24.2.0

The create button in our issue tracker works fine on Firefox 25. Its improbable for it to be disabled.

This situation is likely related to the initial difficulty I had using CEPM with Firefox. There was an update to CentOS-6 today that changed some of the javascript settings in Firefox. This appears to have fixed my problem with CEPM and it would not surprise me to discover that the Issues create button now works as well.


I’ve had identical issues using CEPM on

PBX Firmware: 4.211.64-9
Asterisk Version 11.7.0
PBX Service Pack:

All modules updated w/in past 24 hours.

I’ve had these issues since first purchasing this module near the end of November 2013. At the time the following symptoms were observed when attempting to add additional firmware versions:

In Settings -> EndPoint Manager -> Firmware Management -> Polycom, attempting to select Polycom 1.02 (or any for that matter) and clicking “Submit” resulting in a whole lot of nothing happening followed by a page refresh. A search in /tftpboot/polycom/ and /tfpboot/firmwaredownloads/ further verified that a whole lot of nothing had happened. I could not find anything relevant in the logs either.

I tried using both Firefox 25 and Internet Explorer 11 at the time on a windows machine. In both cases, the page would simply refresh and nothing would happen or change.

I posted to this in the beta forums at the time, but have to date received no response on the post. Fine. I waited a few weeks, tried again and saw the same thing happen. This time, however, Google was a little more helpful and landed me on a few bug reports (that seemed to largely be explained away as client side issues) and this forum thread, which again seems to be blaming the end-user for client side problems on a paid module.

In response to all this reading I did, however, have the thought to try this in a few more client-side environments. First, I performed a Cent-OS system udpate on the pbx distro. Looked like primarily dahdi related updates. Then I tried to perform a firmware download using the GUI administration panel again on Firefox 25 and Internet Explorer 11 from a Windows Machine. Same thing again - nothing at all happened.

I then tried both on Firefox 24 and 25 from a Debian based Linux system. Still no luck. As a last resort I downloaded and tried using the most recent version of Google Chrome - this time the download actually happened.

So, for anyone reading this, the short answer is just keep trying using different browsers - one is bound to work! I do, however, also have a longer hope that the Freepbx development team, understanding the importance of quality support behind a baseline paid module like CEPM, will look further into these recent customer concerns that a quick look through Google reveals to be a concern starting close to December 2013, with the intent of supporting, ideally with an allowable degree of built-in browser obsolecense, CEPM firmware management capabilities to the full functional expectations a paying user base would expect of such a module.

Of course, being in Beta, I have no expectation that everything will work. I signed up for this module knowing this full well! I do however, really hope that the development team ultimately sees these concerns as an engineering problem in need of resolving and not as a simple customer remediation (occasionally synonymous… at times for good reason… with verbal flogging) opportunity. Sometimes a simple “Can you explain the problem better and let’s work to resolve this.” can go a really long way in incentivizing clientelle who have demonstrated a willingness to part with a small amount of cash to support a truly empowering product, to part with a little more for even greater operational functionality.

Until then, I must admit my CEPM experience has left me wanting and suspect of investing in additional, more costly, modules. The primary concern being the disinterested level of support my first paid module experience has demonstrated.

At any rate, wonderful job otherwise. Many of us clearly, as has been correctly pointed out by support personnel in numerous forum topics, would not be able to capitalize on the cost-cutting opportunities great development efforts, such as FreePBX, offer to the tech community as a whole. Thank you for that :slight_smile:


You can always open a support case on paid modules at for faster assistance.

This users issue was his actual computer/browser. He updated firefox on his local computer which happens to be CentoOS and that fixed his issue. His issue was 100% his browser having a bug with javascript.