General Discussion
  >> Fibre Broadband


Register (or login) on our website and you will not see this ad.


Pages in this thread: 1 | 2 | 3 | 4 | 5 | 6 | [7] | 8 | (show all)   Print Thread
Standard User Bald_Eagle1
(regular) Sun 11-Dec-11 23:14:55
Print Post

Re: SNRM & Error levels


[re: WWWombat] [link to this post]
 
Right Folks,

To help me try to understand what is what, I needed to put the relevant data into one table. I ran the xdsl info --show & xdslcmd info --stats commands as close to each other as possible & grabbed a GUI screenshot a few seconds later:-

EDIT: I have only shown the DS data in the table as it seems to be the most relevant.

Text
1
23
45
67
89
1011
1213
1415
1617
1819
2021
2223
2425
2627
2829
3031
3233
3435
3637
3839
40
DESCRIPTION     info --show     info --stats    GUI
                        B:              31              31              N/A
M:              1               1               N/AT:              64              64              N/A
R:              12              12              N/AS:              0.0398          0.0398          N/A
L:              8834            8834            N/AD:              1637            1637            N/A
I:              44              44              N/AN:              44              44              N/A
                Counters                Path 0
OHF:            14469179        14469439        N/AOHFErr:         2967            2967            2967 (shown as FEC in the GUI)
RS:             1261294406      1261394391      N/ARSCorr:         35885878        35885879        N/A
RSUnCorr:       118032          118032          118032 (shown as CRC in the GUI) 
                Path 0HEC:            20937           20937           20937 (shown as HEC in the GUI)
OCD:            0               0               N/ALCD:            0               0               N/A
Total Cells:    2726621042      2726670109      N/AData Cells:     4525231         4525231         N/A
Drop Cells:     0               0               N/ABit Errors:     0               0               N/A
 ES:             22179           22179           N/A
SES:            62              62              N/AUAS:            48              48              N/A
AS:             55566           55567           55572 (shown as DSL up time) 
                Path 0INP:            8.50            8.5             N/A
PER:            3.820           3.82            N/Adelay:          16.00           16.00           N/A
OR:             50.19           50.19           N/A 
Bitswap:        11201           11202           N/A




As I only ever really want to know at a quick glance how my connection is performing since its most recent re-sync (NOT REBOOT), I have been referring to the GUI at http://192.168.1.1/html/content.asp

which uses the data as displayed at URL
http://192.168.1.1/html/status/xdslStatus.asp

As mentioned previously, I am currently using the data from this URL in my stats harvesting & graphing scripts.

One of my harvesting scripts maintains an ongoing stats log 24/7, with samples collected every minute, so I can always refer back to previous sync events & reboots if I ever need to.

The values all match exactly.

You will see from the above table that the GUI reports:-

OHFErr: as FEC Errors.
RSUnCorr: as CRC Errors.
HEC: as HEC Errors.

If any of you study the data from lower down the xdslcmd info --stats log, you will notice that Total time = 1 days 15 hours 1 min 40 sec NEVER exceeds 1 day.
I'm not quite sure what this Total time refers to as it doesn't seem to tie up with any other data.

Even lower down the xdslcmd info --stats log is this entry:-
Since Link time = 15 hours 26 min 7 sec.

From my ongoing log, I see that my connection re-synced at 05:43 this morning (to the nearest full minute).

As always, the error counts & the DSL up time as shown in the GUI were reset to ZEROS.

I ran the xdslcmd commands at 21:09 this evening.
Taking one from the other I get 15 hours & 26 minutes.

That's near enough for me to be equivalent to the data reported at the "Since Link time" entry to be the 55572 seconds DSL up time as reported in the GUI.

FYI, according to the Device GUI page, my modem had been connected for 2 days 14 hours 55 minutes & 47 seconds since its last REBOOT around the time I started pulling these details together.
According to my ongoing log & my memory, I rebooted the modem at 06:14 on 9th December.

Adding those timings together gets us to 21:09 this evening again.

