Hi,

I was looking for a router that provided enough information about the connection (e.g. connection drops) in case I needed to interact more with HO. I have settled on the Ubiquiti Unify UCG. It did not change anything in terms of connection quality. You can see it in action on the Firebrick from Sunday at 16.30 to today at 13.30. The Saturday trace is for the Asus RT-AX88U Pro. Not worth the extra cost given that I am otherwise covered for wifi. Still wall of red on BQM and f8lure. I am willing to bet that HO is blocking them for residential customers.

As you suggested, I have also asked for a different static IP which became active today at 13.30. Range 89.x.x.x. I can PM you the full address if interested. Still solid red other than on the Firebrick. Unusually, the Firebrick trace is squeaky clean. I am not sure it is registering anything

In general, though, I have the impression that changing the IP block has solved the problem. I will keep monitoring and update this thread if not. Thanks a lot for all your help!

For laughs, I have also received (in an email two days ago!) the ticket update on HO sending the engineer on 13 May. "I want to advise you that our team has run a diagnostics and reviewed your connection and advised us that the smaller box that you have is the cause of the issue you have experienced."... As you might remember, the engineer measured the signal at the ONT and concluded that it was not to blame. Their customer support is very kind but a bit all over the place...

Edited by Pippo123456 (Tue 27-May-25 18:42:06)

Alas, nothing has changed. See this post.

Is your Ubiquiti Cloud Gateway set up correctly? It needs to be configured to accept and respond to pings on both v4 & v6.

Yes. Both v4 and v6. Thanks!

In reply to a post by Pippo123456:

Alas, nothing has changed. See this post.

Yeah I don't really understand what's happening with your connection. As said I have a Hyperoptic connection on a business account with a static IPv4 address that literally hasn't skipped a beat.

I'm really at a loss now as to what the root cause of your issue could be. Given you've swapped routers, had them move you to a different IPv4 subnet.

You could try with your routers IPv6 address and see if that works.

Just in case this sheds any light. The first traceroute below is from a machine with a wired connection straight into the UCG (no VPN), whose LAN IP is 192.168.0.1, triggered by a spike (30.5%) in the packet loss. Whenever this happens the (private) IP 172.17.45.118 shows up in the traceroute. This is never the case for a period traceroute.

2025-06-03 09:02:51 TRIGGERED
+----+-----------------------------------------------------------------------+-------+-----+------+------+------+------+
| # | Hostname | Loss% | Snt | Last | Avg | Best | Wrst |
+----+-----------------------------------------------------------------------+-------+-----+------+------+------+------+
| 1 | 192.168.0.1 | 35.0 | 100 | 0.6 | 1.1 | 0.6 | 1.4 |
| 2 | ??? | 100.0 | 100 | - | - | - | - |
| 3 | ??? | 100.0 | 100 | - | - | - | - |
| 4 | ??? | 100.0 | 100 | - | - | - | - |
| 5 | 172.17.45.118 | 96.0 | 100 | 1.7 | 2.0 | 1.7 | 2.1 |
| 6 | ??? | 100.0 | 100 | - | - | - | - |
| 7 | ??? | 100.0 | 100 | - | - | - | - |
| 8 | ??? | 100.0 | 100 | - | - | - | - |
| 9 | ??? | 100.0 | 100 | - | - | - | - |
| 10 | ??? | 100.0 | 100 | - | - | - | - |
| 11 | ec2-13-39-234-20.eu-west-(13.39.234.20) | - | 100 | 10.3 | 10.4 | 9.7 | 11.0 |
+----+-----------------------------------------------------------------------+-------+-----+------+------+------+------+


This second traceroute has run roughly at the same time from a machine with a wired connection to the Openwrt router running wireguard and reaching the internet through the UCG. The openwrt router lan ip is 192.168.1.254, 10.2.0.1 is the IP of the wireguard interface (actually it should be 10.2.0.2 with 10,2.0.1 the address for DNS) , 149,40.48.124 is the VPN server IP address. All trace routes from the connection through the VPN look the same and the monitor never runs a triggered one (reported packet loss in the monitor on this interface at the time was 0%). Honestly I cannot see any difference between the two.


2025-06-03 09:00:13 PERIODIC

+----+-----------------------------------------------------------------------+-------+-----+------+------+------+------+
| # | Hostname | Loss% | Snt | Last | Avg | Best | Wrst |
+----+-----------------------------------------------------------------------+-------+-----+------+------+------+------+
| 1 | _gateway (192.168.1.254) | - | 10 | 0.6 | 0.7 | 0.5 | 0.8 |
| 2 | 10.2.0.1 | 20.0 | 10 | 2.3 | 2.3 | 2.2 | 2.4 |
| 3 | unn-149-40-48-124 (149.40.48.124) | 90.0 | 10 | 2.4 | 2.4 | 2.4 | 2.4 |
| 4 | vl221.lon-eq7-core-1.cdn77.com (79.127.192.222) | 20.0 | 10 | 3.7 | 2.9 | 2.4 | 4.7 |
| 5 | ??? | 100.0 | 10 | - | - | - | - |
| 6 | ??? | 100.0 | 10 | - | - | - | - |
| 7 | 52.46.166.146 | 30.0 | 10 | 4.0 | 10.7 | 3.9 | 50.7 |
| 8 | ??? | 100.0 | 10 | - | - | - | - |
| 9 | ??? | 100.0 | 10 | - | - | - | - |
| 10 | ??? | 100.0 | 10 | - | - | - | - |
| 11 | ??? | 100.0 | 10 | - | - | - | - |
| 12 | ??? | 100.0 | 10 | - | - | - | - |
| 13 | ??? | 100.0 | 10 | - | - | - | - |
| 14 | ec2-13-39-234-20.eu-west (13.39.234.20) | 90.0 | 10 | 11.4 | 11.4 | 11.4 | 11.4 |
+----+-----------------------------------------------------------------------+-------+-----+------+------+------+------+

Thanks for all your help and apologies for the poor formatting!

I also got a new email of work in the area on 17/06 after writing to [email protected], although the timing may be only coincidental.

Edited by Pippo123456 (Tue 03-Jun-25 11:35:02)

Success!

TBM here

It finally worked with an IPV6 address. It took me a while to figure out how to do it as the HO router does not seem to work with IPV6. But once I got the relevant info from HO and used it with the UCG it all kicked in.

Many thanks for all the hand holding! Still need to figure the source of the dropouts without the VPN, but that is a trickier story....