Alpha # dsl_cpe_control -h
DSL_CPE: Welcome to DSL CPI API control application
DSL_CPE: usage: [options]
DSL_CPE: following options are available:
DSL_CPE: --help (-h) - help screen
DSL_CPE: --version (-v) - display version
DSL_CPE: --init (-i) - init device w/ <xtu> Bits seperated by underscore (e.g. -i05_01_04_00_04_01_00_00)
DSL_CPE: --low_cfg (-l) - low level configuration file
DSL_CPE: --console (-c) - start console
DSL_CPE: --event_cnf (-e) - configure instance activation handling <enable/disable>[_mask] (e.g. -e1_1)
DSL_CPE: --msg_dump (-m) - enable message dump
DSL_CPE: --auto_scr_1 (-a) - autoboot start script for ADSL (empty by default)
DSL_CPE: --auto_scr_2 (-A) - autoboot start script for VDSL (empty by default)
DSL_CPE: --firmware1 (-f) - firmware file, default /opt/ifx/firmware/xcpe_hw.bin
DSL_CPE: --notif (-n) - notification script name, default ./xdslrc.sh
DSL_CPE: --tcpmsg (-t) - enable dbgtool, listen only on <ipaddr> (optional, e.g. -t0.0.0.0)
DSL_CPE: --multimode (-M) - set multimode config -M<NextMode>_<AdslSubPref> (e.g. -M1_1)
DSL_CPE: --tc-layer (-T) - set TC-Layer options -T<TcLayer>_<TcConfigUs>_<TcConfigDs> (e.g. -T2_0x3_0x1)
Ahh. maybe it's another multi-call binary that presents a different set of command line options depending on how it's invoked (argv[0]) ? Just a guess.
uklad has commandeered his ECI now, so no more playing with it for me
However, if I've got the gist right..
the CPU in the ECI is a dual core - a MIPS32 and an unknown 32-bit DSP engine - in all probability another MIPS32 with extensions to the instruction set to provide DSP hardware functionality.
The MIPS32 core#1 runs the MIPS Linux operating system. The hardware driver blob aka 'firmware' (/ifx/vdsl2/xcpe_hw.bin) for the second core is loaded by the control core (core#1) into shared memory, and the execution of that code by core#2 is started.
The Linux kernel has a loadable kernel module (/ifx/vdsl2/drv_dsl_cpe_api.ko) which provides an interface from userspace to the kernel by way of a character device (/dev/dsl_cpe_api). It is through this interface that the line statistics from the DSP32 core are obtained. There should be a userspace binary that invokes system calls (read/write/ioctl) on that device. The embedded webserver must be invoking such calls, either directly, or via some middleware (i.e. that xmldb thing).
It's much the same in the Broadcom-chipset Huawei. A userspace binary called xdslcmd is used to invoke ioctl() system calls on /dev/bcmadsl0 to obtain various xdsl stats. The Linux kernel passes these calls to an ioctl de-multiplexer in the device driver, which obtains the stats from the hardware driver (the firmware blob) running on the DSP core. This is via some form of inter-process communication (IPC), semaphores, shared memory or message passing.
This may be of interest http://pastebin.com/2D4NW2HR . In addition, if you look through /www/ there are a lot of hidden web pages, unfortunately none have any statistics.
Ahh. server-side scripting fudged together with javascript. It's very similar to the Huawei, except the ECI also uses that XML database for storing realtime data. [1]
In the excerpt of code below, we can see the embedded servlet function ConfigGetArray().
The servlet parsing engine in the embedded webserver replaces everything within the delimiters <? and ?> with the return value from the ConfigGetArray function.
And the ConfigGetArray() function must query the XML database for the statistic, in this case to obtain the line attenuation for frequency band 0.
..
var StLineAttenuation = new Array();
..
/* Line Attenuation*/
StLineAttenuation[0] = <?ConfigGetArray(/runtime/vdsl2/line/band:0/,lnatten/up,lnatten/down)?>;
You could directly obtain that statistic using xmldbc, with something like this:
xmldbc -g /runtime/vdsl2/line/band:0/lnatten/down
To get a bit closer to the kernel.. you could build strace and monitor the system calls made by xmldbc (et al) as that command is invoked. This will uncover how to communicate directly with the kernel device driver. However the API will be documented in the source code for the drv_dsl_cpe_api device driver.
Also, take a close look at the -a command line option of xmldbc. It will dump the database contents including runtime and temporary data. That could reveal the XML node names for the tonemap data.
Since I haven't got access to an ECI any more, it is with great regret that I must bow out out of the hack-fest but with the reassurance that it is left in the competent hands of uklad and yourself
http://svn.dd-wrt.com:8000/browser/src/router/dsl_cpe_control/src/dsl_cpe_control.c?rev=15977 seems to give us source for the dsl_cpe_control utility.
Aha.. I saw that in the corrupted source tarball published by Openreach.
cheers, a
EDIT: Bit of info in the openwrt.org development mailing list. Note how you read and write to a pipe to send commands to the dsl_cpe_control daemon to request and receive stats from the xdsl layer. That will be for the AR9 (Lantiq's ADSL2 SOC family) but it's probably very similar for the VR9 (VDSL2.chipset family including the VRX268). [2]
[1]
http://www.psidoc.com/showthread.php/635-busybox-quot-httpd-quot-help-needed-hacking-a-router[2]
https://lists.openwrt.org/pipermail/openwrt-devel/2012-January/013602.html