Gigaclear occasional dropouts

I transferred from PlusNet to Gigaclear early this year (because Openreach had no plans to lay FTTP for at least another couple of years). It's generally OK but from time to time the service drops for a couple of minutes before returning automatically.

I raised a fault ticket with them at the time (around April/May), and they tried several things including replacing the 2 Linksys SPNMX55GC nodes (which don't have backup/restore capability but that's a matter for a separate post!), but because of the intermittent nature it wasn't clear if that solved the problem.

It seems to be OK for a few weeks but then the fault returns, happening mutliple times a day.(11 times so far today). The ONT looks OK, with no change on the LEDs.

The Gigaclear tech people seem to think it's a local (to me) problem, but I spoke to a neighbour earlier today who's also just had Gigaclear installed and they're experiencing the same problem.

Has anyone else experienced this and, if so, was it ever satisfactorily resolved (and how)?

Thanks

So does this problem occur on both wireless and ethernet wired devices?

In reply to a post by DFScale:

So does this problem occur on both wireless and ethernet wired devices?

Yes it's everything. The smart TV is connected via ethernet and that stops as well.

The blue light on the Linksys tower changes from steady to blinking as if it's trying to reconnect - which presumably it is because after a couple of minutes it works OK again

Yes, the flashing blue light is attempting to reconnect - see here https://support.linksys.com/kb/article/403-en/

I note that the linksys is automatically updated by gigaclear, so I will just throw into the mix the possibility it is trying to update

Edited by DFScale (Fri 05-Sep-25 18:28:39)

In reply to a post by DFScale:

Yes, the flashing blue light is attempting to reconnect - see here https://support.linksys.com/kb/article/403-en/

I note that the linksys is automatically updated by gigaclear, so I will just throw into the mix the possibility it is trying to update

Interesting thought, although Gigaclear tech support have never suggested this as a possibility, plus it's odd that it happens so often on some days (15 times on Aug 1st, 11 so far today). When it first started happening they sent me replacement nodes (which didn't fix anything*). I would have thought that they'd be able to see if it was due to an attempted update, whether the update was successful and what the before/after versions were.

(*Since the Aug 1st problems they've sent me another pair of nodes but as there's apparently no way of backing up the config to restore to the new nodes - subsequently confirmed by Linksys - I've told Gigaclear that, having 40+ devices needing reserved IPs, I'm not willing to manually reconfigure the new nodes unless and until they can categorically say that will fix it).

In reply to a post by DFScale:

Yes, the flashing blue light is attempting to reconnect - see here https://support.linksys.com/kb/article/403-en/

I note that the linksys is automatically updated by gigaclear, so I will just throw into the mix the possibility it is trying to update

I think with 27 drops yesterday it's fairly safe to say now that it's not down to updates

I've contacted GC tech support (again), will see where it goes this time...

Despite swapping out the MX5500s for a pair of MX4200s the problem remains

Finally yesterday Gigaclear said "We can see the reason your main node is disconnecting is due to a request" and "check any devices you have that could cause as DHCP interference"

Most of my devices have reserved LAN addresses - where the router doesn't allow multiple devices to be allocated the same IP - so I don't see how this might be.

Can anyone tell me how I might identify these "disconnection requests" and where they're coming from? I'm thinking something like Wireshark might help but I've never used that in anger.

I am sure there might be a more technical answer to this using Wireshark etc but.....

Being a bit old school myself, is it time for a process of elimination? I know your network might contain lots of devices, but it does sound like you have a regularly occurring issue so you might not have long to wait until you unplug the correct device (or start with everything off, and turn things on gradually).

If your network is anything like mine, just turning off the WiFi will take at least half of the devices out of the equation.

Presuming that is, that Gigaclear have identified the correct problem of course, but you have to do these things to move on to the next set of diagnostics from them.

In reply to a post by fguk:

I am sure there might be a more technical answer to this using Wireshark etc but.....

