Giga Hub 2.0: PPPoE passthrough/2nd PPPoE session capped (average 330 Mbps) on 3 Gbps plan

[Velaris]

Hello,

I'm on a 3 Gbps plan and I'm seeing a repeatable/hard throughput cap only when using PPPoE on a downstream device (PPPoE passthrough / second session).

My setup:

- Bell Giga Hub 2.0
- Downstream router: UniFi Cloud Gateway Fiber (UCG-Fiber) connected to the Giga Hub 10G port

What works:

- If the UCG-Fiber WAN is set to DHCP (e.g. behind the Giga Hub 2.0/double NAT), I can reach full speed (~3 Gbps).
- If my PC is behind the Giga Hub 2.0 on DHCP, my PC (1GbE NIC) reaches the expected ~1 Gbps.

The problem (reproducible):

When I establish a PPPoE session from a device behind the Giga Hub, throughput is capped around ~300–330 Mbps.

Repro 1: PPPoE from UCG-Fiber

- UCG-Fiber WAN set to PPPoE using my b1 credentials
- Result: ~300–330 Mbps (repeatable), despite 3 Gbps plan

Repro 2: PPPoE from a Windows PC (bypassing UCG-Fiber)

- PC connected by Ethernet to the Giga Hub 2.0
- PC NIC: 1GbE, cable: Cat6A
- Created a Windows "Broadband (PPPoE)" connection using the same b1 credentials
- Result: same cap at ~300–330 Mbps (repeatable)

Because the same cap occurs even when PPPoE is established directly from a PC (*no* UniFi router involved), it points to the Giga Hub 2.0 PPPoE passthrough / secondary PPPoE session path rather than my router.

Can you confirm:

- Is this a known issue on the Giga Hub 2.0 (firmware-related)?
- Is there a firmware update or hardware replacement option to resolve PPPoE passthrough speed caps?

Thanks

[cclo]

I no longer have any issue.  I m with Telus now. Lol!

[Vanadiel]

All available support options are accessible from the Bell support site: Bell support. 

If your concern(s) have not been resolved, there is an escalation option: Unresolved concerns. 

Going by your description of what you have tried so far, I think the escalation option would be the best choice. But it might not be a bad idea to use the general support options one more time just to be sure it needs to be escalated.

[cclo]

You selling an internet package like 3Gbs and 8Gbs packages.  Charging people over $100 a month.  And you expected people just plug a PC behind a bell modem???  People willing to pay that price and use that speed are mostly power users with their own servers and routers!  I m amazed that bell can get away with this “We don’t support your equipment” for years!  Again, I not asking Bell to fix my hardware! I m asking them to fix there DMZ and bridge mode on there own Bell’s equipment!  Another amazing part is.  I run this forum address: forum.bell.ca. but I don’t work for Bell… I work for Dell…,This is the greatest Jokes of all time!

[dks]

“Power users” are a small portion of Bell’s clients. Most customers do want a simple, plug and play solution. Bell provides that option. If Bell does not provide the specific option a user wishes, well, there are other providers and technical workarounds. 

[wardtj]

For me the issue isn't the support, as I agree, most of us with bigger connections will use a decent router, and not rely on the routing functions of the Gigahub for 3Gbs+.

My issue is PPPoE passthrough works on 3Gbs and 8Gbs with the Gigahub 1.0.  There's no warning from Bell that if you upgrade to Gigahub 2.0 or your 1.0 needs to be swapped, that Gigahub 2.0 has issues with PPPoE passthrough and your speeds will not be as advertised.

My other issue is that Gigahub 2.0 DOES WORK at full speed.  Initially, when I upgraded from Gigahub 1.0, it did not work, capped at the 1Gbs both ways.  A week later, boom it was working, without any change 3/3, and then 8 weeks later, it stops working again out of the blue back to 1/1.  This leads me to believe it's a Bell profile setting, and not a technical limitation on the Gigahub 2.0. Speed tests are very consistent.  Modem side 3/3, through Gigahub 2.0 router NAT session 3/3, PPPoE session through Gigahub 2.0 capped at 1/1, while Gigahub 2.0 router NAT session stays 3/3.  Running two speed tests at once clearly shows this.  Gigahub 2.0 router NAT will drop to 2/2 and the second PPPoE session will stay 1/1.

