MT6000 custom build with LuCi and some optimization - kernel 6.6.x

Anyone care to try this for sch_cake.c ?

    1. Adding a proper locking hierarchy with qdisc, tin, and flow level locks
    2. Converting shared variables to use atomic operations
    3. Making all configuration functions thread-safe
    4. Protecting all critical sections with appropriate locks
    5. Ensuring proper cleanup and initialization

The changes ensure that:
    • Multiple threads can safely access the scheduler
    • No race conditions exist in critical sections
    • All shared data is properly protected
    • Proper locking order prevents deadlocks
    • Memory barriers ensure visibility of changes

google drive sch_cake.c diff

1 Like

Hi, the link that you provide seems that require access, can you please give a git link or github etc...?

https://github.com/mindwolf80/sqm

1 Like

I'm not a kernel programmer (but I do code low level C, C++ and Rust professionally). And that diff file looks odd to me.

Since C doesn't dispatch on type, shouldn't you change uses to also use atomic operations on the atomic variables? In particular I would expect great care being taken to use the proper memory access type (relaxed, acquire, etc) for each case.

To me it looks incomplete, like the patch changes the types and inisitialises a few variables. But none of the uses are actually converted?

Edit: it looks like the diff is literally incomplete, the actual C and orig files have more differences that are not included?

My apologies, It appears my Ubuntu VM install has become corrupted with random file restores. I'll try to finish it soon. Time for a fresh install and Clonezilla haha.

Hi,

I switched to latest 4.5.x https://github.com/pesa1234/MT6000_cust_build/tree/main/2025-01-26_r29038-a134d8463a_next-r4.5.22.rss.mtk three days ago and sadly it is less stable for me than rock solid 4.4.3 https://github.com/pesa1234/MT6000_cust_build/tree/main/2024-12-07_r28468-d0427a99f5_next-r4.4.3.mtk

With 4.5.x I experience random few second transfer spikes roughly 1-2 times a day.

1 Like

Much appreciated.. I am no expert, and I love the work these guys do to improve the firmware - but I am worried too many changes happen at once, without properly testing them before moving on..

Personally I wish they would focus on 24.10 (when final is released), with tweaks to improve the MT600 further.. Atleast then we have a stable main branch to work off, rather than an ever changing SNAPSHOT branch.

I do appreciate the work these guys do, but my MT6000 is the main router and with wife and kids having it go up and down is not an option. :smiley:

My personal observation on lots of Samsung phones (flagman models or not) is that all recent models use only 20 MHz on the 2.4 GHz band. And I think that is a deliberate limitation (unfortunately) by the manufacturer although the WiFi chipset (Qualcomm or any other) used may fully support 40 MHz. And I see many other manufacturers do exactly the same with their recent models.
For example Motorola Edge 30 Fusion supports 40 MHz with QAM-256.
It's a pity that this specification (limitation) is not listed officially anywhere or at least I cannot find it.
Yes I know all the hurdles of using 40 MHz but in my local environment that is not an issue and I can get the benefits of using it even with the added support for QAM-256 in 2.4GHz 802.11n.

FWIW I’ve stayed in Pesa’s stable for a year or so now and have never experienced downtime

1 Like

Life on the SNAPSHOT branch is not for the faint of heart. My household has not yet complained on any instability, I try to flash and evaluate after "office hours"

I fully understand that.. I just wish they focused on 24.10 MAIN once released, made their tweaks and released as a "stable" tweaked version of 24.10..

But again, I am happy to install the latest Pesa (with or without snapshot), provided it is stable - unfortunately I am unable to assist with any beta testing, which I know some of you are.. (and all credit to you).

I'm amazed how stable is the Pesa build given it is an experimental branch forked off snapshot :wink:

That being said, the 4.4.x gave me the least number of DNiD (Daaaad! The neeeet is Dooooownnnnn!) events so far :smile:

4.5.x Probably needs to mature a little more.
Awesome job overall!

6 Likes

I believe the nature of this custom build is to get best of the specs, and unfortunately many features & patches are not supportable on 24.10 series.

7 Likes

The WiFi alone is like night & day compared to stock 23.05.5. I've done 1 week on/off with each and the Pesa 4.4.6 is amazing. It's what stock should be but won't because of politics.

6 Likes

4.4.6 or r4.5.24?

4.4.6

1 Like

Can I ask where do you get that patch or it is from you?

I would suggest modifying the existing wan rule to add similar rate limiting to IPv4 pings to prevent potential abuse/ping flood attacks. This would still allow legitimate ping checks but prevent someone from overwhelming your router with a flood of ICMP requests.

nftables

icmp type echo-request limit rate 10/second burst 5 packets accept comment "!fw4: Allow-Ping"

OR using LUCI

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option family 'ipv4'
        option target 'ACCEPT'
        list icmp_type 'echo-request'
        option limit '10/second'
        option limit_burst '5'

May as well do the same for ICMPv6 Forward & ICMPv6 Input. 1000/sec is beyond excessive.

1000 requests per second means:

  • 60,000 per minute
  • 3,600,000 per hour
  • 86,400,000 per day

new limit of 10/second is much more sensible:

  • 600 per minute
  • 36,000 per hour
  • 864,000 per day
3 Likes

Something I was working on for a while, which got corrupted when my VM crashed.

This patch, which is being tested in the next r4.5.24.rss.mtk, is interesting.
I'll also try to see if it fixes the WED and roaming issues.

2 Likes