Random disconnects on br-lan eth0 port 1

With the latest stable LEDE on a Trendnet TEW-732-BR (ath9xxx) my workstation randomly disconnects. I've tried new cables and using a 100baseTX pci card in lieu of the onboard NIC, but I'm still getting random drops Some days the system runs all day without a disconnect. eth0 is configured as a static address.

My logs show a disconnect message and multiple entries of RA lifetime of 0 seconds

Sun May 21 17:33:54 2017 daemon.info odhcpd[693]: Using a RA lifetime of 0 seconds on br-lan
Sun May 21 17:39:15 2017 daemon.info odhcpd[693]: Using a RA lifetime of 0 seconds on br-lan
Sun May 21 17:43:23 2017 daemon.info odhcpd[693]: Using a RA lifetime of 0 seconds on br-lan
Sun May 21 17:51:11 2017 daemon.info odhcpd[693]: Using a RA lifetime of 0 seconds on br-lan
Sun May 21 17:56:59 2017 daemon.info odhcpd[693]: Using a RA lifetime of 0 seconds on br-lan
Sun May 21 18:03:55 2017 kern.info kernel: [1494523.422402] eth0: link down
Sun May 21 18:03:55 2017 kern.info kernel: [1494523.425896] br-lan: port 1(eth0) entered disabled state
Sun May 21 18:03:55 2017 daemon.notice netifd: Network device 'eth0' link is down
Sun May 21 18:04:14 2017 daemon.info odhcpd[693]: Using a RA lifetime of 0 seconds on br-lan
Sun May 21 18:11:44 2017 kern.info kernel: [1494992.418825] eth0: link up (1000Mbps/Full duplex)
Sun May 21 18:11:44 2017 kern.info kernel: [1494992.423865] br-lan: port 1(eth0) entered forwarding state
Sun May 21 18:11:44 2017 kern.info kernel: [1494992.429720] br-lan: port 1(eth0) entered forwarding state
Sun May 21 18:11:44 2017 daemon.notice netifd: Network device 'eth0' link is up
Sun May 21 18:11:46 2017 kern.info kernel: [1494994.427066] br-lan: port 1(eth0) entered forwarding state
Sun May 21 18:11:47 2017 kern.info kernel: [1494995.917699] eth0: link down
Sun May 21 18:11:47 2017 kern.info kernel: [1494995.921198] br-lan: port 1(eth0) entered disabled state
Sun May 21 18:11:47 2017 daemon.notice netifd: Network device 'eth0' link is down
Sun May 21 18:13:24 2017 kern.info kernel: [1495092.417830] eth0: link up (1000Mbps/Full duplex)
Sun May 21 18:13:24 2017 kern.info kernel: [1495092.422845] br-lan: port 1(eth0) entered forwarding state
Sun May 21 18:13:24 2017 kern.info kernel: [1495092.428704] br-lan: port 1(eth0) entered forwarding state
Sun May 21 18:13:24 2017 daemon.notice netifd: Network device 'eth0' link is up
Sun May 21 18:13:26 2017 kern.info kernel: [1495094.426065] br-lan: port 1(eth0) entered forwarding state
Sun May 21 18:13:40 2017 kern.info kernel: [1495108.916570] eth0: link down
Sun May 21 18:13:40 2017 kern.info kernel: [1495108.920066] br-lan: port 1(eth0) entered disabled state
Sun May 21 18:13:40 2017 daemon.notice netifd: Network device 'eth0' link is down
Sun May 21 18:13:42 2017 kern.info kernel: [1495110.417644] eth0: link up (1000Mbps/Full duplex)
Sun May 21 18:13:42 2017 kern.info kernel: [1495110.422661] br-lan: port 1(eth0) entered forwarding state
Sun May 21 18:13:42 2017 kern.info kernel: [1495110.428524] br-lan: port 1(eth0) entered forwarding state
Sun May 21 18:13:42 2017 daemon.notice netifd: Network device 'eth0' link is up
Sun May 21 18:13:44 2017 kern.info kernel: [1495112.425885] br-lan: port 1(eth0) entered forwarding state
Sun May 21 18:13:47 2017 daemon.info odhcpd[693]: Using a RA lifetime of 0 seconds on br-lan
Sun May 21 18:16:29 2017 kern.info kernel: [1495277.914873] eth0: link down
Sun May 21 18:16:29 2017 kern.info kernel: [1495277.918374] br-lan: port 1(eth0) entered disabled state
Sun May 21 18:16:29 2017 daemon.notice netifd: Network device 'eth0' link is down
Sun May 21 18:16:31 2017 kern.info kernel: [1495279.415953] eth0: link up (1000Mbps/Full duplex)
Sun May 21 18:16:31 2017 kern.info kernel: [1495279.420974] br-lan: port 1(eth0) entered forwarding state
Sun May 21 18:16:31 2017 kern.info kernel: [1495279.426835] br-lan: port 1(eth0) entered forwarding state
Sun May 21 18:16:31 2017 daemon.notice netifd: Network device 'eth0' link is up
Sun May 21 18:16:33 2017 kern.info kernel: [1495281.424190] br-lan: port 1(eth0) entered forwarding state
Sun May 21 18:16:43 2017 kern.info kernel: [1495291.914741] eth0: link down
Sun May 21 18:16:43 2017 kern.info kernel: [1495291.918260] br-lan: port 1(eth0) entered disabled state
Sun May 21 18:16:43 2017 daemon.notice netifd: Network device 'eth0' link is down
Sun May 21 18:16:45 2017 kern.info kernel: [1495293.415839] eth0: link up (1000Mbps/Full duplex)
Sun May 21 18:16:45 2017 kern.info kernel: [1495293.420857] br-lan: port 1(eth0) entered forwarding state
Sun May 21 18:16:45 2017 kern.info kernel: [1495293.426727] br-lan: port 1(eth0) entered forwarding state
Sun May 21 18:16:45 2017 daemon.notice netifd: Network device 'eth0' link is up
Sun May 21 18:16:47 2017 kern.info kernel: [1495295.424050] br-lan: port 1(eth0) entered forwarding state
Sun May 21 18:18:37 2017 kern.info kernel: [1495405.413597] eth0: link down
Sun May 21 18:18:37 2017 kern.info kernel: [1495405.417109] br-lan: port 1(eth0) entered disabled state
Sun May 21 18:18:37 2017 daemon.notice netifd: Network device 'eth0' link is down
Sun May 21 18:18:38 2017 kern.info kernel: [1495406.914671] eth0: link up (1000Mbps/Full duplex)
Sun May 21 18:18:38 2017 kern.info kernel: [1495406.919694] br-lan: port 1(eth0) entered forwarding state
Sun May 21 18:18:38 2017 kern.info kernel: [1495406.925556] br-lan: port 1(eth0) entered forwarding state
Sun May 21 18:18:38 2017 daemon.notice netifd: Network device 'eth0' link is up
Sun May 21 18:18:40 2017 kern.info kernel: [1495408.922915] br-lan: port 1(eth0) entered forwarding state
Sun May 21 18:23:24 2017 daemon.info odhcpd[693]: Using a RA lifetime of 0 seconds on br-lan
Do I need to lenthen the RA lifetime?  Anything else I should look at?

