Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[JustAnother]

[JustAnother]

[JustAnother]

See this post below info on xdslcmd --help

http://forum.kitz.co.uk/index.php/topic,10289.msg317080.html#msg317080


admin - added link for xdslcmd --help

[JustAnother]

Reserved post 2.

[JustAnother]

Reserved post 3.

[JustAnother]

Reserved post 4.

[kitz]

[Bald_Eagle1]

Hi kitz,

Very interesting article thank you for posting

>> Annex B:

That has me puzzled because thats the standard for adsl over ISDN and used in certain countries, whereas I thought we used Annex A / Annex M in the uk.

Out of curiousity does the standard firmware connect using annex B or is it just on the unlocked firmware?  My understanding is that the annex defines the mapping available for the downstream/upstream tones for use.  Annex A defines which tones are available for the upstream reserving those needed for POTS.  Im assuming if the router is set at Annex B, yet the standard used by BT is Annex A, the MSAN will just over-ride this.

Here's a snippet from my unlocked modem:-

Code: [Select]

# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 6210 Kbps, Downstream rate = 31968 Kbps
Path: 0, Upstream rate = 6311 Kbps, Downstream rate = 27189 Kbps

Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 3.7 5.5
Attn(dB): 0.0 0.0
Pwr(dBm): 12.3 6.2
VDSL2 framing
Path 0
B: 31 191
M: 1 1
T: 64 40
R: 12 12
S: 0.0374 0.9657
L: 9401 1690
D: 1743 1
I: 44 102
N: 44 204
Counters
Path 0
OHF: 22277373 1375498
OHFErr: 3274 217
RS: 4259640857 2267123
RSCorr: 3490669 947
RSUnCorr: 363316 0

Path 0
HEC: 70735 0

Elsewhere, this is mentioned:-

G.992.3_Annex_K_PTM

Does that help at all?


Paul.

[kitz]

Another Annex B

>>> G.992.3_Annex_K_PTM

Where was that???        Now that is VERY strange - because G.992.3 is actually adsl2!! 
VDSL should be showing as G993.x


Basically the G number defines the type of DSL, whilst the Annex defines the spectral mask in use.
As I mentioned earlier, its the Annex which maps out which tones can be used for (DMT) bitloading and these masks set the maximum bits which can be used in each particular bin (hence why we sometimes see curved bit loading graphs particulary on the upstream and lower end of the downstream).

This is a typical example of an Annex A Mask


- Note the inverted 'U' shape for bitloading

An Annex M Mask simply shunts the lower downstream tones (those that you see with not as much bit loading) over to be available for upstream.  These crossover tones dont get the full bitloading to keep downstream v upstream crosstalk between the 2 technologies to a minimum on the MSAN.

TBH I dont know much about Annex B as I didnt think it was in use in the UK (but then again I dont have any personal experience with VDSL), but off the top of my head it gives some of the POTS reserved tones in Annex A over to the upstream on Annex B

[Bald_Eagle1]

Hi kitz,

Another Annex B

>>> G.992.3_Annex_K_PTM

Where was that???        Now that is VERY strange - because G.992.3 is actually adsl2!! 
VDSL should be showing as G993.x

It comes from the modem's URL http://192.168.1.1/html/status/xdslStatus.asp

The full details are:-

Code: [Select]

var DSLCfg = new Array(newstDsl"InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig",
"Up","VDSL2","","6311","27189","0","0","6348","32044","57","38","0","0","62","123","G.992.3_Annex_K_PTM"),null);

var DSLStats = new Array(new stStats("InternetGatewayDevice.WANDevice.1.WANDSLInterfaceConfig.Stats.Showtime",
"113126","0","585276","0","6252","290","0","0","0","0","0","0"),null); var DslUpTime = "117811";

var time = 0;

It is quite possible that the modem is displaying G.992.3 incorrectly, instead of G.993.2.
It does display some other data back-to-front or a bit "mixed up".

It would appear that a number of bugs may be present in the Broadcom software. The general impression from those that understand these things is that it is rather poorly written.


