No it was with pesa's 4.4.6 build. vanilla and stock keeps dropping speeds too much.

1 Like

Can this be considered the best current router for openwrt? Since Openwrt is official, I imagine that everything will work perfectly both with the official firmware and with Openwrt directly.

1 Like

OpenWRT works well with a particular device as long as there are users who test snapshots and RCs, report issues and attempt to fix them. So MT6000 is currently well supported. Recently there haven't been any significant issues reported.

4 Likes

In case you brick it, its super easy to restore, for many users should be the number one point.
Just keep preinstalled uboot

4 Likes

Guess I spoke too soon the speeds tanked after a while maybe I just have a semi lemon on the silicon lottery. There is no other WiFi signals out here to cause interference.

2 Likes

This is related to powersave mode in iphone, its easy to fix it, power on battery save mode with wifi connected, disconect wifi from control center, turn off power save mode and reconnect to wifi.
I have consistent speeds with all gadgets in my house.

1 Like

I just upgraded to 4.4.6 yesterday (from 4.4.0) and it seems out of the box I get around 600 down and slightly more up.. This is 80mhz, 5Ghz. (I've got 1gig broadband)

This is also related to client, im able to reach consistent 950/950 with 3x3 80mhz, and with wed, with gigabit contract reach full 1020/1020 with 2.5g ont

1 Like

Yes, agreed. Im using a S24 Ultra, so the client is fairly up to date and should be able to get > 600mb.

@pesa1234 twt patches from iopsys https://dev.iopsys.eu/feed/openwrt-core/-/merge_requests/660

4 Likes

Hi, I just upgraded to 4.4.6 (because many people are recommending it) from the mighty 4.3.6. I finally made the transition to APK but not without issues.

I'm unable to install adblock and luci-theme-argon because of this dependency

ERROR: unable to select packages:
  libubus20241020-2024.10.20~252a9b0c-r1:
    conflicts: libubus20250102-2025.01.02~afa57cce-r1[libubus=2024.10.20~252a9b0c-r1]
    satisfies: world[libubus20241020]
               cgi-io-2022.08.10~901b0f04-r21[libubus20241020]
               dnsmasq-full-2.90-r3[libubus20241020]
               libiwinfo20230701-2024.10.20~b94f066e-r1[libubus20241020]
               libudebug-2023.12.06~6d3f51f9[libubus20241020]
               logd-2024.04.26~85f10530-r1[libubus20241020]
               netifd-2024.12.17~ea01ed41-r1[libubus20241020]
               odhcpd-ipv6only-2024.05.08~a2988231-r1[libubus20241020]
               procd-2024.12.22~42d39376-r1[libubus20241020]
               procd-ujail-2024.12.22~42d39376-r1[libubus20241020]
               rpcd-2024.12.02~cc9a471c-r1[libubus20241020]
               rpcd-mod-file-2024.12.02~cc9a471c-r1[libubus20241020]
               rpcd-mod-iwinfo-2024.12.02~cc9a471c-r1[libubus20241020]
               rpcd-mod-luci-20240305-r1[libubus20241020]
               rpcd-mod-rrdns-20170710[libubus20241020]
               rpcd-mod-ucode-2024.12.02~cc9a471c-r1[libubus20241020]
               ubox-2024.04.26~85f10530-r1[libubus20241020]
               ubus-2024.10.20~252a9b0c-r1[libubus20241020]
               ucode-mod-ubus-2024.12.06~209f041f-r1[libubus20241020]
               uhttpd-mod-ubus-2023.06.25~34a8a74d-r4[libubus20241020]
               wpad-openssl-2024.10.24~b80b3791-r2[libubus20241020]
  libubus20250102-2025.01.02~afa57cce-r1:
    conflicts: libubus20241020-2024.10.20~252a9b0c-r1[libubus=2025.01.02~afa57cce-r1]
    satisfies: rpcd-mod-rpcsys-2024.12.02~cc9a471c-r1[libubus20250102]

APK is complaining that libubus20250102, required by these packages, conflicts with libubus20241020.

Do you know what am I missing? The correct Pesa's repo is in the distfeeds.conf file, I did not make any change.

3 Likes

Hey all! Many thanks to @rikroe for some excellent updates to this Docker-based build project for pesa's repo:

@rikroe's contributions are:

If you hit any bugs, please open an issue here: https://github.com/Fail-Safe/openwrt-pesa1234-build/issues

5 Likes

Thanks for keeping this updated!!!

4 Likes

Hi to the community..

I'm not sure if anybody has noticed this, or if this due to the custom builds, but on my Flint 2, the router date/time keeps getting de-synchronized based on actual date/time.

I only noticed it after putting a wrong ntp server domain on the list of ntp servers via luci. After an hour, the difference is around minus 1 min, and for almost a day, the difference was almost an hour (delayed by almost an hour).

I've got a hotplug to log the ntp updates on my other routers which I added to the flint to see what is happening (and that's the time I found a typo on the list of ntp servers).

