MasterVitronic / fusionpbx

Automatically exported from code.google.com/p/fusionpbx
0 stars 0 forks source link

provisioning file names for tftp server #493

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1.Enable provisioning
2.Add devices
3.ls /var/lib/tftpboot

What is the expected output? What do you see instead?
files should be in the format of lowercase without hyphens. aa11bb22cc33.xml or 
aa11bb22cc33.cfg

Current Results
Cisco SPA112 - AA-11-BB-22-CC-33
Yealink - aa-11-bb-22-cc-33
Panasonic - aa-11-bb-22-cc-33

What version of the product are you using? On what operating system?
FusionPBX 3.4
Ubuntu 12.04

Please provide any additional information below.
My FusionPBX version 3.3 machine writes the files correctly.
It's the two new ver 3.4 machines I'm deploying that now have the issue.

These three telephones look for a lowercase mac address file name by default.

Original issue reported on code.google.com by gr8liq...@gmail.com on 31 Oct 2013 at 6:12

GoogleCodeExporter commented 9 years ago
This is no longer an issue with the new changes to the provisioning.
Please Close

Original comment by gr8liq...@gmail.com on 22 Dec 2013 at 5:04

GoogleCodeExporter commented 9 years ago
Wait! Forget that last comment. I forgot that I had edited the 
provision_write.php file so that the files were created correctly.
I just updated my dev machine to the latest 
freeswitch Version 1.2.17 git 7712626 2013-12-27 20:52:28Z
and
fusionpbx version 3.4 revision 4985
When I save a device or an extension and the file is created/updated, the file 
name is in the aa-bb-cc-dd-ee-ff format.

Original comment by gr8liq...@gmail.com on 30 Dec 2013 at 2:02

GoogleCodeExporter commented 9 years ago
In the 3.5 dev branch in this version I rewrote the code that writes the 
provisioning files writing the code into a PHP class. Tested writing the files 
to the file system and there are no dashes anymore in the mac address therefore 
I'm closing this issue.

Original comment by markjcrane@gmail.com on 30 Apr 2014 at 8:02