GL.iNET Flint 2 (GL-MT6000) discussions

Hardware Questions and Recommendations
1869

Here are my results with your script after 2 days uptime:

cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
 11:   55108275   10886419    5134652   37005813     GICv3  30 Level     arch_timer
 14:          0          0          0          0     GICv3 142 Level     wdt_bark
 25:          0          0          0          0   mt-eint   9 Edge      keys
 62:         13          0          0          0   mt-eint  46 Level     mdio-bus:01
 63:         31          0          0          0   mt-eint  47 Level     mdio-bus:07
 82:          6          0          0          0   mt-eint  66 Level     mt7530
117:          0          0          0          0     GICv3 148 Level     10320000.crypto
118:          0          0          0          0     GICv3 149 Level     10320000.crypto
119:          0          0          0          0     GICv3 150 Level     10320000.crypto
120:          0          0          0          0     GICv3 151 Level     10320000.crypto
121:         13          0          0          0     GICv3 155 Level     ttyS0
122:          0          0          0          0     GICv3 205 Level     xhci-hcd:usb1
123:       1875          0          0       6445     GICv3 175 Level     11230000.mmc
130:         11          0   72713656          0     GICv3 229 Level     15100000.ethernet
131:          0          0          0   60735578     GICv3 230 Level     15100000.ethernet
133:       1254   10595013          0          0     GICv3 245 Level     mt7915e
137:          0          3          0          0    mt7530   0 Edge      mt7530-0:00
138:          0          3          0          0    mt7530   1 Edge      mt7530-0:01
139:          0          0          0          0    mt7530   2 Edge      mt7530-0:02
140:          0          0          0          0    mt7530   3 Edge      mt7530-0:03
IPI0:     54694      64445     125326      80914       Rescheduling interrupts
IPI1:  41068954    9475405    6668926   27139722       Function call interrupts
IPI2:         0          0          0          0       CPU stop interrupts
IPI3:         0          0          0          0       CPU stop (for crash dump) interrupts
IPI4:         0          0          0          0       Timer broadcast interrupts
IPI5:         0          0          0          0       IRQ work interrupts
IPI6:         0          0          0          0       CPU wake-up interrupts
Err:          0

I don't have much experience with irqbalance in the first place so I can't tell for sure if does the job as expected but it looks alright. Thanks for sharing the script with us!

1870

Turns out you can just do option 'background_radar' 1. However, I've noticed that this doesn't work after a reboot. It seems that hostapd still wants to have a radar scan completed before enabling a DFS channel, but this setting causes it not to do that initial scan. 5 GHz radio remains disabled until some time passes for the background scanning to do its job and then a manual wifi restart is needed. I'm turning it off. I've edited the earlier post to not confuse people.

2 Likes
1871

Team,

anybody to provide me how to autostart the iPerf3 service when MT6000 will be restarted?
@reboot
iperf3 -s -D
doesn't work...

Thanks
Neuro

1872

Is this still the best reasonably powerful and decent router to get in Oct 2024?

4 Likes
1873

Considering it's $127 on prime right now I'd say it is by far. My only complaint is I wish the USB port was on the back since I use it for a 2TB Ksmbd share, but I got a USB3.1 angle connector to hide the cable :man_shrugging:

1 Like
1874

well there is something going on here though :wink:

i made a issue since i noticed the band being wrong reported when it is 'stuck ' though i happen to have this setting in my configuration aswell.

it showed 6.130ghz for channel 36 that is not correctly :stuck_out_tongue:

2 Likes
1875

Probably a typo in all the new wifi 6e and wifi 7 code they added recently, but maybe mt76 is incorrectly reporting. I gotta build a new snapshot this weekend and test too.

2 Likes
1876

I got to ask... I saw you have list ht_capab 'SMPS-STATIC' in your wireless config. I'm curious how to verify if various magic options actually do anything good. Do you have any pointers? What effects did you see after enabling this?

1877

i did not noticed a change with this option, though it may works but its still a remnant when i was testing the multicast crash issue :wink:, but this option did not influence it. :+1:

It was suggested with energy saving modus on clients.

1878

Does this mean the Flint 3 is around the corner with Wifi 7 :wink:

2 Likes
1879

https://store-eu.gl-inet.com + "THANKS10"
It's available again :wink:

1 Like
1880

https://forum.gl-inet.com/t/any-plans-for-wifi-7-device-with-at-least-4-2-5gb-ethernet-ports/30509/8

1 Like
1881

