Anime4000
Care posting a traceroute to both ipv4 and ipv6 of the domain?

How do you do speedtest with DiGi Sri Kembangan?
I only got:
Kuala Lumpur
Petaling Jaya
Subang Jaya
Shah Alam
Penang

Mind getting me the speedtest server ID?

Did the Skyworth or D-Link works without PLOAM password too? This is strange

Anime4000
How did you fix the MTU? It fix by itself when you try 1492?

Looks like the BNG you are using is overloaded or shitty. Everything after your BNG has elevated latency.

Compare to mine:

It continues to happen with or without maximizing your upload / download?

OK I got a wild idea, can you get me the output of:
traceroute 218.100.44.182

Also screenshot me this website
https://rpkitest.nlnetlabs.net/

This post has been edited by kwss: Jun 1 2025, 03:47 AM

Not gg... Everything is working correctly. TM have moved all their BNG to default-free routing from my observation and turned on RPKI check.
Initially I thought your lone BNG is configured incorrectly because mine still cannot do 1492 MTU and I must use PLOAM password.

So I was kind of guessing something f'ked up and TM just recreate everything. But since OLT configuration is location based, I supposed they just temporary allow all connected ONU to continue operating by just registering their SN. It is just a theory.

Did you fill up your uplink to cause the disconnect or it just disconnect by itself?

OK, I got a different theory.
I lean towards problem with the BNG and not the last mile distribution network based on the following facts:
1. OLT cannot do HQoS
2. OLT is purely layer 2 and cannot differentiate IPv4 and IPv6
3. Given your problem only occurs with IPv4 but not IPv6 on all ONU regardless of PPTP and VEIP, it cannot be layer 2 issue.
4. Only BNG do layer 3

My guess is...
Since this is a new BNG, maybe they didn't configure the TCAM partitioning correctly. Now I don't know the hardware and the spec, or even if it uses TCAM or HBM. But let's just assume it is classic service router and uses TCAM.

The IPv4 routing table is very large and if the TCAM partition is configured incorrectly, it will overflow and the BNG will fallback to software processing. The only way to know for sure is check the BNG log for TCAM exception. At least on Cisco that's what shows up in log.
On IPv6, the routing table is much smaller and it will have no problem and packet just flies through.

Now if this actually happens, it is in an undefined behavior territory. They might get route flapping. Will PPPoE disconnect? Not sure, it is undefined behavior when the system is overloaded.

There might be another cause, CGNAT state tracking. Even if you have a public IP, there might still be state tracking. Maybe it is configuration issue, maybe it is software bug, maybe it is just how it works. But I really haven't come across CGNAT state tracking issue causing PPP session to be killed.

Or maybe the supervisor / line card is just broken. Everything is just a guess.
But main focus would be on BNG based on what happened to you.

EDIT:
Just to mention, at least on a Cisco, if TCAM is overflowed, latency did increase and bandwidth did drop. Exactly like what you observe.

This post has been edited by kwss: Jun 1 2025, 04:45 AM

Okay, so the SoC allow packet pacing on the ASIC.
But does this solve your random disconnect issue or the IPv4 speed issue?

I honestly think packet pacing has nothing to do with the pppoe disconnect. Maybe TM fixed it or something. Maybe it is just by chance.
For many decades nobody needs packet pacing to keep pppoe alive. Not during dial-up era. Not during DSL era. Not during FTTP era. Today won't be the day we need this. Like seriously...

Packet pacing is useful if you don't want to overrun buffer, especially from higher speed interface to lower speed interface. That's about it. I cannot wrap my head around how it can solve all the problems you are facing.

Don't get me wrong. Having new feature for your product is definitely good. Giving user control is a good thing.

Just saying none of this can solve TM problem. I tried MTU 1492 and it didn't work. I still need PLOAM password for my ONU to work.
I don't know what is happening to your area.
Maybe just ask the Elite team to move you off that BNG.
Cursed IP address might not be a thing, but I think cursed BNG is real.
At least tng55 have a track record of moving off a broken BNG.

EDIT:
I recalled one encounter with an ex-customer. His mantra is this: If something is broken, buying a new one will surely fix it.

This post has been edited by kwss: Jun 2 2025, 04:18 AM

