I think you can login using tmadmin.
Click Security -> ACL.
I didn't test this out as this belongs to some cafe.
However it looks like should work.


Both version will solve speed drop issue. v2.0.6 is better in my opinion since it uses a newer SDK.
The ONR do have 2 slots for firmware storage so it is supposedly quite bullet-proof but as with all firmware update, there is risk.
As long as you verify the sha256sum after download, you should be very safe, other than power outage, which should be handled by the 2 slots image.

This post has been edited by kwss: Apr 26 2025, 03:31 PM

Nice work! 🎉🎉
Maybe can go find if they have a bug bounty program and report it.

That's how cheap IoT device works in general. Keep pumping out new model and sell them while using the reference design is the same.

Have you identified where is the vulnerability? Is it in the webserver? Or within the web-app? Or somewhere else?

EDIT:
I suspect they have a default key for the token and manufacturer is expected to change it but didn't.
Maybe you look for it and change it for your PON stick.
Most developers are not aware of such things. The most recent one being ASP.NET:
https://www.microsoft.com/en-us/security/bl...t-machine-keys/

This post has been edited by kwss: Apr 28 2025, 01:29 PM

I mean more like report it directly to upstream but after having a look, just forget it.
https://corp.mediatek.com/security-contact

Basically they are saying you work for free until they invite you to get paid.

This is the expected behavior for anything that uses MASQUERADE in Linux iptables.

Just DMZ your gaming device or enable UPnP or NAT-PMP.

Alternatively get router that perform CG-NAT or EIM-NAT

I never use pfSense or OPNsense before but a quick search says there's a upnp plugin.

What is this? The TM staff clearly says need to file a report just to check if you are behind CGNAT.
He didn't confirm nor deny you are behind CGNAT.

1 Gbps plan definitely not CGNAT.
TM CGNAT IP all comply to RFC 6598.

Maybe OPNsense is out of your league. Just saying.

Like all the tech bro just starting out, fake it till you make it. 💪💪
😂😂😂

What's your black dlink firmware version? Tried upgrading to v2.0.6?
Speed drop on bridge mode is a known firmware bug.

syahpian neekun
The speed drop is fixed in v2.0.3 itself so it must be other problem already.
Since your old ONU works, why not just use it? The extra 100Mbps download speed is really that significant for you?

It is true. But at the same time, all the consumer hardware is like pump and dump with literally zero support.
Wish you luck.

There is another problem after they allow MTU 1500.
In IPv6, the BNG will send ICMPv6 Packet Too Big even if the MRU is 1500 and big enough to receive it.
Using IPv4 doesn't face this problem. My guess is they put in this broken workaround because some of their supplied router eats ICMPv6 packet in the name of firewalling.

There are other minor issue with their BNG the last time I test them, such as the weird reuse of magic number.
I also don't quite understand why their L2MTU cannot be increased, considering TM claim's all their MPLS circuit runs 9k MTU worldwide in their marketing material.
Maybe their marketing team lied.

I removed them twice. Once when renovating my front yard. Another time when doing some small renovation in my living room.
They are just quick disconnect cable. At least that's how mine is.
I keep them in zip lock bag and seal them tight with rubber band while disconnected.
Use alcohol swab to clean both side before reconnecting.

neekun
When you said the technician laptop can get full speed, how many run did he tried? Is it consistently getting full speed or how?

Can you try the following:
DLink as bridge. Asus as router.
Disconnect all wired devices.
Disconnect all wifi devices.
Confirm in your Asus UI only your iphone 16 is connected.
Run the speedtest.

Yes I removed the whole cable. They are quick disconnect cable.

Flow Control is a LAN problem. Among all the stupid invention in the world of networking, Flow Control ranks very high in my list.
You connect one slow device in your network that randomly sends out a pause frame, your switch / router propagate it, then every device that does pause frame slows to a halt.

That's the first thing I kill for all deployment. You can test it by disconnecting every single device and test using WiFi or packet capture and look for the dreaded pause frame.

Since one technician laptop have no problem, then viola, very high chance that laptop has pause frame killed.
Either the driver for some random NIC has it disabled by default, or someone disabled it but forget about it.

Then the D-Link... Obviously it doesn't propagate pause frame.
Mikrotik also won't propagate pause frame by default.

Pause frame basically tells every device on your network to pause transmit. Transmit = Upload.
It should be DISABLED.

It is easier for you to just disconnect everything and test. It is a straight Yes / No if nothing is connected.

Not sure about how you go about disabling then as I don't use Asus and don't use Windows.
But try looking into the properties inside Device Manager.

If you have access to a Linux machine connected via wired, get me the output of:

You can download Kali Linux Live Boot and just boot it using USB. If you have a macOS maybe just try and see if the command works.

Since you unplug one by one, I suspect the pause frame quanta is still in effect. It's not like you unplug and all the device will suddenly stop pausing.

If all else fail, boot Kali. Open wireshark, capture for 5 minutes without doing anything and post it here.
Just do a speedtest inside Kali to check if it's affected first.

Yes set it to Disabled. Then just disconnect and reconnect. Pause frame should be killed for good.
The problem with using this method is you must set on all computers.

Mikrotik has Flow Control configuration and default to disabled. Same goes for Cisco. The advantage is you don't need to set per computer as the switch / router will eat up the pause frame.

I use Ubiquiti for WiFi, with self hosted controller (https://hub.docker.com/r/jacobalberty/unifi).
Basically I use L3 adoption and runs everything on AWS.

Be aware, Mikrotik is like Cisco with UI. Meaning instead of knowing what you specifically need to do + the command, you still need to know specifically what to do but can instead click around.

Eg: to configure a LAN, in every home router, you basically go to LAN page and just enter IP address.

In Mikrotik, these are the steps:
1. Go to Interfaces > VLAN. Create a new VLAN for your segment.
2. Go to Bridge > VLAN. Tie all the ports to the VLAN you created, specify which are the tagged and untagged port. This is the latest way to do things now. You will see a lot of tutorial online teach you by creating new bridge. But those method are the previous best practice which doesn't work optimally with L3 hardware offload.
3. Go to IP > Addresses to specify the virtual interface address.
4. Go to IPv6 > Addresses and repeat for IPv6.
5. Go to IP > DHCP server to create an entry for the virtual interface. Go to Network tab and create a specification. Then go to DHCP tab to create the service
6. Go to IPv6 > ND to create SLAAC for IPv6. You must also specify the MTU here since Mikrotik cannot do MTU 1492.
7. Go to Interface > Interface List. Add your new segment as LAN here or NAT won't work properly.

Assuming you do everything right and I didn't miss any steps, you should have a running network segment.
Not trying to scare anyone from buying Mikrotik and experimenting, but just trying to give you a reality of using Mikrotik.

Another example: Gaming router.
In a lot of gaming router, they default to UPnP + NAT-PMP + EIM-NAT. In Mikrotik, all of these requires manual configuration. None work out of the box. You also need to configure the conntrack UDP timeout from the default 30 seconds to something higher.

In conclusion, consider seriously before throwing money into Mikrotik. People already doing networking professionally or have passion will enjoy it.

Ubiquiti L3 Adoption (I use the DNS method):
https://help.ui.com/hc/en-us/articles/20490...doption-Layer-3

This post has been edited by kwss: May 19 2025, 12:56 AM

Just PSA. HEX Refresh uses an arm32v5 CPU. If your intention is to use public container image, it is extremely limited, almost useless.
If running container on Mikrotik is the goal, get arm64.