Hub 5 and pfSense/opnSense Firewall

[BaldrickBravo]

Hello,

I've been offered the Hub 5 upgrade.
I currently use the SH2 AC in "Modem Only" mode with pfSense.

Has anyone using pfSense installed the Hub 5 yet? Any issues?

I noted this AVForums thread in which a person posted:
> My router is Asus RT-AC87U. You need to update the firmware before uninstalling your old hub. The reason for this is to change the DHCP setting from Uninterrupted to Continuous otherwise it will not connect.

https://www.avforums.com/threads/virgin-media-o2-super-hub-5-sh5.2383152/#post-29895810

By way of explanation, I found this:

> Therefore, you can modify DHCP query frequency to be continuous (query DHCP frequncy[sic] @12Hz).

https://www.asus.com/support/FAQ/1043591

That seems to suggest the Asus router is issuing DHCP Discover/Request 12 times each second in 'continuous' DHCP mode? ...

I'm tempted to order the Hub 5 and find out the hard way. Still interested to hear anyone elses experiences.

Thanks
.BB

[jem101]

---

@BaldrickBravo wrote:

Well then don't say it. All you are doing is discouraging people from sharing feedback that is useful to the community. It's not only unhelpful, it is also quite childish.

I wouldn't have considered upgrading without good reason.

And if people don't upgrade, then these problems are not identified and not resolved.

---

All true, but my real concern is that unsuspecting users are being sent out the Hub 5, thinking it is a nice upgrade, without being notified that they are being sent equipment which doesn’t actually work fully. There are issues with it, did you know that it doesn’t support the telephony feature, the VM supplied WiFI pods don’t work with it, there are acknowledged problems with VPNs and if the latter stops you working from home, well sorry about that, tough!

Now if you were fully informed beforehand and accepted the hub on that basis then fine - there is a concept of ‘informed consent’ in law, are you fully and absolutely aware of what you are getting and using? I’m sorry but, no VM utterly failed to properly inform their customers as to what they were getting and if push comes to shove they will be crucified in Court over this. Noticed how many thread there are about users being ‘allowed’ to go back to an earlier Hub model?

I would have absolutely no issues with customers testing new equipment and feeding back issues with it where appropriate, but this just hasn’t happened with the Hub 5, I’m sorry but, this is a complete PR disaster, obviously driven by a marketing decision.

Take a look through the forums and see how many thread there are from users saying that they took up the offer of a Hub 5 and found that x no longer works. After a lot of messing about, they get a Hub 3 or 4 back and mysteriously everything works again?

Yes, VM need to roll out new equipment, yes it needs tested ‘in the field’, but importantly users need to know exactly what it is they are doing and being given. The Hub 5 is an absolute epic fail on VM’s part and they need to be called out on it at every single opportunity!

[gary_dexter]

---

@BaldrickBravo wrote:
And now your are trying to start an argument.

Let me explain this for you in small words. Some of the hub3 and hub4 issues were resolved Like this one for instance: https://community.virginmedia.com/t5/Forum-Archive/Vivid-100-VMDG505-Connection-dropped-45-Minutes/m...

Most of the problems that were not fixed were hardware problems.

The Hub 5 is, as you probably know, built on unrelated chipset so shouldn't be subject to the same set of issues.

VM were very good when I had issues with the SH3 (as a new customer) and downgraded me to an SH2ac. The first SH2ac died within a couple of months and was replaced with another SH2ac. That is now getting increasingly flakey - it has gone from hardlocking up occasionally (every 6 months or so) to hard locking up every week or so over the last year.

I'm fortunate, I have a second Internet connect. So I can take the hit of upgrading and getting a dud hub.

I suggest you dial it back a notch or two. I've observed plenty of your posts here in the same vein. You give the IT profession a bad reputation.

---

No most of the issues are firmware issues and are still not fixed.

The Hub5 has a whole bunch of issues and should never have been released to the general public at this stage.

Unless you’re on a 1GB connection and want the extra couple hundred meg from the 2.5GB WAN port there’s no real warranting need to take a Hub5. That and it’s not being offered (or shouldn’t be) to Gig1 customers anyway, so those on a 600Mbps connection or less won’t benefit from running it in Modem Mode either as will gain nothing bandwidth wise. 

[legacy1]

SO...does it work in modem mode? your router getting a WAN IP? your router doing NAT for your LAN?

If no a PC to the hub in modem mode should work then you can copy its MAC
to your router and if that don't work Wireshark between the hub and router filter
port 68 or port 67 or arp

[BaldrickBravo]

Just a quick update on this.

I left the new hub in situ overnight.

At about 3am (after 5 hours uptime) it start responding to ping (ICMP echo request). At about 7am I logged back into the hub and I was run through the first run UI again.

On completing this, the hub stopped responding to ping and the WebUI became inaccessible. I checked and there was no response from 192.168.100.1 port 80.

$ nc -vz 192.168.100.1 80
nc: connect to 192.168.100.1 port 80 (tcp) failed: Connection timed out

I turned the hub off and back on. This state persisted the reboot. I have left it alone since, in the hope at some point it starts responding to ping again. Then I can change my external DNS to see if unsolicted ingress is allowed and whether the websites/VPN endpoint are externally available.

This seems to suggest that accessing the hub in modem mode puts it into a funky state. And at some point something happens to fix it.

I haven't hit the reset pin yet. I'd like to wait and get a good measure of how it is behaving before I do.

The other observation I made, was that my DNS resolution check failed several times overnight, which is not usual. It is a sensitive check and is usually the first to fail when there is an Internet connectivity problem. I haven't had time to check the firewall logs yet. I have precautionarily routed all the hosts on my network over the other line so that any issues with the hub don't affect us working from home.

