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!

[User5519]

Follow-up with a more precise root cause, in case it's useful: I ran a continuous ping (1.1.1.1) through one of these ADMZ lease-renewal events and captured my own router's syslog for the same window:

14:38:58 dhcp client: deconfig
14:38:59 udhcpc_wan: hnd_get_phy_status: Temporarily Router cannot get the PHY() status...
14:39:02 BWDPI: force to flush flowcache entries
14:39:02 BWDPI: rollback fc
14:39:04 Samba Server: smb daemon is stopped
14:39:05 Samba Server: daemon is started
14:39:06 wan_up: Restart DDNS
14:39:06 dhcp client: bound 76.65.x.x/255.255.255.0 via 142.124.x.x for 600 seconds.

Two things stand out. The ping only dropped once across the ~8-second sequence, so the raw WAN reachability gap is closer to 1 second, not the full renewal window. More importantly: the DHCP lease failing to renew cleanly forces my router into a full interface deconfig/rebind, which in turn flushes my own router's connection-tracking/flow-cache table (visible above), even though the public IP doesn't change.

That's likely why the impact is so inconsistent - a Teams/Zoom call or VPN tunnel loses its NAT mapping and has to detect the break and re-establish, which shows up as a multi-second freeze, while a fresh request just gets a new mapping instantly and barely blips. So it isn't only a DHCP lease-renewal problem in isolation, it's a renewal that's also forcing a connection-tracking reset downstream - which would explain why some users report browsing as fine while calls and VPNs take the hit, even though the underlying event happens like clockwork every ~600 seconds.

[User5519]

One more piece worth adding to the DHCP-renewal picture, thanks to re-reading @Cylac 's original post from back in July: I think the "600-second lease" framing undersells what's actually happening. Cylac's OpenWrt log shows a very specific pattern: repeated unicast renews to 192.168.2.1 that go unanswered, then broadcast renew attempts that also go unanswered, then "lease lost, entering init state," immediately followed by a successful DISCOVER-based bind to the same public IP. That's not a renewal glitch - that's a renewal that never happens at all.

My own two full-day syslog captures (445+ lease cycles combined, across two reboots) show the exact same shape on Asuswrt: every single cycle is a full "deconfig" followed by a fresh "bound," with zero exceptions - never a quiet in-place lease extension. Different client, different OS, same result. That strongly suggests the Giga Hub's ADMZ DHCP server simply doesn't implement mid-lease RENEW/REBIND (unicast or broadcast) at all - it only responds to a full DISCOVER/OFFER/REQUEST/ACK exchange, so every ~600 seconds forces a complete WAN interface teardown/rebuild instead of a silent renewal, which is what's driving the flow-cache flush and connection drops downstream.

Also want to be clear on one point, since a couple of replies in this thread have framed this as Bell not supporting third-party equipment: that's not what's being asked for here. Nobody's asking Bell to certify or support an Asus, UDM, or OpenWrt box specifically. Advanced DMZ is a Bell-documented, Bell-supplied feature of the Giga Hub itself - the DHCP server handing out the 600-second lease is Bell's own code, not anything running on our equipment. @dg6464 's testing, @Cylac 's testing, and mine all show the same Bell-side behavior regardless of what's plugged into the WAN port. This is a feature that worked before the recent firmware and is broken now - that's a regression to fix, not a compatibility request.

@BellAlexander  @BellPatricia  - given this points pretty specifically at the ADMZ DHCP server never ACKing a renewal, is this something engineering can confirm and target directly, separate from the PPPoE passthrough fix in 3.11.6.3?

[dg6464]

I've been quiet for a bit just testing the various options out.

I have to say that by far... the simplest solution has been just using a plain old DHCP WAN on my firewall/router (OPNsense) alongside standard DMZ on the Bell Gigahub (not Advanced DMZ), with a DHCP reservation on the Bell Gigahub for the IP given to the WAN interface of the firewall/router.

I initially thought this would cause issues due to double-NAT, but I just kept all of the NAT rules / port-forwards on my OPNsense that existed whilst using my PPPoE setup for external services, Xbox, Nintendo, etc.

I have had zero issues thus far for over 3 weeks. I have full symmetrical 3Gbps speed, zero connectivity issues, Open NAT on all gaming platforms, no issues from externally-facing services.

This is definitely the interim method I would recommend to anyone experiencing issues with PPPoE on their own router/firewall whilst all users wait for the new .3 or .4 firmware revisions. It's simple. It works. No messing around with poorly-implemented PPPoE passthrough or poorly-implemented ADMZ due to modem firmware that probably should have had this solved considering the massive amount of in-field time these modems have had (at least Gigahub 1.0) and millions of users to pull testing data from.

[Pokato]

Hi all, I want to see if more of the elusive 3.11.6.3 or newer firmware has been seen in the open?

[dks]

I was on 3.11.6.2 and now am on 3.11.6.4. This happened in the last week or so, at night. I don't have any changelog for the .4 release and I don't use a separate router, so I can't say more, but it is in the wild. 

[rj083]

@BellAlexander Can you upgrade me to 3.11.6.3 or 3.11.6.4?

[Pokato]

It would be great if @BellAlexander could advise whether 3.11.6.4 is official and live.

[shlomithemoney]

Or at a minimum, just keep us updated on ANYTHING. No updates in 2 months for such a major bug is both a ridiculous and pathetic example of Bell's everyday customer service quality. How much effort would it be for Bell to take 2 minutes to just update us weekly, even if there is nothing new?

At this point, I am not even sure what is more infuriating: the broken v3.11.6.2 firmware hijacking our 3rd-party routers, or Bell's blatant lack of common sense and basic respect for their paying customers.

[AquaGoat]

Some update from @BellAlexander sure would be nice...

[Pokato]

Called support, and they confirmed .2 is still the current release.  3.11.6.4 is still under testing...

[Philonious1]

 

[BoringPlodder]

@BellAlexander @BellPatricia @Bell it has been 3 full months since this thread started, how has this not been fixed yet?!?  What compensation is going to be offered to those who have had their internet connection die every 10 minutes for THREE MONTHS?

[BellAlexander · Accepted solution]

We know you are all excited and continue to wait patiently for the next firmware release. As we shared in our last update here, when we have new update or deployment information to share we will share it here in the Community.

Stay tuned and thank you again for your patience and understanding.

@BellAlexander - Community Manager

[BoringPlodder]

I think @BellAlexander and the rest of us have a different definition of “excitement” and “patient”.  We just want our internet working and Bell to fix what Bell broke.