Today's snapshot includes a possibly significant commit: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=7d256aff7b959b4a4f1337b1076090ad800dfd3b

I've updated to: OpenWrt SNAPSHOT r27716-fa6bd065dd
No issues so far.

5 Likes
1882

I wonder if this should be broken out as a new thread, as it's not specific to MT6000...

I'm seeing similar issues in 2.4, but only with Android dual-band 11ac capable chipsets...

As mentioned in the CR/BugReport - Intel AX chipsets seem to be ok, and I can confirm that ath10k on Windows11 and Ubuntu is fine as well...

But there's still a lot of unanswered questions, and a need for discovery on which client STA's from both a OS/Driver Level, along with what hardware is in play for this issue.

1883

@jbrossard gonna flash a build with that and the mt76 update that just went in tonight or tomorrow... Good times for MT devices.

@janusz07 woa Q4! Figured they would wait a little longer. Hopefully it's similar in size, maybe it'll be called GL-MT7000. My wishlist is simply the Filogic 880 (a little beast in the Bpi-r4). Keep the same ports/ram/storage to keep price down, move USB3 to the back, and I would be happy.

7 Likes
1885

WireGuard speeds on various builds I have tested today. All via a 1GB port.
Test suite: https://github.com/cyyself/wg-bench

On device to on device (loopback)

These tests are indicative of kernel performance where packet steering does not affect locally tested WireGuard speeds.

  • Current master snapshot shows a slightly speed regression
  • GL.iNETs 4.6.4-op24 release2 firmware shows a large speed regression

I am unable to test pesa1234s custom build yet.

From fastest to slowest:

OpenWrt 23.05.5 r24106-10cc5fcd00
"kernel": "5.15.167"

[ WITHOUT PACKET STEERING ]

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   994 MBytes   834 Mbits/sec    0             sender
[  5]   0.00-10.00  sec   993 MBytes   833 Mbits/sec                  receiver

=======

GLiNET 4.6.4 release 1
	"kernel": "5.4.238"
	"description": "OpenWrt 21.02-SNAPSHOT r15812+1075-46b6ee7ffc"
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   956 MBytes   802 Mbits/sec    0             sender
[  5]   0.00-10.00  sec   954 MBytes   800 Mbits/sec                  receiver

=======

GLiNET 4.5.8 release 4
	"kernel": "5.4.238"
	"description": "OpenWrt 21.02-SNAPSHOT r15812+1071-46b6ee7ffc"
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   953 MBytes   799 Mbits/sec    0             sender
[  5]   0.00-10.00  sec   951 MBytes   798 Mbits/sec                  receiver

=======

GLiNET 4.7.0 beta3
	"kernel": "5.4.238"

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   947 MBytes   795 Mbits/sec    0             sender
[  5]   0.00-10.00  sec   946 MBytes   793 Mbits/sec                  receiver

=======

2024-10-10 snapshot

OpenWrt SNAPSHOT r27719-3f6e087b6f / LuCI Master 24.281.62975~383edb4

[ WITHOUT PACKET STEERING ]
	"kernel": "6.6.54"
	"description": "OpenWrt SNAPSHOT r27719-3f6e087b6f"
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   894 MBytes   750 Mbits/sec    0             sender
[  5]   0.00-10.00  sec   892 MBytes   748 Mbits/sec                  receiver

=======

4.6.4-op24 release2
	"kernel": "6.6.47"
	"description": "OpenWrt 24.0 r27229+44-ebe7c5f1a3"
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   787 MBytes   660 Mbits/sec    0             sender
[  5]   0.00-10.00  sec   786 MBytes   659 Mbits/sec                  receiver

=======

Test between two devices

Using the fastest above firmware:

OpenWrt 23.05.5 r24106-10cc5fcd00
"kernel": "5.15.167"

AP as SERVER through a WireGuard tunnel

The following tests do not show that I saturate all cores according to htop, so evidently there is room for improvement (irq affinities or packet steering).

Running the iperf3 -c 192.168.1.1 -u -b 500000000 results in roughly 500mbit before packet loss starts

OpenWrt 23.05.5 r24106-10cc5fcd00
"kernel": "5.15.167"

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec   579 MBytes   486 Mbits/sec  0.014 ms  12939/456868 (2.8%)  receiver

Running iperf3 -c 192.168.1.1 -t -z is slightly worse

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-33.00  sec  1.69 GBytes   440 Mbits/sec                  receiver

AP as CLIENT through a WireGuard tunnel

performs better

Run iperf3 -c 192.168.1.3 TCP test

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   913 MBytes   766 Mbits/sec  525             sender
[  5]   0.00-10.01  sec   910 MBytes   763 Mbits/sec                  receiver

Run iperf3 -c 192.168.1.3 -u -b 1000000000 -M 1000 UDP test

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec  1001 MBytes   839 Mbits/sec  0.000 ms  0/766915 (0%)  sender
[  5]   0.00-10.00  sec   992 MBytes   832 Mbits/sec  0.009 ms  6524/766893 (0.85%)  receiver
1886

Hello,

I have two MT6000 (one in Router mode and the other in AP Dumb) the APDUMB has stopped working the eth1 port and Lan 1, has anyone had something similar happen to them? I have flashed again and restored the default values ​​but it does not link these two ports, the rest work correctly...

Log:

Thu Oct 10 10:53:13 2024 kern.warn kernel: [    2.110068] mt7530-mdio mdio-bus:1f lan1 (uninitialized): validation of  with support 00,00000000,00000000,00006000 and advertisement 00,00000000,00000000,00000000 failed: -EINVAL
Thu Oct 10 10:53:13 2024 kern.err kernel: [    2.359996] mt7530-mdio mdio-bus:1f lan1 (uninitialized): failed to connect to PHY: -EINVAL
Thu Oct 10 10:53:13 2024 kern.err kernel: [    2.368329] mt7530-mdio mdio-bus:1f lan1 (uninitialized): error -22 setting up PHY for tree 0, switch 0, port 5
Thu Oct 10 10:53:13 2024 kern.info kernel: [    2.378761] mtk_soc_eth 15100000.ethernet eth0: entered promiscuous mode
Thu Oct 10 10:53:13 2024 kern.info kernel: [    2.385490] DSA: tree 0 setup
Thu Oct 10 10:53:13 2024 kern.info kernel: [    2.388697] clk: Disabling unused clocks
Thu Oct 10 10:53:13 2024 kern.info kernel: [    2.395128] VFS: Mounted root (squashfs filesystem) readonly on device 179:7.
Thu Oct 10 10:53:13 2024 kern.info kernel: [    2.402432] Freeing unused kernel memory: 448K
Thu Oct 10 10:53:13 2024 kern.info kernel: [    2.406905] Run /sbin/init as init process
Thu Oct 10 10:53:13 2024 kern.debug kernel: [    2.410989]   with arguments:
Thu Oct 10 10:53:13 2024 kern.debug kernel: [    2.413941]     /sbin/init
Thu Oct 10 10:53:13 2024 kern.debug kernel: [    2.416632]   with environment:
Thu Oct 10 10:53:13 2024 kern.debug kernel: [    2.419756]     HOME=/
Thu Oct 10 10:53:13 2024 kern.debug kernel: [    2.422103]     TERM=linux
Thu Oct 10 10:53:13 2024 user.info kernel: [    2.520701] init: Console is alive
Thu Oct 10 10:53:13 2024 user.info kernel: [    2.524186] init: - watchdog -
Thu Oct 10 10:53:13 2024 user.info kernel: [    2.741996] kmodloader: loading kernel modules from /etc/modules-boot.d/*

Thu Oct 10 10:53:14 2024 kern.warn kernel: [   14.310022] mtk_soc_eth 15100000.ethernet eth1: validation of  with support 00,00000000,00000000,00006000 and advertisement 00,00000000,00000000,00000000 failed: -EINVAL
Thu Oct 10 10:53:15 2024 kern.err kernel: [   14.559996] mtk_soc_eth 15100000.ethernet eth1: mtk_open: could not attach PHY: -22
Thu Oct 10 10:53:15 2024 kern.info kernel: [   14.567880] br-lan: port 1(eth1) entered blocking state
Thu Oct 10 10:53:15 2024 kern.info kernel: [   14.573104] br-lan: port 1(eth1) entered disabled state
Thu Oct 10 10:53:15 2024 kern.info kernel: [   14.578340] mtk_soc_eth 15100000.ethernet eth1: entered allmulticast mode
Thu Oct 10 10:53:15 2024 kern.info kernel: [   14.585234] mtk_soc_eth 15100000.ethernet eth1: entered promiscuous mode
1887

I'm not having any issue with my dumb AP using LAN1. I don't use the WAN port on that device.

1888

Lan1 and wan1 died for me, also Wifi.

1889

A device like this with at least 4x2.5G ports would be my dream! Let's hope they can pull this off at a reasonable price.