I have a TPLink WR1043ND device with openwrt as a unmanaged switch with VLANs.
It is connected to a netgear GS110TPP managed switch.
There is a separate vlan for wifi and wifi-guest and the four switch ports are on a separate vlan with the wan port on the mgmt lan.
The auto-DOS feature keeps shutting down the port that connects the WR1043ND. But only shows the log message it is shutdown because of a dos attack from the wr1043ND.
My question is, how can i find the client device that is causing it?
I have two other TPLINKs with the same config and it is not happening to them,
so it has to be a client on my failing one that is causing it.
I placed the linux and win PCs directly on the GS110TPP and the port is still being shutdown, so it is either the TPLink device itself, or one of the WiFi clients that is triggering the DOS shutdown. Appreciate some ideals on how i can find each wifi client it is
Well since the tp-link device is running OpenWrt, then its OpenWrt related. But @GwaiTsi it sounds more likely that your Huwei phone is part of a botnet or that the auto-DOS prevention is not very good than that the OpenWrt device is the problem. Try wiresharking the traffic and see what's happening right before the port is shut down
Putting the Huawei phone aside for a second, I had a Kubuntu PC and Windows PC connected to the lan ports on the TP Link, I moved them off and directly onto the netgear for the time being.
The Kubuntu port was shutting down the Netgear Port as soon as i use the Dolphin File Manager to access NFSv4 mounted directories. So long as i don't try to access NFS it is works fine.
You could be right about the Huawei, but it have it off for now until i can ensure no other devices are triggering the problem. For the Kubuntu PC, i have temporarily turned of auto-ds and it works fine with NFS. Obviously, this is more likely to be something to do with the packets from the PC but i don't know enough about how to get to the bottom of this.
Interesting. I'm guessing this is just failure of the AutoDOS protection. NFSv4 is a legit protocol in use by a lot of people, but not at all common on MS Windows networks for example. The switch probably is pretty dumb about it. Does it have "tunables" you can tell it to ignore port 2049 TCP and UDP for DOS purposes? Because I imagine grabbing a big file off the file server looks like a gigabit of data stream and if it's not in the Auto DOS thing as a legit protocol, then it's probably flagged for "what the hell are you doing with a full gigabit of traffic on this port?"
The settings available for the auto-DoS are: (default all enabled)
Denial of Service Min TCP Header Size (0 to 31)
Denial of Service Max ICMP Packet Size (0 to 16376)
Denial of Service ICMPv4 Disable Enable
Denial of Service ICMPv6 Disable Enable
Denial of Service Ping of Death Disable Enable
Denial of Service IPv6 Fragment Disable Enable
Denial of Service ICMP Fragment Disable Enable
Denial of Service Smurf Disable Enable
Denial of Service SIP=DIP Disable Enable
Denial of Service SMAC=DMAC Disable Enable
Denial of Service TCP FIN&URG&PSH Disable Enable
Denial of Service TCP Flag&Sequence Disable Enable
Denial of Service TCP Fragment Disable Enable
Denial of Service TCP Offset Disable Enable
Denial of Service TCP Port Disable Enable
Denial of Service TCP Source Port Disable Enable
Denial of Service TCP SYN&FIN Disable Enable
Denial of Service TCP SYN&RST Disable Enable
Denial of Service UDP Port Disable Enable
I would disable that broken feature for both UDP and TCP it's not protecting you from anything, and in fact the manual says its by default supposed to be disabled.
from the manual:
Denial of Service L4 Port. Enable or disable this option by selecting the appropriate radio button. Enabling L4 Port DoS prevention causes the switch to drop packets that have TCP/UDP source port equal to TCP/UDP destination port. The factory default is Disable.
ok. for some reason the gs108t had the default settings with tcp/udp disabled but the gs110tpp had them enabled. That seems to have fixed the Kubantu causing it and i know it is not the Huawei phone as it was turned off and my other umidigi phone was with me when the GS108T Lagg ports shutdown.
Port 4 below is connected to the other TP Link WDR1043 which has 2x win10pcs and and a KodiBox and an LG TV connected. So i can be sure if it the Umidigi phone or one of the other devices.
Interestingly, the error seems to be port4 but the lagg ports are shutdown. I have turned to DoS off on the GS108T while i tried to figure out if the phone/s are causing it on the GS110TPP.
180>1 2021-01-12T19:06:33.176+1:00Z 192.168.x.x-1 PORT-4-ERR_DISABLE rsd_port.c(950) %% dos error detected on GigabitEthernet8, putting GigabitEthernet8 in err-disable state
<179>1 2021-01-12T19:06:33.176+1:00Z 192.168.x.x-1 SYSTEM-3 %% Interface GigabitEthernet8 has been shutdown by DOS attack notification.
<180>1 2021-01-12T19:06:32.006+1:00Z 192.168.x.x-1 PORT-4-ERR_DISABLE rsd_port.c(950) %% dos error detected on GigabitEthernet7, putting GigabitEthernet7 in err-disable state
<179>1 2021-01-12T19:06:32.006+1:00Z 192.168.x.x-1 SYSTEM-3 %% Interface GigabitEthernet7 has been shutdown by DOS attack notification.
Hmm... yeah, that's right. My linux desktop also uses some random low numbered port for communicating to my NFS4 server... in my case when I wireshark now it's 988 -> 2049
I don't know why the malformed response data stuff, you should ask the suricata people.
I'm intrigued by suricata, how are you setting it up? Using a port-mirror? With NFS traffic, I assume it's probably more traffic through your switch than one port could mirror, so perhaps suricata is only seeing part of the conversation and getting confused?
It's a feature on his netgear switch. Comes enabled by default, and started being triggered on the port where his OpenWrt access point was connected so he was trying to figure out whether it was caused by the access point or a client of the access point.