You mean what kind of packet? LCP-Echo or just the dropped packet counter of the interface?
If you pace the transmit and it never overrun the buffer then no packet will be dropped. It is expected.
But for a shared infrastructure, you never know how much is the current utilization, that's why congestion control algorithm is a thing. Then again there's algorithm like BBR which tries to gain an unfair advantage of using up the pipe by blasting it and accepting high transmit retry as normal business.

Anime4000 Your kind of jam.
How to bring data centre-like connectivity to your home with IPTTTH
https://blog.apnic.net/2025/05/26/how-to-br...me-with-ipttth/

Set MRU to 1500. It will massively decrease the chance of website breakage.

I have confirmed return path can actually do 1500 for IPv4.
For IPv6, it will get blocked by the BNG if anything is more than 1492. This is some cheap dirty trick to workaround those stupid router TM gave that have stupid IPv6 setup.

This is some shenanigan done by TM. Long time back, TM will not broadcast RA but I don't know what convinced them this is such a great idea.
No properly configured router will accept RA. Mikrotik by default will never accept RA.
Accepting RA is a security issue as it means anyone on the L2 network can poison your upstream route.

The correct way is do it using DHCPv6 IA_NA. However for some reason, if you try to configure it like this, you get nothing. Not even the prefix.

Conclusion: TM still don't fully understand IPv6.

Actually I am just wondering. Would it be better to just shape upstream?
Reason is this:
If the OLT transmit the packet and your ONU already received it, then there is no reason to pace it. Dropping the packet will only cause higher layer protocol to perform a retransmit.

It is even more chronic in congested last mile because in PON network, all downstream traffic reaches every single ONUs.

If that is the case, then I think having 2488 for all the options is the best.
This way, it will not cause anything to be dropped.
What do you think?

I have to say I don't understand now.
So that number is a byte value for Layer 1? And it's a representative of frame size? Excluding the preamble?
But then your calculation is actually Layer 2.

So then using the largest number is the best right? Or just leave it as default?

Malaysia orders telecoms firms to hand over user data, raising privacy concerns
The government claims it’s for a mobile project, but critics cite data security risks.

The Malaysian government has ordered the country’s telecommunications firms to hand over detailed records of phone calls and internet usage, according to industry sources, raising concerns about the state’s use of data as it broadens its controls over online activity.

In April, the Malaysian Communications and Multimedia Commission sent a letter to telecoms companies instructing them to send detailed call and internet logs for the first three months of this year, apparently for the government’s Mobile Phone Data project, two industry sources confirmed.

Non-compliance would be considered an offence under the Communications and Multimedia Act, which carries a penalty of a 20,000 ringgit (US$4,700) fine or six months' jail, the commission said in the letter seen by This Week in Asia.

“They are asking for call records, IP call records, location, latitude and longitude,” one source said. “We have asked MCMC about transparency and accountability for the use of the data. We don’t know if MCMC will make a public statement that such an exercise is under way.”

The MCMC did not immediately respond to a request for comment.

Prime Minister Anwar Ibrahim’s administration imposed mandatory licensing for social media platforms in January in a bid to stamp out scams, online gambling and child sex exploitation targeted at Malaysians.

Also posted on Kopitiam
https://forum.lowyat.net/topic/5526338/

Actually I predict this time it will go on smoothly.
The reason is simple. 99% of the user don't care as long as they don't see breakage.

The previous time, they went so hard to break not only porn but also third party DNS.
Then TM went even further to forge TLS certificate and kill Cloudflare Zero Trust with all their BGP hijacking.

They surely learnt from their mistake and be quiet this round. You don't see Farkmee say anything too.

Yes DoH + HTTP/3 is the bare minimum to at least counter some of these government "project".

I still have my full blown anti-censorship system online and standby. Just need to pay AWS for IPv4 address and I'm good to go.

Actually we all know they are targeting political enemy. Think about it, nobody cares if you watch porn.

Previously they announce to mainstream media, hence they have to come out with a we are trying to protect you and your kids kind of narrative.
Now they just do it quietly and skip the mass censorship part. I'm sure that will come later, it's a powerful weapon during election.

In reality, those who need protection the most don't get it. They just don't have access to people with that technical skills.
Think about all the kidnapped cases, when someone in power is about to lose it.

Your religion is between you and your creator.
You are free to turn off the Internet. It saves you money too.

Also, go read The Art of Thinking Clearly by Rolf Dobelli.