Kitz Forum
Broadband Related => Broadband Hardware => Topic started by: burakkucat on October 26, 2013, 11:36:34 PM
-
In my grotto I have a Huawei HG612 Home Gateway and a Planet VC-230N. The latter device is currently configured in CO mode with profile 17a.
If it would be considered worthwhile, I could flash each of the various firmware images listed below into the HG612 and record the basic statistics once the device has synchronised with the VC-230N. Each test would be carefully controlled to ensure that they were all carried out under identical conditions.
The firmware images that I have selected for testing are:
- The original Asbo unlocked
- The Asbo unlocked, with the new BLOB
- The Wolfy unlocked, with the GUI
Do fellow Kitizens think it would be worthwhile exercise? :-\
-
Do fellow Kitizens think it would be worthwhile exercise? :-\
Indeed it would 8)
-
Thank you. Obviously my testing would not be as extensive as that which Asbokid could perform with his Huawei SmartAX MA5616 MSAN :no: but it should provide some metrics for comparison. :)
-
Sounds really helpful especially if you have enough cable to give some typical attenuation between the devices. I would not have thought that the trouble that Asbo went to with baluns would be needed as you be using the same device with any impedance issues fixed, and just changing firmware.
-
I agree, it looks like very useful research.
-
Thank you, all, for your feedback.
I've put this little project onto my 'ToDo' list and now will try to find the time to action it. ;)
-
Finally 'the time was ripe' ((C) 1980s Sir Humphrey Appleby of Yes, Minister and Yes, Prime Minister fame) and some testing was performed.
The HG612 firmware images tested were:
(1) Original Asbo Image Unlocked.
(2) Asbo Image Unlocked, With New BLOB.
(3) Wolfy Image Unlocked, With GUI.
The VC-230N Configuration ('One Port DSLAM'):
Profile 17a, Annex A.
SNRM set to 6 dB.
Interleaved (8 ms).
INP set to 3.
No rate capping.
Local loop length == 1.5 metres.
Testing Procedure:
VC-230N powered up.
After 5 minutes, HG612 powered up.
After 5 minutes, HG612 GUI statistics gathered,
HG612 CLI statistics gathered,
VC-230N GUI statistics gathered.
Attached, below, are four files -- showing the VC-230N's configuration and the line_stats_p obtained from the HG612 with each of the firmware images, listed above, installed in turn.
-
Attached, below, are the corresponding first HG612 GUI pages for each of the firmware images tested.
-
Attached, below, are the corresponding second HG612 GUI pages for each of the firmware images tested.
-
Attached, below, are the corresponding VC-230N GUI pages for each of the firmware images tested.
-
Finally the ASCII text data from the HG612, for each of the firmware images tested, can be supplied via e-mail to anyone interested.
The data collected was the output returned by the following nine xdslcmd lines --
- xdslcmd --version
- xdslcmd profile --show
- xdslcmd info --vendor
- xdslcmd info --cfg
- xdslcmd info --stats
- xdslcmd info --show
- xdslcmd info --Bits
- xdslcmd info --pbParams
- xdslcmd info --linediag
-
Thank you B*cat.. I has headache & since I have to be up early tomorrow, now is possibly not the best time for me to be looking at stats in depth :D
I shall give closer strutiny to pbParams and graphs when I have a clear head, however I cant help but notice both of Asbos give a similar attainable rate on the HG GUI. The 3rd shows a better SNRm and therefore higher attainable rate. I do note that the 3rd upstream attainable appears to be capped at 51316?
-
I do note that the 3rd upstream attainable appears to be capped at 51316?
That is very odd. It is certainly not something that I had configured . . . The VC-230N was (and still is) set to 'No rate capping'. ???
I'll send you a ZIP format file of all the data, via e-mail, for your consideration on another day -- when there are less empty wine bottles a-rolling across the floor, chased by kittehs . . . ::)
-
Finally the ASCII text data from the HG612, for each of the firmware images tested, can be supplied via e-mail to anyone interested.
I'd also be interested in a copy of the zip file containing all the data, please.
-
How could I forget that beak? :-X My tail still remembers the last time that it was tweaked. :'(
-
Thank you black cat, I has mail... but Im not going to attempt to open it tonight as I am off to my bed now. Will be tomorrow eve at the earlier before I get chance to look. No doubt by then someone else may have dissected the results.
The obvious thought that did occur is if its the apparent capping of the upstream thats giving the increase in the downstream.
HowlingWolf's firmware includes the new banding profiles and separation of the up/down tones in U0 yes? Wonder if theres something in there that also limits the max up sync.
Any-hows its good night from me.
-
How could I forget that beak? :-X My tail still remembers the last time that it was tweaked. :'(
Miaow!
Slightly different format, but the graphs are re-attached, differentiating 'shared/other' tones etc.
The results are ever so slightly mis-leading though as the Planet VC-230N in CO mode delivers slightly different band plans to those delivered by Beatty on a live connection.
The updated firmware does look like the winner though.
Somewhat surprisingly, there is still no US data contained in the raw data for QLN, Hlog & SNR, even when using the updated firmware (as shown in graph F3).
-
Slightly different format, but the graphs are re-attached, differentiating 'shared/other' tones etc.
I knew you would do that. Thank you. :)
The results are ever so slightly mis-leading though as the Planet VC-230N in CO mode delivers slightly different band plans to those delivered by Beatty on a live connection.
Absolutely true. That fact definitely needs to be emphasised. As I mentioned in the third post to this thread: ' . . . should provide some metrics for comparison.' So to expand on that statement, the three sets of experimental data can be compared -- one with another -- but should not be taken as 'absolute' or compared with the results obtained from a live Openreach NGA GEA-FTTC VDSL2 circuit.
The updated firmware does look like the winner though.
I concur. The latest Beattie firmware image does appear to 'come out on top'. :clap2: :dance: :silly:
:drink: for Wolfy -- for unlocking Beattie's latest firmware image, thus allowing these tests to take place.
-
Thanks for the test. A test with some attenuation would be really conclusive. You don't happen to have a a good length of 100m of cat 5 or other twisted pair cable do you? It is easy to run through each pair in turn giving a length e.g. 4 times with 4 pairs.
-
:hmm: Hmm . . .
Having just had a good 'rummage' in the bowels of my grotto, I have resurfaced with a reel of 6-core, three pair, CW1308 cable.
The next steps will be to fit a battery of cells to the Tester 301C, measure the length of its pair of test leads, loop one of the pairs of the CW1308 cable at its far end, connect the looped pair & one of the other open-circuited pairs to the two pairs of input sockets of the 301C and thus determine the length of the CW1308 cable, by use of the 301C in differential mode. (Having remembered to subtract the length of the test leads from the result obtained.) ::)
Then some thought will need to be applied to the method of connecting that CW1308 cable to the RJ11 sockets of the VC-230N and the HG612. Perhaps the simplest method will be best? Take the shortest RJ11 to RJ11 lead from the multitude that are 'held in reserve', sever it at the mid-point and attach each half to the two ends of the 'local loop'.
So yes, Les, a test with a longer 'local loop' will be possible. However I think I should repeat the last test (F3-Test) -- in view of the anomaly that Our Leader, Kitz, has noticed.
-
The test leads were measured at 1.5 metres. The Tester 301C indicated a total length of between 133 - 134 metres for the CW1308 cable plus the test leads.
Hence I shall refer to a 'local loop' length of 396 metres, when the next set of tests are performed. :)
-
I was going to buy a dslam but I expect its not as simple as plugging in a cable, and they not that cheap either.
-
I believe (if my memory serves me correctly) that Asbokid has previously indicated that he would be willing to sell his second Huawei SmartAX MA5616 to a fellow experimenter, with the money going as a donation to the Dogs' Trust.
In a reply (dated: November 23, 2012 at 10:15 pm) to a query (asked in a comment to his MA5616 MSAN blog (http://insidehuaweima5616msan.wordpress.com/about/)) Asbokid said --
The barebones MA5616 start at about £100 on Taobao, the Chinese version of ebay. Linecards are £80 for a 32-port ADSL2+, and quite a bit more for a VDSL2 linecard.
Shipping from China and Customs charges on top of that.
-
yeah when i ooked on ebay all 32 port ones were sold out.
I also may have not been looking at the right adverts. The ones I seen were circa £500.
-
yeah when i ooked on ebay all 32 port ones were sold out.
I also may have not been looking at the right adverts. The ones I seen were circa £500.
Chrys, you were probably looking at this eBay listing (http://www.ebay.co.uk/itm/261266570475)? :-\
Asbokid's purchase was direct from an agent in China and not via eBay. Other than that, I know no further details.
-
I think I shall wait for 'others' to digest the information so far obtained and, perhaps, repeat those initial three tests 'to be absolutely sure' of the results.
Testing with a longer 'local loop', as suggested by Les, will then be performed.
-
Chrys, you were probably looking at this eBay listing (http://www.ebay.co.uk/itm/261266570475)? :-\
Asbokid's purchase was direct from an agent in China and not via eBay. Other than that, I know no further details.
I seem to recall him saying that his postage was practically as much as what he paid for the dslam... and it took an eon for it to arrive. :(
-
yeah when i ooked on ebay all 32 port ones were sold out.
I also may have not been looking at the right adverts. The ones I seen were circa £500.
Chrys, you were probably looking at this eBay listing (http://www.ebay.co.uk/itm/261266570475)? :-\
Asbokid's purchase was direct from an agent in China and not via eBay. Other than that, I know no further details.
yeah probably so I meant 16 ports sold out.
-
Thanks b*cat for the stats which Ive just had a look at. Thanks too for BE providing the graphs.
Other than what has already been observed I dont have much else to add.
Re the 'upstream cap'
Ive done a quick rough & ready calculation on the changes in the upstream band.
If tones 0-159 were all being used for upstream (I have no way of knowing if 40-159 was used for up or down)
and if all tones were fully bitloaded,
then the new BT banding means a total loss of about 7,728 kbps from the max available upstream on the new firmware, across all 3 of the US bands.
-
To be sure that nothing had been missed, I went back and repeated the tests for each of those three firmware images. Everything was configured exactly as described above.
I performed two extra steps after uploading each firmware image to the HG612. Once the device had re-booted itself at the end of the upload process, I then entered the GUI and selected the option to restore the default configuration. The device re-booted itself once again as part of that process. Finally I performed a 'long reset' of the device.
I now have a 10.5 MB ZIP format file containing all the experimental results. (Both the original and repeated tests.) Copies will now be sent to both Kitz and Bald_Eagle1. If anyone else would like to receive a copy, please say so here. (If I do not know your e-mail address, to which the results should be sent, please let me know by a PM. Obviously if you know that I am aware of your e-mail address, nothing further needs to be done.)
-
Thank you blackcat. This kitteh has just spent a good hour (gosh how time flies) looking at & comparing the results.
Again thanks to BE for the graphs.
Some musings from me
-----
Maximum Sync - F2 & F3 have a max upstream cap of 51316.
At first glance F1 appeared to show better 'maximum' downstream than F2, but repeat testing showe F2 to be the better of the pair. Since both swang within about the same range, I think I'll have to say nothing conclusive can be drawn.
F3 showed far better max downstream. Some of this though would be down to the re-organisation of the tone banding. The increase though is approx double of my rough calculation of what these tones would be worth if the bits were fully loaded.
Attained sync - Nothing much between them, but no surprise since they seem to have reached a plateau.
SNR Margin. - F3 has much higher SNR margin.
I actually find the figures 19.8, 19.7, 19.6 quite strange, when compared to F1 & F2
F1 & F2 appeared to show evidence of a different PSD mask than F3
The PSD mask on F3 in more in line with what I'd expect to see on adsl, as the 'uuuu' shape on F1 & F2 isnt something I'd seen before. IMHO the u shape was too regular to be anything other than PSD masks. This shape doesnt appear to follow bit loading though ??? so something else going on there for F1 & F2, no idea what exactly.
F3 has better bit loading. This could be related to the PSD type masking mentioned above.
The new tone banding on F3 also brings it more in line with adsl/adsl2+ banding for up/down.
This has both plus and minus points. Less chance of vdsl-v-dsl crosstalk. Less upstream tones mean a much lower upstream speed for long lines. Perhaps limiting upstream speeds to around 500-1000kbps depending on psd mask and bitloading.
I havent looked at all the settings, I believe the b*cat was doing that and has noticed SRA is now switched on by default. This could or could not be interesting as Ive recently seen sight of a document sent out to ISPs who are to supply their own FTTC modem/routers to the EU rather than use the openreach modem. One of the items that BT states it will be in-house testing for modem compliance is SRA.
----
and as I type this out something else just struck me. F3 appears to have far better bit loading, so at first glance we may say - yep F3 is best. Yet.. how comes they all have very similar sync speed. Is F3 carrying more overhead and if so what for?
----
The above are just thoughts and may or may not be correct.
-
For reference purposes, I have attached the 'snapshot' montages for F1, F2 & F3
& just for 'fun', I have attached a montage for my own connection :(
Being a longer line length, used in 'real life' conditions, my connection actually 'needs' to use the U0 band for upstream bitloading.
-
Here is a sideways difference between the two files (which contain some selected output returned by various incantations of the "xdslcmd" command) -- the left hand side is from the original Asbo unlocked firmware image & the right hand side is from the original Wolfy unlocked firmware image.
Unlocked Asbo image. Unlocked Wolfy image.
(bcm96368MVWG_fs_kernel_HG612V100R001C01B028SP10_Asbo_Unlocked) (bcm96368MVWG_fs_kernel_HG612V100R001C01B030SP06_Wolfy_Unlocked)
# xdslcmd --version # xdslcmd --version
xdslcmd version 1.0 xdslcmd version 1.0
DSL PHY: AnnexA version - A2pv6C030b.d22g | DSL PHY: AnnexA version - A2pv6C038m.d24j
******* Pass ********* ******* Pass *********
# xdslcmd profile --show # xdslcmd profile --show
Modulations: Modulations:
G.Dmt Enabled G.Dmt Enabled
G.lite Enabled | G.lite Disabled
T1.413 Enabled | T1.413 Disabled
ADSL2 Enabled ADSL2 Enabled
AnnexL Enabled | AnnexL Disabled
ADSL2+ Enabled ADSL2+ Enabled
AnnexM Disabled AnnexM Disabled
VDSL2 Enabled VDSL2 Enabled
VDSL2 profiles: VDSL2 profiles:
8a Enabled 8a Enabled
8b Enabled 8b Enabled
8c Enabled 8c Enabled
8d Enabled 8d Enabled
12a Enabled 12a Enabled
12b Enabled 12b Enabled
17a Enabled 17a Enabled
30a Enabled 30a Enabled
US0 Enabled US0 Enabled
Phone line pair: Phone line pair:
Inner pair Inner pair
Capability: Capability:
bitswap On bitswap On
sra Off | sra On
trellis On trellis On
sesdrop Off sesdrop Off
CoMinMgn Off CoMinMgn Off
24k On 24k On
phyReXmt(Us/Ds) Off/On phyReXmt(Us/Ds) Off/On
TpsTc AvPvAa TpsTc AvPvAa
monitorTone: On monitorTone: On
dynamicD: On dynamicD: On
dynamicF: On | dynamicF: Off
SOS: On SOS: On
Training Margin(Q4 in dB): -1(DEFAULT) Training Margin(Q4 in dB): -1(DEFAULT)
# xdslcmd info --cfg # xdslcmd info --cfg
xdslcmd: ADSL driver and PHY status xdslcmd: ADSL driver and PHY status
Status: Showtime Status: Showtime
Retrain Reason: 0 Retrain Reason: 0
> Last initialization procedure status: 0
Max: Upstream rate = 66480 Kbps, Downstream rate = 131956 Kbps | Max: Upstream rate = 51316 Kbps, Downstream rate = 155408 Kbps
Path: 0, Upstream rate = 51316 Kbps, Downstream rate = 104997 Kbps | Bearer: 0, Upstream rate = 51316 Kbps, Downstream rate = 104999 Kbps
adslTrainingMarginQ4: -1 adslTrainingMarginQ4: -1
adslShowtimeMarginQ4: -1 adslShowtimeMarginQ4: -1
adslLOMTimeThldSec: -1 adslLOMTimeThldSec: -1
adslDemodCapMask: 0090447a adslDemodCapMask: 0090447a
adslDemodCapValue: 0010447a | adslDemodCapValue: 0090447a
adsl2Param: 00000000 adsl2Param: 00000000
adslPwmSyncClockFreq: 0 adslPwmSyncClockFreq: 0
adslHsModeSwitchTime: 0 adslHsModeSwitchTime: 0
adslDemodCap2Mask: 00500200 adslDemodCap2Mask: 00500200
adslDemodCap2Value: 00500200 | adslDemodCap2Value: 00500000
vdslParam: 007f00ff vdslParam: 007f00ff
vdslParam1: 00000000 vdslParam1: 00000000
xdslAuxFeaturesMask: 00000003 | xdslAuxFeaturesMask: 00060003
xdslAuxFeaturesValue: 00000003 | xdslAuxFeaturesValue: 00060003
vdslCfgFlagsMask: 00000000 | vdslCfgFlagsMask: 00210400
vdslCfgFlagsValue: 00000000 | vdslCfgFlagsValue: 00210400
> xdslCfg1Mask: 00000000
> xdslCfg1Value: 00000000
> xdslCfg2Mask: 00000000
> xdslCfg2Value: 00000000
> xdslCfg3Mask: 00000000
> xdslCfg3Value: 00000000
> xdslCfg4Mask: 00000000
> xdslCfg4Value: 00000000
> maxDsDataRateKbps: 0
> maxUsDataRateKbps: 0
> maxAggrDataRateKbps: 0
> xdslMiscCfgParam: 00000000
> AFE_ID: 10608100 00000000
When viewing the sdiff, please take note of the "marker" in the "central gutter" between the two files. A "null" marker indicates that there is no difference. A "|" marker indicates that there is a difference. A "<" marker indicates a line unique to the left hard side, whilst a ">" marker indicates a line unique to the right hand side.
The sdiff file is also attached below, for anyone who would like to examine it locally.
-
FWIW, using the original Asbo unlocked firmware & allowing BT to update it, I only see this for the xdslcmd profile --show command:-
# xdslcmd profile --show
Modulations:
G.Dmt Enabled
G.lite Enabled
T1.413 Enabled
ADSL2 Enabled
AnnexL Enabled
ADSL2+ Enabled
AnnexM Disabled
VDSL2 Enabled
Phone line pair:
Inner pair
Capability:
bitswap On
sra Off
trellis On
sesdrop Off
CoMinMgn Off
24k On
phyReXmt(Us/Ds) Off/On
TpsTc AvPvAa
monitorTone: On
dynamicD: On
dynamicF: Off
SOS: On
Training Margin(Q4 in dB): 50
#
i.e. I don't see any of this:-
VDSL2 profiles:
8a Enabled
8b Enabled
8c Enabled
8d Enabled
12a Enabled
12b Enabled
17a Enabled
30a Enabled
US0 Enabled
This is from a failed attempt to lower SNRM on my connection:-
Training Margin(Q4 in dB): 50
-
Please consider the screen scrape, attached below. It is of one particular page of the HG612's GUI after that device had synchronised with the (one port) DSLAM (the VC-230N).
The firmware image being used was the original unlocked version from Asbokid. (bcm96368MVWG_fs_kernel_HG612V100R001C01B028SP10_Asbo_Unlocked)
For the testing that was currently being performed, it was only necessary for the HG612 to establish synchronism with the VC-230N.
Look down at the WAN Packet section. The ptm1.101 line refers to the Ethernet bridge between the HG612's LAN1 and WAN ports. Nothing was shown as occurring because that bridge was not in use. However the ptm1.301 line is interesting. That line refers to the tagged VLAN, which exists for the BTagent ("Beattie's busybody") to communicate with the "Evil Empire". ;) What caught my eye was that the values reported in the Byte and Packet columns, under the Send header, continued to increment as the BTagent ("Beattie's little snitch") attempted to "call home", following the power up of the HG612.
The fact that the BTagent desperately wants to report back to the "Evil Empire" (via a tagged VLAN numbered 301) makes me wonder if I should try to provide such a VLAN, just to see what the "busybody" will attempt to do next. :angel:
Comments, suggestions, etc, are welcomed from all. :)
-
FWIW, using the original Asbo unlocked firmware & allowing BT to update it, I only see this for the xdslcmd profile --show command:-
<snip>
:hmm: Hmm . . . I wonder if a "long reset" would be required? :-\
Perhaps Wolfy may have an opinion on your observation that he might share?
-
:hmm: Hmm . . . I wonder if a "long reset" would be required? :-\
Perhaps Wolfy may have an opinion on your observation that he might share?
From what I can gather, a long reset whilst still using Asbo's original firmware (subsequently updated by Beattie) causes 'telnet' access to be blocked.
I will experiment, probably at the weekend, with a copy of Wolfy's firmware at hand in readiness........................
-
Please consider the screen scrape, attached below. It is of one particular page of the HG612's GUI after that device had synchronised with the (one port) DSLAM (the VC-230N).
The firmware image being used was the original unlocked version from Asbokid. (bcm96368MVWG_fs_kernel_HG612V100R001C01B028SP10_Asbo_Unlocked)
For the testing that was currently being performed, it was only necessary for the HG612 to establish synchronism with the VC-230N.
Look down at the WAN Packet section. The ptm1.101 line refers to the Ethernet bridge between the HG612's LAN1 and WAN ports. Nothing was shown as occurring because that bridge was not in use. However the ptm1.301 line is interesting. That line refers to the tagged VLAN, which exists for the BTagent ("Beattie's busybody") to communicate with the "Evil Empire". ;) What caught my eye was that the values reported in the Byte and Packet columns, under the Send header, continued to increment as the BTagent ("Beattie's little snitch") attempted to "call home", following the power up of the HG612.
The fact that the BTagent desperately wants to report back to the "Evil Empire" (via a tagged VLAN numbered 301) makes me wonder if I should try to provide such a VLAN, just to see what the "busybody" will attempt to do next. :angel:
Comments, suggestions, etc, are welcomed from all. :)
I'd certainly be interested is seeing what's going on there. My own research into BTAgent got interrupted some time back and there's little chance of me getting back to it any time soon.
From what I can gather, a long reset whilst still using Asbo's original firmware (subsequently updated by Beattie) causes 'telnet' access to be blocked.
That's correct. There's a post on this in the other thread if you're interested in the technical details.
-
I have come across something that may be of interest to Eagles and Wolves, as well as general Kitizens.
It would probably be best for me to start at the beginning . . .
Walter recently asked about the procedure for updating the firmware in HG612 devices. Having given a typed, step-wise, description I thought it would be useful to collect together a series of "screen scrapes" whilst performing such an update myself.
My (one and only) HG612 currently had the "Wolfy unlocked with GUI" firmware installed. I duly updated it with the "Asbo original unlocked" firmware, capturing "screen scrapes" during the process.
That is the background information. Subsequently I entered the GUI of the device and as I "passed by" the WAN ---> Network page, something did not "seem right" under the WAN Packet heading. It took a few moments for me to realise that the ptm1.301 line was completely missing! ???
Having satisfied myself that I had, indeed, updated the device with the "Asbo original unlocked" firmware, a faint tintinnabulation occurred at the back of my mind. Going to Maintenance ---> Device, I left-clicked upon Restore Default Setting under the Reset tab. Once the device had finished its re-boot cycle, I returned to the WAN ---> Network page and observed that the ptm1.301 line was now present under the WAN Packet heading.
As that faint tintinnabulation had now been transmogrified into a loud peel of bells, I searched my archive for a note that had been sent to me some years ago, by Asbokid. And here it is --
I just flashed the unlocked SP10 firmware into that early HG612 which had SP06 firmware ... and it works but you need to perform one
extra step.
The working XML config file from SP06 is still stored in the persistent data area of the flash memory and you need to overwrite that
old SP06 config with the new SP10 config file.
To do that you have to 'Restore Default Settings'. That's an option under [Maintenance | Device | Reset] in the HG612 web interface.
The unlocked SP10 XML config file is then read from the squashfs read-only root file system and it is written to the persistent data
area of the flash memory. That ensures that the old SP06 config file is overwritten.
So, fellow HG612 firmware "flashers", beware! ;)
-
I still have two phases of investigations to complete that come under this subject heading.
- A repeat of my earlier experiments but with a "local loop" of some significant length, as requested by les-70. All the components are now "in place" for this to be performed. I just need to make four pairs of connections and then find a suitable "time window" to perform the three separate experiments.
- For the second phase, I would like to have some input from others. I have collected together a sequence of "screen-scrapes" which shows the configuration of the VC-230N. Those images can be downloaded in a ZIP format file (http://elrepo.org/people/ajb/tmp/VC-230N_Config.zip). The VC-230N is configured in CO mode with its wireless as a client device and the wireless, the VDSL2 port & the four LAN ports all bridged together. This phase is intended to investigate the two VLANs that are configured in a HG612 device. The VLAN tagged 101 is used by the LAN1 port to VDSL2 port bridge of the HG612 device. The VLAN tagged 301 is that used by Beattie's busybody, the BTagent, within the HG612 device. I have attached, below, an image that shows how I have configured four VLANs in the VC-230N device. With it powered up and an Ethernet patch cable connecting my laptop computer to the LAN4 port, it is possible to obtain Internet access through the wireless link. With an HG612 device connected to the other end of the VDSL2 "local loop", my proposal is to prove that the LAN1 port of the HG612 device and the LAN1 port of the VC-230N device are linked via the VLAN 101. Once that is confirmed, the next step will be to focus attention onto the LAN3 port of the VC-230N device from which would appear the busybody's attempts to "call home" via the VLAN tagged 301. Finally I propose to configure a third VLAN, tagged 401, bound to the LAN2 port on the HG612 device and attempt to obtain Internet access. Suggestions as to how the HG612 device should be configured for this will be welcomed.
-
I have come across something that may be of interest to Eagles and Wolves, as well as general Kitizens.
<snip>
The working XML config file from SP06 is still stored in the persistent data area of the flash memory and you need to overwrite that old SP06 config with the new SP10 config file.
<snip>
So, fellow HG612 firmware "flashers", beware! ;)
My research into why some people were losing telnet access while others didn't shows that this only happens when the config is changed as the update process does not clear the 'user' config areas in flashmem. Only restoring the defaults via the reset button or the web interface does that.
There's a post on it here: http://forum.kitz.co.uk/index.php?topic=13130.msg247609#msg247609 (http://forum.kitz.co.uk/index.php?topic=13130.msg247609#msg247609)
The relevant part is about halfway down after a quote from bbnovice.
Finally I propose to configure a third VLAN, tagged 401, bound to the LAN2 port on the HG612 device and attempt to obtain Internet access. Suggestions as to how the HG612 device should be configured for this will be welcomed.
One approach might be to temporarily configure the modem for routed mode then examine the bridging and iptables configuration via telnet. That might point you in the right direction.
Unfortunately I can't assist right at this moment. I had a bit of a disaster at the end of last week when a BGW V7 vhd test installation decided to stomp all over the BGW XP partition bootblock after running without any problems for nearly a week. After much 'fiddling about' I was forced to wipe the entire drive, repartition it and restore to cure the problem.
Do you have any idea how long it takes to backup and restore 300GB of operating systems, virtual machines, games, assorted O/S iso images and miscellaneous other materials... :'(
I'm still in the middle of attempting to bring order out of chaos and archive as much of this stuff off onto DVD where it belongs.
I may also be still suffering from PDRDS (Post Disaster Recovery Distress Symptoms) :crazy:
-
I may also be still suffering from PDRDS (Post Disaster Recovery Distress Symptoms) :crazy:
I can almost here the pain in your text, same thing happened to me last march with 2 partitions and had to install the first OS and use Easeus Data recovery program to recover partition 1 & 2 data and lost 3% which is not bad but it took 3 hours to scan the partitons.
all my data now go's onto a usb2 external HD its slow at 2-10 Megabytes per second :'(
-
I have finally prepared a 398 metres local loop and am now ready to repeat the tests with those three firmware images. Tomorrow's task, me thinks.
Completely irrelevant to the tests but if I opted to take a FTTC based service, the loop length from my NTE5/A to the PCP and then down a tie-cable pair to the Huawei SmartAX MA5616 MSAN would be . . . precisely 391 metres!
Edit: As "today" is the "tomorrow" referenced above and I have not performed the tests (where does a feline's time go (when awake)?) I attach, as a consolation, an image of the 398 metres local loop that will eventually be used . . . :angel:
-
After a lot of "fiddle-faddling" and "cat cursing", three sets of measurements were made with a 398 metre "local loop".
I'm not happy with the results. :no: As the connections between the ends of the "local loop" and the two halves of the severed RJ11 to RJ11 patch cable were very "temperamental", I intend to repeat the experiment.
My latest plan for the "local loop" is to fit an LJU2/3A socket at either end (the cable and the sockets' IDCs are, as we know, made for each other ;) ) and then use two RJ11 to 431A patch leads to connect the HG612 & VC-230N devices to the LJU2/3A sockets.
-
An image of the revised "local loop" is attached, below.
I'm now awaiting the delivery of a hideously expensive (£0-99) "RJ11 to 431A patch lead", hopefully sometime tomorrow. (Typical. I only had one stashed away in the bowels of my grotto. ::) )
-
Not got a Sky receiver you could pinch one from?
-
Not got a Sky receiver you could pinch one from?
b*cat lifts a paw, exposes the claws, dismisses any suggestion of objects related to the Murdoch empire, yawns and thinks "feed me"! ;)
-
Not got a Sky receiver you could pinch one from?
b*cat lifts a paw, exposes the claws, dismisses any suggestion of objects related to the Murdoch empire, yawns and thinks "feed me"! ;)
So sorry, only a suggestion ::)
-
After a lot of "fiddle-faddling" and "cat cursing", three sets of measurements were made with a 398 metre "local loop".
will the 398 meters LL pick up any interference from it being coiled like that ? :-\
-
So sorry, only a suggestion ::)
I appreciate it. :friends:
-
will the 398 meters LL pick up any interference from it being coiled like that ? :-\
It's not so much the "pick up" of RFI but the effect of the attenuation, from a significant loop length, in which les-70 is interested.
As for the length of the loop, once the two RJ11 to 431A patch leads are also factored in, it will be a very nice round 400 metres. :)
-
will the 398 meters LL pick up any interference from it being coiled like that ? :-\
It's not so much the "pick up" of RFI but the effect of the attenuation, from a significant loop length, in which les-70 is interested.
As for the length of the loop, once the two RJ11 to 431A patch leads are also factored in, it will be a very nice round 400 metres. :)
I know it's just for the attenuation test, but looking forward to see your results but I am sure it will be Technical jargon until someone can break it down into layman's terms ;D
-
I know it's just for the attenuation test, but looking forward to see your results but I am sure it will be Technical jargon until someone can break it down into layman's terms ;D
I know that both our leader, Kitz and a certain analytical Eagle will be ready to consider some more raw data . . . once harvested.
-
At long last, some more raw data has been generated. This time with a local loop length of 400 metres.
The raw data has been submitted to Our Leader, Kitz and the Eagle with a deficit of head feathers. In due course, when the moment is ripe, etc, my two analysts will make their considerations known. :angel:
A quick review shows that the latest firmware image (bcm96368MVWG_fs_kernel_HG612V100R001C01B030SP06_Wolfy_Unlocked) has the best performance, followed by the original firmware image with the updated Broadcom BLOB (bcm96368MVWG_fs_kernel_HG612V100R001C01B028SP10_Asbo_Unlocked_Updated_BLOB) and then the original firmware image (bcm96368MVWG_fs_kernel_HG612V100R001C01B028SP10_Asbo_Unlocked) "brings up the rear".
There is one other observation that I shall mention in this preliminary report -- the overall performance has been severely degraded in going from a local loop length of 1.5 metres to one of 400 metres. :( :-X
-
What can I say, other than just about everything looks 'wrong' in the graph montages.
I suspect the issue has something to do with the cable still being coiled, the particular type of cable or the method employed of jointing the cable & doubling back up & down to make the total length of around 400m.
I wonder if things would look 'better' if the cable was somehow uncoiled?
Attached to this message are the resulting montages from the 3 firmware images (first run).
The next message contains attachments, in the same order, of the repeated tests.
-
Repeated test results attached...........
-
As you say - very odd. I believe you have a TDR so one potentially easy test would be to look down the "400m" with it and check if there are any reflections other than one at the end on the modem or dslam. I don't think coiling twisted pair should have much effect.
Edit: A resistance check may also show something.
-
A magnetic field will be generated around the coils of wire if you pass a current through them thats my physic's lesson it depends on how much current and other stuff ;D
-
Good suggestions -- thank you.
The current configuration is:
- end one, green/white striped wire to IDC2 of the LJU2, number one
- end one, white/green striped wire to IDC5 of the LJU2, number one
- end two, green/white striped wire connected to blue/white striped wire
- end two, white/green striped wire connected to white/blue striped wire
- end one, blue/white striped wire connected to orange/white striped wire
- end one, white/blue striped wire connected to white/orange striped wire
- end two, orange/white striped wire to IDC2 of the LJU2, number two
- end two, white/orange striped wire to IDC5 of the LJU2, number two
Time to fit the batteries into the Tester 301C . . . :-\
-
Using the Tester 301C showed nothing abnormal with the "long local loop". It's "end-point" was clearly visible when a shorting link was applied and removed at the far end.
Leaving the shorting link in-situ, a check with the Ohmmeter 18C showed a total resistance of 338 Ohms. As there are six segments "in the loop" (starting at the green/white striped wire and ending at the white/green striped wire), I guess that 56.33 Ohms per segment is reasonable.
Unless there is some compelling reason for me to measure and record the parameters for each of those six segments in turn, then I'll just "leave things be". The result of testing the three different firmware versions is identical with the results obtained with the "short local loop".
-
Thanks for the results. The very large degradation with the 400m suggests something must be wrong. ??? The resistance does seem high and since the the TDR did not show bad joints I wonder if the cable is not solid copper. One reference gives -"The conductor resistance of CCS telephone cables with 1/0.5mm diameter conductors is confirmed as around 700Ω/km. CW 1308 defines a maximum conductor resistance for a 1/0.5mm conductor as 97.8Ω/km". If it is copper coated steel that may be the issue. A magnet is the simple test!.
Otherwise it may be impedance mismatch causing a bounce of the signal up and down the 400m. The 338ohms ought however to be attenuating any reflection. Asbo went to a lot of trouble with baluns doing similar tests but I have never really understand why it might be critical especially in a test in which only the firmware is changed.
Edit: In fact given a skin effect at high frequencies I am not sure how much the resistance tells us.
-
I agree with you that there is a background niggle that something is "not right". :(
Thank you for providing the relevant details from the CW1308 specifications. Perhaps I may eventually get around to some further investigations. Starting with a magnet . . . ;)
Regarding Asbokid's testing, he only used a balun to connect a noise generator to the pair. The various attenuators that he inserted into the circuit were of the classic resistive Pi design, each built to provide a know dB value insertion loss.
-
The reel of CW1308 cable was placed in an accessible location and each end -- of each of the three pairs -- was prepared to allow connection to the Ohmmeter 18C.
Insulation Resistance
Green pair 0 Ohms
Blue pair 0 Ohms
Orange pair 1 MOhms
Loop Resistance
Green wire 1 58 - 59 Ohms
Green wire 2 55 Ohms
Blue wire 1 53 - 54 Ohms
Blue wire 2 55 - 56 Ohms
Orange wire 1 54 Ohms
Orange wire 2 54 - 55 Ohms
:wall: >:(
-
Further testing (with a fridge magnet) confirmed that the conductors are made of copper coated steel! >:(
The Ohmmeter 18C was deployed, once again --
Insulation Resistance
Green pair 0 Ohms
Blue pair 0 Ohms
Orange pair 0.5 M Ohms
Loop Resistance
Green pair 92 Ohms
Blue pair 123.3 Ohms
Orange pair > 9999 Ohms
b*cat is very grumpy. :rain:
-
Sorry your grumpy but the best place for it is stored on a coil rather than in use. Always a bright side! I have some runs of the stuff in my house - just on telephone extensions that are not actually in use. If I ever replace them I will be with solid copper ethernet cable as the locations would be good ones for ethernet round the house. I did once have the modem at the end of the stuff and adding about 15m of CCS to a 1km line only made a small difference of about 0.5db in snrm. It is better than anything untwisted but one of the worst features is supposed be long term corrosion in Krone joints.
I guess The CCS provides some explanation of the results
-
The only thing we can gain from this sorry tale is the typical data obtained from an appalling 400 metres local loop. :-\
(The performance will be very familiar to Walter, from his experiences in trundling his wheelbarrow around and about in Ewhurstshire.)
What has amazed me is the loop resistance results. Considering that one would expect an open-circuit pair to show infinity, the green and blue pairs are clearly useless.
The orange pair is not that good, either. The insulation resistance has halved between the two successive measurements!
-
Some final comments on that spool of (supposedly) CW1308 specification cable.
- Making use of a magnet (with thanks to Les for the suggestion) showed that the wires were not solid copper but just copper coated steel cores.
- The cable was carefully de-spooled with the idea to check the "far end" for any potential damage. None was found.
- During the de-spooling process it was observed that there are distance markers on the outer sheath. The physical length of that cable is actually 100 metres. :o The fact that the TDR determined length (of the three pairs, serialised) was more than three times the physical length, also shows that there is some significant defect in the cable.
:(
If any Kitizen would like to have that spool of cable -- for experimental purposes, to mimic the poor Openreach D-side cabling perhaps (such as can be found in Ewhurst, Surrey, for example) -- then it will be free to s/he who wishes to collect it from The Cattery, Off DP1032, Via P28, EABSE. I will also be prepared to send it, via courier, to any UK address in exchange for the shipping cost. ;)
-
Unlucky on that cable burakkucat. Still interesting to see the results against a dodgy cable though.
FYI, on all new cable I buy the first thing I do is strip back a few inches of the sheath and scrape a stanley blade along the core, if silver starts to shine through it goes back or in the recycling. A magnet is a good idea but it won't detect copper coated aluminium ;)
-
A magnet is a good idea but it won't detect copper coated aluminium ;)
Indeed. That had occurred to me but I had failed to make a note of it here. Thank you for adding the detail. :)
-
No problem :)