PPPOE not working after a recent firmware update

[shlomithemoney]

Hello,

I know this is a grey zone and is not officially supported but like a lot of Bell users i use my own routing equipment and like other users i have found that since my modem rebooted on the latest firmware, pppoe from the router is not working anymore.

There is already a reddit thread discussing the details here:

https://www.reddit.com/r/bell/comments/1u2k2rb/did_bell_start_blocking_pppoe_connections_entirely/ 

Basically the bug seems to be that "Any packet over certain size would trigger incorrect PPP frame length meaning that the length reported in the header was different from the actual payload size."

Is it possible to know if this is related to some firmware issue and a fix is coming or if it was deliberate change from Bell?

Any info about this would be appreciated since its currently starting to impact more users and we are all on our own so far wasting our time debugging this.

Thanks!

[Khorem]

UPDATE / CORRECTION to my previous post:

Unfortunately, I spoke too soon.

PPPoE is now connecting successfully and the connection itself has been stable on my UDM-SE (since my last post) while my Giga Hub is still running firmware 3.11.6.2.

However, I just tested the WAN speed directly from the UDM-SE and the PPPoE performance problem is definitely still present.

Current UDM-SE speed test:

Download: 323 Mbps
Upload: 489 Mbps

My Bell service is 3 Gbps.

So to clarify my previous post: PPPoE connectivity is working for me on 3.11.6.2, but PPPoE throughput is still severely degraded.

Sorry for the premature update. I wanted to correct it so nobody takes my previous post as confirmation that 3.11.6.2 has been fixed.

[MALHamON]

When I checked my GigaHub this morning, it was upgraded to 3.11.6.3.

I re-enabled my DMZ and ADMZ, connected my Synology RT6600AX router using my PPPoE credentials and everything appears to be working. I’m seeing ~945mbps up/down on 1Gbps ports. 

Name: Giga Hub
LAN MAC address:
WAN MAC address: 
Firmware version: 3.11.6.3
Rescue version: SGC83100030C
User interface version: 9.0.0-alpha2
Hardware version: 5690-000001-000

[Gio1234]

Thank you for the update @MALHamON , good to know there is another sighting of the 3.11.6.3 firmware. Can only cross my fingers it gets deployed to my gigahub soon.

[dg6464]

I'm still on 3.11.6.2 firmware and am experiencing the disconnects every 600 seconds using ADMZ, which is happening regardless what I try.

I got no call back from Bell Level 2 Support and am getting frustrated with this issue.

Really in need of my modem being upgraded to 3.11.6.3 firmware... I didn't notice the 600 second DHCP renewal outages until I got back to work and was on Zoom calls having them freeze every 10 minutes and have VPN constantly disconnecting/reconnecting.

Also, as an FYI to the Bell folks monitoring this thread... when the modem is put into Advanced DMZ mode... the leases just don't refresh properly at the half-way mark. There's something wrong with the Gigahub's DHCP implementation where it doesn't answer to provide a refresh before the DHCP expires... causing a 2-3 second tear down and bring-up of the connection.

ADMZ DHCP behavior appears to be severely broken/opaque: the downstream router receives a public WAN IP with a private 10.x gateway, a /1 subnet mask, and an extremely short 600-second lease, while DHCP renew/rebind behavior is inconsistent or non-responsive. The Bell gateway also appears to retain stale internal configuration (for example advertising itself as 192.168.2.1 after being changed to 192.168.3.1), suggesting the ADMZ implementation is not a true bridge and may leave stale routing/DHCP state in the firmware.

Double-NAT via DHCP to the Bell modem works, but breaks gaming and isn't a proper workaround.

Fix this now please, it's getting ridiculous... or maybe... communicate what the timeline is to your frustrated customers.

[BoringPlodder]

@BellAlexander @BellPatricia it's been almost 2 months since a firmware update broke this functionality, it's been a month and a half since BellAlexander posted you were were aware of the issue and were working on a fix, and crickets since.  It's been 3 weeks since first user reports of a .3 firmware in the wild and still no updates from Bell.  When is Bell going to fix this and what is Bell going to do for the affected customers?  I think we as the people who are paying for substandard service have a right to be upset about this whole situation.  

[BlondieSL]

