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.