I'm running an TP-Link Archer C7 v2 with OpenWrt 18.06.4, r7808-ef686b7292.
After a few days (random) I cannot get past 90-95 mbit.
So when I transfer data from one machine to the other, or use the internet it limits at 95mbit max.
I have run iPerf3 between my MacBook and Desktop, same results. This is done with a cable connection but also wireless.
After I reboot the Archer everything is back to normal and I'm getting 900+ mbit with iPerf3 (local).
What could be the problem?
“900 Mbps” tells me this is purely a switch issue. Likely it is renegotiating to 100BASE-T. Check your cabling and potentially the jacks in the Archer C7v2
When doing iPerf3 (after the reboot) it's hitting the 940-950 mbit, so that's around 1 gigabit.
It sounds plausible that the switch is turned back to 100base-t.
Though the Archer sits in a cabinet without anyone touching it. Plus after a reboot it works on 1000base-t again so I don't know if that could be the problem.
But of course I'll have a look once the problem occurs again.
You can use luci to check switch port speeds or the following command
swconfig dev switch0 show|grep speed
At the moment they are 1000BaseT.
But of course I have rebooted the Archer this morning due to the problems.
So I'll check again once the problem arrives again.
Ok, the problem just happened again.
After checking the port speeds I can see that 1 port is back at 100BaseT instead of 1000BaseT.
Thats clarifies why I'm only hitting around 90-95 mbit.
But the OpenWrt device and the device on the other end of the cable or in a closet and are never touched. So I don't have a clue why it's happening....
Could be a faulty cable. You can test that with a lan tester.
Otherwise the port might be faulty. Try the cable on another port on both devices.
Thought so... I tried a LAN cable tester. It's a cheap one but all 8 + G did blink correctly, at the same time. Did test for minutes (not only 1 run).
I will try another port and see how it goes.
The strange part of this whole story is that it happens only after days of use and when you unplug and plug the cable back the issue is gone.
Keep you posted!
Are you using Cat5E cable or higher.
How long is the cable.
Cable is 20 meter. It's a CAT6 shielded cable.
The tester, I have to check. It has 9 lights (8 + G) which light up if they are correctly matched.
I have a modem here, when it is "overheating", it throttles down the Ethernet ports to 100 Mbit\s.
Was a bit annoying in the summer 
What device is connected to the " faulty" port?
Is it a desktop? Maybe check for energy saving settings in the Ethernet controller settings.
It's a TP-Link TL-SG108E v2.0 switch.
All the other ports on the TL-SG108E and on the Archer C7 (OpenWrt) are still 1000BaseT when the problem occurs. It's just this one port...
So it could be the Archer, the TL-SG108E or the cable that has problems.
I switch the Archer out for a different one (I have 2 of them) and am testing it now.
But like I said before it happens irregularly and sometime after 10 - 14 days...
So I'll have to wait.
Did you check the pins in the Ethernet ports?
I once bought some cat6 cables that fit a bit to tight in the ports and broke one pin.
The switch also has the ability to test the connection quality.
I will have a look at the pins once I get back. Thanks for the heads up!
At the moment the connection with the cable = Normal
Cable Fault Distance(m) = 1m
Other ports have 1 meter as well. I don't know what that means though..
Will do a check whenever the problem occurs again as well.
Is this from the Cable Test?
Cable Fault Distance (m)
If the connection status is short, close (or short) or crosstalk, here displays
the length from the port to the trouble spot.
It doesn't mention "normal" status, maybe it displays the estimated cable length.
Are any bad packets logged in the Port Statistics overview?
Yes, it's from the Cable Test within the TL-SG108E.
This is from the official user guide.
Test results:
Displays the connection status of the cable connected to the port.
The test results of the cable include “No Cable”, “Open”,
“Short”, ”Open Short”, “Normal”, “Cro Cable” and “others”.
Cable Fault
Distance(m):
Displays the error length (in meters) of the cable
Yes, there are bad packages...
But only: RxBadPkt
I've read a lot people have the same bad packets with this model switch.
Though it seems harmless.
From that link:
I asked tp-link for this problem some months ago.My model number is 108E V2. They said need not worry about this, This is the Statistical mechanism of chipset.
If the packet size is 64Byte, if this packet is untag, this packet is RxGoodPkt. If this packet is tagged, this packet is RxGoodPkt and Rx Bad Pkt.
In a word, every tagged packets, if the size is 64byte, will be be identified as bad packet.
Do you use tagging?
Yes, I use VLAN tagging.
I have 5 VLAN's (vlan 20, 30, 40, 50 and 60). They are all tagged on that port.
Quick draw of my network layout (not my full network):
I also use a TP-Link switch with this cable testing option and I cannot say it is very accurate. Better try a different cable if you cannot get ahold of a proper cable tester.
Last but not least, try a different port. In the same switch I recently experienced bizarre behavior which eventually was solved by moving the device to a different port.
Thanks @trendy
Running a new cable is the last thing I want to do because the cable is 20 meters long and goes under the floor. So it's a last resort. 
I have switch the Archer C7 (OpenWrt) with another Archer C7 (I have 2) and will check if that fixes the problem. If not I will try another port on the TP-Link switch.