So, we can also confirm that AS does NOT equate to the time since the latest REBOOT.


As I understand things (may be wrong though) CRC errors are uncorrectable.
This appears to be the RSUnCorr: data & also the CRC Errors data as reported in the GUI.

I don't know what OHFErr actually means, but it is the data reported as FEC Errors in the GUI.

HEC: exactly matches the HEC Errors as reported in the GUI.


So the question is:-

Is the GUI correctly reporting errrors after all or not?



Paul


EDIT:
RSCorr: for my connection was reported as 35885878.
Does that seem too much for a 15.5 hour connection for it to be FEC errors?

Edited by Bald_Eagle1 (Sun 11-Dec-11 23:22:13)

Standard User XRaySpeX
(eat-sleep-adslguide) Sun 11-Dec-11 23:59:09
Print Post

Re: SNRM & Error levels - EDITED x 2


[re: Bald_Eagle1] [link to this post]
 
In reply to a post by Bald_Eagle1:
This appears to be the RSUnCorr: data & also the CRC Errors data as reported in the GUI.
You will/should notice in the Since Link Time section of the xdslcmd info --stats log, which you didn't post, that CRC equates to the OHFErr field and FEC equates to the RSCorr field. Contradicts GUI interpretation!

Which is more likely to be correct, the primitive i/f or the high-level one?

EDIT: Your AS does indeed look like uptime since last resync. In which case the all the error counts would seem too high for that period, as you pointed out for RSCorr, and so must have been counted since last reboot. Even your ES are high at 1 every 2.5 secs. (confused but you stated error counts were zero at last resync 15 hours ago)

EDIT2: Just remembered, AS is uptime since last RESYNC. But my error counts are not zeroised at same time. So I have to keep remembering to look at GUI LAN uptime when analysing errors.

1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU => 2010: Orange 16 Meg LLU => 2011: Orange 19 Meg WBC

Edited by XRaySpeX (Mon 12-Dec-11 05:21:59)

Standard User Bald_Eagle1
(regular) Mon 12-Dec-11 00:41:08
Print Post

Re: SNRM & Error levels


[re: XRaySpeX] [link to this post]
 
In reply to a post by XRaySpeX:
You will/should notice in the Since Link Time section of the xdslcmd info --stats log, which you didn't post, that CRC equates to the OHFErr field and FEC equates to the RSCorr field. Contradicts GUI interpretation!

Which is more like to be correct, the primitive i/f or the high-level one?



I hadn't noticed the FEC from the Since Link Time section equating to the RSCorr field. Thanks for pointing that out.

However, in various other documents, I have read that RSUncorr is usually reported as CRC errors, not OHFErr.

I have been unable to determine anywhere what OHFErr actually means.

From higher up the log:-
OHFErr: 2967
RSCorr: 35885879
RSUnCorr: 118032

From the Since Link Time section
FEC: 35885879
CRC: 2967

I really don't know which is correct as there appear to be a few discrepancies.

The error counts as reported in the GUI were indeed set to zero.
I have seen them climb during the day.

So, maybe some of the stats from xdslcmd info --stats relate to the connection since re-sync & some of them relate to to the connection since reboot ???

My whole xdslcmd info --stats log:-

Text
1
23
45
67
89
1011
1213
1415
1617
1819
2021
2223
2425
2627
2829
3031
3233
3435
3637
3839
4041
4243
4445
4647
4849
5051
5253
5455
5657
5859
6061
6263
6465
6667
6869
7071
7273
7475
7677
7879
8081
8283
8485
8687
8889
9091
9293
9495
9697
9899
100101
102103
104105
106107
# xdslcmd info --stats 
xdslcmd: ADSL driver and PHY statusStatus: Showtime
Retrain Reason: 2Max:    Upstream rate = 5922 Kbps, Downstream rate = 31616 Kbps
Path:   0, Upstream rate = 5941 Kbps, Downstream rate = 25549 Kbps 
Link Power State:       L0Mode:                   VDSL2 Annex B
VDSL2 Profile:          Profile 17aTPS-TC:                 PTM Mode
Trellis:                U:ON /D:ONLine Status:            No Defect
Training Status:        Showtime                Down            Up
SNR (dB):        5.1             6.0Attn(dB):        0.0             0.0
Pwr(dBm):        12.1            6.3                        VDSL2 framing
                        Path 0B:              31              175