I see that ITU-T G993.2 does cover "Very high speed digital subscriber line transceivers 2 (VDSL2)"
&
ITU-T G.992.3 covers "Asymmetric Digital Subscriber Line (ADSL) transceivers 2 (ADSL2)"


Paul

EDIT:-
BT's variant of VDSL2 does "optionally" use upstream band U0 (tones 0 to 95).
My understanding is that that US band is used in the UK to assist somewhat with US over longer line lengths.
& some of that actually overlaps with DS band D1 (tones 32 to 859).

I have a "longer" line length, & I see quite a fair amount of bitloading at these lower frequency bands (see attached graph) The blue sections show the "shared" tones



[attachment deleted by admin]

[kitz]

Yep G.993.1 is VDSL and G.993.2 is VDSL2.

I think you may be right about it perhaps being a mixed up display.  As regards to Annex K, I'd not even heard of that before.

Annex B shocked me a bit because I'd not been aware it was in use in the UK, Ive been a bit out of touch in the past year, so I cant really comment if they are using it or not and I need to get myself back up to speed at some point. 

If you are seeing bit loading at the lower frequencies (below 25kHz - Bin 7) then this would indicate some other Annex mask in use.   

>> My understanding is that that US band is used in the UK to assist somewhat with US over longer line lengths & some of that actually overlaps with DS band D1 (tones 32 to 859).

I could be wrong, but that sounds like Annex_L

-----

I need to do some digging, but not tonight, its taken me about 2 hours to type just this as Ive had to rush my cat to the vets tonight where they did a quick emergency op. Im up and down like a yoyo atm, as he's not coping very well with one of those cone collar thingies, and seems to need constant supervision.  Everytime I think he's settled and I go to sit back at the PC, I'll then hear him crash into something. 

[JustAnother]

Merry Christmas, ha, didn't expect the founder to post here!

I have updated the post - as the correct interpretation of Annex B has yet to be decided I've just linked to the first discussion post.

[johnwigley]

Crossposting as may be of interest to many:

http://forum.kitz.co.uk/index.php/topic,15343.msg291580.html#msg291580

[burakkucat]

Assuming one has a Huawei HG612 available (a HG612 that has been unlocked by flashing it with the relevant firmware image [1]) then it is possible to access the device via the LAN2 port, either by ssh or by telnet. From the initial ATP> prompt one can then invoke a Busybox shell.

The command that is of most use, upon which all the monitoring software depends, is the Broadcom xdslcmd utility which interfaces with the Broadcom proprietary driver. The xdslcmd command, when asked, will display its mode of usage --

Code: [Select]