Below is the hotplug script (/etc/hotplug.d/ntp/20-ntpd-logger)

#!/bin/sh
[ $ACTION = "step" ]    && logger -t ntpd Time set, stratum=$stratum interval=$poll_interval offset=$offset
[ $ACTION = "stratum" ] && logger -t ntpd Stratum change, stratum=$stratum interval=$poll_interval offset=$offset

Now on the logs, I see the ntp re-aligning the date/time in the router like every couple of seconds.

Tue Feb 18 14:08:42 2025 user.notice ntpd: Stratum change, stratum=3 interval=32 offset=0.045591
Tue Feb 18 14:09:09 2025 user.notice ntpd: Stratum change, stratum=4 interval=32 offset=0.042969
Tue Feb 18 14:09:14 2025 user.notice ntpd: Stratum change, stratum=3 interval=32 offset=0.043976
Tue Feb 18 14:09:46 2025 user.notice ntpd: Stratum change, stratum=4 interval=32 offset=0.043027
Tue Feb 18 14:10:52 2025 user.notice ntpd: Stratum change, stratum=3 interval=32 offset=0.045696
Tue Feb 18 14:11:26 2025 user.notice ntpd: Stratum change, stratum=4 interval=32 offset=0.043930
Tue Feb 18 14:11:58 2025 user.notice ntpd: Stratum change, stratum=3 interval=32 offset=0.045749
Tue Feb 18 14:12:31 2025 user.notice ntpd: Stratum change, stratum=4 interval=32 offset=0.044280
Tue Feb 18 14:14:08 2025 user.notice ntpd: Stratum change, stratum=3 interval=32 offset=0.043917
Tue Feb 18 14:15:48 2025 user.notice ntpd: Stratum change, stratum=4 interval=32 offset=0.043841
Tue Feb 18 14:16:19 2025 user.notice ntpd: Stratum change, stratum=3 interval=32 offset=0.046488
Tue Feb 18 14:17:58 2025 user.notice ntpd: Stratum change, stratum=4 interval=32 offset=0.044914
Tue Feb 18 14:18:30 2025 user.notice ntpd: Stratum change, stratum=3 interval=32 offset=0.045125
Tue Feb 18 14:20:07 2025 user.notice ntpd: Stratum change, stratum=4 interval=32 offset=0.046302
Tue Feb 18 14:22:17 2025 user.notice ntpd: Stratum change, stratum=3 interval=32 offset=0.047568
Tue Feb 18 14:22:22 2025 user.notice ntpd: Stratum change, stratum=4 interval=32 offset=0.045118
Tue Feb 18 14:22:49 2025 user.notice ntpd: Stratum change, stratum=3 interval=32 offset=0.046006
Tue Feb 18 14:23:21 2025 user.notice ntpd: Stratum change, stratum=4 interval=32 offset=0.043871
Tue Feb 18 14:24:26 2025 user.notice ntpd: Stratum change, stratum=3 interval=32 offset=0.045966
Tue Feb 18 14:24:58 2025 user.notice ntpd: Stratum change, stratum=4 interval=32 offset=0.043785
Tue Feb 18 14:25:30 2025 user.notice ntpd: Stratum change, stratum=3 interval=32 offset=0.045449
Tue Feb 18 14:26:04 2025 user.notice ntpd: Stratum change, stratum=4 interval=32 offset=0.043223
Tue Feb 18 14:26:37 2025 user.notice ntpd: Stratum change, stratum=3 interval=32 offset=0.046734
Tue Feb 18 14:26:45 2025 user.notice ntpd: Stratum change, stratum=4 interval=32 offset=0.042596
Tue Feb 18 14:27:10 2025 user.notice ntpd: Stratum change, stratum=3 interval=32 offset=0.042190
Tue Feb 18 14:27:42 2025 user.notice ntpd: Stratum change, stratum=4 interval=32 offset=0.042321
Tue Feb 18 14:27:50 2025 user.notice ntpd: Stratum change, stratum=3 interval=32 offset=0.045873
Tue Feb 18 14:28:15 2025 user.notice ntpd: Stratum change, stratum=4 interval=32 offset=0.044055
Tue Feb 18 14:28:48 2025 user.notice ntpd: Stratum change, stratum=3 interval=32 offset=0.044651
Tue Feb 18 14:29:20 2025 user.notice ntpd: Stratum change, stratum=4 interval=32 offset=0.042491
Tue Feb 18 14:29:28 2025 user.notice ntpd: Stratum change, stratum=3 interval=32 offset=0.045008
Tue Feb 18 14:30:26 2025 user.notice ntpd: Stratum change, stratum=4 interval=32 offset=0.041727
Tue Feb 18 14:30:58 2025 user.notice ntpd: Stratum change, stratum=3 interval=32 offset=0.042478
Tue Feb 18 14:31:31 2025 user.notice ntpd: Stratum change, stratum=4 interval=32 offset=0.042660
Tue Feb 18 14:32:03 2025 user.notice ntpd: Stratum change, stratum=3 interval=32 offset=0.045456
Tue Feb 18 14:32:35 2025 user.notice ntpd: Stratum change, stratum=4 interval=32 offset=0.043154
Tue Feb 18 14:32:46 2025 user.notice ntpd: Stratum change, stratum=3 interval=32 offset=0.045701
Tue Feb 18 14:35:50 2025 user.notice ntpd: Stratum change, stratum=4 interval=32 offset=0.044937
Tue Feb 18 14:36:23 2025 user.notice ntpd: Stratum change, stratum=3 interval=32 offset=0.046871
Tue Feb 18 14:36:52 2025 user.notice ntpd: Stratum change, stratum=4 interval=32 offset=0.044432
Tue Feb 18 14:36:55 2025 user.notice ntpd: Stratum change, stratum=3 interval=32 offset=0.045515