M:              1               1T:              64              40
R:              12              12S:              0.0398          0.9400
L:              8834            1600D:              1637            1
I:              44              94N:              44              188
                        Counters                        Path 0
OHF:            14469439                557050OHFErr:         2967            52
RS:             1261394391              214596RSCorr:         35885879                327
RSUnCorr:       118032          0 
                        Path 0HEC:            20937           0
OCD:            0               0LCD:            0               0
Total Cells:    2726670109              0Data Cells:     4525231         0
Drop Cells:     0Bit Errors:     0               0
 ES:             22179           120
SES:            62              0UAS:            48              48
AS:             55567 
                        Path 0INP:            8.50            0.00
PER:            3.82            9.40delay:          16.00           0.00
OR:             50.19           27.23 
Bitswap:        11202           1053 
Total time = 1 days 15 hours 1 min 40 secFEC:            69259181                671
CRC:            79524           157ES:             22179           120
SES:            62              0UAS:            48              48
LOS:            9               0LOF:            10              0
Latest 15 minutes time = 1 min 40 secFEC:            686             0
CRC:            0               0ES:             0               0
SES:            0               0UAS:            0               0
LOS:            0               0LOF:            0               0
Previous 15 minutes time = 15 min 0 secFEC:            144726          0
CRC:            311             0ES:             7               0
SES:            2               0UAS:            0               0
LOS:            0               0LOF:            0               0
Latest 1 day time = 15 hours 1 min 40 secFEC:            33408666                96
CRC:            2923            42ES:             166             30
SES:            15              0UAS:            0               0
LOS:            0               0LOF:            0               0
Previous 1 day time = 24 hours 0 secFEC:            33644772                451
CRC:            70179           65ES:             21820           46
SES:            22              0UAS:            16              16
LOS:            5               0LOF:            5               0
Since Link time = 15 hours 26 min 7 secFEC:            35885879                327
CRC:            2967            52ES:             193             31
SES:            15              0UAS:            0               0
LOS:            0               0LOF:            0               0


Register (or login) on our website and you will not see this ad.

Standard User XRaySpeX
(eat-sleep-adslguide) Mon 12-Dec-11 01:16:51
Print Post

Re: SNRM & Error levels


[re: Bald_Eagle1] [link to this post]
 
In reply to a post by Bald_Eagle1:
The error counts as reported in the GUI were indeed set to zero.
But were they reported as zero at that time by xdslcmd?

Perhaps you should start from a fresh reboot and keep your eye on them.

Even if your error counts are counted since reboot time (2d 15h), your RSCorr, HEC & ES are terribly high, far higher than the last 2 posters to post theirs. Even ES are 1 every 10 secs; I would expect at least 60 sec per ES.

Maybe VADSL is so fast that error mount up more quickly. But I can't believe that; I'm only running at half your speed on ADSL2+ wink

1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU => 2010: Orange 16 Meg LLU => 2011: Orange 19 Meg WBC
Standard User john2007
(legend) Mon 12-Dec-11 08:45:27
Print Post

Re: SNRM & Error levels


[re: Bald_Eagle1] [link to this post]
 
OHF possibly means superframe thus OHFErr would be superframe error.
Standard User Bald_Eagle1
(regular) Mon 12-Dec-11 09:17:18
Print Post

Re: SNRM & Error levels


[re: john2007] [link to this post]
 
In reply to a post by john2007:
OHF possibly means superframe thus OHFErr would be superframe error.



