Where is this option documented, and what is the default if the option isn't explicitly set?
So the present >OpenWrt< multicast_to_unicast_all setting was renamed from multicast_to_unicast. Refs:
- https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=ab61232b0abe2158c346f9fbf17f34e64de5288a
- https://github.com/openwrt/luci/commit/6069f4f228305e3e0b59cb6deb9de9934aa68b6f
- https://github.com/openwrt/openwrt/commit/09ea1db93b53d2c1e4a081f20fbbddd4bffd451d
However, the OpenWrt multicast_to_unicast_all setting is actually toggling the hostapd multicast_to_unicast option. Based upon hostapd: https://android.googlesource.com/platform/external/wpa_supplicant_8/+/master/hostapd/hostapd.conf
(Sorry for the Android source link. Will try to find a different reference if possible.)
The default multicast_to_unicast setting is '0':
# Multicast to unicast conversion
# Request that the AP will do multicast-to-unicast conversion for ARP, IPv4, and
# IPv6 frames (possibly within 802.1Q). If enabled, such frames are to be sent
# to each station separately, with the DA replaced by their own MAC address
# rather than the group address.
#
# Note that this may break certain expectations of the receiver, such as the
# ability to drop unicast IP packets received within multicast L2 frames, or the
# ability to not send ICMP destination unreachable messages for packets received
# in L2 multicast (which is required, but the receiver can't tell the difference
# if this new option is enabled).
#
# This also doesn't implement the 802.11 DMS (directed multicast service).
#
#multicast_to_unicast=0
Just to be very clear, the quoted selection of my previous post that you selected seems to indicate that I am generally suggesting this should be disabled. However, the larger context is that I have historically enabled this setting, but given the current issue it seems to play some part in (Mt798x-wmac 18000000.wifi: Message xxxxxxxx (seq 5) timeout - #6 by _FailSafe), I am recommending it be disabled until the root of the issue can be resolved. At least rule out this setting instead of disabling bridger + WED as a first-line-of-defense when client connectivity issues are presenting.
1 Like
Thank you. Since I've never enabled this setting, I don't have to be concerned with disabling it. 
1 Like
Is the setting “On” be default?
1 Like
Thanks, this is off for me. So I don’t think this is the issue for me.
I did try another device, I swapped one of my dumb APs with a rt3200. Still same issue in my setup.
This may be off the point, but it is something that concerns me.
On the MT6000 this is set to 1. (On the ath79 series it was 0.)
/sys/devices/virtual/net/br-lan/lower_phy1-ap0/brport/multicast_to_unicast
I was curious about this, so I explicitly assigned 0.
1 Like
Did this improve the reliability of Bridger for you? I can’t test until the weekend when family is out of the house.
WED and bridger remain disabled. I am satisfied with the stability of the GL-MT6000, because it is a powerful CPU and I believe it is fast even without offloading.
add:
I am now trying to tune the STP.
1 Like
Returning to an old question:
I ran today into trouble with my MT6000 with up-to-date main/master snapshot.
And I seem to be unable to enter the failsafe mode.
The LEDs blink ok, but the button press does not lead into failsafe getting triggered. (and keeping repeatedly pushing the reset button a bit longer will sooner or later lead into an actual reset when the boot process completes)
I suspect that there might be some actual trouble with entering the failsafe with MT6000. Possibly introduced in the last few months?
Has anybody with MT6000 running a current master snapshot been able to enter OpenWrt failsafe mode recently ?
(Ps. I recovered via the OEM recovery flash mode)
1 Like
no problems here. Running OpenWrt SNAPSHOT r26086, but I had it self compiled
edit: forgot to mention that I’m on 6.6.28 kernel
Seems like something strange there.
I have intermittent trouble getting into failsafe mode.
I tested several times.
Most times the entrance trigger fails, but it seemed to succeed once (based on rapid LEDs, but I didn't actually try the failsafe console)
(self-built r26128-9e86e0b33b with normal kernel 6.1)
I can reproduce.
My GL-MT6000 is on a little bit more than a week old OpenWrt SNAPSHOT, r25996-e0363233c9 build.
Does anyone else encounter sporadic switch breakage?
Once every 1-2 weeks, the machines plugged into the ports say the network cable is unplugged, and the only way to recover is rebooting (either via wifi, or power cycling).
There are no new entries in the system or kernel log at all, but both WAN (one 2.5G ONT, using PPPoE, plugged into the 1st port) and LAN (two 1G machines, plugged into the 1G ports) becomes unreachable, even though OpenWrt shows the interfaces as up (and restarting the interfaces succeeds, but doesn't change anything). I tried disabling HW acceleration when the issue happened, but it also didn't change anything. I've been having this issue since day one (never tested stock, I flashed OpenWrt snapshot right away in early January, and updated it every now and then).
I just updated from the 04/08 snapshot to today's one, and left HW acceleration disabled. If it happens again, any idea how could I troubleshoot it?
I just set up my new MT6000. The 2.5 Gbit/s port looks great and I got 2.35 Gbits/sec via iperf3. However, the wireless connection seems to be unreliable. Sometimes it gets around 100 Mbits/s and sometimes only around 2 Mbits/sec. I've followed the dump AP mode setup and activated WED as described in the wiki. Has anyone had similar experiences or suggestions on how to fix this?
Hi Chris,
it might be worth opening a separate topic in the "Installing and Using..." section for your problem.
In general the WiFi on the MT6000 is pretty reliable.
2 Likes
Have you tried disabling WED? While it usually worked great, sometimes I had huge packet losses and extremely slow speeds.
I suspect it's because of the lack of AQL support with WED. The channels are very crowded in my apartment. However, since disabling WED, it's been rock stable. It actually seems unnecessary on MT6000, unless you want to use the CPU for something else. iperf3 still reaches 1.5 Gbps without WED (over 160 MHz), with CPU usage barely reaching 50%. So, no reason to rely on an outdated proprietary firmware for handling Wi-Fi traffic.
1 Like
Today I got some other 2.5 gigabit hardware up and running; this is going from librespeed-go on the GL-MT6000 to my laptop via a 2.5g switch and then a 2.5g USB dongle:
I'm very happy with the performance of the MT6000
13 Likes
I think kernel 6.6 is now default in snapshot builds. Not currently home so can't verify right now.
Make sure you are getting r26161-3f7d8e20cd or newer.
The 3f7d8e20cd corresponds to the commit hash in git and this is about 4 commits after MediaTek moved to 6.6.
See:
https://github.com/openwrt/openwrt/commits/main/ (commit hashes on right)
And this one on May 4th.
4 Likes
Yep i flashed new snapshot earlier and 6.6 is default.
4 Likes