Hub one losing wifi connection

[#1]

Quiet possibly a little premature yet, but put the Apple Watch in flight mode last night. No reboot as yet this morning!
Edited to add…
The IT guy at work thinks this could also possibly indicate an exchange issue as this is where the reboot is happening…
03:46:34, 20 Jan. (196616.640000) PPPoE is down after 2091 minutes uptime [Waiting for Underlying Connection (WAN Ethernet 7 -​ Down)]

[#2]

Hi @Prawnyloks

Thanks for coming back to us. Sorry to see that this has dropped again.

Just for your reference, here is the current state of play with your connection.

From our suppliers perspective, the next step would be to dispatch another engineer. However, I'm going to tag my colleague @bobpullen on this one just in case there's anything in the router logs that we're missing. What puzzles me is how consistent the time of the drops are (with the exception of the most recent one which seems to be a bit of a break from the rule).

At this stage, I'd recommend monitoring the connection over the next 48 hours, ensuring that you're in the test socket of your premises. If the drops continue and @bobpullen can't shed any additional light, it's likely that we'd need to escalate this through our suppliers and potentially send another engineer.

Let us know how you get on.

Best wishes

Dave

[#3]

The line is physically dropping sync as can be seen below.

The only way the router should ever cause this, is if it's rebooting/restarting - and it isn't:

[#4]

Thanks for your input @RandallFlagg. I can see from the graph, that the drops are happening exactly as I described. Obviously with the exception of Thursday when the firmware was pushed and then Friday when the engineer visited, followed by the profile being reset. Saturday is the first day I'm aware of with no drops at all.

So, if it isn't my router as @bobpullen says, the graph just shows the connections going up and down and as such doesn't mean that much to me I'm afraid. Then maybe it's worth looking at the external WAN next? Could something at the exchange be causing a problem like my colleague suggested, or something else externally?

I had a good chat with the engineer during his visit and he said that there is categorically nothing wrong with my line that could be causing this. He has performed these tests twice now. Why would sending another engineer to test my line again help? Unless of course they're going to camp out in the early hours to test when these drops are actually happening!

The engineer also pointed out to me that there isn't actually any milage in me plugging in to the test socket in my case as I'm already plugged in to the master socket with no other extensions present, no other wiring can affect it, and if I were to plug in to the test socket then I will have to use an other filter as the plug is the phone type and not the DSL one on my type of master socket. The setup I currently have is as clean as it gets. I will add a photo of my master socket so you can see the type.

Btw, I accidentally caused a reboot by seeing how easy it was to remove the faceplate. Incidentally, if the router isn't rebooting/restarting shouldn't the light just stay blue and not go through the orange start up process? I have seen it do this when it reset a week or two back around 6am?

Lastly, the reboot that happened this morning has now knocked my line connection speed back down a level to 38.17Mbps from the previous 39.95Mbps. Speed test are now around 35Mbps instead of over 36Mbps. I guess that it will reduce again when the next drop happens, so please can someone ensure that the profile keeps getting reset for me as long as this keeps happening?

I will continue monitoring, but at the moment I'm not too hopeful and will be surprised if I'm not reporting back with more of the same very soon.

[#5]

Thanks for getting back to us.

At the moment we have an escalation open with our suppliers and they'll be able to advise us further on what can be done instead of just throwing multiple engineers at the fault.

As soon as we know more our faults team will update you further

[#6]

Thanks for the update @MatthewWheeler. Let’s hope someone comes up with something new to try as we seem to have been travelling in circles since Christmas now 🤞🏼

[#7]

@MatthewWheeler, I just got off the phone with another of your tech guys, I forgot his name sorry. I had received another message via the ongoing fault ticket, asking to send yet another engineer to test the line that has twice already passed with flying colours. The chap I just spoke to said he would look into this for me and try to stop these unnecessary circles we seem to going in and try find another route to go down beyond my property. Really hoping he can get somewhere this time! Lets see what tomorrow brings.

[#8]

Btw, two drops yesterday to my knowledge (yesterday and overnight). One around 3:45pm I think and then the other early this morning around 1:25am. Timings seem to be getting more erratic now and this last drop has lowered my profile by another 4Mbps again!
Please can it be reset again?

[#9]

Router log from the reboot page…
01:25:38, 23 Jan.
(447356.190000) PTM over DSL is up
01:25:35, 23 Jan.
(447353.430000) CWMP: session closed due to error: Could not resolve host
01:25:35, 23 Jan.
(447353.420000) CWMP: Server URL: https://dbtpnhdm.bt.mo; Connecting as user: ACS username
01:25:35, 23 Jan.
(447353.410000) CWMP: Session start now. Event code(s): '4 VALUE CHANGE'
01:25:05, 23 Jan.
(447323.080000) CWMP: session closed due to error: Could not resolve host
01:25:05, 23 Jan.
(447323.050000) CWMP: Server URL: https://dbtpnhdm.bt.mo; Connecting as user: ACS username
01:25:05, 23 Jan.
(447323.050000) CWMP: Session start now. Event code(s): '4 VALUE CHANGE'
01:25:05, 23 Jan.
(447322.700000) CWMP: Initializing transaction for event code 4 VALUE CHANGE
01:25:02, 23 Jan.
(447320.110000) PTM over DSL is down after 573 minutes uptime
01:25:02, 23 Jan.
(447320.110000) PPPoE is down after 572 minutes uptime [Waiting for Underlying Connection (WAN Ethernet 7 - Down)]
01:25:01, 23 Jan.
IN: ACCEPT [57] Connection closed (Port Forwarding: UDP [192.168.1.75]:10300 <- - > [212.159.19.183]:10300 - - - [50.16.197.146]:32099 ppp3 NAPT)
01:25:01, 23 Jan.
IN: ACCEPT [57] Connection closed (Port Forwarding: UDP [192.168.1.75]:10300 <- - > [212.159.19.183]:10300 - - - [52.8.110.102]:32099 ppp3 NAPT)
01:24:59, 23 Jan.
(447317.460000) PPP LCP Send Termination Request [User request]
01:24:20, 23 Jan.
IN: BLOCK [16] Remote administration (TCP [118.70.202.142]:38390- >[212.159.19.183]:443 on ppp3)
01:17:11, 23 Jan.
IN: BLOCK [16] Remote administration (TCP [42.118.100.141]:64011- >[212.159.19.183]:443 on ppp3)
01:12:13, 23 Jan.
ath10: STA 2c:08:8c:00:fd:a5 IEEE 802.11: WiFi registration failed
01:11:28, 23 Jan.
IN: BLOCK [16] Remote administration (TCP [74.82.47.21]:37991- >[212.159.19.183]:8443 on ppp3)
01:05:20, 23 Jan.
IN: BLOCK [16] Remote administration (TCP [116.255.221.214]:60556- >[212.159.19.183]:80 on ppp3)
01:02:35, 23 Jan.
ath10: STA 2c:08:8c:00:fd:a5 IEEE 802.11: Client associated
01:01:33, 23 Jan.
IN: BLOCK [16] Remote administration (TCP [45.233.245.198]:32877- >[212.159.19.183]:8080 on ppp3)
01:00:24, 23 Jan.
IN: BLOCK [16] Remote administration (TCP [210.61.228.36]:17531- >[212.159.19.183]:8080 on ppp3)
00:58:20, 23 Jan.
IN: BLOCK [16] Remote administration (TCP [113.23.100.236]:12440- >[212.159.19.183]:443 on ppp3)
00:53:44, 23 Jan.
IN: BLOCK [16] Remote administration (TCP [179.106.102.238]:15370- >[212.159.19.183]:8080 on ppp3)
00:52:18, 23 Jan.
ath10: STA 5c:ad:cf:ce:dd:58 IEEE 802.11: Client associated
00:52:18, 23 Jan.
ath10: STA 5c:ad:cf:ce:dd:58 IEEE 802.11: Client disassociated
00:52:13, 23 Jan.
ath10: STA 2c:08:8c:00:fd:a5 IEEE 802.11: WiFi registration failed
00:43:59, 23 Jan.
IN: BLOCK [16] Remote administration (TCP [210.29.34.10]:2916- >[212.159.19.183]:22 on ppp3)
00:38:52, 23 Jan.
IN: BLOCK [16] Remote administration (TCP [120.79.130.249]:43921- >[212.159.19.183]:8080 on ppp3)
00:31:05, 23 Jan.
IN: BLOCK [16] Remote administration (TCP [74.82.47.47]:40029- >[212.159.19.183]:8080 on ppp3)
00:26:25, 23 Jan.
IN: BLOCK [16] Remote administration (ICMP type 8 code 0 113.204.83.58- >212.159.19.183 on ppp3)
00:23:20, 23 Jan.
IN: BLOCK [16] Remote administration (TCP [79.58.215.225]:53187- >[212.159.19.183]:22 on ppp3)
00:21:14, 23 Jan.
IN: BLOCK [16] Remote administration (TCP [177.9.179.44]:8187- >[212.159.19.183]:8080 on ppp3)
00:20:26, 23 Jan.
IN: BLOCK [16] Remote administration (TCP [5.54.202.129]:30356- >[212.159.19.183]:8080 on ppp3)
00:09:03, 23 Jan.
IN: BLOCK [16] Remote administration (TCP [8.42.242.124]:22887- >[212.159.19.183]:80 on ppp3)
00:04:06, 23 Jan.
IN: BLOCK [16] Remote administration (TCP [195.175.107.230]:53110- >[212.159.19.183]:8080 on ppp3)
00:01:51, 23 Jan.
IN: BLOCK [16] Remote administration (TCP [185.53.91.23]:56320- >[212.159.19.183]:443 on ppp3)
23:55:10, 22 Jan.
IN: BLOCK [16] Remote administration (TCP [177.19.255.253]:42625- >[212.159.19.183]:443 on ppp3)
23:52:34, 22 Jan.
IN: BLOCK [16] Remote administration (TCP [71.6.233.61]:443- >[212.159.19.183]:443 on ppp3)
23:41:30, 22 Jan.
IN: BLOCK [16] Remote administration (TCP [58.218.56.102]:314- >[212.159.19.183]:8080 on ppp3)
23:40:05, 22 Jan.
IN: BLOCK [16] Remote administration (TCP [218.92.1.178]:37902- >[212.159.19.183]:22 on ppp3)
23:39:37, 22 Jan.
IN: BLOCK [16] Remote administration (TCP [198.108.67.82]:38049- >[212.159.19.183]:8443 on ppp3)
23:39:27, 22 Jan.
ath10: STA 2c:08:8c:00:fd:a5 IEEE 802.11: Client associated
23:39:19, 22 Jan.
IN: BLOCK [16] Remote administration (TCP [37.49.228.121]:58149- >[212.159.19.183]:80 on ppp3)
23:36:42, 22 Jan.
IN: BLOCK [16] Remote administration (UDP [52.73.169.169]:50491- >[212.159.19.183]:161 on ppp3)
23:35:53, 22 Jan.
ath10: STA 5c:ad:cf:ce:dd:58 IEEE 802.11: Client associated
23:32:13, 22 Jan.
ath10: STA 2c:08:8c:00:fd:a5 IEEE 802.11: WiFi registration failed
23:31:18, 22 Jan.
IN: BLOCK [16] Remote administration (TCP [42.118.71.238]:59587- >[212.159.19.183]:443 on ppp3)
23:29:53, 22 Jan.
IN: BLOCK [16] Remote administration (ICMP type 8 code 0 23.108.65.85- >212.159.19.183 on ppp3)
23:29:50, 22 Jan.
IN: BLOCK [16] Remote administration (TCP [201.177.12.61]:3733- >[212.159.19.183]:8080 on ppp3)
23:24:16, 22 Jan.
IN: BLOCK [16] Remote administration (TCP [178.93.46.27]:50004- >[212.159.19.183]:80 on ppp3)
23:23:43, 22 Jan.
IN: ACCEPT [57] Connection closed (Port Forwarding: UDP [192.168.1.75]:10301 <- - > [212.159.19.183]:10301 - - - [50.16.197.146]:32099 ppp3 NAPT)
23:23:43, 22 Jan.
IN: ACCEPT [57] Connection closed (Port Forwarding: UDP [192.168.1.75]:10301 <- - > [212.159.19.183]:10301 - - - [52.8.110.102]:32099 ppp3 NAPT)
23:22:06, 22 Jan.
IN: ACCEPT [54] Connection opened (Port Forwarding: UDP [192.168.1.75]:10300 <- - > [212.159.19.183]:10300 - - - [52.8.110.102]:32099 ppp3 NAPT)
23:22:06, 22 Jan.
IN: ACCEPT [54] Connection opened (Port Forwarding: UDP [192.168.1.75]:10300 <- - > [212.159.19.183]:10300 - - - [50.16.197.146]:32099 ppp3 NAPT)
23:21:54, 22 Jan.
ath10: STA 2c:08:8c:00:fd:a5 IEEE 802.11: Client associated
23:17:45, 22 Jan.
ath00: STA 28:ad:3e:0e:42:3c IEEE 802.11: Client associated
23:17:45, 22 Jan.
ath00: STA 28:ad:3e:0e:42:3c IEEE 802.11: Client disassociated
23:17:30, 22 Jan.
IN: ACCEPT [57] Connection closed (Port Forwarding: UDP [192.168.1.75]:10300 <- - > [212.159.19.183]:10300 - - - [52.8.110.102]:32099 ppp3 NAPT)
23:17:29, 22 Jan.
IN: ACCEPT [57] Connection closed (Port Forwarding: UDP [192.168.1.75]:10300 <- - > [212.159.19.183]:10300 - - - [50.16.197.146]:32099 ppp3 NAPT)
23:16:33, 22 Jan.
IN: ACCEPT [54] Connection opened (Port Forwarding: UDP [192.168.1.75]:10301 <- - > [212.159.19.183]:10301 - - - [52.8.110.102]:32099 ppp3 NAPT)
23:16:33, 22 Jan.
IN: ACCEPT [54] Connection opened (Port Forwarding: UDP [192.168.1.75]:10301 <- - > [212.159.19.183]:10301 - - - [50.16.197.146]:32099 ppp3 NAPT)
23:16:19, 22 Jan.
ath00: STA 28:ad:3e:0e:42:3c IEEE 802.11: Client associated
23:16:19, 22 Jan.
ath00: STA 28:ad:3e:0e:42:3c IEEE 802.11: Client disassociated
23:15:45, 22 Jan.
ath00: STA 28:ad:3e:0e:42:3c IEEE 802.11: Client associated
23:15:45, 22 Jan.
ath00: STA 28:ad:3e:0e:42:3c IEEE 802.11: Client disassociated
23:08:34, 22 Jan.
IN: BLOCK [16] Remote administration (TCP [182.79.223.194]:59387- >[212.159.19.183]:8443 on ppp3)
23:02:13, 22 Jan.
ath00: STA 5c:cf:7f:39:b3:8d IEEE 802.11: Client disassociated
23:02:13, 22 Jan.
ath10: STA 2c:08:8c:00:fd:a5 IEEE 802.11: WiFi registration failed
23:02:13, 22 Jan.
ath00: STA 5c:cf:7f:39:b3:8d IEEE 802.11: WiFi registration failed
23:02:01, 22 Jan.
IN: BLOCK [16] Remote administration (TCP [185.53.88.19]:28- >[212.159.19.183]:80 on ppp3)
23:01:02, 22 Jan.
OUT: BLOCK [7] ICMP replay (ICMP type 3 code 1 212.159.19.183- >23.23.35.4 on ppp3)
23:01:00, 22 Jan.
BLOCKED 2 more packets (because of ICMP replay)
23:00:59, 22 Jan.
OUT: BLOCK [7] ICMP replay (ICMP type 3 code 1 212.159.19.183- >23.23.35.4 on ppp3)
22:59:46, 22 Jan.
ath00: STA 5c:cf:7f:39:b3:8d IEEE 802.11: Client associated
22:59:44, 22 Jan.
ath00: STA 5c:cf:7f:39:b3:8d IEEE 802.11: Client disassociated
22:59:38, 22 Jan.
ath00: STA 5c:cf:7f:39:b3:8d IEEE 802.11: Client associated
22:59:07, 22 Jan.
IN: BLOCK [16] Remote administration (TCP [104.218.54.163]:57860- >[212.159.19.183]:80 on ppp3)
22:56:11, 22 Jan.
ath10: STA 2c:08:8c:00:fd:a5 IEEE 802.11: Client associated
22:54:29, 22 Jan.
IN: BLOCK [16] Remote administration (TCP [45.112.126.121]:35219- >[212.159.19.183]:443 on ppp3)
22:52:38, 22 Jan.
IN: BLOCK [16] Remote administration (TCP [222.186.129.44]:9090- >[212.159.19.183]:22 on ppp3)
22:42:13, 22 Jan.
ath10: STA 2c:08:8c:00:fd:a5 IEEE 802.11: WiFi registration failed
22:35:53, 22 Jan.
IN: BLOCK [16] Remote administration (TCP [119.29.80.17]:30483- >[212.159.19.183]:22 on ppp3)
22:33:35, 22 Jan.
IN: BLOCK [16] Remote administration (TCP [95.225.65.39]:54996- >[212.159.19.183]:80 on ppp3)
22:33:26, 22 Jan.
IN: BLOCK [16] Remote administration (TCP [45.58.137.143]:3450- >[212.159.19.183]:22 on ppp3)
22:32:22, 22 Jan.
IN: BLOCK [16] Remote administration (TCP [80.18.216.25]:11197- >[212.159.19.183]:80 on ppp3)
22:32:05, 22 Jan.
ath00: STA 38:c9:86:91:48:04 IEEE 802.11: Client associated
22:30:21, 22 Jan.
ath10: STA 2c:08:8c:00:fd:a5 IEEE 802.11: Client associated
22:29:50, 22 Jan.
IN: BLOCK [16] Remote administration (TCP [37.49.228.121]:42313- >[212.159.19.183]:80 on ppp3)
22:29:31, 22 Jan.
IN: BLOCK [16] Remote administration (TCP [61.216.40.209]:64458- >[212.159.19.183]:443 on ppp3)
22:25:12, 22 Jan.
IN: BLOCK [16] Remote administration (TCP [190.17.1.47]:25918- >[212.159.19.183]:443 on ppp3)
22:23:15, 22 Jan.
IN: BLOCK [16] Remote administration (TCP [202.86.222.4]:35883- >[212.159.19.183]:443 on ppp3)
22:15:37, 22 Jan.
ath00: STA 38:c9:86:91:48:04 IEEE 802.11: Client disassociated
22:13:35, 22 Jan.
ath00: STA 38:c9:86:91:48:04 IEEE 802.11: Client associated
22:12:32, 22 Jan.
IN: BLOCK [16] Remote administration (TCP [177.68.39.76]:60936- >[212.159.19.183]:80 on ppp3)
22:12:13, 22 Jan.
ath10: STA 2c:08:8c:00:fd:a5 IEEE 802.11: Client disassociated
22:12:13, 22 Jan.
ath10: STA 2c:08:8c:00:fd:a5 IEEE 802.11: WiFi registration failed
22:12:13, 22 Jan.
ath10: STA 94:44:44:96:19:bc IEEE 802.11: WiFi registration failed
22:10:52, 22 Jan.
IN: BLOCK [16] Remote administration (TCP [139.162.114.154]:59880- >[212.159.19.183]:80 on ppp3)
22:09:41, 22 Jan.
IN: BLOCK [16] Remote administration (TCP [202.191.121.126]:22213- >[212.159.19.183]:443 on ppp3)
22:07:23, 22 Jan.
(435460.860000) New GUI session from IP 192.168.1.65

[#10]

So, I had a few fairly settled weeks since my last post, then a couple more issues which resulted in me finding that Channel 36 was the only/best one to use for 5GHz wifi. However, sadly the router has started playing up more and more again

A few times now, I've had a situation where the 5GHz wifi stops working, but the the router doesn't seem to realise it -- just that devices connected to it can't get to the internet or even to the Hub Manager page. See log from shortly after 08:50 this morning for an example. Turning the wifi off and on doesn't seem to fix anything, so a reset is required.

Yesterday I also experienced a random disconnection (not for the first time) which shows in the log at 10:06, apparently triggered by a [user request]... which I did not!

I've noticed quite a lot of log entries (at times) in my log generally -- not much idea what they mean or whether they matter -- but I'm now back at the point of Question 183874134 from the end of October and would really like to get things working properly again.

I don't have any Kindle, Fire or other Amazon devices, but all my troubles seemed to start around the date of the Firmware update I had in October... is there a chance that's causing all this bother too?

Any help, advice or updates you can give would be appreciated! Thanks, Tim.

[#11]

@tj sounds symptomatic of a know issue affecting the version you were upgraded to. I've just pushed another update to your router so let me know how that goes...

[#12]

Thanks @bobpullen, much appreciated

The update has arrived; hopefully everything will be stable now. 

[#13]

afternoon all, hope you don't mind me jumping on the thread.  My parents have had their plusnet one hub for a couple of months now.  total technophobes and have been complaining about the wifi service to their iPad.  having read this thread i'm wondering if they would benefit from the firmware upgrade.  

i'm not saying its isolated to the iPad, but i can't confirm as i've not been around to check it.  they do have amazon fire sticks and a couple of echos on the network too.

The symptom is very much a case of slow wifi speeds which comes and goes, and then the network will stop responding to requests, i.e new web pages and it stalls.  They've had BT before now and had no issues with the network.  the last time i was at their house i changed the channel for the wifi, which had no success at all and anytime i've carried out a speedtest it certainly tells me that they're gaining the best from their line, its more wifi LAN issues i think.

i have considered helping my dad over the phone to split the 2.4 and 5Ghz but wondered if a firmware upgrade pushed out would solve the issues.  its a difficult task when he's not the best with technology and i'd do anything to avoid the headache

current plusnet hub one firmware is 4.7.5.1.83.8.259 and last update: unknown.

any thoughts?

[#14]

Hi @Firsttruster,

It sounds like the current firmware version in use could be causing the issues that you're describing. As this isn't your account and we don't have access to any of the account or router details, I'm afraid that we have no way of updating this manually from our side as it stands. The good news is that there is a firmware update rollout  due to take place between now and March, which will update Hub One routers to a newer version of the firmware.

That being said, if you can arrange for the account holder to pass their details on to us, we can look into this issue further and see what can be done to speed up this process.

[#15]

Thanks for the reply @TheMightyAJ.

I've just spoken with him and got the details you should require however, i suspect this maybe isn't enough for you to proceed.  if i am able to PM you, i can send you his router serial number and confirm any other details you would require?