Thanks for that info.
Just as you posted, I noticed from asbokid's blog that the same HG612 modem used on an ADSL2+ connection does report SF & SFErr instead of OHF & OHFError in the same "Counters" section of the xdslcmd info --stats log.

Now, what are SF & SFErr, do they at all relate to FEC errors, & are they worth reporting?

It does indeed appear that the GUI is reporting HEC & CRC errors correctly, the query remaining is what should it actually be reporting for FEC errors?

It appears that it should be reporting either FEC: from the "Since Link time" section, or RSCorr from the "Counters" section (identical values).
The GUI is currently reporting OHFErr as the FEC Errors value.

Edited by Bald_Eagle1 (Mon 12-Dec-11 09:20:36)

Standard User john2007
(legend) Mon 12-Dec-11 11:00:53
Print Post

Re: SNRM & Error levels


[re: Bald_Eagle1] [link to this post]
 
FEC error is a misnomer. They are packets with errors which have been automatically corrected at the receiver.

I would have thought if a superframe is in error you'd have CRC errors reported for the individual frames, so I guess you'd be double reporting errors.
Standard User WWWombat
(committed) Mon 12-Dec-11 12:36:20
Print Post

Re: SNRM & Error levels


[re: Bald_Eagle1] [link to this post]
 
Here's my accumulated knowledge on the errors. It might help!!!


In ADSL, all data is transferred back-and-forth in Frames & SuperFrames. These frames define the layout of data so that the modem can latch onto the real end-user data; to do this it surrounds that data by some "marker" data, some control information, and the CRC checksums.

There are 4000 frames per second (*) - one frame takes 0.25ms. Obviously the size of data within each frame varies according to the overall sync speed achieved.

The specs then define a sequence of frames to be one SuperFrame. The SF takes 17ms, and consists of 69 frames: 68 real data frames and 1 synchronisation frame.

(*) The 4000 frames/sec rate is the rate of real data frames; with the addition of the sync frames, there are actually (69/68)*4000 frames per second = 4058.

One SF every 17ms is almost 59 SF's per second.

So... How does this relate to the errors?

1. If the modem fails to find the sync frame where it expects it (ie every 69th frame), this counts as a Framing Error. If this persists for long period (ie seconds or more), this is counted in the LOF (Loss of Framing) counter.

LOF probably leads to the modem needing to perform a resync.

2. CRCs are transmitted per SF, so it goes to say that SFErr would be very similar to the count of CRC errors.

3. If the modem doesn't receive *anything*, this gets counted (as a number of seconds) in the LOS (Loss of signal) counters

LOS probably leads to the modem needing to perform a resync.

4. ES, SES and UAS are all a count of seconds too: Errored Seconds; Severe Errored Seconds; and UnAvailable Seconds.

UAS looks to be the accumulated time that the modem has been performing Syncs: It tends to start at around 7-10 after the first sync, and goes up in rough multiples.

ES is the number of second-long periods in which 1 or more errors occurred (I take it to mean CRC errors). If you get high CRC counts and low ES, it means the errors come in short sharp bursts (and SES is likely to increment). If CRC and ES go up at the same sort of rate, then the errors are coming in a spread-out fashion.