# xdslcmd --help
Usage: xdslcmd start [--up] [--mod <a|d|l|t|2|p|e|m|v>] [--lpair <(i)nner|(o)uter>]
           [--trellis <on|off>] [--snr <snrQ4>] [--bitswap <on|off>] [--sesdrop <on|off>]
           [--sra <on|off>] [--CoMinMgn <on|off>] [--i24k <on|off>] [--phyReXmt <0xBitMap-UsDs>]
           [--TpsTc <0xBitMap-AvPvAaPa>] [--monitorTone <on|off>]
           [--profile <0x00 - 0xFF>|<"8a |8b |8c |8d |12a |12b |17a">] [--us0 <on|off>]
           [--dynamicD <on|off>] [--dynamicF <on|off>] [--SOS <on|off>]
           [--forceJ43 <on|off>] [--toggleJ43B43 <on|off>]
       xdslcmd stop
       xdslcmd connection [--up] [--down] [--loopback] [--reverb]
           [--medley] [--noretrain] [--L3] [--diagmode] [--L0]
           [--tones] [--normal] [--freezeReverb] [--freezeMedley]
       xdslcmd configure [--mod <a|d|l|t|2|p|e|m|v>] [--lpair <(i)nner|(o)uter>]
           [--trellis <on|off>] [--snr <snrQ4>] [--bitswap <on|off>] [--sesdrop <on|off>]
           [--sra <on|off>] [--CoMinMgn <on|off>] [--i24k <on|off>] [--phyReXmt <0xBitMap-UsDs>]
           [--TpsTc <0xBitMap-AvPvAaPa>] [--monitorTone <on|off>]
           [--profile <0x00 - 0xFF>|<"8a |8b |8c |8d |12a |12b |17a">] [--us0 <on|off>]
           [--dynamicD <on|off>] [--dynamicF <on|off>] [--SOS <on|off>]
           [--forceJ43 <on|off>] [--toggleJ43B43 <on|off>]
       xdslcmd bert [--start <#seconds>] [--stop] [--show]
       xdslcmd afelb [--time <sec>] [--tones] [--signal <1/2/8>]
       xdslcmd qlnmntr [--time <sec>] [--freq <msec>]
       xdslcmd inm [--start <BB_THRESH 10*dB> <INMIATO> <INMIATS>] [--stop] [--show]
       xdslcmd snrclamp [--shape <shapeId>] [--bpshape [bpIndex-bpLevel,]]
       xdslcmd diag [--logstart <nBytes>] [--logpause] [--logstop] [--loguntilbufferfull <nBytes>]
           [--loguntilretrain <nBytes>]
       xdslcmd info [--state] [--show] [--stats] [--SNR] [--QLN] [--Hlog] [--Hlin] [--HlinS] [--Bits]
           [--pbParams] [--linediag] [--linediag1] [--reset] [--vendor] [--cfg]
       xdslcmd profile [--show] [--save] [--restore]
       xdslcmd --version
       xdslcmd --help
#

That looks to be a full and complete description of the xdslcmd utility's usage. Or is it?

Quite recently it has been shown that the info sub-command of the xdslcmd utility can take a vectoring flag and then display vectoring information relating to a VDSL2 circuit. [2][3]

For example --

Code: [Select]

# xdslcmd info --vectoring
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason:   0
Last initialization procedure status:   0
Max:   Upstream rate = 4847 Kbps, Downstream rate = 21648 Kbps
Bearer:   0, Upstream rate = 4789 Kbps, Downstream rate = 22059 Kbps
Bearer:   1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Vectoring state: 5
VCE MAC Address: 0:0:0:0:0:0
Total error samples Ethernet pkts sent: 0
Total error samples Ethernet pkts discarded: 0
Total error samples statuses sent: 0
Total error samples statuses discarded: 0
#

Very recently, a discussion took place between the occupants of the Eagle's Nest and The Cattery when it was agreed that attempts should be made to discover any other latent flags of the xdslcmd utility's sub-commands.

A quick look was taken at byte level of the contents of the most recent firmware image and only the following (partial) strings were seen --

Code: [Select]

Broadcom Corporatio
ver. 2.0
6368
96368MVWG
3551453
3217096960
2756608
3219853568
794845
EchoLife_
V100R001C01B030SP08-1407000358
qshs

This forum has many members with a wide range of abilities . . . I wonder if someone would be willing to dismantle the latest firmware image and then look into the binary files that are the Broadcom xDSL driver & the xdslcmd utility, please?

Knowing the help output that is displayed by the utility may then give clues as to which part of the binary file that should be given close scrutiny. Who knows what might be discovered?


[1] Acknowledging the work of Asbokid in developing the procedure & creating the initial unlocked firmware image and Wolfy's later work in creating the more recent unlocked firmware images.
[2] http://forum.kitz.co.uk/index.php/topic,14361.msg315738.html#msg315738
[3] http://forum.kitz.co.uk/index.php/topic,15593.msg315751.html#msg315751

[ejs]

Looking at the strings in xdslcmd, there's probably:
--phycfg
--mcfg
--lcfg
They probably are used with the configure sub-command, but it might be impossible to determine what they are for, especially if they just take some hexadecimal digits as input.

Possibly there's xdslcmd info --toneGroupObjects

xdslcmd diag
--dumpBuf
--dbgcmd


Looking in the driver, I'm not sure how much will be interesting. There appears to be some sort of provision for the ability to disable bitswap and VN (virtual noise?) when vectoring is in use.

DRV VECT(VECTORMGR_SET_MODE_CMD_ID): disableBS=0x%x disableVN=0x%x, MSG: disableBS=0x%x disableVN=0x%x direction=%d

There's also something similar about that in the Broadcom AdslMibDef.h file included with the source code for some devices.