I'm on Bell Business Fiber also with a GigaHub.  All has been perfect for over a year.  Then, perhaps 2 months ago, the PPPoE renegotiation started happening.
The GigaHub is in true Bridge mode. (which limits what I can see on the little LCD. I only gets very basic items).

Due to this PPPoE reconnecting issue, I wrote a tiny script to monitor a bunch of IPs, some local, some internet... to see what was going on.

My Bell Business Modem is a GigaHub. It is in full BRIDGE mode. I use my
Asus RT-AX58U

as my router. Now, what I cannot confirmed is which version the modem has. It could be
3.11.6.2 (the known buggy version) or if it was updated to 3.11.6.3 (supposedly bug fixes version). The problem is, I can't get into the GigaHub's LCD menu to get to see the firmware. It's very locked down. I only see "Status", "factory reset", "Bridge mode". No way to get to above or device data.

But what I've done this ween was to test changing numbers in the PPPoE, MTU/MRU fields. The default was 1492. I tried 1472, which should have not caused issue, however, not only did PPPoE still go through reconnects at random times, MOSTLY as 34 minutes past some hour and very often at 2:34 AM... the normally solid internet became "glitchy". But almost always, hh:34. I assumed that Bell must be sending these modems some backend commands or keep alive checks. I don't know.

I returned to 1492 and the internet was fine again.

But the PPPoE resets were still happening. So I then changed the numbers to 1480/1480 and I've not passed 44 hours without a single renegotiation event.

So I'm not sure if it's the 1480/1480 that has resolved it. I don't know if just before changing those numbers, Bell pushed the "fixed" firmware. I do need to check which firmware is on the box.

I wonder if others with a setup similar to mine (Bell Business or Bell Residential with GigaHub) have the same experience and have change MTU/MRU for PPPoE!??

[dks]

Thank you for your question. I have 3.11.3 firmware and can not see any way to change the MTU on my Giga Hub 2.0 (unbridged).  According to the CIRA Internet Performance Test, the PMTU is 1500. 1492 was common when I was on DSL, however. 

[BlondieSL]

Well, it now turns out to be moot since I have no way to even see the firmware level on the Bell GigaHub.  For clarity, I'm on Bell Business and the GigaHub is in
True Hardware Bridge Mode.  Always has been since even before Bell true Fiber... on my older twisted wire system, also bridge mode on Bell Business. Just never an isseu.

With my changing my Asus Routers WAN settings MTU/MRU to 1480/1480, I got 80 hours without this PPPoE renegotiation event.  I hope that was the fix.  But nope!
Early this morning and several times since, there have been several events.  Some, every 4 hours on the dot, loss of internet (but PPPoE still connected), then every 8 hours, PPPoE renegotiation.

Bell has a serious problem here when affecting Bell Business customers.

I'm an Engineer in the field since internet became a thing (actually before that).
I check everything and my router is perfectly fine as it always has been.  Between a script I wrote to monitor Bell's PPPoE and the router logs, it has become completely clear that the issue is Bell.  Plus, Bell has taken ownership of the bug in firmware  ending in .2.

[EonBlue]

Fully agree. Keeping this thread going, too. Absolutely unacceptable to not receive the service we pay for over a multi-month span and the updates have not been fast or consistent enough.

Is there no internal testing for new firmware before it is deployed, whether it be with Bell or the company that manufactures the modems? So crazy that no one caught this and we're still stuck dealing with it months later.

[Philonious1]

Hi,

3.11.6.3 fixes PPPOE passthrough.

Unifi using PPPOE passthrough, not ADMZ.

I was on 3.11.6.2 - PPPOE broken.

Called Tech support, patiently repeated myself a few times, insisted an escalation to senior tech support. Was told 3.11.6.2 was the latest and that I have to wait for 3.11.6.3 to come out.

Not 10 seconds after hanging up the Gigahub restarted on its own! had 3.11.6.3 installed, and PPPOE started working. Was kind of creepy, but I guess senior tech support got the message and did it on the post.

Immediate Speedtest on the UDM PRO shows 2.9 download and 2.6 upload. 

[Vanadiel]

That is good news. Thanks for sharing.

[Pokato]

Just finished talking to a lvl2 tech/supervisor, same answer: the 3.11.6.2 is still the latest version in their system.

