@NewOmadaUser What do you mean? I see it in the alertmessage for the firewall.

@Fae Do we have a timeline when ER605 v1 will receive the firmware update to accomodate to see the source of Large Ping Attacks?

@Fae - Any progress on the ER605 v1 firmware update to support the ability of viewing the source IP for Large Ping Attacks?

 Hi  @Fae 

Controller Version 5.7.6

Model OC200 1.0

Firmware Version 1.21.7 Build 20221206 Rel.58608

RT01 detected Large Ping attack and dropped 12 packets.

Omada Controller v5.6 will support showing the source IP of the detected "Large Ping Attack" or "Ping of Death Attack"


Seems not, v5.7.6 is not showing the source IP in the log.

  @Lurk 

I haven't been getting any Large Ping attacks since the last few firmwares that were released. I ensured it's enabled in Security settings. I'm using the latest version of Omada software as of today, 5.7.4. When I run Check For Updates it says it's the latest so not sure where you got 5.7.6 from but I guess the updates are different depending on the device model which in my case it's Software.

@yorkman, you're right. The model (OC200 1.0) @Lurk is using is a hardware controller.

I'm using Software controller and it's on the same release version as yours.

I do intermittently see one or two large ping attacks, and all originate from apple devices (iPhone / iPad). However, the frequency has most certainly come down recently.

  Hi @yorkman ,

This is where I checked the current OC200 firmware and controller version.
 

And here is the never ending alerts

i logged from 8.30am to 8.40am - icmpv6 only showing up on the LAN side of the router

and icmpv4

But, when I restrict to larger frames 

icmp && frame.len >= 255
 

Goodness, lots of icmp packets are being dropped at the router. It doesn't seem to add up exactly with the log times or number of packets, but the logs are being written to after the packets are dropped so it won't quite line up.

My conclusion in this case is the router doesn't like the icmp packets originating on the LAN side, and not an attack from the WAN side. Given the other no-Flag messages are occuring at the same frequency and time, it seems they are related.

In case you want to know how I monitored the WAN side I used a SG108PE and created a two port 'port vlan' and mirrored the port and connected that to wireshark.

I did the same for the LAN side so I can see both sides and what is dropped and what isn't using two instances of wireshark on the same PC.

I think this is an 'own goal' as the alerts are being generated for LAN side packets.

In both cases the target IP has been apple services - 17. 253. 121. 201 

NetRange:       17. 0. 0. 0 - 17. 255. 255. 255
CIDR:           17. 0. 0. 0/8
NetName:        APPLE-WWNET
NetHandle:      NET-17-0-0-0-1
Parent:          ()
NetType:        Direct Allocation
OriginAS:       
Organization:   Apple Inc. (APPLEC-1-Z)
RegDate:        1990-04-16
Updated:        2021-12-14


And 23. 194. 133. 234

NetRange:       23. 192. 0. 0 - 23. 223. 255. 255
CIDR:           23. 192. 0. 0/11
NetName:        AKAMAI
NetHandle:      NET-23-192-0-0-1
Parent:         NET23 (NET-23-0-0-0-0)
NetType:        Direct Allocation
OriginAS:       
Organization:   Akamai Technologies, Inc. (AKAMAI)
RegDate:        2013-07-12
Updated:        2013-08-09

 

from google 
iCloud content is stored on Akamai servers. Asuming you are using iCloud, e.g. to store Safari bookmarks, it is normal that opening Safari triggers a connection to Akamai since the actual content (= Safari bookmarks) are physically stored on Akamai distribution servers and needs to be synced when opening the browser.

Seems to be tp-link doesn't like how the apple devices (phone, homepod) sending icmp packets to their servers and freaks out.


Doh.

  Hi, @NittyMDev 

I came to the same conclusion that it was apple devices!

Did a long post in this thread about it. Good work!