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

Velaris
Contributor II

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

3 132 8,534
132 REPLIES 132

dks
Community All-Star
Community All-Star

“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. 

I am a Community All-Star and customer. I'm here to help by sharing my knowledge and experience. My views on Bell and the Community Forum are my own and not the views of Bell or any of its affiliates.

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
Contributor III

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
Community All-Star
Community All-Star

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. 

I am a Community All-Star and customer. I'm here to help by sharing my knowledge and experience. My views on Bell and the Community Forum are my own and not the views of Bell or any of its affiliates.

ScratchMang
Contributor II

dks,

The “power users are a small minority” argument is irrelevant. Providing a functional bridge mode, Advanced DMZ, standalone ONT or working PPPoE passthrough would not remove the Giga Hub’s plug-and-play service from anyone else.

wardtj has identified the real issue clearly:

  • PPPoE passthrough is a supported Bell feature.

  • It worked at multi-gigabit speeds on the Giga Hub 1.0.

  • The Giga Hub 2.0 has also worked at full speed before becoming capped again without any customer-side changes.

  • Bell provides no warning that upgrading or replacing a Giga Hub 1.0 may severely reduce PPPoE performance.

  • Bell admits there is a problem but provides no ETA, downgrade option or supported alternative.

That behaviour strongly suggests a Bell firmware, provisioning or network-profile problem, not inadequate customer hardware.

cclo is also correct: fixing Advanced DMZ, bridge mode or PPPoE passthrough would not interfere with plug-and-play service. Bell has had years to address these problems. Customers paying over $120 per month should not be dismissed because they represent a smaller portion of Bell’s subscriber base.

Nobody is claiming that installing a third-party ONT is supported. Customers resort to unsupported bypasses because Bell’s supported equipment and supported PPPoE implementation fail to deliver the speeds being sold.

Community All-Stars have not consistently maintained that distinction. Customers were repeatedly told this involved unsupported, custom or non-standard equipment until wardtj clearly demonstrated that the defective feature itself is supported.

The issue is simple: Bell advertises PPPoE passthrough as supported, knows it is not functioning correctly, continues charging for multi-gigabit service, and offers no repair timeline or supported alternative.

Bell should fix the feature, permit affected customers to downgrade to a Giga Hub 1.0, or provide a proper standalone ONT or bridge-capable option. 

Or failing that cut the bill of those affected by 66% until such time as there is a Fix. Perhaps once they begin to loose revenue they will invest the time to resolve the issue.

dks
Community All-Star
Community All-Star

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. 

I am a Community All-Star and customer. I'm here to help by sharing my knowledge and experience. My views on Bell and the Community Forum are my own and not the views of Bell or any of its affiliates.

Gio1234
Contributor II
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
Community All-Star
Community All-Star

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. 

I am a Community All-Star and customer. I'm here to help by sharing my knowledge and experience. My views on Bell and the Community Forum are my own and not the views of Bell or any of its affiliates.

Gio1234
Contributor II
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
Community All-Star
Community All-Star

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. 

I am a Community All-Star and customer. I'm here to help by sharing my knowledge and experience. My views on Bell and the Community Forum are my own and not the views of Bell or any of its affiliates.

dks,

The fact that Sagemcom manufactures the Giga Hub does not transfer responsibility away from Bell.

Customers purchase service from Bell, pay Bell each month, receive equipment selected and supplied by Bell, and receive firmware approved and deployed through Bell. Whatever contractual relationship Bell has with Sagemcom is Bell’s responsibility, not the customer’s. But nice try at deflecting again.

GIO1234 stated this correctly. Bell chose the vendor and equipment, controls what customers are issued, and is responsible for delivering the service being sold. Bell cannot force customers to use its hardware and then point at the manufacturer when that hardware or firmware fails.

Referring customers to Bell’s limitation-of-liability clauses is also not a technical answer. Those clauses do not repair broken PPPoE passthrough, restore the speeds customers pay for, provide an ETA or prevent customers from leaving Bell. Nor do they address Bells inability to deliver a service as advertised.

Customers affected by this failure are reasonably asking for one of the following:

  • a firmware rollback or repair;

  • a clear ETA;

  • replacement hardware that works;

  • a supported alternative handoff;

  • or a substantial bill reduction until Bell delivers the purchased service.

As GIO1234 also noted, the technical reports in this thread create an important record for escalation, including through the CCTS if Bell continues collecting full payment while knowingly providing degraded service.

You then stated that we are arguing with someone who has no influence. Nobody claimed that you control Bell’s engineering department. The issue is that you repeatedly enter the discussion to defend Bell, minimize the problem, cite liability clauses and tell customers to wait indefinitely.

GIO1234 was correct again. If you have no influence, those deflections contribute nothing. The useful response would be to help collect firmware versions, speed results, configuration details and escalation information, or simply allow affected customers to document the problem without repeatedly explaining why Bell should not be held responsible.

Your final response amounts to.... Bell knows best, Bell is looking into it, and perhaps Bell will eventually deliver a solution.

That is not good enough.

Bell has a supported feature that does not work properly, no ETA, no supported alternative and no apparent urgency. Customers should not be expected to continue paying full price indefinitely while Bell investigates “in due course.”

If you have nothing more useful to contribute than “Bell knows best and Bell will deliver someday,” then your comments serve no practical purpose and are, quite frankly, becoming increasingly annoying.

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.

I am a Community All-Star and customer. I'm here to help by sharing my knowledge and experience. My views on Bell and the Community Forum are my own and not the views of Bell or any of its affiliates.

Vanadiel,

I understand your point, but this workaround simply returns me to the situation I am specifically trying to avoid.

Using the Giga Hub as the router means surrendering control of my network to Bell, accepting Bell’s visibility into my connected devices, and either living with double NAT behind my own firewall or abandoning it in favour of Bell’s routing, Wi-Fi and pods.

That is not a solution.

Bell has had considerably more than “several months.” Giga Hub PPPoE problems have been publicly documented since at least October 2022. The specific Giga Hub 2.0 hard speed-cap issue has been documented since January 6, 2026.

So this is not a new or recently discovered problem. Bell has had years to address the broader PPPoE issues and more than six months to address the current Giga Hub 2.0 failure.

More importantly, Bell knew the original Giga Hub had serious PPPoE problems, verifying that those problems were fully resolved should have been near the top of the validation checklist before releasing the Giga Hub 2.0. When a first-generation product has a major known defect, ensuring that defect is corrected in the replacement model is basic product development and quality assurance. 

Instead, Bell released a second-generation device with the same class of problem, forced customers onto it, provided no downgrade option and now expects customers to wait indefinitely for another investigation.

Bell is also clearly capable of providing reliable fibre service and appropriate hardware to business customers. The technology and hardware already exist. Residential customers should be allowed to request suitable Bell-provided equipment while Bell investigates its defective Giga Hub 2.0 implementation.

Oh, and please do not try to turn this into a DHCP, static-addressing or residential-server discussion. PBLs, SBLs and other mechanisms already exist to enforce residential service restrictions.

I do not need Bell to manage my LAN. I need Bell to provide a reliable service handoff at the advertised speed and then stay out of my network.

All I want is the service I have been paying for. Bell should provide working replacement hardware, permit a downgrade to equipment that works, supply a standalone ONT, or reduce the bill until Bell delivers the purchased service.

Bell chose this hardware. Its defects and the years spent failing to resolve them are Bell’s responsibility, not mine.