Being a bit old school myself, is it time for a process of elimination? I know your network might contain lots of devices, but it does sound like you have a regularly occurring issue so you might not have long to wait until you unplug the correct device (or start with everything off, and turn things on gradually).

If your network is anything like mine, just turning off the WiFi will take at least half of the devices out of the equation.

Presuming that is, that Gigaclear have identified the correct problem of course, but you have to do these things to move on to the next set of diagnostics from them.

The problem with this approach is that the connection drops are sporadic, sometimes weeks apart, so I might never be able to pin it down to a specific device - it's trying to prove a negative

Yes I could turn off the WiFi and eliminate a bunch of devices, but that would compromise my setup and operation, and yet the same "how long do I leave it" problem exists.

I'm trying to get more detail about the drops (if they're seeing something, tell me what they're seeing!) but I'm starting to get pushback now, they've just said "We do not advise to make configurations and adjustments on Linksys routers". Crazy!

If the commands to disconnect are coming sporadically, it's likely to be a device that's rarely used within your home. If it was daily, it's something you use a lot of.

Are you able to think which devices you rarely turn on are rarely used but connected?

Ah sorry, it sounded like you had a fairly reliable unreliability to work with (multiple drops in a day, regularly), but as you say, that is too much compromise if it isn't every day.

Taking into account you may not get the answers you want from the ISP, how about you put another device in charge of the internal network (temporarily), and double NAT? Obviously a rubbish idea if your network is too complex with incoming ports etc. However it again might prove a point.

In reply to a post by fguk:

Being a bit old school myself, is it time for a process of elimination?

Agree. Old school too.

In reply to a post by brushton:

The problem with this approach is that the connection drops are sporadic, sometimes weeks apart, so I might never be able to pin it down to a specific device - it's trying to prove a negative

Yes I could turn off the WiFi and eliminate a bunch of devices, but that would compromise my setup and operation, and yet the same "how long do I leave it" problem exists.Crazy!

Nope, you are not thinking this through. You have been told "check any devices you have that could cause as DHCP interference", which may or may not be the cause, but to go any further with the ISP, you need to look into it. First thing is to cut all your dhcp leases to something ridiculously short and see whether the problem becomes more frequent.

And if that is inconclusive see if you have a dhcp lease table in the router. Keep an eye on what is running out of lease and see whether the problem arises shortly after the lease has run out. Or you could be proactive and put absolutely everything on to your LAN and go around them one by one and prompt them to renew their leases. A power recycle should do this. See whether this prompts your problem to recur.

In reply to a post by fguk:

Taking into account you may not get the answers you want from the ISP, how about you put another device in charge of the internal network (temporarily), and double NAT? Obviously a rubbish idea if your network is too complex with incoming ports etc. However it again might prove a point.

Or put another device on a network LAN connection with a dhcp server, but no other role in the network. Turn off the dhcp server on the main router. Check that you only have the one dhcp server initially, otherwise you might just replicate the problem with a new dhcp server.

In reply to a post by Bryer:

If the commands to disconnect are coming sporadically, it's likely to be a device that's rarely used within your home. If it was daily, it's something you use a lot of.

Are you able to think which devices you rarely turn on are rarely used but connected?

I've tried, but the drops happen at all hours of the day - and night! - and it happens independently of us doing anything, seeing it drop when, say, we turned something on, would be a piece of cake to identify

In reply to a post by DFScale:

In reply to a post by fguk:

Being a bit old school myself, is it time for a process of elimination?

Agree. Old school too.

In reply to a post by brushton:

The problem with this approach is that the connection drops are sporadic, sometimes weeks apart, so I might never be able to pin it down to a specific device - it's trying to prove a negative

Yes I could turn off the WiFi and eliminate a bunch of devices, but that would compromise my setup and operation, and yet the same "how long do I leave it" problem exists.Crazy!

Nope, you are not thinking this through. You have been told "check any devices you have that could cause as DHCP interference", which may or may not be the cause, but to go any further with the ISP, you need to look into it. First thing is to cut all your dhcp leases to something ridiculously short and see whether the problem becomes more frequent.