Interesting thing is he told me he could see the .3, but it is not certified and still under testing, hence the reason he cannot push it through.

And...he told me there is even a .4 version under testing as well.

[Philonious1]

Well that just goes to show your mileage will vary depending on who you reach and how.

All I can say with certainty is that in 2024, BellPatricia from on this forum, was able to push Firmware 1.17 herself, on the spot, and I watched it happen within moments of her last message.

This time around I sent her a DM (no answer).

Sent BellAlexander a DM (no answer)

Called tech support level 1 (can’t do it, it doesn’t exist)

Agent escalated my ticket to level 2 (she came back on the line and said it exists but they supposedly couldn’t do it either).

Hang up the call and 10 seconds later and SOMEONE did it. That can’t possibly be a coincidence.

Wild.

[NinjaNet]

Hello Everyone,

Same with for all dealing with the PPPOE firmware issue, I am now experiencing a strange Wi-Fi download speed issue with my Bell Fibre connection.

On previous working PPPOE version, Wi-Fi 6E download speeds were close to the maximum available speed. Recently since workaround setup, download speeds have dropped significantly, while upload speeds remain close to full speed.

What’s interesting is that:

• Wired devices still get full speed
• Wi-Fi devices (3rd party) are significantly slower on download
• With the WAN configured through DHCP/DMZ, Wi-Fi download is around 300 Mbps and 930 Mbps upload
• Switching the WAN back to PPPoE increases the Wi-Fi download to around 500 Mbps 
• and 500 Mbps upload
• Previously, PPPoE was working normally and Wi-Fi 6E could reach the maximum available speed up to 1.5 Gbps both sides
• on DMZ, WiFi 6E upload remains around 900+ Mbps but download is seriously impacted.
• MTU is 1500 and MSS is blank.
• No QoS is enabled.

The issue appears to be related to how the WAN connection is being handled rather than the Wi-Fi itself. As I tested this without the DMZ or PPPOE, separately and the download speed is affecting downstream access points. This confirm that the Bell Giga Hub (broken) is causing much more problems on our equipment's than previously thought. Knowing they are not responsible of 3rd party devices, the DMZ or PPPOE are both breaking our private infrastructures, when this same system was working flawlessly before this firmware 3.11.6.2 was pushed. It's really frustrating for many reason, first client service is really poor, second the service is no longer reliable forcing customer to look elsewhere, and losing so much of our time and patience doesn't worth to be loyal to Bell anymore after more then 20 years.

Has anyone else experienced a similar Wi-Fi-only download speed reduction with Bell Fibre, particularly after recent Giga Hub firmware updates?

Thanks, 

[User5519]

Adding a data point to this thread: I'm seeing the same Advanced DMZ DHCP lease issue that @dg6464 described in detail above (Aug 18) - a WAN drop and rebuild every ~10 minutes, tied to the 600-second lease not renewing cleanly. My Asus GT-BE98 Pro's logs show the identical pattern:

dhcp client: bound 76.65.x.x/255.255.255.0 via 142.124.x.x for 600 seconds.

dhcp client: deconfig -- roughly every 597-600 seconds, all day.

It's a real disruption day to day, not just a log curiosity: Teams meetings and streaming drop every time the lease tears down.

My Giga Hub is on the same hardware @AxelBest reported above, running firmware 3.11.6.2:

Firmware version: 3.11.6.2
User interface version: 9.0.0-alpha2
Hardware version: 5690-000001-000

Switching to PPPoE isn't a workable fallback for me, since it's well documented earlier in this thread as capping throughput around 300-500 Mbps regardless of the downstream router - too big a speed reduction to accept as a permanent workaround.

@BellAlexander  @BellPatricia given the later reports in this thread that 3.11.6.3 fixed PPPoE passthrough for some users, but @Philonious1 was explicit that their fix was for PPPoE, not ADMZ, and dg6464 was still seeing the 600-second ADMZ drop as of Aug 18: can you confirm whether 3.11.6.3 (or the .4 build @Pokato was told is in testing) actually addresses the Advanced DMZ DHCP lease-renewal bug specifically, separate from the PPPoE throughput issue? And given how inconsistently .3 seems to be rolling out, is there any way to opt in rather than wait for a wave rollout?