Sorry to put a cat amongst the embedded pigeons, but I have a serious (I think) problem after the update:
I noticed no internet late this afternoon, so walked into room to find the HH5 with a red solid "b" illuminated and nothing happening.
So I thought - hmm, lets go back and have a troubleshoot. Didn't respond on LAN side to ping on 192.168.1.254, nor on port 443 either. Strange, so I thought I'll ping -b 255.255.255.255 , then arp -an - nothing related to the HH5 in the arp cache at all, not even an <incomplete> entry. Predictably, mtr 18.104.22.168 gave nothing, not even a first hop on the LAN ( PC is static, with HH5 IP as the default gw)
Back to HH5, check cables haven't fallen out, plug and regplug each cable, LAN-side and DSL cable, at both end. Still nothing, no change in lights, steady red "b" on front.
Power cycle, same red "b" after 2 or 3 seconds of green. No response to the default lan-side IP or ping broadcast then arp -an.
So, try a long-off power cycle. Turn off HH5 on back power switch, then swicth-off and unplug HH5 PSU at mains. leave 2 or 3 minutes, then plug back in, then turn mains PSU on, then HH5 power switch. Again, shows a red "b" after a couple of seconds of green.
So, try next a reset button press. Starting with a 15-second press with power off, when powered on - shows a red "b" after a couple of seconds of green.
Next, 15-second button-press, with power on this time. a second after the button is pressed - same as above - shows a red "b" after a couple of seconds of green. Same every time.
No WiFi detected with any ESSIDs (Bt WiFi is set on for this account) + No RF emissions on a 3GHz sample&hold FSM placed right next to it.
Now, unfortunately I don't have any logs saved (it should really have a an external syslogd server option if it's going to be this unreliable ! ) though when I checked last night at 0200hrs or sometime not long after that, I did notice the WAN uptime was far longer than 33 minutes, so I assumed an update had been applied to stabilise it - a quick look in the TR069 log confirmed some new (new meaning - sometime after 2000hrs Thursday) OpenRG and CWMP activity, though I didn't make notes due to the early hours)
History of events between last night discovery of inoperable HH5 today :
I had seen the post from RobbieMac about the new update to be served (presumably by OpenRG command then TR069 there after), "expected Friday afternoon", and, noticing another forum member had applied the wifi-reset workaround, decided that I would leave it for the TR069 update, so that both angles were tested.
Curiosity caused me to look at it during the early hours of Friday morning , noticed there'd been OpenRG and WAN uptime was longer than before, maybe 1-2hours . I expected the the update to be on Friday, so I made a note to check the logs Friday late afternoon to see if there was in fact any CWMP activity.
Friday late aftenoon when I found the unresponsive router with the red "b" on the front. It's now powered off, but still plugged into the NTE5/VDSL Mk1 faceplate via the DSL lead. No customer side wiring, or telephones on that circuit at all. That's up to date as of the time of this posting.
I'll do some troubleshooting of of the PSTN line later, probably tomorrow now, maybe run whatever tests I can (there doesn't seem to be very much testing I can do myself for a BT retail PSTN line 😞 )
I'm trying to get hold of another VDSL modem or modem/router to test the cabinet/VDSL signal, I recall seeing the red "b" about a month ago (when I spend ages being repeatedly cut off from the BT callcentre 😞 The red b in that case was (if memory serves me right) after getting a PADT, on reboot I got good/fast (80/20) sync but no PADO)
However, for that problem last month, decribed as a "network error", the HH5 appeared to go through a boot sequence of various flashing lights when I powercycled it, before eventually (after a minute or two?) finally displaying the red "b", possibly flashing, I don't remember exactly sorry. This time, unlike last month, on startup or reboot it's a second or two of green LED , then straight to the red "b" withing 3 seconds of powerup. No LAN activity at all.
I hope is isn't bricked - if it is I will not be amused at all I've already spent about 18 hours of research and troubleshooting yesterday to end up with all the symptoms of a brick and to top the lot - done remotely to fix something else that was cocked up !
HH5, previously doing 31-33-minutes uncommanded reboots, left connected as instructed (not done the manual wifi-reset suggested) overnight Thursday intop Friday
Noticed after 0200 BST (0100UTC) Friday that an update had been applied. I went back to sleep.
Next day (today, Friday )"No internet" just before 1700hrs Friday, unsure when this happened though.
Can't access HH5 on LAN
No reponse to ping -b 255.255.255.255 then arp -an
At power-on:- green LED for one or two seconds then red "b".
Tried power cycle - same.
Tried long (2-3 mins off) power-cycle, with PSU off too, to eliminate PSU crowbar -same.
Tried power-off 15 second reset-button - same.
Tried power-on 15-second reset-button - same.
Different Cat6 patches tried, into several different devices, direct into a NIC, through a couple of different switches
No wifi detected at all from it.
Anything else I can do? 2-button presses together? Hold a button and apply power?
We should really preserve the logs if possible, to work out what caused it, so I don't want to completely blank it.
Like I say, I'll test the PSTN line at some point tomorrow, but it doesn't even respond on the LAN sitting next to the workstation.
I hope this isn't a more widepread problem. I'm off to bed, I've had more than enough of this.
Problem HH5 Update
Robbie rang me yesterday but unfortunately I was out at hospital - a big problem for me is that I have telecare health monitoring, so if the broadband isn't capable of holding up for 1 hours periods with relatively low packet loss and acceptable latency/jitter I get recalled to hospital 😞 Another prpblem is that, although I have a far better ISP and a second line in my home than BT, the Telecare will only use VDSL, the other connection is ASDL2+, so it's no good for it. It's a shame "Britain's Best Broadband" has failed me.
When I got released I managed to borrow a Openreach VDSL modem (a "white box") so have that on the line - it's working OK but I seem to have dropped from a perfect 80/20 IP profile (or thereabouts) to a 62/20, probably as a result of the HH5 Reboot-of-Death saga.
I say Reboot-of-Death because last night, on giving the HH5 one last try - it was dead as a dodo, no lights, no activity at all - I've tried restart, reset, every button under the sun - not a sausage.
I was hoping some system or CWMP logs could be recovered to work out what was wrong - certainly, the pattern of lights it was exhibiting after I found it "in pain" on Friday evening was definitely NOT the same as my mate's HH5:
When booting, a working HH5: goes through a slow, prolonged ( 1-2minutes or more ) sequence of green, flashing green, then (depending on whether it can sync or not to the line) Blue (resumably success), Orange or Orange+Red-"b" flashing lights (with no sync or error) This took 2 minutes or more even with no DSL line plugged into it
( I think I've got all that right, all from memory of last night when I picked up the modem )
My HH5, after the rollout of the half-hour reboot "fix" on the 18th: from power-on, went through the following rapid cycle:-
A maximum 2 seconds of Green, then straight to a Red "b", WITHOUT associated Orange LED that signifies the line problem. This sequence was over and done, fixed to a solid (not flashing!) Reb "b" withing 3 seconds of power-on. There was no reponse on LAN, no apr activity on the LAN at all, no WiFi detected nor any RF on my 3GHz b/w meter.
When tested late the next day, it was completely dead on power-up, no lights or activity at all. (My HH5's PSU powers my friend's one fine, so It's not that)
Robbie suggested an engineer visit was needed, but I've had bad experiences with repeated BT no-shows for work jobs, so I'm rather nervous. Can this be swapped by an engineer?
My near-neighbours were recently (January 2014) told by the BT Engineer that neither HomeHubs nor modems were not carried on the vans so if it hadn't arrived in the post for the day of install, a new appointment was required, which took another 3 weeks (and was a no-show - unsurprising) - so you can understand my concerns for what is now a definitely dead HH5 on a working line.
The borrowed modem survived 40GB+ downloaded overnight of Debian and FreeBSD ISOs without a hitch, though the BT Wholesale speedtester suggests contention/congestion at the moment - I'll try the test login in a day or so when I've rested a bit ) I have to give the modem back in a few days, I have no WiFi without the HH5, but at least I know what the problem is now.
Robbie / Mods - either email me anytime <-- preferred, it works fine via my other ISP ( Andrews and Arnold ) or
ring my mobile number <--please ring only from Monday onwards ( I need to catch up on some rest, eventful weekend! ) There's no phone on the Infinity 2 line except when I'm testing quiet-line / ringback.
I have notified Robbie of your post here as he owns this case for you. When he returns to the office he will be in touch.
I have arranged to start the ball rolling on an order to replace your Home Hub 5.
|Did you get the help you needed?|
Help others by clicking on ‘Mark as accepted solution’
|Show your appreciation!|
Click on the star next to a reply to say thanks
|Help guide to using the community? Click below|
I'd have to see the errors you are referring to, the assoc/disassoc lines don't tell us anything on their own. They are, in fact, normal activity associated with the WiFi being enabled or cycled or reset, which could happen whenever a route is established (triggered by a link going down or up) by PPP fro example. There is also the added complication of the BT WiFi IPsec tunnel route, I'm not sure what extra that entails every time it builds/drops it's link.
Note that although there were a lot of logs posted by me with my problem, none of them contained any PPP errors at all, only normal activity. Compared to some routers I see daily, the logs were rather bare, hence why I posted them as they were easy to read.
It's possible that a mains glitch or power supply problem causes other things to happen, but a comparison of all logs in context would be needed (that's why, in part) I posted lots of logs of different types early in the thread.
Logfile analysis is difficult, good logs contain immense amounts of information, the majority of them are not errors, but success entries. I analyse log files all the time, but most people barely look at them.
You're looking for abnormal things, not normal, but unless you appreciate what normal is, it's tempting to assume every entry is an error unless you are used to dealing with Linux or Unix systems. My desktop/workstaion PC generates about 5-to-10,000 logfile entries every day, which are compressed, archived, and rotated automatically . I haven't noticed and error for weeks on this machine. I also store the logs in a central place and run a log analysys program (Splunk) to establish baselines and abnormal behaviour. This is very necessary when dealing with hundreds of machines, but with a bit of experience you can easily find problems "by eye" when you need to, you just refer to the timestamp around a certain event.
The reason for the wifi needing reset to apply the patch was probably because a wifi-related daemon was in a state that needed restarted but it could not be done remotely, so an OpenRG reboot was needed. BT can't get people to restart their hubs on request, so they set them to do it remotely using OpenRG. When the HH comes up, as part of the boot sequence it contacts the TR069 CWMP server to get patches.
Update on my problem: New HH5 repalcement for the bricked one has arrived, I'll install it when I get home. Line is still working fine on a borrowed VDSL modem into a real router.
I'm no expert, but I'll have a guess.
The update pushed out on the 15th changed something in the way auto wifi channels are selected. Reboots started 24 hours later, maybe when wifi leases were renewed after the reboot?
The reboots at 30 minute intervals (some users were quoting 33, some 34, but I'm sure it was 30 and the extra minutes quoted were including reboot time) could tie into a time interval that the auto wifi channel sensing uses. There was obviously a bug in this process that caused the router to crash / reboot.
Fixing the wifi channels prevented this auto sensing routine running, hence no reboot. Patch was pushed to mine last night and no issues since.
You may be right, but I'd hope that...
a] The router takes less than 3 minutes to boot and issue a lease to a client,
b] The router doesn't scan channels every 30 minutes to find a clear channel. That's not how smart-wireless works - it should be dynamic and real-time.