This post if related to… I cant post links…
wiki.freepbx: Desk Phone Module for Asterisk (DPMA) SSL Certificate Expiration
My phone system has been down since the 28th as no phones are able to register and download their configurations from the PBX. I have been attempting to upgrade/install the digium_phones module and am unable to do so due to a error.
“loader.c:463 load _dynamic_module: Error loading module ‘res_digium_phones.so’: /lib64/libc.so.6: version ‘GLIB_2.14’ Not Found
Im currently running the following server.
OS: Centos-release-6-10.el6.centos.12.3.x86_64
Asterisk Version: Asterisk 11.17.1
DPMA Version: res_digium_phone-11.0_3.4.13-x86_64
Ive been forced to manually to try and manually install this package as the yum repo’s for package.digium are all dead, so Im unable to upgrade via yum.
I have attempted the following fix, but has had not positive results.
“askubuntu: questions 421642 libc-so-6-version-glibc-2-14-not-found”
Any help would be greatly appreciated, Im a solo IT guy that inherited this PBX and the entire company’s phone system is kaput.
I believe Im big time effected by this SSL error. My PBX has been down now for 3 day. Ive been trying to upgrade to the DPMA 3.4.13 for Asterisk 11 and Im getting no where fast.
I keep getting an error
“loader.c:463 load _dynamic_module: Error loading module ‘res_digium_phones.so’: /lib64/libc.so.6: version ‘GLIB_2.14’ Not Found (required by /usr/lib64/asterisk/modules/res_digium_phones.so)”
I have attempted to apply the following fix “askubuntu—/questions/421642/libc-so-6-version-glibc-2-14-not-found” which has done nothing to help the situation.
My entire companies phone system is down and Ive been banging my head on the wall with this for 3 days now.
I inherited this tech debt from another IT guy about 5 months ago. If you can imagine, if this system is out of date, how many others are out of date as well. I put this server at the bottom of my tech debt list. I wasn’t expecting this SSL cert issue.
Depending on the age of that DPMA (I don’t remember, sorry) there may be more than one .so file. No need to re-run registration as long as the license file is preserved (it should be)
P0*CLI> module reload res_digium_phone.so
P0*CLI> digium_phones show version
Digium Phone Module for Asterisk Version GIT-11.0_3.4.13-0-g7621412M
I have reboot the server and now Im trying to re-register one of the phones. Im now getting an invalid credentials for the proxy.
Im trying to find where these credentials are set so I can see if they got reset. But I would say the upgrade worked as it should.
Any advice?
EDIT
It seems configurations were consolidated in the newer version. The original configs were the following…
res_digium_phone_additional.conf
res_digium_phone_applications.conf
res_digium_phone_devices.conf
res_digium_phone_firmware.conf
res_digium_phone_general.conf
Looks like all of these have sections inside
res_digium_phone.conf
If the phone’s able to connect at all, then things are good w.r.t. the SSL cert. expiration. In the spirit of hitting things with a dull hammer so that someone doesn’t have to try to understand everything about your setup in order to help (FreePBX, Asterisk, DPMA, Phones, etc. are a multi-faceted, infinitely configurable blender of features), why not factory reset a phone, point it at the server, and go from there. Figure out what authentication method you have set (if any), figure out what pin codes you have set (if any), filter for used and unused (all) extensions if you’re not doing MAC-based, and good luck.
After adding all the configuration information from those individual configs into the main config, all the phones in the company are able to pull down their original configs and have full access to their voicemail again.
Thanks for the software for my build, you’re a life saver.
After I finish getting everyone’s phone up and running, Ill post a write up in here so that google can index it for others to find.
Tuesday, June 1st 2021, I got a report that a user could not access their voicemail, but phone communication seemed to have remained stable
I rebooted that users phone and during boot found that the phone no longer could download its config from the server with an error that pointed towards network communication error.
I established that network communication was not an issue by checking ICMP, SIP Debugging, NIC testing, Switch replacements.
Checked inside the PBX and found that in the “Connectivity > Digium Phones” in the Phone Info column that all phones were getting an IP address, but the MAC was not registering.
Checked the “Full” logs and found a lot of “chan_sip.c: Retransmission timeout reached on transmission”
Spent two days googling and checking forum post and discovered Digium is owned by Sangoma, which then pointed me to the cert error.
Downloaded the build for Centos6 Asterisk11 64-bit and attempted an installed. Install failed with a “/lib64/libc.so.6: version ‘GLIB_2.14’ Not Found”
@mdavenport provided a different build above for my PBX and the patch worked immediately.
Migrated all configurations from the old individual…
res_digium_phone_additional.conf
res_digium_phone_applications.conf
res_digium_phone_devices.conf
res_digium_phone_firmware.conf
res_digium_phone_general.conf
… and placed them into the res_digium_phone.conf file and rebooted the server.
Rebooted a phone that has already been provisioned. Phone successfully downloaded config and after boot voicemail was accessible.
However, something seems very wrong with this picture. I know nothing about Digium phones, but AFAIK all IP phones store their configurations in flash memory. They are generally programmed to request a new configuration from a provisioning server on boot up, periodically, and/or when they receive a Notify request. If provisioning fails (usually because the server is down or because of a network problem), they just use the configuration stored in flash.
If a certificate issue causes provisioning to fail, the phone should continue to use its current configuration. Making and receiving calls should not be affected.
What went wrong here? This seems like a very serious firmware bug, causing all the phones in the company to go down. Can it be easily fixed?