I don't think this is normal basing on my other routers which doesn't get this de-synchronized so often. My other routers, ntp usually needs to re-align after a couple of hours.

I might do more testing to see if this is a build issue, or issue on openwrt, or issue with the device itself.

By the way, that is based on latest branch next-r4.5.26.rss.mtk.

Update: Tested other builds from https://github.com/pesa1234/MT6000_cust_build/tree/main, specifically, r4.4.6.mtk and r4.5.22.rss.mtk, flashed them with no settings saved.

With r4.4.6.mtk didn't see any ntpd synching except very very few just after boot.

On r4.5.22.rss.mtk, there was a slight increase of the ntpd sync, but not too concerning because they are between couple of mins (ranging between 5mins to 20mins).

Did those two while I was rebuilding latest from branch next-r4.5.26.rss.mtk, and after flashing with this and testing for a 2 hours (with restored settings). And now it looks like NPTD sync is back to normal.

What is your:

cat /etc/config/system
?

This was what I was using during my tests

config timeserver 'ntp'
	list server 'pool.ntp.org'
	list server 'ph.pool.ntp.org'
	list server 'asia.pool.ntp.org'
	list server 'sg.pool.ntp.org'

But alls good now with the latest rebuild for the next-r4.5.26.rss.mtk branch. Not sure what was the issue with the last Sunday's build from the same branch that made the router clock not ticking properly.

1 Like

You see that in log cause you changed your system time server.

I don't get what you mean?

The issue I reported has nothing to do with changing the ntp settings but the clock of the router is ticking abnormally.

I made a build last Sunday using the mentioned branch and installed it. I noticed the next day that the time of the router was delayed by an hour when I got back from my office. I manually adjusted the time then monitored and checked the router date/time every 30mins to 1hr and clock keep getting misaligned by a a few mins.

That's when I added the logging for ntpd and noticed that it kept trying to re-sync the roruter date/time every few seconds (see logs from previous post).

I did more test and flashed other versions of the build just to see the difference in how often ntpd was trying to re-align the routers time.

Now I re-pulled the branch I mentioned, and did a rebuild. Now everything is back to normal. Based on the logs, ntpd is not trying to re-align the clock every few seconds but more a normal of hours before it's' being triggered (same with the rest of my routers - i've got a bunch by the way).

I said that cause I ve had that problem and it was causing by that.

1 Like

Are all of those servers in the same country/Time zone.

for example if you are in Asia use the these
0.asia.pool.ntp.org
1.asia.pool.ntp.org
2.asia.pool.ntp.org
3.asia.pool.ntp.org

Find your country here and use the same ones for your country dont mix and match.
https://www.ntppool.org/zone/asia
https://www.ntppool.org/zone/@