And if that is inconclusive see if you have a dhcp lease table in the router. Keep an eye on what is running out of lease and see whether the problem arises shortly after the lease has run out. Or you could be proactive and put absolutely everything on to your LAN and go around them one by one and prompt them to renew their leases. A power recycle should do this. See whether this prompts your problem to recur.

Ah OK, I was wondering if I should make the leases longer to reduce the requests, but this is an interesting way of proceeding. It's kind of odd (to me) that with a (standard) 1440 minute lease time and 30-40 devices this "interference" might be a problem

Thanks

In reply to a post by DFScale:

In reply to a post by fguk:

Taking into account you may not get the answers you want from the ISP, how about you put another device in charge of the internal network (temporarily), and double NAT? Obviously a rubbish idea if your network is too complex with incoming ports etc. However it again might prove a point.

Or put another device on a network LAN connection with a dhcp server, but no other role in the network. Turn off the dhcp server on the main router. Check that you only have the one dhcp server initially, otherwise you might just replicate the problem with a new dhcp server.

Interesting, hadn't thought of that. I have a spare Raspberry Pi or 2 kicking around, I think one of those might do the job

In reply to a post by brushton:

Ah OK, I was wondering if I should make the leases longer to reduce the requests, but this is an interesting way of proceeding. It's kind of odd (to me) that with a (standard) 1440 minute lease time and 30-40 devices this "interference" might be a problem

The difference between trying to make a problem go away and finding whether something is a problem so you can take targetted action.

Good luck!!

It's been quite unstable today (14 drops so far) without me doing anything on it. I'm building a Raspberry Pi DHCP server (using PiHole) but I'm just wondering if I can deduce anything from the DHCP remaining lease times if I reduce the standard value to, say, 30 minutes?

Does it tell us anything if some devices are still on a near-24-hour refresh after 30 minutes have expired?

