I own a D-Link DIR-860L, running:
# cat /etc/openwrt_release DISTRIB_ID='OpenWrt' DISTRIB_RELEASE='19.07.4' DISTRIB_REVISION='r11208-ce6496d796' DISTRIB_TARGET='ramips/mt7621' DISTRIB_ARCH='mipsel_24kc' DISTRIB_DESCRIPTION='OpenWrt 19.07.4 r11208-ce6496d796' DISTRIB_TAINTS=''
and experiencing some peculiar disconnects on LAN.
After flashing OpenWrt 19.07.4 clean and doing the basic setup, I noticed in the log random disconnects on the LAN side. Worth mentioning that I'm only using 100Mbit ethernet adapters.
The log records are in the form:
mtk_soc_eth 1e100000.ethernet eth0: port x link down mtk_soc_eth 1e100000.ethernet eth0: port x link up
The port order on this router looks messed up and I couldn't yet figure out which physical port belongs to which port number. All 4 LAN ports are used and I was able to identify the port for the laptop system I'm using on my desk because it has a different cable color. It's plugged in port 1 (router) and looks like port 4 in OpenWRT. Apparently, port 3 on router is actually port 2 in OpenWRT and is connected to a cheap Gembird USB 100Mbit NIC feeding a Raspberry Pi Zero.
Now the peculiarities:
- The port 1 (router) - port 4 (OpenWRT) got disconnected many times, sometimes even after a few minutes - 10-20, for no apparent reason. One scenario I was almost always able to reproduce was to bounce the pppoe interface - like in this snippet:
Sat Oct 24 18:17:02 2020 user.notice firewall: Reloading firewall due to ifup of wan (pppoe-wan) Sat Oct 24 18:25:41 2020 kern.info kernel: [ 1005.881400] mtk_soc_eth 1e100000.ethernet eth0: port 4 link down Sat Oct 24 18:25:44 2020 kern.info kernel: [ 1008.340405] mtk_soc_eth 1e100000.ethernet eth0: port 4 link up
- If I disconnected/reconnected the Raspberry Pi Zero (at the source - not touching the router) - port 3 (router) - port 2 (OpenWRT), that would usually bounce port 1 (router) - port 4 (OpenWRT) too.
Sat Oct 24 17:37:32 2020 kern.info kernel: [59968.686679] mtk_soc_eth 1e100000.ethernet eth0: port 2 link down Sat Oct 24 17:37:37 2020 kern.info kernel: [59973.079235] mtk_soc_eth 1e100000.ethernet eth0: port 2 link up Sat Oct 24 17:56:26 2020 kern.info kernel: [61102.245327] mtk_soc_eth 1e100000.ethernet eth0: port 4 link down Sat Oct 24 17:56:30 2020 kern.info kernel: [61106.337661] mtk_soc_eth 1e100000.ethernet eth0: port 4 link up
I tried disabling the VLAN functionality and that didn't help. Went on and disabled "Force link" on the LAN interface and that seemed to calm down the random disconnects + the pppoe induced ones + the Raspberry Pi Zero induced ones.
Still - port 1 (router) - port 4 (OpenWRT), the desktop system, would loose connectivity randomly with no "mtk_soc_eth 1e100000.ethernet eth0" log records.
Last try - I own a spare (new) Gembird USB 100Mbit NIC and swapped it on the Raspberry Pi Zero board. It's some hours now I couldn't notice any disconnects (including not logged ones).
And .. I have two theories:
the old Gembird USB 100Mbit NIC is faulty and might have injected some noise in the Ethernet Transformer on the router PCB. Could be that the coils for the ports 2 & 4 (OpenWRT) are adjacent and can influence each other. But this doesn't explain the pppoe bouncing induced disconnection on port 4 (OpenWRT).
stumbled upon the following unresolved issues with the mt7621 driver:
Wondering if what I was experiencing (maybe still am - not yet sure it's all fine now) is related to these driver issues.
I have experience with other 2 such D-Link DIR-860L routers, one running OpenWRT 18.x and the other one 19.07.3, but both are connected on only one LAN port to a Gigabit Switch and I never noticed such strange disconnects.
I'm also not sure I understand what force_link really means for the issue I'm reporting and if it did help somehow deactivating it. This isn't really helpful - LAN interface is by default brought up at boot:
force_link boolean no 1 for protocol static, else 0 Specifies whether ip address, route, and optionally gateway are assigned to the interface regardless of the link being active ('1') or only after the link has become active ('0'); when set to '1', carrier sense events do not invoke hotplug handlers
Any help appreciated.