SOLVED Call detail Records application stopped updating records

[rkbsimpsipper]

Strange deal, I can't get any new call records, I have ran the upgrade sequence hoping that would set it straight but it is still not populating any new calls.

Is there a way to reset this app entirely? Reinstall the module maybe?

Thanks a bunch

 

[rkbsimpsipper]

bump

 

[pbxgeek]

Do you use a cron job or service for CDR upload?

 

[rkbsimpsipper]

Not that I am aware of. I have not altered the default method this application uses to display the records in any way. No more records have populated via the fusionapp "Call Detail Records" for over a month. Is there a service or cron job that I can verify or manually trigger?

 

[pbxgeek]

post your /etc/freeswitch/autoload_configs/xml_cdr.conf.xml here

 

[rkbsimpsipper]

configuration name="xml_cdr.conf" description="XML CDR CURL logger">
  <settings>
    <!-- the url to post to if blank web posting is disabled  -->
    <!--<param name="url" value="http://127.0.0.1/app/xml_cdr/xml_cdr_import.php"/>-->

    <!-- optional: credentials to send to web server -->
    <!--<param name="cred" value="E98hy%dXW:^Fy1bRkS^"/>-->

    <!-- the total number of retries (not counting the first 'try') to post to webserver incase of failure -->
    <!-- <param name="retries" value="2"/> -->

    <!-- delay between retries in seconds, default is 5 seconds -->
    <!-- <param name="delay" value="1"/> -->

    <!-- Log via http and on disk, default is false -->
    <!-- <param name="log-http-and-disk" value="true"/> -->

    <!-- optional: if not present we do not log every record to disk -->
    <!-- either an absolute path, a relative path assuming ${prefix}/logs or a blank value will default to ${prefix}/logs/xml_cdr -->
    <param name="log-dir" value=""/>

    <!-- optional: if not present we do log the b leg -->
    <!-- true or false if we should create a cdr for the b leg of a call-->
    <param name="log-b-leg" value="false"/>

    <!-- optional: if not present, all filenames are the uuid of the call -->
    <!-- true or false if a leg files are prefixed "a_" -->
    <param name="prefix-a-leg" value="true"/>

    <!-- encode the post data may be 'true' for url encoding, 'false' for no encoding, 'base64' for base64 encoding or 'textxml' for text/xml -->
    <param name="encode" value="true"/>

    <!-- optional: set to true to disable Expect: 100-continue lighttpd requires this setting -->
    <param name="disable-100-continue" value="true"/>

    <!-- optional: full path to the error log dir for failed web posts if not specified its the same as log-dir -->
    <!-- either an absolute path, a relative path assuming ${prefix}/logs or a blank or omitted value will default to ${prefix}/logs/xml_cdr -->
    <!-- <param name="err-log-dir" value="/tmp"/> -->

    <!-- which auhtentification scheme to use. Supported values are: basic, digest, NTLM, GSS-NEGOTIATE or "any" for automatic detection -->
    <!--<param name="auth-scheme" value="basic"/>-->

    <!-- optional: this will enable the CA root certificate check by libcurl to
         verify that the certificate was issued by a major Certificate Authority.
         note: default value is disabled. only enable if you want this! -->
    <!--<param name="enable-cacert-check" value="true"/>-->
    <!-- optional: verify that the server is actually the one listed in the cert -->
    <!-- <param name="enable-ssl-verifyhost" value="true"/> -->

    <!-- optional: these options can be used to specify custom SSL certificates
         to use for HTTPS communications. Either use both options or neither.
         Specify your public key with 'ssl-cert-path' and the private key with
         'ssl-key-path'. If your private key has a password, specify it with
         'ssl-key-password'. -->
    <!-- <param name="ssl-cert-path" value="$${base_dir}/conf/certs/public_key.pem"/> -->
    <!-- <param name="ssl-key-path" value="$${base_dir}/conf/certs/private_key.pem"/> -->
    <!-- <param name="ssl-key-password" value="MyPrivateKeyPassword"/> -->

    <!-- optional: use a custom CA certificate in PEM format to verify the peer
         with. This is useful if you are acting as your own certificate authority.
         note: only makes sense if used in combination with "enable-cacert-check." -->
    <!-- <param name="ssl-cacert-file" value="$${base_dir}/conf/certs/cacert.pem"/> -->

    <!-- optional: specify the SSL version to force HTTPS to use. Valid options are
         "SSLv3" and "TLSv1". Otherwise libcurl will auto-negotiate the version. -->
    <!-- <param name="ssl-version" value="TLSv1"/> -->

    <!-- optional: enables cookies and stores them in the specified file. -->
    <!-- <param name="cookie-file" value="/tmp/cookie-mod_xml_curl.txt"/> -->
  </settings>
</configuration>

 

[pbxgeek]

