Print

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

[kitz]

Thank you for that b*cat.

I was just a bit surprised that there was nothing to indicate the command was successful, hence the query. 
Since it moaned at me the second time I attempted it, I then sussed that the first attempt must have been accepted. 

That is useful information and could do perhaps with being recorded somewhere permanent.   Not tonight though as Ive realised its way past my bed time and due to the fact I have to be up and out tomorrow, I guess Im not going to get many zeds now.

[roseway]

I can confirm b*cat's information. It's fairly common practice with Linux commands to give no response when they're successful. Often there will be an optional -v or --verbose parameter which will cause it to return a "success" response. The "no process killed" response is quite normal and benign, and in this case simply indicates that the processes in question were already not running at the time the command was issued.

(Incidentally, the -v or --verbose parameter doesn't appear to be recognised in the implementation of the killall command in this router)

[Chrysalis]

quick reply @ greybeard.

Its my understanding too that crosstalk impacts most on the shorter lines and that its the higher frequencies that are affected most.

However, I dont know if the following info helps, but when on adsl2+ I was one of the first (if not the 1st) people to go on a shiny new  BE MSAN.  At first I could get a full 24Mb, over time this deteriorated to 21Mbps.. most remarkably so when the MSAN started to fill up with o2 users.   

The place where I noticed crosstalk had the most impact though was across the 6,7,8,9,10 Mbps range.   By that I mean the max tones in use by anyone syncing at say 8Mbps would be using.   After tones 260 both my SNR and bit loading started to increase.  At about tone 300 my SNR was better than say tone 130.   It was all a nice smooth dip bit like a shallow bowl.   Somewhere around tone 255 (8Mb) was my lowest SNR...  until tone 460 ish.
This saucer shape meant that I could never get full bit loading over the 128 -288 region when in the early days I could.

Obviously the more users that synced at x speed then the worse impact it would have on my snr and bit loading across those tones.   There must have been far fewer people syncing at over 14Mbp, which is why my own SNR was good there and least impacted by other users and would start to rise again.

Hope you get the gist of what Im trying to say..  I possibly have a DMTtool graph from about 2008ish when you could see this happening quite clearly, but its on an old drive that I need to hook up to the network sometime to transfer some data from. :/ 

thats a big point kitz.

given most people are on 40/10 not 80/20 then those people probably only use the D1 and D2.  When tones arent needed on sync then the power output is disabled, as seen with the medley phase vs the discovery phase.  So I think its quite plausible my issue is crosstalk, but I respect the possibility of it been external noise also.  However my line did recover when the engineer the other week moved cables around, meaning I was temporarily away from my disturber, at the moment more evidence seems to be pointing to crosstalk.

More weirdness?

At 5am today my attainable dropped by another 4mbit.  No loss of sync, so either DLM changed something without requiring a resync or some interference changed at 5am.  I cant generate new graphs, the modem stats script is hanging after ***********11

ok attaching before and after bit/snr graphs, the after is from the new modem stats tool (I finally upgraded after this problem).  On the new graph the snr declines smoothly whilst on the old was dips, but it doesnt look obvious to me where the signal has been lost.

My loop loss on D1 is under 10db I think the snr really should be around 60db.

[Chrysalis]

whats the reccomended way to kill btagent?

Establish a telnet connection to the HG612, invoke the busybox shell and issue a killall -KILL start btagent command.

A power-cycle or reboot of the device will turn Beattie's busybody back on.

thanks, since I probably forget about this I added the command to auto run whenever I login to the telnet.

so with tr069 on BT can collect performance stats but they need btagent to make remote changes?

[NewtronStar]

Right gonna ask the Big question  Will the GUI be back after the new firmware has been modded ? I know it's to early to ask that question but any thoughts or inside info would be nice 

[burakkucat]

so with tr069 on BT can collect performance stats but they need btagent to make remote changes?

Well, that's not quite what I believe to be the case. Here follows my speculation, as a result of tingles received in my whiskers . . .

The BT Agent calls home to the Evil Empire (once at boot? periodically? -- probably the latter) and establishes a secure connection to a dedicated server. Many functions can then occur. One function is to compare the current version of the firmware on the CPE with the latest available and if there is a difference, upload the latest image and reboot the device.

TR-069 is a defined means for communication between the device and a remote system. It is capable of being used for data gathering, configuration changes and other functions -- of which firmware upgrades are but one.

Perversely, some might say typically, Beattie appears to have decided to 'do her own thing' by embedding proprietary code into the CPE. Very little is publicly known about her busy-body, the BT Agent, but it does seem highly likely that it is identical across the entire spectrum of CPE devices that she provides to end users.

[burakkucat]

Right gonna ask the Big question  Will the GUI be back after the new firmware has been modded ? I know it's to early to ask that question but any thoughts or inside info would be nice 

How long is a piece of string? 

The question that you are really asking is "Has the GUI just been disabled or has its code been removed from the latest firmware?" and that can only be answered when someone has managed to obtain a copy of the firmware image for inspection . . . 

[Greybeard33]

quick reply @ greybeard.

Its my understanding too that crosstalk impacts most on the shorter lines and that its the higher frequencies that are affected most.

However, I dont know if the following info helps, but when on adsl2+ I was one of the first (if not the 1st) people to go on a shiny new  BE MSAN.  At first I could get a full 24Mb, over time this deteriorated to 21Mbps.. most remarkably so when the MSAN started to fill up with o2 users.   

The place where I noticed crosstalk had the most impact though was across the 6,7,8,9,10 Mbps range.   By that I mean the max tones in use by anyone syncing at say 8Mbps would be using.   After tones 260 both my SNR and bit loading started to increase.  At about tone 300 my SNR was better than say tone 130.   It was all a nice smooth dip bit like a shallow bowl.   Somewhere around tone 255 (8Mb) was my lowest SNR...  until tone 460 ish.
This saucer shape meant that I could never get full bit loading over the 128 -288 region when in the early days I could.

Obviously the more users that synced at x speed then the worse impact it would have on my snr and bit loading across those tones.   There must have been far fewer people syncing at over 14Mbp, which is why my own SNR was good there and least impacted by other users and would start to rise again.

Hope you get the gist of what Im trying to say..  I possibly have a DMTtool graph from about 2008ish when you could see this happening quite clearly, but its on an old drive that I need to hook up to the network sometime to transfer some data from. :/

Yes, I see now that I was wrong to say that the highest tones will always be affected worst. I should have qualified it by "if other things are equal" - i.e. if the crosstalk is between lines of similar length, all with uncapped profiles. Clearly that is not always the case, particularly when the crosstalk is between pairs in the cable between the FTTC cab and the PCP. A long line with no D3 signal cannot degrade the D3 of an adjacent short line. Nevertheless, Chrysalis seems to have suffered approx 15dB loss of SNR throughout the D2 band and the D1 band above the ADSL cutback, and I doubt that there are many FTTC lines that are so long that they do not at least make full use of the D1 band. FEXT cross-coupling is mainly capacitive, which increases with increasing frequency, so it is puzzling that Chrysalis' noise does not seem to have this characteristic.

[NewtronStar]

Right gonna ask the Big question  Will the GUI be back after the new firmware has been modded ? I know it's to early to ask that question but any thoughts or inside info would be nice 

How long is a piece of string? 

The question that you are really asking is "Has the GUI just been disabled or has its code been removed from the latest firmware?" and that can only be answered when someone has managed to obtain a copy of the firmware image for inspection . . . 

  Yeah BC thats is the Question and Answer we are looking for Disabled or Removed ? I guess once we know, then we will know which direction the HG612stats software is going as I am sure it used the GUI were as DSLstats used Telnet i could be wrong ?

[Greybeard33]

Right gonna ask the Big question  Will the GUI be back after the new firmware has been modded ? I know it's to early to ask that question but any thoughts or inside info would be nice 

How long is a piece of string? 

The question that you are really asking is "Has the GUI just been disabled or has its code been removed from the latest firmware?" and that can only be answered when someone has managed to obtain a copy of the firmware image for inspection . . . 

Attached is a listing of the directory where the webimg and webidx files were to be found in the old firmware. A reasonably thorough hunt through the rest of the root file system failed to reveal them. Of course, that is not to say that one of our hacker friends might not be able to build them back in again....

I believe the current version of HG612_stats uses only the Telnet interface.

[NewtronStar]

Attached is a listing of the directory where the webimg and webidx files were to be found in the old firmware. A reasonably thorough hunt through the rest of the root file system failed to reveal them. Of course, that is not to say that one of our hacker friends might not be able to build them back in again....

I believe the current version of HG612_stats uses only the Telnet interface.

So it looks like it has been removed, you would need some spare space on that Eprom /Flash memory if the GUI was to be re-built and by the looks of it there is no spare memory left after update.

[burakkucat]

I guess once we know, then we will know which direction the HG612stats software is going as I am sure it used the GUI <snip> i could be wrong ?

I can quite definitely say that you are . . . wrong!    Sorry, but knowing who wrote the original code that 'kick-started' the Baldy bird's project, I can definitely say that it does use TCP port 23.

I have a stale kitteh biscuit as a prize for the first person to correctly identify the initial writer of the code which inspired No-feathers. 

<snip> by the looks of it there is no spare memory left after update.

Do you have a reference (or link) please? I would be very surprised, unless something else, very significant in size, has been added to the new image. 

[burakkucat]

Attached is a listing of the directory where the webimg and webidx files were to be found in the old firmware. A reasonably thorough hunt through the rest of the root file system failed to reveal them. Of course, that is not to say that one of our hacker friends might not be able to build them back in again....

Thank you GB. I shall, in a short while, scrutinise your file.

I believe the current version of HG612_stats uses only the Telnet interface.

 

[Bald_Eagle1]

I can quite definitely say that you are . . . wrong!    Sorry, but knowing who wrote the original code that 'kick-started' the Baldy bird's project, I can definitely say that it does use TCP port 23.

Yes, I can confirm that the GUI's URL is not used for obtaining any stats for the HG612 Modem Stats package of compiled programs.

It was indeed used in the original batch file versions, but even then, I eventually switched to purely telnet obtained stats as some of the data presented to the GUI was clearly 'wrong'.

[Ronski]

I have a stale kitteh biscuit as a prize for the first person to correctly identify the initial writer of the code which inspired No-feathers. 

IIRC it was your good self running on Linux and BE converted it to Windows, I'll let you keep the biscuit though if I'm correct