The Firewall is getting the public IP assigned to it so it doesn't look like the hub is NATting.
Anyway, I will post updates as/when I find out more for anyone who might be observing out of interest.

[Adduxi · Accepted solution]

---

@BaldrickBravo wrote:

<sni[>  I haven't hit the reset pin yet. I'd like to wait and get a good measure of how it is behaving before I do.  <snip>

---

Yes, I have a hub 5 in modem mode and I did have to do a 60 second pinhole reset twice.  It did display some really weird screens as you have found out.  However, it's connected to a Draytek Vigor 2860 dual wan router and working fine at the moment.  I don't run any services from home, so just a simple setup. 

As you know the Hub is in, what is described by VM Mods, as a "soft launch", with ongoing firmware work in progress.  So, I was aware of this and as I have a dual wan I was quite happy to use the Hub 5.   It has a noticeable difference in latency and it looks like this chipset is superior to the Puma.

Just my observations ! 

[BaldrickBravo]

So with the web UI accessed and hoob rebooted at ~7am, the hub has started responding to pings as of 12pm

$ ping -c10 192.168.100.1
PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
64 bytes from 192.168.100.1: icmp_seq=1 ttl=62 time=2.77 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=62 time=2.52 ms
64 bytes from 192.168.100.1: icmp_seq=3 ttl=62 time=2.32 ms
64 bytes from 192.168.100.1: icmp_seq=4 ttl=62 time=2.38 ms
64 bytes from 192.168.100.1: icmp_seq=5 ttl=62 time=2.29 ms
64 bytes from 192.168.100.1: icmp_seq=6 ttl=62 time=2.17 ms
64 bytes from 192.168.100.1: icmp_seq=7 ttl=62 time=2.15 ms
64 bytes from 192.168.100.1: icmp_seq=8 ttl=62 time=2.38 ms
64 bytes from 192.168.100.1: icmp_seq=9 ttl=62 time=2.37 ms
64 bytes from 192.168.100.1: icmp_seq=10 ttl=62 time=2.24 ms

--- 192.168.100.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9014ms
rtt min/avg/max/mdev = 2.154/2.359/2.767/0.171 ms

And port 80 is open:

$ nc -w2 -vz 192.168.100.1 80
Connection to 192.168.100.1 80 port [tcp/http] succeeded!

However, externally, port 443 times out:

nc -w5 -vz mysubdomain.mydomain.sometld 443
nc: connect to git-bn.mysubdomain.mydomain.sometld (81.1xx.xxx.xxx) port 443 (tcp) timed out: Operation now in progress

If I switch my dynamic DNS client to use the other Internet connection, and wait for the DNS TTL to lapse:

$ nc -w5 -vz mysubdomain.mydomain.sometld 443
Connection to mysubdomain.mydomain.sometld (78.1xxx.xxx.xxx) 443 port [tcp/https] succeeded!

That looks very consistent with what I experienced earlier.
I'll try reseting and re-configuring the hub tonight.

[BaldrickBravo]

s/hoob/hub/

[BaldrickBravo]

Pinging the DSL modem (192.168.1.2), in comparison to the hub 5 (192.168.100.1):

$ ping -c 5 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=63 time=0.967 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=63 time=0.915 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=63 time=0.894 ms
64 bytes from 192.168.1.2: icmp_seq=4 ttl=63 time=0.842 ms
64 bytes from 192.168.1.2: icmp_seq=5 ttl=63 time=0.702 ms

--- 192.168.1.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 0.702/0.864/0.967/0.090 ms
2022-02-04T13:41:59

$ ping -c 5 192.168.100.1
PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
64 bytes from 192.168.100.1: icmp_seq=1 ttl=62 time=2.33 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=62 time=2.38 ms
64 bytes from 192.168.100.1: icmp_seq=3 ttl=62 time=2.22 ms
64 bytes from 192.168.100.1: icmp_seq=4 ttl=62 time=2.27 ms
64 bytes from 192.168.100.1: icmp_seq=5 ttl=62 time=2.54 ms

--- 192.168.100.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 2.223/2.349/2.535/0.107 ms

That's interesting. 864ms average RTT to the DSL modem. 2349ms average RTT to the Hub 5.

There's no WiFi involved here. I would expect the Hub 5 RTT to be sub-second.

[BaldrickBravo]

Caved in and hit the reset button.
After it had reset, logged in, set password and put it back into modem mode. At the moment it is still off-line.

I checked on the hub a few minutes after putting it into modem mode. LED was flashing blue at a rate of between 30 and 60 times a second (medium speed). Reading the small pamphlet that came with the hub, that suggests unsuccessful WPS pairing!

I checked again a few minutes later and the LED was solid green. Don't know what that means. (Flashing green is software update.)

I'm going to give it twenty minutes and then give it a power cycle.

[BaldrickBravo]

Power cycled.

Hub booted with a constant lit white LED. A few minutes later, this was solid green.
No Internet access tho.

Checked firewall. It had been leased 192.168.0.193. Weird.
Released the lease and renewed (on the firewall). It was then issued a public IP address.

Internet connectivity restored. Hub was pingable internally on 192.168.100.1 (although mean average RTT is 7585ms).
Unsolicitied WAN ingress to firewall also working. Websites and openvpn endpoints are accessible again.

I'm now able to log into the hub without seeing the first-run wizard.
Network status returns a HTTP 500 status for status and downstream tabs; I think that is well covered in other threads.

Current hub details:

Standard specification compliant:DOCSIS 3.1

Hardware version:1.1

Software version:LG-RDK_2.23.11-2106.14

Cable MAC address:34:5D:9E:xx:xx:xx

Cable modem serial number:YAAS13xxxxxx

System up time:0day(s)0h:24m:59s

Network access:Allowed

So that is some welcome improvement.