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

New update...

4 Likes

The list of packages I remove grows each build. I'm in no position to make demands but could we please keep it clean?

2 Likes

Why not, ask, if you are not the only one I can remove it for sure.
Can I ask the list?

May I ask why you remove, not enough space on your device?

1 Like

Hi, for me personally i dont use half of the packages installed :slight_smile: i only use adblock luci-upnp and bascially the usuals such as htop and collectd. Id love a clean build with latest kernel and updates to drivers etc.

1 Like

Good news, everyone! :smiley:

After we have been testing with kernel 6.6 for a while, the devs are switching our target to 6.6 as default kernel:

3 Likes

Nah it's not about space but running processes/services (especially Samba/Avahi) and clutter in the UI and my config directory.

This is what I currently remove:

opkg remove luci-app-acme luci-app-adblock luci-app-ksmbd luci-app-vnstat2 luci-app-openvpn openvpn-openssl ksmbd-avahi-service avahi-dbus-daemon libavahi-dbus-support wsdd2 luci-app-statistics collectd collectd-mod* --autoremove

This is what I add (not saying it should be default):

opkg install nano jq ddns-scripts-cloudflare luci-app-ddns luci-app-commands libsensors5

Those commits have yet to be approved for merging.

Coincidentally, default to kernel 6.6 was just merged. :rocket:

6 Likes

Happy days :smiley:

Woohoo! Latest snapshot installed! :slight_smile:

1 Like

Hi, im new to these forums, but been over on the GL.iNet forums for quite a while reading through about the MT6000 which I currently own, I saw a post stating this is the best firmware and most upto date firmware to use on my device, as GL.iNet themselves dont seem to be getting anywhere with firmware, I decided to flash this firmware and run a few tests, so far pretty impressive.

I just have a quick question, apart from deleting the IPv6 interface, how can I make sure that IPv6 is disabled ?

Also my regarding my settings after setting up my country code (GB) I noticed when using 160mhz DFS channels the 5ghz doesnt work, ive waiting about 15 mins for it to connect, but it never did, ive experienced this before with GL's firmware, some of their firmwares allowed me to use those channels in the UK without issue, other firmwares didnt, and some other firmwares reverted to lower channels after a couple of hours, but when setting the country code to the US, im able to use 160mhz channel 128 with no problems, it connected in about 3 mins, UK OFCOM allow home users to use DFS channels.

Also noticed that disabling Adguard Home as allowed my 2ghz to work a little faster, but that is understandable.

Why would you want to disable IPv6?

Im new to OpenWRT and having IPv6 enabled is just confusing more thing for me, my ISP doesnt support IPv6 as far as im aware, so theres no point having it enabled anyway.

Delete wan6 interface

Delete IPv6 ULA-Prefix

Disable Ipv6 assignment lenght

and dhcp v6 disabled

Can I know how do you feel the wifi performance?

2 Likes

5ghz is the same as I was getting on the GL firmware

2.4ghz is finally way better, I have a lot of IoT devices, cameras, Alexa's, lights, kettle etc and they were all suffering, like when someone rang the smart doorbell for instance, it was never making it through to me when I was away from home, im now getting double the download speed and upload speed with this firmware when testing, so far its working brilliant.

Like I say, the only issue so far is if I set country code to GB I cant use DFS channels, ive had to set country code to the US.

This was 5ghz 160mhz channel 128 after 15mins with country code set to GB:

This is 5ghz 160mhz channel 128 with country code set to US:

I suggest you simply ignore IPv6. I don't change anything with IPv6 even though my ISP doesn't support it, but they say support is coming. They already support IPv6 with 5Gb and 10Gb plans. Eventually they will support it on the lower speed (2 Gb and 1 Gb) DHCP enabled tiers.

Hi from wireless-regdb-2024.01.23

# GB as part of EU/CEPT accepted decisions 2005/513/EC (5GHz RLAN, EN 301 893)
# and 2006/771/EC (amended by 2008/432/EC, Short-Range Devices, EN 300 440)
#  EU decision 2005/513/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
#  EU decision 2006/771/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
# Harmonized CEPT countries (July 2019): https://www.ecodocdb.dk/download/25c41779-cd6e/Rec7003e.pdf
# GB: https://www.ofcom.org.uk/__data/assets/pdf_file/0019/136009/Ofcom-Information-Sheet-5-GHz-RLANs.pdf
# GB: https://www.ofcom.org.uk/__data/assets/pdf_file/0028/84970/ir-2030.pdf
# GB: https://www.ofcom.org.uk/__data/assets/pdf_file/0013/126121/Statement_Implementing-Ofcoms-decision-on-the-57-71GHz-band.pdf
country GB: DFS-ETSI
	(2400 - 2483.5 @ 40), (100 mW)
	(5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
	(5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
	(5470 - 5730 @ 160), (500 mW), DFS, wmmrule=ETSI
	# short range devices (ETSI EN 300 440-1)
	(5725 - 5850 @ 80), (200 mW), NO-OUTDOOR
	(5925 - 6425 @ 160), (250 mW), NO-OUTDOOR, wmmrule=ETSI
	# 60 GHz band channels 1-6
	(57000 - 71000 @ 2160), (40)

Should be these the available channel right?

Yes, they relaxed the rules as we are not really part of the EU anymore since brexit

this is the range im trying to use 5470 - 5730 @ 160 DFS Ch 128 (5640mhz)

@pesa1234 @thedude since several people investigated iperf3 tests with Packet Steering I decided to focus on SQM to see how it's affected. I know this is a situational test since and are so many variables involved compared to iperf. In the end, the GL-MT6000 can do 900Mbps with SQM :rocket:.

My internet is a cable modem with gigabit service, OpenWrt 5/5/24 snapshot (kernel 6.6.29) -

Best performance was all CPUs and RPS none:
SQM cake, irqbalance + packet steering: (all CPUs)/None: 891 Mbps, +6ms and 877 Mbps, +2ms.
and again with SQM fq_codel: (all CPUs)/None: 917Mbps, +4ms.

Less performance:
SQM cake, irqbalance, packet steering, Enabled/None: 743 Mbps, +4ms
SQM cake, irqbalance, packet steering, Enabled/128: 688 Mbps, +2ms
SQM cake, irqbalance, packet steering, Enabled/256: 722 Mbps, +2ms
SQM cake, irqbalance, packet steering, Disabled: 715 Mbps, +3ms

WireGuard tests - seeing a range of 750-800 Mbps across a handful of tests. This is a regression from the 800-900Mbps I tested 6 months ago. Not sure why, I don't use this anyway.

3 Likes

That's an interesting result, since it was faster for you with steering flows (RPS) set to 256 instead of 128. And I'd assume you run the tests a few times, just to make sure there weren't any one off results?

I believe @pesa1234 needed the steering flows (RPS) set to 128 to get over 2Gbps when using speedtest-cli from the router itself. But based on your results it seems like using RPS and packet steering without all cores might make things worse when you're using SQM :thinking:

I'd be curious to know if reverting to a firmware with the old packet steering script resolves that, since the GL-MT6000 achieving 900Mbps via WireGuard is one of GL.iNet's selling points.

There's a WireGuard iperf3 benchmark here that demonstrates that the router can achieve 900Mbps.

I'd love to do some testing myself, but unfortunately I don't have gigabit internet yet.