SES is the number of second-long period where severe error rates occurred (I take it to mean lots of errors within the 1 second, but I don't know how many "lots" are).

5. From (4), I assume that AS would be Available Seconds, but I've never seen it before!

So "uptime" for the device ought to be a total of both AS and UAS.

It isn't clear whether AS is only the time for this most recent sync, or it accumulates over each & every sync.

6. FEC is "Forward Error Correction", where small faults in data are detected & corrected using "Reed Solomon" (RS) blocks, and only apply to interleaved data. When interleaving is present, the data is spread (interleaved) amongst many frames to provide protection.

I assume that FEC & interleaving work *within* a SF, and that CRC verification works on the data block *after* FEC has corrected anything that needed correcting, and re-orders the interleaved blocks. That seems logical, as there's no way that CRC checks would work on uncorrected, unordered data.

7. RSCorr is the count of RS blocks that have been successfully corrected - and presumably don't lead to CRC errors.

8. RSUnCorr is the count of RS blocks that were not successfully corrected, and presumably lead to CRC errors.

However, RSUnCorr are *not* CRC errors directly. There can be both many RS blocks per SF (so many RSUnCorr can lead to a single CRC error) *and* there can be zero RS blocks per SF - any data sent in the fast path (ie is not interleaved) is not part of the RS blocks but can still cause a CRC error.

9. As I mentioned yesterday, I always though that HEC represented errors in the ATM encapsulation (as Framing Errors & CRC counts cover all the data within the ADSL frames themselves).

But I didn't think that ATM applies to FTTC, so I'm really not sure what is being counted here. I note that HEC is reported in a section that mentions "cells", but cells are the method of encapsulation within ATM. Curiouser & curiouser

When I graphed my Netgear's stats for CRC & HEC for ADSL, I noticed that whenever the HEC count incremented, then CRC would also always increment. However, the CRC count could increment on its own too. That means the CRC count was always guaranteed to be >= HEC count. That doesn't happen to my VDSL stats.

So... all that was for ADSL. I don't know how that information maps onto VDSL2 and its use within FTTC, but there are some obvious parallels:

a. It seems the "OHF" is the VDSL equivalent to "SF", and that OHFErr might be the real CRC error count.

b. "OHF" goes up 4,500 every 10 seconds on my modem, suggesting VDSL2 is running at 450 OHF's per second. That suggests you could see up to 450 CRC's per second maximum.

On my 40Mbps connection, it suggests almost 89Kb per OHF.

c. RS goes up 864,000 every 10 seconds on my modem, suggesting 192 RS blocks per OHF.

On the 40Mbps connection, that would be about 460 bytes per RS block.

d. "Cells" goes up 770,000 every 10 seconds.

On 40Mbps, that would be 520 bytes per cell. Real ATM has only 48 data bytes plus 5 header bytes per cell. However, FTTC certainly doesn't suffer from that 5/53 overhead (9.5%), so can't really be based on ATM.

I really don't know how to interpret Cells & HEC here.


Then there is the matter of the "--stats" presentation. This is done in a slightly funny way...

Think of the modem as keeping a few separate "pots" of counters that it increments every time an error occurs.

The "--stats" options causes these pots to be printed out in the following order:

1. Total Time
This pot is reset at reboot, and increments whenever an error is trapped.
The time given ought to be the total time, but looks to be incorrect.
(On my modem, the ES, SES, UAS, LOS and LOF values are higher than those in "Since Link" below, suggesting this pot covers a longer period)

2. Latest 15 minutes
This pot is reset once every 15 minutes, and increments inbetween.
The time shows how long since the last reset (ie will be less than 15 mins)

3. Previous 15 minutes
This pot is created as a copy of (2) just before that one is reset; it does not increment.
The time shows 15 minutes, because (2) is reset at the 15 minute point.

4. Latest 1 day
This pot is reset once every 24 hours, and increments inbetween.
The time shows how long since the last reset (ie will be less than 24 hours)

5. Previous 15 minutes
This pot is created as a copy of (4) just before that one is reset; it does not increment.
The time shows 24 hours, because (4) is reset at the 24 hour point.

6. Since Link
It looks like:
This pot is created at the establishment of the link, and reset at resync.
The time shows the length of time that the link has remained in sycn.
(On my modem, the ES, SES, UAS, LOS and LOF values are lower than those in "Total Time" above, suggesting this pot covers a shorter period. I have zero values for UAS, LOS, LOF which suggest it only counts errors since the line was last shown as available)

To conclude:
The right number for FEC comes from "RSCorr". Logging this lets you know how many tiny, correctable, errors have been introduced on your line. It currently looks like the same number is presented in the "Since Link" FEC counter, but can't be sure.

The right number for CRC is not RSUnCorr, but might be OHFErr. It currently looks like the same number is presented in the "Since Link" CRC counter, but can't be sure. Logging this lets you know the bigger uncorrectable errors encountered by the line.

My experience of HEC means that I'm not convinced the HEC here is the same as it was in ADSL, so I don't know the value of logging it.
Standard User XRaySpeX
(eat-sleep-adslguide) Mon 12-Dec-11 17:30:40
Print Post

Re: SNRM & Error levels - EDITED


[re: WWWombat] [link to this post]
 
A very comprehensive analysis, which comes round to the interpretation of the error types that I posted yesterday.
In reply to a post by WWWombat:
So "uptime" for the device ought to be a total of both AS and UAS.
It looks like you have solved something that has always puzzled me: why AS only approximates to the time in secs since last resync.
In reply to a post by WWWombat:
1. Total Time
This pot is reset at reboot, and increments whenever an error is trapped.
The time given ought to be the total time, but looks to be incorrect.
It always looks like this Total Time is the time since the last reboot, but after discarding all the days from day 2 onwards. E.g. Reboot time 14d 15h 1m 40s ago shows as:
Total time = 1 days 15 hours 1 min 40 sec


1999: Freeserve 48K Dial-Up => 2005: Wanadoo 1 Meg BB => 2007: Orange 2 Meg BB => 2008: Orange 8 Meg LLU => 2010: Orange 16 Meg LLU => 2011: Orange 19 Meg WBC

Edited by XRaySpeX (Mon 12-Dec-11 17:37:22)

Standard User asbokid
(regular) Mon 12-Dec-11 18:18:03
Print Post

Re: SNRM & Error levels


[re: WWWombat] [link to this post]
 
Excellent information from WWWombat. Thank you for posting it!

Hopefully the TBB contributor, JustAnother, will be able to incorporate it into his very useful FAQ for the xdslcmd tool. [1]

Unpacking the server-side scripts used by the web server embedded in the Huawei can also help to identify the 'Anomaly Counters' displayed in the GUI.

We can look a bit closer at the xDSL MIB objects passed in the parameter lists of those server-side scripting functions.

Here is the parameter list for the function call webGetCfgEntry() found in the .asp resource at http://192.168.1.1/html/status/xdslStatus.asp :

Text
1
23
45
67
89
1011
1213
1415
16
var DSLStats =
<%webGetCfgEntry(InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.Stats.Showtime,    HECErrors|
    ATUCHECErrors|    CRCErrors|
    ATUCCRCErrors|    FECErrors|
    ATUCFECErrors|    X_ATP_HECErrors_2|
    X_ATP_ATUCHECErrors_2|    X_ATP_CRCErrors_2|
    X_ATP_ATUCCRCErrors_2|    X_ATP_FECErrors_2|
    X_ATP_ATUCFECErrors_2,stStats);
%>;


Before serving up that .asp resource, the Huawei's scripting engine dynamically populates the parameters to the function:

Text
1
23
45
67
89
1011
1213
14
var DSLStats = new Array(new stStats("InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.Stats.Showtime",
    "292008",    "0",
    "1074551",    "0",
    "42205",    "105",
    "0",    "0",
    "0",    "0",
    "0",    "0"),
null);


In the above example from Paul's line, we can determine the following:

Text
1
23
45
67
89
1011
1213
..
  HECErrors              = 292008  ATUCHECErrors          = 0
  CRCErrors              = 1074551  ATUCCRCErrors          = 0
  FECErrors              = 42205  ATUCFECErrors          = 105
  X_ATP_HECErrors_2      = 0  X_ATP_ATUCHECErrors_2  = 0
  X_ATP_CRCErrors_2      = 0  X_ATP_ATUCCRCErrors_2  = 0
  X_ATP_FECErrors_2|     = 0  X_ATP_ATUCFECErrors_2  = 0



The acronym "ATUC" is jargon for ADSL Transceiver Unit in Central Office [3]. In plainspeak, ATUC means the DSLAM.

Similarly, the xDSL modem in the consumer premises is known by the official acronym ATU-R, where 'R' means Remote.

Just to confuse things further, ATU-C and ATU-R are identified in the Broadcom driver source code as the "Far End" (FE) and the "Near End" (NE) !

So ATUCHECErrors is a count of the HEC Errors measured at the DSLAM.

All of those function parameters shown above, starting with HECErrors and ending with X_ATP_CFECErrors_2, are defined in a XML model of the xDSL MIB for the Huawei.

That MIB model is found in the Huawei's root file system under the filename /etc/t_tree.xml

The full 84kB XML MIB file can be viewed at [2]

Below is an excerpt from that MIB model showing a part of the Stats.Showtime subtree:

Text
1
23
45
67
89
1011
1213
1415
1617
1819
2021
2223
2425
2627
28
<Stats CMO="0x00008A00">
        <Showtime CMO="0x00009000">          <ReceiveBlocks CMO="0x00009001" Type="VALUE_TYPE_ULONG"
          AppName="cms" MaxLength="0" DefaultValue="0xFFFFFFFF" />          <TransmitBlocks CMO="0x00009002" Type="VALUE_TYPE_ULONG"
          AppName="cms" MaxLength="0" DefaultValue="0xFFFFFFFF" />[...]
          <SeverelyErroredSecs CMO="0x00009005"          Type="VALUE_TYPE_ULONG" AppName="cms" MaxLength="0"
          DefaultValue="0xFFFFFFFF" />          <HECErrors CMO="0x00009006" Type="VALUE_TYPE_ULONG"
          AppName="cms" MaxLength="0" DefaultValue="0xFFFFFFFF" />          <ATUCHECErrors CMO="0x00009007" Type="VALUE_TYPE_ULONG"
          AppName="cms" MaxLength="0" DefaultValue="0xFFFFFFFF" />          <CRCErrors CMO="0x00009008" Type="VALUE_TYPE_ULONG"
          AppName="cms" MaxLength="0" DefaultValue="0xFFFFFFFF" />          <ATUCCRCErrors CMO="0x00009009" Type="VALUE_TYPE_ULONG"
          AppName="cms" MaxLength="0" DefaultValue="0xFFFFFFFF" />          <FECErrors CMO="0x0000900A" Type="VALUE_TYPE_ULONG"
          AppName="cms" MaxLength="0" DefaultValue="0xFFFFFFFF" />          <ATUCFECErrors CMO="0x0000900B" Type="VALUE_TYPE_ULONG"
          AppName="cms" MaxLength="0" DefaultValue="0xFFFFFFFF" />[...]
          <X_ATP_ATUCFECErrors_2 CMO="0x00009011"          Type="VALUE_TYPE_ULONG" AppName="cms" MaxLength="0"
          DefaultValue="0xFFFFFFFF" />        </Showtime>
      </Stats>


The XML shows us the MIB OIDs, the datatypes of the elements, and the applications from where their current values are obtained.

In the Huawei, there appears to be a message server (/bin/MidServer) which actually retrieves the statistical data on behalf of the web server. The MidServer proxies all requests for MIB objects and dispatches those requests to the appropriate application {cms|cwmp|cli|tr064| etc.} to obtain an answer.

There is probably enough understood of the xdlscmd binary to reverse-engineer it now. It could be re-written as an open source application.

The xdslcmd tool is found (under a variety of names) in tens of millions of Broadcom 63xx-based broadband access units, so an open source tool would potentially benefit a large number of end-users.

Much of this work has already been done under the auspices of the openwrt.org and the ddwrt open-source firmware projects. [4][5]

cheers, a

[1] http://forum.kitz.co.uk/index.php/topic,10289.0.html
[2] http://pastebin.com/XbDjJC3T
[3] http://www.analytic.ru/articles/lib26.pdf
[4] http://openwrt.org/
[5] http://www.dd-wrt.com/
Pages in this thread: 1 | 2 | 3 | 4 | 5 | 6 | [7] | 8 | (show all)   Print Thread

Jump to