585 v8 firmware

[#1]

Phew! ....Thanks for the reassurance

[#2]

It doesn't resync the router so won't be seen as a connection drop, don't worry. It is just a brief disconnection and reconnection of the PPP layer to switch to the new profile, as spraxyt says

[#3]

Thanks Matt Are you able to comment as to whether the reporting of zero output power (which I've recently observed in other users' router stats as well) is any cause for concern?

[#4]

IIRC that's a reporting bug in the firmware and isn't anything to worry about. It's been mentioned a couple of times on these forums.

[#5]

Aaaargh!!! I've been celebrating prematurely. Matt, you didn't maybe test or tweak anything in my settings since my last post? What had been a rock solid stable superfast connection has just dramatically changed detrimentally, as is apparent from the speedtests below





The only events in my router logs remain regular hourly syncs, but obviously something is now suddenly (and seriously) very wrong. I followed up with another BT Speedtest which encountered similar problems (I didn't proceed with test 3). I've been wearing my kid gloves since the start of the migration, and haven't changed anything in any way at this end. Just been browsing the forums this morning. Can anyone shed any light on what might have suddenly caused this problem?

Link Information     

Uptime: 3 days, 7:27:26 
DSL Type: G.992.5 annex A 
Bandwidth (Up/Down) [kbps/kbps]: 1,195 / 18,203 
Data Transferred (Sent/Received) [kB/kB]: 0.00 / 0.00 
Output Power (Up/Down) [dBm]: 12.0 / 0.0 
Line Attenuation (Up/Down) [dB]: 9.5 / 20.0 
SN Margin (Up/Down) [dB]: 6.5 / 7.0 
Vendor ID (Local/Remote): TMMB / IFTN 
Loss of Framing (Local/Remote): 155 / 0 
Loss of Signal (Local/Remote): 35 / 0 
Loss of Power (Local/Remote): 0 / 0 
Loss of Link (Remote): 0 
Error Seconds (Local/Remote): 59 / 0 
FEC Errors (Up/Down): 0 / 0 
CRC Errors (Up/Down): 0 / 403 
HEC Errors (Up/Down): 0 / 284

[#6]

Hi caulbox,
There could be a number of reasons for that. Your profile is ok on BT's side and ours. Your sync rate is still up and your connection hasn't dropped. I'd just monitor it for a but and see how it goes. You can find some help here but I'd hang on a bit before you try to troubleshoot it.
Jojo

[#7]

Thanks Jojo. I've got to go out for an hour or so soon, so that suits me fine

I'm also very patient, so I honestly don't mind if things take some time to finally stabilize. But the worry I have is whether problems like the above (especially as I've now logged a substandard BT Speedtest) have potential to wreak havoc with the training assessment?

[#8]

...starting to relax again already

[#9]

Whatever that low speed event was caused by the WAN uptime suggests your connection to the exchange didn't drop and your sync speeds down and upstream have not changed which supports that hypothesis. My guess is that there was a temporary fault in BT's network which was quickly bypassed or fixed. So nothing to be concerned about.
Regarding the displayed downstream output power being zero. There have been suggestions this occurs when the true value is the maximum possible. I'm on 21CN and have a TG585v8 with v8.2.7.8 software which reports 20.0dBm (and as an aside uptime is over 126 days). I have a feeling that would be reported as 0.0dBm on the v7.

[#10]

I sincerely appreciate your further comments and food for thought. What exactly do you mean by "when the true value is the maximum possible"?
One other thing you can perhaps advise me about is that whilst I was looking for possible causes of the low speed event at my end (retrospectively within the last hour) I've just come across a warning in the Event Viewer (XP SP3) which I've never witnessed before. I've done a bit of Googling but I'm flooded with info. It's starting to make a bit of (malware/virus seurity related) sense, but I'd appreciate your succinct expertise and advice.
Apart from my browser, I didn't have any programs whatsoever running at 8.00 a.m. this morning. Should I be concerned about this message, or is it warning me of normal behaviour which might possibly occur more often now, because of my new faster connection?
Event Type: Warning
Event Source: Tcpip
Event Category: None
Event ID: 4226
Date:  18/11/2011
Time:  08:00:38
User:  N/A
Computer: GRAFVE
Description:
TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts.

[#11]

Quote from: caulbox

... What exactly do you mean by "when the true value (of output power) is the maximum possible"?

My understanding is that to keep crosstalk between lines tolerable BT transmit the signal from the exchange using a maximum 100mW (milliwatts) power - which is 20dBm. However I don't know whether that is a regulatory requirement or not, and my understanding could be wrong. On ADSLmax maximum output power values were generally just under 20dBm, but values appear to go just a touch higher on ADSL2+.

Quote from: caulbox

(text extract reordered) TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts. Apart from my browser, I didn't have any programs whatsoever running at 8.00 a.m. this morning. Should I be concerned about this message, or is it warning me of normal behaviour which might possibly occur more often now, because of my new faster connection?

This is something I haven't come across before. I doubt it is associated with your faster connection, Naturally Microsoft suggest the worst interpretation (virus infection) though unless you've reason to suspect there might be there's probably a more innocent explanation. For example was your antivirus updating its definitions at the time, or perhaps Windows checking for updates? You might have browsed to a page with a number of images while internet access was (temporarily) blocked or slow giving the appearance of non-existent resources.
It would be prudent to scan your computer but if this event is a one-off I'd be inclined to ignore it.

[#12]

I suppose there could indeed be a 20dBm threshold figure which marks the onset of a possible firmware glitch in the TG585v7 linestats. That would be in keeping with my own experience. On 20CN when my output power was 19.5dBm it was always displayed correctly. But since (the event logged) 21.0dBm it's been reported as zero in the stats.
I've had no further reoccurrence of the 4226 warning event so hopefully it will prove to be a one-off. Malwarebytes' Anti-Malware gives me a clean bill of health, and whilst I haven't done a thorough deep antivirus scan, I trust that ZoneAlarm antivirus would have alerted me if a virus was implicated. (I can also dismiss any possibility that updating of virus definitions was the cause for the warning, as I don't allow automatic updates)
Since I last posted, I've saved a copy of the MS page which explains how to do some detective work using Netstat and Task Manager (not sure if -no is a possible MS typo or the command is updated in SP3, but the -n -o logic is clear). Unfortunately though, as on this occasion, I probably won't even know about any reoccurrence of similar behaviour until looking back at the warning in my Event Viewer (maybe several days later). But I am going to keep a wary eye, and if the behaviour ever does become frequent, then it'll be just a matter of time before the culprit gets identified!
I'm certainly not letting this bother me for now, but at the risk of showing my ignorance again. I am becoming more inclined to follow your earlier advice and reboot my router just once (after the training period) - just in case something malicious could have poisoned my router's cached DNS lookups in the past?  And - back on topic at last - I'm now also more inclined to eventually update the TG585 firmware, probably after 12th December as you further suggest. Much thanks

[#13]

The command netstat -no works for me on both XP SP3 and Vista. I found this guide to Windows netstat, food for thought in the discussion too. However I do feel the event you had is most likely an odd hiccup. Nevertheless taking the actions you mentioned would be prudent.

[#14]

Thanks for a useful link. Incidentally the -no suffix is working for me too now - my bad earlier as I'd just copied and pasted the command from the microsoft page (and subsequently edited out an extraneous carriage return to no avail, as I used EditPad Lite)

Back to my connection. A bit of a strange one this morning. As I implied earlier, drops in connection are extremely rare for me. Even with my new faster speeds, I was beginning to relax, thinking  my connection would likely remain just as stable and reliable as I'd become accustomed to (my SNR margin was varying at most between 6.0 and 7.5) Admittedly and expectedly my error count had noticeably increased from what I was used to on 20CN, but I didn't think it was anything to worry about (stats after 10 days below).

So I was a bit disturbed when I discovered that my connection had (untypically) dropped shortly after 7.00 a.m. this morning. The good news is that my sync has actually increased slightly following re-connection, and my speeds and profile(s) haven't taken a knock (BT's profile slightly increased to 16070 reflecting the higher sync, Plusnet line speed still at 16 Mb).

But what I don't understand is where the 4,294,967,264 errors suddenly originate from. Although my training period is now over(?) I am left wondering whether this mornings strange drop in connection was not so much a problem at my end, but might have been triggered by some necessary (or overly aggresive) RAMBo behaviour?

Alternatively I've also begun to muse over whether the drop in my connection (and subsequent strange stats) might in any way have been caused by Plusnet's maintenance work on the Broadband Faults Troubleshooter - which was due to complete around the time of my dropped connection. I don't want interleaving on if I can avoid it, as I don't think it's necessary with my good line? But I've noticed that another user has reported interleaving related issues last night, around the time when the maintenance work was due to commence. I'm left wondering whether behind the scenes maintenance has any potential to effectively indelicately touch upon some (interleaving related?) switch, which might explain my dropped connection and/or very brief PPP session, as well as the strange new error counts?





Link Information (after 10 days training - 25th Nov 8 a.m.)   

Uptime: 10 days, 4:01:35 
DSL Type: G.992.5 annex A 
Bandwidth (Up/Down) [kbps/kbps]: 1,195 / 18,203 
Data Transferred (Sent/Received) [kB/kB]: 0.00 / 0.00 
Output Power (Up/Down) [dBm]: 12.0 / 0.0 
Line Attenuation (Up/Down) [dB]: 9.5 / 20.0 
SN Margin (Up/Down) [dB]: 6.5 / 6.5 
Vendor ID (Local/Remote): TMMB / IFTN 
Loss of Framing (Local/Remote): 155 / 0 
Loss of Signal (Local/Remote): 35 / 0 
Loss of Power (Local/Remote): 0 / 0 
Loss of Link (Remote): 0 
Error Seconds (Local/Remote): 70 / 0 
FEC Errors (Up/Down): 0 / 0 
CRC Errors (Up/Down): 0 / 3,869 
HEC Errors (Up/Down): 0 / 2,084



Link Information (after drop this morning -  possible RAMBo or Plusnet enforced drop?)

Uptime: 0 days, 0:21:54 
DSL Type: G.992.5 annex A 
Bandwidth (Up/Down) [kbps/kbps]: 1,211 / 18,215 
Data Transferred (Sent/Received) [kB/kB]: 0.00 / 0.00 
Output Power (Up/Down) [dBm]: 12.5 / 0.0 
Line Attenuation (Up/Down) [dB]: 9.5 / 20.0 
SN Margin (Up/Down) [dB]: 6.0 / 6.5 
Vendor ID (Local/Remote): TMMB / IFTN 
Loss of Framing (Local/Remote): 155 / 0 
Loss of Signal (Local/Remote): 35 / 0 
Loss of Power (Local/Remote): 0 / 0 
Loss of Link (Remote): 0 
Error Seconds (Local/Remote): 105 / 0 
FEC Errors (Up/Down): 4,294,967,264 / 0 
CRC Errors (Up/Down): 4,294,967,264 / 0 
HEC Errors (Up/Down): 0 / 0

Logged Events
Nov 27 07:19:17 SNTP Synchronised to server: 212.159.13.49 
Nov 27 07:10:22 GRP Default destination is routed via gateway 87.112.xxx.xx 
Nov 27 07:10:22 PPP link up (Internet) [87.112.xxx.xx] - a new different address is now used 
Nov 27 07:10:21 PPP CHAP Chap receive success : authentication ok 
Nov 27 07:10:21 PPP CHAP Receive challenge (rhost = pcl-ag03) 
Nov 27 07:10:21 PPP CHAP Receive challenge (rhost = bras-red5.pr) 
Nov 27 07:10:05 GRP Default destination is not routed anymore via gateway 87.112.xxx.xxxx 
Nov 27 07:10:04 PPP link down (Internet) [87.112.xxx.xxx] 
Nov 27 07:09:57 FIREWALL event (1 of 1): deleted rules 
Nov 27 07:09:58 GRP Default destination is routed via gateway 87.112.xxx.xxx - same old address is used here
Nov 27 07:09:58 xDSL linestate up (ITU-T G.992.5; downstream: 18215 kbit/s, upstream: 1211 kbit/s; output Power Down: 21.0 dBm, Up: 12.5 dBm; line Attenuation Down: 20.0 dB, Up: 9.5 dB; snr Margin Down: 6.0 dB, Up: 7.0 dB) 
Nov 27 07:09:32 xDSL linestate down 
Nov 27 07:09:07 FIREWALL event (1 of 1): created rules 
Nov 27 07:09:07 GRP Default destination is not routed anymore via gateway 87.112.xxx.xxx 
Nov 27 07:09:07 xDSL linestate down 
Nov 27 06:19:17 SNTP Synchronised to server: 212.159.6.10

[#15]

pull the other one?
I hadn't realised till I viewed my own post, but by my reckoning
Lancashire (where I'm based) is a fair distance from the BT tower!
Is my location irrelevant to what is being measured by SpeedTest and PingTest?