You are not using the default upload. This line is commented out.
<!--<param name="url" value="http://127.0.0.1/app/xml_cdr/xml_cdr_import.php"/>-->

So you must have a cron job or a service that does the upload. If it's a service, you might need to restart it. Check the status

service xml_cdr status

 

[rkbsimpsipper]

rkb@e1p:~$ sudo service xml_cdr status
[sudo] password for rkb:
Unit xml_cdr.service could not be found.
rkb@e1p:~$ systemctl status xml_cdr
Unit xml_cdr.service could not be found.
rkb@e1p:~$ sudo !!
sudo systemctl status xml_cdr
Unit xml_cdr.service could not be found.

 

[rkbsimpsipper]

You are not using the default upload. This line is commented out.
<!--<param name="url" value="http://127.0.0.1/app/xml_cdr/xml_cdr_import.php"/>-->

So you must have a cron job or a service that does the upload. If it's a service, you might need to restart it. Check the status

service xml_cdr status

Back onto this, I have never altered this file. I am also the only person that has ever logged into this machine.

 

[pbxgeek]

No service. Your last option is a cron job. Check here

crontab -e

You should have something like this in the file

* * * * * /usr/bin/php /var/www/fusionpbx/app/xml_cdr/xml_cdr_import.php 300 abcdef0123456789 >/dev/null 2>&1

 

[rkbsimpsipper]

So i ran an ls -lh to see if the file was edited, and it was, on the last date the call records display.

```-rw-r--r-- 1 www-data www-data 4.0K Jun 6 13:20 xml_cdr.conf.xml```
So strange, makes me think I have been hacked.

 

[rkbsimpsipper]

No service. Your last option is a cron job. Check here

crontab -e

You should have something like this in the file

* * * * * /usr/bin/php /var/www/fusionpbx/app/xml_cdr/xml_cdr_import.php 300 abcdef0123456789 >/dev/null 2>&1

The crontab is blank

 

[whut]

So i ran an ls -lh to see if the file was edited, and it was, on the last date the call records display.

```-rw-r--r-- 1 www-data www-data 4.0K Jun 6 13:20 xml_cdr.conf.xml```
So strange, makes me think I have been hacked

The crontab is blank

So i ran an ls -lh to see if the file was edited, and it was, on the last date the call records display.

```-rw-r--r-- 1 www-data www-data 4.0K Jun 6 13:20 xml_cdr.conf.xml```
So strange, makes me think I have been hacked.

Hacked? Nooooo. Having not edited your cronjob is not an indication that you have been hacked. Add the cronjob as pbxgeek shared

 

[rkbsimpsipper]

I am stating that my cdr's stopped updating on the exact date that the cdr xml file had been altered. Not whether the crontab was populated. Simply trying to correlate how/why the file would have been edited on the exact day the cdr's stopped, without my involvement at all. Or if another error would have caused that file to be edited, so I am puzzled.

 

[rkbsimpsipper]

The application worked flawlessly for 2 years solid.

 

[pbxgeek]

So i ran an ls -lh to see if the file was edited, and it was, on the last date the call records display.

```-rw-r--r-- 1 www-data www-data 4.0K Jun 6 13:20 xml_cdr.conf.xml```
So strange, makes me think I have been hacked.

There is no service, no cron job, and the default file was modified. You found your issue. Currently, you have nothing that processes your CDRs. A cron job or service is preferable, but modifying the XML file is easier and faster.

 

[rkbsimpsipper]

There is no service, no cron job, and the default file was modified. You found your issue. Currently, you have nothing that processes your CDRs. A cron job or service is preferable, but modifying the XML file is easier and faster.

We found the fix, and that is appreciated. Thanks for the help. I will investigate the cause. Maybe it was something as simple as a kernel upgrade, or the cron package itself.

 

[pbxgeek]

I am stating that my cdr's stopped updating on the exact date that the cdr xml file had been altered. Not whether the crontab was populated. Simply trying to correlate how/why the file would have been edited on the exact day the cdr's stopped, without my involvement at all. Or if another error would have caused that file to be edited, so I am puzzled.

I don't know what happened, but clearly, there is no financial interest in hacking your CDR XML file from a hacking perspective. Unless someone really wanted to hide calls they were making out of your box, but that's just too clever. Replace your passwords and SSH Keys just in case and that should do the trick

 

[rkbsimpsipper]

I don't know what happened, but clearly, there is no financial interest in hacking your CDR XML file from a hacking perspective. Unless someone really wanted to hide calls they were making out of your box, but that's just too clever. Replace your passwords and SSH Keys just in case and that should do the trick

That's the only thing I could come up with as well. Good idea on the password swap. Thanks again

 

[pbxgeek]

Glad I could help. Mark the thread as solved. It would help others. We did some good troubleshooting here.