# /bin/xdslcmd info --pbParams

Didn't play with that one when exploring the Telnet interface - will do so the next time I take the laptop down to where the modem is.

Excellent work on the firmware BTW!

Pleasure, mr_bean! Hope you get some use out of it..

There are lots more things that could be done on the Huawei..

The BBU port on the front needs activating. It's clearly an RS232 serial port. The port is seen by the Linux-MIPS kernel as /dev/ttyS1. However, it needs to be enabled in the firmware.[1] As yet, that hasn't been done. There are two binaries in the firmware that try to access the BBU port (/bin/monitor and /bin/equipcmd). The relevant extracts of code from those binaries have been disassembled. For those interested or with suggestions, please email.

It's a puzzle why OpenReach/Huawei ever fitted the BBU port. In early photos of the Huawei in BT's SIN 498 document [2], the BBU port is shown as a USB Type A socket.

Yet at some point, it was decided to downgrade the BBU port from USB to RS232 . A strange decision since the Linux kernel has a mature USB driver for the 63xx processor family. And modems built on that platform do normally have a USB port. Maybe BT thought that a USB port would be too alluring to meddlers and tinkerers?!

Mechanically the RS232 BBU port is presented externally as an obscure JST-XH socket. [3] That socket is apparently more commonly found in model aircraft where it connects servo power packs. Perhaps Huawei had a surplus dustbin full of the connectors. And where better to dump them than on Blighty Telecom!

That xdslcmd command discussed above can supply a huge amount of different statistics, including individual bit depths and SNRs for each of the subcarriers. There are too many stats to manually analyse from their numerical values alone. The stats need to be graphed. That could be done on the Huawei itself. The device could graphically present its line stats via its own web interface. Fun project for someone?!

Alternatively, the device could log an overview of its line statistics to a remote syslogd daemon. That framework is largely supported on the Huawei [4]. Some sort of periodic (cron?) job just needs to be run on the device. That process would query the xdsl driver for the various line statistics. An overview of the stats would be generated. The overview would be sent over the LAN or even the wider internet to a logging daemon.

The xDSL driver in the Huawei can also conjure up undocumented statistics, such as the QAM constellation maps.

Late last year, Netgear accidentally (oopsadaisy!) released Broadcom's confidential source code for its 63xx xDSL driver. Cat, bag, out! It's in that release that the hidden goodies can be found.[5]

Briefly, have a good poke into the xdsl driver code.. In particular, look at the function prototypes in ~/DG834GBv4_V5/DG834GBv4_V5.01.01_src/bcmdrivers/broadcom/char/adsl/bcm96348/adsldrv.c.

There's a function in that file called adsl_ioctl(). If you examine the array of function pointers in adsl_ioctl(), you can determine the full range of ioctl() request codes that the xdsl driver responds to.

Some of those ioctl requests, which query the xdsl driver for stats, are hidden and cannot be reached from userspace using the standard tool xdslcmd.

However, it should be fairly easy (famous last words) to hack up some code that invoked those hidden functions.

I haven't tried it yet, but the function DoGetConstelPoints() sounds particularly interesting.

Judging by its name, the function provides the coordinates of the QAM constellation maps. Calling that function may well provide the data needed to render one of those curious looking graphics like this one..[6]

Anyway.. enough rambling!

cheers,
asbokid

[1] http://huaweihg612hacking.wordpress.com/2011/07/19/a...
[2] http://www.sinet.bt.com/498v3p2.pdf
[3] http://huaweihg612hacking.wordpress.com/2011/08/15/b...
[4] http://img89.imageshack.us/img89/5436/huaweihg612log...
[5] http://huaweihg612hacking.wordpress.com/2011/07/26/b...
[6] http://zone.ni.com/cms/images/devzone/pub/RF_sw_test...

Edited by asbokid (Mon 05-Sep-11 22:59:11)

In reply to a post by MHC:

Text
1 2	US: (0,95) (696,1183) DS: (32,687) (1192,1627)

Hi MHC..

I guess those figures in brackets must be the lower and upper tone numbers for each of the frequency bands. If so, it's not clear why the tones for U0 (0,95) and D1 (32,687) overlap.

This paper [1] on VDSL2 band plans is interesting. It was published by the chief engineer of Ikanos who worked on the xDSL chipset simulator which Broadcom uses.

The OpenReach Profile 8c connection stats can be compared against the stats from that Profile 17a VDSL2 connection in Germany.

Profile 17a has a downstream bandwidth of 17MHz, whereas Profile 8c has ~8MHz bandwidth. Hence the Profile numbering..

Profile 17a uses 4095 subcarriers or "discrete multi-tones" (DMTs) and Profile 8c uses a total of 1972 tones.

That German Profile 17a VDSL2 connection shows that Band U0 is unused. According to the Ikanos paper, Band U0 was designated as a long distance upstream band.

The stats from xdslcmd show that Band U0 is used by Profile 8c in Blighty but the band is not used by Profile 17a in the FTTC product in Germany/Austria. That is presumably because 17a is delivered over shorter distances at higher speeds and Band U0 isn't needed.