Thanks

Sounds familiar?
LAN stops working every now and then

Thanks for the reply.

What is different about my setup is that my devices on Wired interfaces all have static addresses.
If my configuration is correct, this suggests that the issue may not be dhcp related.

My ISP is PPPoE and I have seen discussions (windows 7)that random disconnects can be fixed with an mtu setting of 1492. I have set both my clients and routers to have an mtu of 1492.

There is also issues with other 1000baseT drivers (realtek in debian) where the "free driver" also randomly disconnects.

I was interested in setting my router ethernet to use 100BaseTX or to increase the RA lifetime. Anyone know where to do this in luci or the command line?

Just to be sure I don't think my problems are DHCP related also. If you read the whole thread you'll notice someone else with the same issue that has the whole DHCP service disabled.

During the disconnects, do you have internet connection on your router? Can you ping 8.8.8.8 after logging though SSH to your router?

I am unable to ping the router itself (192.168.2.1). I am on OpenBSD and with netsurf, when the connection is not responsive, the browser window will not open. If I > ifconfig re0 down and then restart the network, the netsurf-gtk process will proceed, open a window and render my home page.

I have had other instances where the the workstation router link seems down and when I start interrogating, the browser window starts after a minute or two. I'm wondering about a watchdog timeout or a connection renewal?

I'm not sure if I understand correctly but you are saying that during the disconnect, you can't ping the router from OpenBSD and when you restart the network on OpenBSD the issue is resolved?

In that case I don't think there is a problem with your LEDE installation. It looks more like a problem with your OpenBSD system. Next time this happens to you can you use another device to connect (using for example WiFi) and check if the Internet is working?

I'll try a wireless/dhcp connection the next episode and report back. I also did not have the problem with the latest OpenWRT release. I was running a dual boot Debian/OpenBSD system and same hardware in Debian would also loose the connection.

Since a connection requires both a server and a client, I'm not going to rule out the router.

Just in case it helps someone, I found similar issues on other distros and I also have this very issue on Alpine Linux with desktop hardware and a LAN bridge on it.