Hi  @Virgo 

it's like when the engine light comes on in the car, maybe you should stop straight away and call a towie, or maybe no worries light is faulty.

from Google 

TCP Null Attack

In case of TCP Null Attack, the victim server gets packets with null parameters in the ‘flag’ field of the TCP header, i.e. none of the 6 TCP flags (URG, ACK, PSH, RST, SYN, FIN) is set. As a rule, packets of this kind are used to scan the server’s ports before a large-scale attack.

 

I tried searching for all 6 flags set to 0, also nothing captured in wireshark.

Given it seems to be happening regular 10 minutes im looking at the 600 second state timeout setting and will adjust that to see if the logging regularity also changes.

I'd feel better if I knew it was a false positive or that if it was an attack I could do something before it escalates.

  @Lurk  "and dropped 8 packets"  , maybe it has made relatively good protection.

Hi  @HelsingL ,

It's possible the alerts are indicating the router is blocking something useful. 

The Block Large pings though seemed to be blocking LAN side traffic going to the WAN from apple devices, so theoretically valid traffic, which may or may not have caused one or more of the apple devices some delay doing something that it does. 

I tried to find out through Tp-link what triggers the different alerts but I couldn't get that info. I wasn't able to identify or reproduce packets causing the alerts given the criteria they gave me.

Another thing I noticed with the alerts, I setup a large ping that fires once every minute from the LAN (1000 bytes)  to google and every 10 minutes the router reported dropping 10 packets, so it saved up alerts and logged them every 10 minutes and not when it occurred. I used PingInfoView from Nirsoft to do that ping thing.

So given I can't find the packets that are causing the alerts and they don't match the description provided by tp-link about the TCP Header fields, then I think it isn't doing much useful except spamming the log. But what I do know now is that the time the alert is logged, is not necessary when the packet was sent. It saves up alerts and logs every 10 minutes.

The truth is out there somewhere....but for now my logs are spammed.

 

  @Lurk 

maybe it's better to report here

Additional Tips For Reporting Security Issues: 

At TP-Link, customer security comes first. To report Security Issues regarding TP-Link products, please follow the situation below and submit the feedback from HERE.

• (1) To submit security-related inquiries, click Contact Technical Support  where our support engineers will help look into your concerns personally and assist in the first time.

• (2) To report Product Security or Vulnerability issues, click  Submit Security Feedback  where your information will be handled by our network security engineers, and you can expect a reply in 1-3 business days.

Hi  @nurix 

I tried logging an incident with support

Hello and thank you for contacting TP-Link support.

Basically there are 3 kinds of reports would trigger the report with detected TCP no-Flag attack:
1. Report with FIN mark only  
2. Report with FIN, URG, and PSH at the same time
3. Report without any TCP mark

Large ping attack happens when the gateway detects the packets over 1024 Byte, and some of them are normal if they do not affect the use of network.
If the reports with large ping attack did not influence your network, then you can just ignore it and pay attention to our website with newer firmware later which would add the feature to adjust the packet size and detect the origin of the large ping.


So I tested the three options

I applied the three filters you suggested to the wireshark trace with the no-Flag alerts.

  1.Report with FIN mark only

tcp.flags == 0x001

0 0 0 0  0 0 0 1


2. Report with FIN, URG, and PSH at the same time

tcp.flags == 0x029

 

0 0 1 0  1 0 0 1

3. Report without any TCP flags set

tcp.flags == 0x000

0 0 0 0  0 0 0 0

((tcp.flags == 0x000 ) || (tcp.flags == 0x001) || (tcp.flags == 0x029))

No packets in were returned when I applied the filter to the capture.
 

And what say support?

a) Is your network affected, and b) a firmware update is coming.

So I'm sort of done with support for now.

  @Lurk 

So, prior to the last firmware update I took on my ER605 Router, I could not tell what "Large Pings" were coming from. Now that I can see the IPs that has revealed that ALL of my Roku devices are the source of friendly fire. Which is somewhat relieving that it's not a true attack. Though curious why so much chatter is needed to the mother ship by Roku.

But...prior to the update I could not identify the source IP for the large pings. Now I can, but now I have these "ER605_Router detected TCP no-Flag attack and dropped 3 packets" logs now...but no source.  So it's almost like I traded one unknown for another. I suspect it's still probably ROKU... but not sure. 

  @Jase96 

What controller are you using to get the IP information on the large Ping Attack?  My controller still does not support it even with the latest firmware.  Using a hardware controllers.

Thanks

  @Lurk 

You can check where did the "TCP no-flag" attack came from using Wireshark. Mostly, it came from your ISP so mirror your WAN port to any available port and use Wireshark with this filter:
tcp.flags == 0x000

or use this filter to include TCP SYN+FIN attack:
tcp.flags == 0x000 || tcp.flags == 0x003 

  @mlburgoon 

I am using a hardware controller. OC200 running v5.9.32. That manages the ER605 v1. I also have  a 16 port and 8 port Jetstream switches and 3 EAP WAPs