Here [2], someone at Ericcson ploughs through the maths to arrive at some figures for theoretical maximum bandwidth in bits per second..

The Profile 17a statistics, duplicated below, appear to show that only one upstream band (U1) and only one downstream band (D1) are actually in use, even though three bands in each direction are technically available.

Maybe that explains the attenuation issue with the web interface of the 63xx firmware. Is it displaying the (average) attenuation for the tones in a single frequency band which maybe is a band that is not in current use?

cheers,
asbokid

Text

1 23 45 67 89 1011 1213 1415 1617 1819 2021 22

# adslctl info --pbParams adslctl: ADSL driver and PHY statusStatus: Showtime Retrain Reason: 2Max:    Upstream rate = 992 Kbps, Downstream rate = 13620 Kbps Path:   0, Upstream rate = 139 Kbps, Downstream rate = 1096 Kbps  Discovery Phase (Initial) Band PlanUS: (0,95) (872,1203) (1972,2779) DS: (32,867) (1208,1971) (2788,4051)Medley Phase (Final) Band Plan US: (0,95) (872,1203) (1972,2779)DS: (32,867) (1208,1971) (2788,4051)        VDSL Port Details       Upstream        DownstreamAttainable Net Data Rate:        992 kbps         13620 kbps Actual Aggregate Tx Power:    -  24.4 dBm           7.4 dBm============================================================================   VDSL Band Status        U0      U1      U2      U3      D1      D2      D3  Line Attenuation(dB):  3.3     14.9    22.6     N/A    7.0     16.8    27.3 Signal Attenuation(dB):  0.0     14.5    0.0      N/A    7.0     16.8    27.3        SNR Margin(dB):  0.0     32.6    0.0      N/A    36.9    0.0     0.0          TX Power(dBm): -128.0  -24.4   -128.0    N/A   -4.6    -22.0   -128.0

[1] http://www.analogzone.com/nett0220.pdf
[2] http://www.ericsson.com/ericsson/corpinfo/publicatio...

Edited by asbokid (Tue 06-Sep-11 00:56:16)

Cool:

# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max:    Upstream rate = 17096 Kbps, Downstream rate = 40792 Kbps
Path:   0, Upstream rate = 9999 Kbps, Downstream rate = 39999 Kbps

Discovery Phase (Initial) Band Plan
US: (0,95) (696,1183)
DS: (32,687) (1192,1627)
Medley Phase (Final) Band Plan
US: (0,95) (696,1183)
DS: (32,687) (1192,1627)
       VDSL Port Details       Upstream        Downstream
Attainable Net Data Rate:      17096 kbps         40792 kbps
Actual Aggregate Tx Power:    -   1.0 dBm          10.0 dBm
============================================================================
  VDSL Band Status        U0      U1      U2      U3      D1      D2      D3
  Line Attenuation(dB):  6.5     31.3     N/A     N/A    15.4    39.2     N/A
Signal Attenuation(dB):  12.4    30.4     N/A     N/A    15.4    39.2     N/A
        SNR Margin(dB):  16.8    16.9     N/A     N/A    6.6     6.5      N/A
         TX Power(dBm): -13.8   -1.3      N/A     N/A    9.2     2.6      N/A

How safe is it to do this.

I'm quite interested to have a poke around but obviously don't fancy the idea of wrecking the modem in the process

The BBU port on the front needs activating. It's clearly an RS232 serial port. The port is seen by the Linux-MIPS kernel as /dev/ttyS1. However, it needs to be enabled in the firmware.[1] As yet, that hasn't been done. There are two binaries in the firmware that try to access the BBU port (/bin/monitor and /bin/equipcmd). The relevant extracts of code from those binaries have been disassembled. For those interested or with suggestions, please email.

It's a puzzle why OpenReach/Huawei ever fitted the BBU port. In early photos of the Huawei in BT's SIN 498 document [2], the BBU port is shown as a USB Type A socket.

The most obvious answer is that BT (at some point) thought battery back-up was a useful thing to have. Whether you agree....

It makes sense in that case to use a connector usually associated with power supplies - I assume that the serial port was intended to get status from a "smart" battery pack. The fact that there's a "battery status" page on the UI also suggests this was the plan.

OK I 'fess up - I bought a spare modem to do this with. However, absolutely no problems with the "upgrade" as per asbokid's instructions. It took less than five minutes.

Where did you buy one from? (how much?)

Keep up the good work ...

It would be interesting to look at an unbranded Huawei too ... they are also made with four Ethernet ports. The code used for the BT variant is likely to be a modified version of the original which may have had additional functionality included.

Battery back up or supply has been considered for FTTC (and FTTH) which would then allow users to have just a DSL line with no telephony associated with the line, just VOIP. The is a requirement for BT to ensure emergency calls can be made in event of a fire/emergency when there is no local power. So far BT do not want to go down that path as it would be very easy for the end user to remove battery power and emergency contact would be lost.