[Solved] ZTE MF286D eth strange behavior

Using 286D with OpenWRT installed, works fine, except ethernet problem.

All ports work fine, ping to router has 0% errors.

Ping between PCs (through MF286D router) works with errors. Sometimes less, sometimes even more than 90% of pings are failed. At the same time pings to MF286D are fine.

AFAIK this router has a built-in hardware bridge. How can I check it? Or just try to disable this module to check whether it fails on not.

You have 2 PCs that you're testing with and the 286D. Are both PCs directly connected to the 286D?

What happens if you setup simultaneous persistent pings from the PCs to the router (so both PCs are pinging the router at the same time)... do all the pings succeed? Do some fail? If some fail, is it always from one PC or the other, or does it happen to both?

1 Like

Yes, two PCs are connected to MF286D. And one laptop through wifi.

All 3 devices ping router well. Laptop pings both PCs well without errors.

PCs can't ping each other! Looks like harware switch (bridge) is broken. :frowning:

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall
# ubus call system board
	"kernel": "6.1.63",
	"hostname": "OpenWrt-mf286d",
	"system": "ARMv7 Processor rev 5 (v7l)",
	"model": "ZTE MF286D",
	"board_name": "zte,mf286d",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "SNAPSHOT",
		"revision": "r24538-73410e2aa0",
		"target": "ipq40xx/generic",
		"description": "OpenWrt SNAPSHOT r24538-73410e2aa0"
# cat /etc/config/network

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr ''
	option netmask ''

config globals 'globals'
	option ula_prefix 'auto'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'wan'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'

config interface 'lan'
	option device 'br-lan'
	option proto 'dhcp'

config interface 'lan6'
	option proto 'dhcpv6'
	option device '@lan'

#config interface 'lte'
#        option proto 'qmi'
#        option device '/dev/cdc-wdm0'
#        option pdptype 'IPV4V6'
#        option apn 'internet'
#        option ipv6 'auto'
# cat /etc/config/firewall

config defaults
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'

DHCP is disabled, Wi-fi is configured (works fine, but contains sensitive data)

Have you tried using a stable release build?

No, I didn't. :frowning_face:

Do you think this will solve the problem? Looks like hardware problem, but how can I check it?

Start by using a stable release. We will try to narrow down the potential issues.

Can you help me to detect where the packets are lost? And how does the switch inside OpenWrt work?

It does not look like a bug of unstable release, it looks like my hardware bug or a kernel driver bug.

What do I mean. May be you can tell witch kernel modules are responsile for harware switch? How can I disable some features and test?

The switch is a specific chip inside the device that connects to all the lan ports. It is configured by OpenWrt, but then basically runs standalone, forwarding traffic between ports (or the CPU/routing engine) as needed.

There are lots of possible reasons that a switch could act up -- it could be misconfigured, there could be problematic devices connected downstream (yes, this can disrupt switch behavior), switching loops, or hardware failures.

Did you try a stable release?

No, I didn't find any stable(!) releases for MF286D. But I want to fix this bug myself.

How can I disable hardware switch and test it's configuration? May be it is possible to enable debug mode or params?

Another reason why I don't want to try any other releases is that I replaced QCA chip (the old one was broken and the network did not start at all). After soldering new chip I have git network, tested all ports (1000 Mb each), but now have this strange bug with traffic between ports.

Seems pretty easy to locate using the firmware selector:

Sometimes, snapshots can have odd bugs due to the fact that they are changing all the time (they're daily builds) and they don't get nearly as much testing. Typically stable releases, while they may still have bugs, are less likely to have random issues that may appear in one and not in another.

When you say you want to fix it yourself, I'm not sure what that means -- if the problem is due to something wrong with the snapshot you're using, there's nothing you can do to fix it aside from flashing a different version.

I'm not sure what you would expect to do here, but no, it's not really practical to do this. Maybe if you build your own source code, you could actively disable the switch, but then you'd be unable to connect to the device.

??? Did you replace it with an identical chip?

Well, it's hard to know your issue is software or hardware based, but working with a proper release build will reduce the likelihood of it being a software issue.

Yes, I replaces with exactly the same chip. It works, all ports work.

I can't upgrade this device, because it requires UART access, it could not be upgraded with sysupgrade. And another reason is that I need it working at the moment. :slight_smile:

Can you give me any docs to read? It have to be configurable, IMHO.

I've not seen this type of behavior.

login to your router via ssh and do the following:

cd /tmp
wget https://downloads.openwrt.org/releases/23.05.3/targets/ipq40xx/generic/openwrt-23.05.3-ipq40xx-generic-zte_mf286d-squashfs-sysupgrade.bin
sysupgrade -n /tmp/openwrt-23.05.3-ipq40xx-generic-zte_mf286d-squashfs-sysupgrade.bin

This should reset the device to defaults while flashing 23.05.3. Show us the output of this.

Of course, at last will upgrade OpenWRT, but I don't want to do it now.

There is a /sys folder of switch: /sys/devices/platform/soc/c000000.switch/, but nothing interesting is located there.

I'm not sure what you're expecting to happen if you don't try to follow the guidance I'm providing.

This isn't going to help you.

Ok, now will test :slight_smile:

I didn't want to upgrade, because I can brick the device and then have to format ubi partitions again.

Ok, upgraded, now will test.

I upgraded and tested. I'm crazy, because it WORKS. It works fine.

Sorry for disturbing. It was really the easiest way just to upgrade to release version.

Sorry for wasting your time. :frowning:

That is why it was my first suggestion.

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
Thanks! :slight_smile: