Netgear GS110 auto-DOS drops port of OpenWrt WR1043ND device

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

???

  • Is this OpenWrt-related?
  • A simple web search of "auto-DOS feature" shows many network problems with this, none seem related to OpenWrt.

Unmanaged...with VLANs???

:confused:

So is it managed or unmanged???

(Please show the switch config.)

1 Like

I had to do this way, because with routing i had only problems.

In any case, the problem seems to be a huawei phone connected via the wifi (can't confirm 100% yet still testing). I am not sure if it is the end device, or the tplink itself that causes the problem.

In any case, the netgear auto-ds function seems very sensitive to invalid packets (or maybe there is malware on the device?)

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'xxxx:xxxx:xxxx::/48'

config interface 'lan'
        option type 'bridge'
        option ifname 'eth1.1'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        list dns '192.168.100.1'
        option gateway '192.168.100.1'
        option delegate '0'
        option force_link '0'
        option stp '1'
        option ipaddr '192.168.100.100'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option vid '1'
        option ports '0t 5 6t'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option vid '10'
        option ports '0t 2 3 4 5t'

config switch_vlan
        option device 'switch0'
        option vlan '3'
        option vid '60'
        option ports '0t 5t'

config switch_vlan
        option device 'switch0'
        option vlan '4'
        option vid '70'
        option ports '0t 1 5t' 

config switch_vlan
        option device 'switch0'
        option vlan '5'
        option vid '80'
        option ports '0t 5t'
        
config interface 'LAN10'
        option proto 'none'
        option igmp_snooping '1'
        option ifname 'eth1.10'
        option stp '1'
        option delegate '0'
        option type 'bridge'

config interface 'WLAN0'
        option proto 'none'
        option type 'bridge'
        option igmp_snooping '1'
        option delegate '0'
        option ifname 'eth1.60'

config interface 'WLAN1'
        option proto 'none'
        option type 'bridge'
        option ifname 'eth1.70'
        option delegate '0'

config interface 'WLAN2'
        option delegate '0'
        option type 'bridge'
        option proto 'none'
        option ifname 'eth1.80'

So this isn't OpenWrt-related?

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 

does the manual have something to say about those? Perhaps "using port 2049" is considered a DOS?

"Denial of Service UDP Port. Enabling UDP Port DoS prevention causes the switch to drop packets for which the UDP source port is equal to the UDP destination port." - same for TCP.

NFS uses the source and destination as 2049 right?

exactly. I would disable that.

Also there are PLENTY of legit reasons for that kind of traffic, for example maybe an RTP session (SIP audio) or a game... that should never have been included in the software in the first place IMHO.

so i should try that for both UDP and TCP or just one?

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.

1 Like

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.

so i had to disable auto-ds functionality for the time being, and i setup suricata and one thing i am seeing in relation to NFS is;

TCP Generic Protocol Command Decode nas 2049 client 798 1:2223001
SURICATA NFS malformed response data

TCP Generic Protocol Command Decode client 798 nas 2049 1:2223000
SURICATA NFS malformed request data

it seems the 798 port here is being random rather than fixed

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?

To be clear/just curious...this auto-DOS feature is or isn't an OpenWrt feature?

I'm kinda lost:

  • Where is the feature located?
  • Why did you enable it?

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.

1 Like

auto-dos is a netgear switch feature.

1 Like