It's a supported feature, Bell will tell you this when you call in.  What's not supported is bypassing the ONT.  I agree, that's take it into your own hands stuff.  But, if the Gigahub 2.0 supports PPPoE, then a fix should be done.  OR, customers should be allowed to downgrade back to Gigahub 1.0 on request. Exec office escalations should not be needed.  Again, this DOES WORK on Gigahub 2.0, but it appears to be a Bell network profile setting that's causing it not to work.

Not sure why all the MVP's here defend Bell and say it's not supported.  PPPoE passthrough IS supported.  It's stated for the HomeHubs and GigaHub 1.0.  This is not new.  ONT Bypass is not supported.  That's clear.

[cclo]

Does fixing the Advance DMZ and Bridge mode take away the ability of the plug and play function?  Does fixing a feature in its own Bell Modem too much to ask for?  I was with Bell from 2019 till last July.  It is over 7 years and they hasn’t do anything about it!  I guess I m one of the  small portion of Bell’s customers that paying them over $120 per month just on internet that they don’t need.  I m so happy I moved all my TV, Cell phone and internet over to Telus.  I was thinking going back to Bell because they kept mailing me with deals.  But thanks for the input. 

[dks]

Thanks for your comments. You are correct. PPPoE Passthrough is supported. There are issues, which are being investigated, with currently no ETA for a fix. Installing your own ONT to bypass the Giga Hub is not supported. That has been what Community All-Stars have been saying consistently. 

[dks]

A couple of things. The Giga Hub is a third party product. While Bell may have a hand in the device, the manufacturer, Sagemcom is responsible. You are correct, the passthrough issue is being investigated, but there is no ETA, according to Bell. The other issues are Bell policy decisions and way above any pay grade in the forum. With reference to "compensation", the Terms of Service document has something about that under Warranties and Our Liability. See pp. 5 & 6. 

[Gio1234]

dks,

Customers pay their monthly bill to Bell Canada, not Sagemcom. Bell chooses the vendor, specifies the hardware requirements, codes/approves the customized firmware wrapper, and pushes the updates to our homes. Passing the buck to a third-party manufacturer does not absolve Bell of their service delivery obligations.

Furthermore, referencing the 'Warranties and Our Liability' section of the Terms of Service is a deflection. While those legal clauses shield Bell from massive legal damages, they do not shield Bell from customer churn.

If a firmware update breaks standard networking protocols (PPPoE passthrough and WAN DHCP lease handshakes) on a device we are forced to use, customers have every right to demand a roll-back, an ETA, or financial compensation for a degraded service. If frontline forum staff cannot address this, then the community's collective data logs serve as the necessary paper trail for escalating complaints directly to the CCTS (Commission for Complaints for Telecom-television Services).

[dks]

Thanks for your comments. You are attempting to argue with someone who has no influence on your issue. I am just conveying facts. All of your points have been addressed in earlier posts. Bell staff do read all posts, however. 

[Gio1234]

If you have no influence on the issue, then continuing to post unhelpful reminders about Bell's legal liabilities and vendor relationships serves no purpose here.

It would be best to collect technical data and pressure Bell into accelerating a fix for a broken service. Since you confirm Bell staff are reading this, let's keep the focus strictly on user logs, firmware version numbers, and escalation steps so they can see the exact scope of the problem.

[dks]

Thanks for your comments. Post whatever technical information you wish. I expect Bell will post any news in due course. I can say that Bell is aware of the issue you raise and, as has been said, is looking at it. 

[Vanadiel · Accepted solution]

It's possible PPPOE passthrough currently not working well, is not due to a firmware bug but other reasons. If there is anything new to report, it was already mentioned that updates will be provided in these forums.

It's always a good idea to collect information, but I am thinking that at this point additional information is not really going to do much if anything towards a possible solution for the encountered PPPOE issue(s).

Due to the size of the network and the channels that have to be followed to address these kind of issues, it's my experience it can take several months for a solution to surface. If I remember correctly it took several months for the pods issue to be fixed.

In the meantime while waiting for a solution, you might be better served using a level 3 switch connected to the 10G port of the HH as opposed to a router using PPPOE. While not ideal in every circumstance, it would at least provide a stable connection that can serve the remainder of your LAN hardware.

[Maddjik]

Is the solution to the problem available?thanks

[dks]

Thank you for your question. The issue is being worked on. Please see posts with a green check mark for more information. Bell will report if there are updates.