(Sorry if this is a dumb question, I'm star trekking with this )

In reply to a post by brushton:

Does it tell us anything if some devices are still on a near-24-hour refresh after 30 minutes have expired?

The dumb question is the one you don't ask ...

AIUI, the clients own the lease for the time they were originally given. You can't push a reduced lease by reducing it on the server. There probably is a client command to renew the lease [different for every operating system no doubt ...]. The certain way to reduce the lease is to restart the machine in question [or wait for all the leases to expire].

In reply to a post by DFScale:

In reply to a post by brushton:

Does it tell us anything if some devices are still on a near-24-hour refresh after 30 minutes have expired?

The dumb question is the one you don't ask ...

AIUI, the clients own the lease for the time they were originally given. You can't push a reduced lease by reducing it on the server. There probably is a client command to renew the lease [different for every operating system no doubt ...]. The certain way to reduce the lease is to restart the machine in question [or wait for all the leases to expire].

Thanks!

I did wonder if that might be the case, but when I reduced the lease time I saw some that had changed to the new timeout and some still unchanged. I hadn't knowingly reset any of the "short-lease" devices, although I didn't look closely enough to see if maybe they were only the ones connected by wifi and that might have disconnected and reconnected. (Was concentrating on setting up the Pihole).

Anyway, I've now installed the Pihole DHCP server (with a 2d timeout for now) and disabled the one on the router, so I'll see if this makes any difference.

In reply to a post by brushton:

In reply to a post by DFScale:

In reply to a post by brushton:

Does it tell us anything if some devices are still on a near-24-hour refresh after 30 minutes have expired?

The dumb question is the one you don't ask ...

AIUI, the clients own the lease for the time they were originally given. You can't push a reduced lease by reducing it on the server. There probably is a client command to renew the lease [different for every operating system no doubt ...]. The certain way to reduce the lease is to restart the machine in question [or wait for all the leases to expire].

Thanks!

I did wonder if that might be the case, but when I reduced the lease time I saw some that had changed to the new timeout and some still unchanged. I hadn't knowingly reset any of the "short-lease" devices, although I didn't look closely enough to see if maybe they were only the ones connected by wifi and that might have disconnected and reconnected. (Was concentrating on setting up the Pihole).

Anyway, I've now installed the Pihole DHCP server (with a 2d timeout for now) and disabled the one on the router, so I'll see if this makes any difference.

Typically the clients will attempt a renewal at half the lease time.

Is there a DHCP relay on the router?

In reply to a post by Eeeps:

In reply to a post by brushton:

In reply to a post by DFScale:

... nested quotes trimmed ...

The dumb question is the one you don't ask ...

AIUI, the clients own the lease for the time they were originally given. You can't push a reduced lease by reducing it on the server. There probably is a client command to renew the lease [different for every operating system no doubt ...]. The certain way to reduce the lease is to restart the machine in question [or wait for all the leases to expire].

Thanks!

I did wonder if that might be the case, but when I reduced the lease time I saw some that had changed to the new timeout and some still unchanged. I hadn't knowingly reset any of the "short-lease" devices, although I didn't look closely enough to see if maybe they were only the ones connected by wifi and that might have disconnected and reconnected. (Was concentrating on setting up the Pihole).

Anyway, I've now installed the Pihole DHCP server (with a 2d timeout for now) and disabled the one on the router, so I'll see if this makes any difference.

Typically the clients will attempt a renewal at half the lease time.

Is there a DHCP relay on the router?

No DHCP relay, no subnets, but the router was originally working as the DHCP server. That's now disabled in favour of the Pihole and so far all has been well - though the connection has previously lasted for several weeks before playing up. I'm still trying to get an answer out of Gigaclear as to *exactly* what they can see in relation to the drops but I seem to be back at square one, having encountered someone on their helpline who's suggesting they send replacement devices and try a vanilla setup and says their "higher network team don't talk to customers" *sigh* That's a shame, some of the helpline staff are quite knowledgeable anyway, and if I could get to one of those I reckon I could get some more useful information.

Following up on this I had the "final" assessment from Gigaclear as follows:-

As discussed, our network teams has investigated and come to the conclusion that the disconnects are occurring due to home network device:- The error on our diagnostic tool is "user-request", suggesting a application level or device (i.e. not physical switch) requesting this

If you require any further assistance regarding this following the investigation you said you would complete into you home networking, then please don't hesitate to reply to my email and I will get back in contact as soon as I can.

Whilst the Pihole might have helped - and the ad blocking is a welcome bonus - the problem still exists, it happened while we were on holiday so I was network blind for several days until we returned and I was able to power-cycle the router.

So now I'm wondering where to go next.

Should I go down the Wireshark (or similar) rabbit hole trying to find the source of this "user-request" (although my background is IT I know very little about network analysis and its tools)?

Should I swap out the Linksys mesh network in favour of a traditional, more-capable, router? According to the specs the Linksys MX4200s can support "40+ connections per node". I have about 40 devices, with a mixture of wired and wireless connections, so whilst capacity shouldn't be a problem I do wonder if that could be the cause.

Or is there another option? (apart from just sucking it up of course )

I used to use one of these to these one of these to power cycle my router once a week.

I have an OPNsense router and there is a CRON option where I can make the box reboot regularly.

In reply to a post by Michael_Chare:

I used to use one of these to these one of these to power cycle my router once a week.

I have an OPNsense router and there is a CRON option where I can make the box reboot regularly.

Interesting, thanks. I do have a bunch of similar plugs (TP-Link Kasa/Tapo) talking to Home Assistant but obviously once the router drops the internet connection I can't access them externally. I don't *think* it would be possible to set up an automation for one of these to cycle the power periodically but I will have a look.

The Linksys MX4200 doesn't seem to have the ability to run a cron job but I'll look into using Opnsense as an alternative, that might provide a workaround - or even eliminate the problem (although it's another rabbit hole )