Wireless Access

Hi,

Can someone possibly give me some advice on ping-flood troubleshooting?  I have a user who keeps getting disconnected for a ping-flood and this shows in both the MM and in the controller logs, but it doesnt actually show any details on the event.
I'm trying to find out what the destination address/addresses of the ICMP traffic are, but can't seem to find reference to this.
I don't have local access to the device to run wireshark on it.

thanks

------------------------------
matt
------------------------------

It might be in the security log

------------------------------
Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.
------------------------------

No, doesnt seem to give you source/dest in the sec log for floods.

------------------------------
matt
------------------------------

Original Message:
Sent: Nov 05, 2021 09:55 AM
From: Colin Joseph
Subject: ping-flood troubleshooting

It might be in the security log

------------------------------
Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.
------------------------------

What is the exact message?

------------------------------
Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.
------------------------------

Original Message:
Sent: Nov 08, 2021 11:15 AM
From: matt pollard
Subject: ping-flood troubleshooting

No, doesnt seem to give you source/dest in the sec log for floods.

------------------------------
matt
------------------------------


Original Message:
Sent: Nov 05, 2021 09:55 AM
From: Colin Joseph
Subject: ping-flood troubleshooting

It might be in the security log

------------------------------
Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

Nov 18 11:34:32 stm[3976]: <501103> <5990> <WARN> |stm| Blacklist add: xx:xx:xx:xx:xx:xx: Reason: ping-flood

------------------------------
matt
------------------------------

Original Message:
Sent: Nov 08, 2021 11:23 AM
From: Colin Joseph
Subject: ping-flood troubleshooting

What is the exact message?

------------------------------
Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.
------------------------------


Original Message:
Sent: Nov 08, 2021 11:15 AM
From: matt pollard
Subject: ping-flood troubleshooting

No, doesnt seem to give you source/dest in the sec log for floods.

------------------------------
matt


Original Message:
Sent: Nov 05, 2021 09:55 AM
From: Colin Joseph
Subject: ping-flood troubleshooting

It might be in the security log

------------------------------
Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

I run into similar issues on occasion here on our campus. Students bringing their computers to campus preloaded with all sorts of bloatware, some of which can cause the ping-flood issues. I have found some 3ed party printer software can cause issues, and Lenovo's Vantage app has caused problems (they do arp and ping sweeps causing the blacklisting). Once uninstalled, the problem goes away. Sometimes it takes looking at the add/remove program list, seeing what's running, trial and error, etc. to figure it out.

You shouldn't need access to the workstation to run a datapath capture - you can do one of the following:

#1 - Setup remote datapath capture and forward to your workstation running wireshark

- In CLI, identify the user's current UAC ( show user-table | include <user's mac or ip> )
- Logon to that controller using " logon <controller's ip> "
- Run the following commands:
-- packet-capture destination ip-address <your IP address>
-- packet-capture datapath mac <user's mac> all
- Launch wireshark on your PC
- Start a capture and include the following filter:
-- (mac == xx:xx:xx:xx:xx:xx || eth.addr == xx:xx:xx:xx:xx:xx || wlan.addr == xx:xx:xx:xx:xx:xx || wlan.ta == xx:xx:xx:xx:xx:xx || wlan.ra == xx:xx:xx:xx:xx:xx || wlan.sa == xx:xx:xx:xx:xx:xx || wlan.da == xx:xx:xx:xx:xx:xx) && !icmp


#2 -Monitor the datapath session table on the controller for the user and for protocol 1 (ICMP)
- In CLI, identify the user's current UAC ( show user-table | include <user's mac or ip> )
- Logon to that controller using " logon <controller's ip> "
- Run the following command:
-- show datapath session table <user's IP> and look for Prot 1.


Hopefully that helps, good luck!

​​

------------------------------
Michael Haring

AirHeads MVP 2017, 2019-2021
------------------------------

Managed to try option 2 today and that didnt prove very fruitfull. I could see the session and its connections , but no proto 1.  Just a bunch of proto 17 followed by a disconnect for ping-flood.
I'll try and sync with the end user tomorrow and do option 1.

We seem to be getting more and more of these coming in now from students with new laptops of various brands and they are getting quite frustrated.

Does anyone know how high you can raise the limit before the defense is effectively useless? Currently at 150 per 30 seconds.

------------------------------
matt
------------------------------

Original Message:
Sent: Nov 07, 2021 10:20 AM
From: Michael Haring
Subject: ping-flood troubleshooting

You shouldn't need access to the workstation to run a datapath capture - you can do one of the following:

#1 - Setup remote datapath capture and forward to your workstation running wireshark

- In CLI, identify the user's current UAC ( show user-table | include <user's mac or ip> )
- Logon to that controller using " logon <controller's ip> "
- Run the following commands:
-- packet-capture destination ip-address <your IP address>
-- packet-capture datapath mac <user's mac> all
- Launch wireshark on your PC
- Start a capture and include the following filter:
-- (mac == xx:xx:xx:xx:xx:xx || eth.addr == xx:xx:xx:xx:xx:xx || wlan.addr == xx:xx:xx:xx:xx:xx || wlan.ta == xx:xx:xx:xx:xx:xx || wlan.ra == xx:xx:xx:xx:xx:xx || wlan.sa == xx:xx:xx:xx:xx:xx || wlan.da == xx:xx:xx:xx:xx:xx) && !icmp


#2 -Monitor the datapath session table on the controller for the user and for protocol 1 (ICMP)
- In CLI, identify the user's current UAC ( show user-table | include <user's mac or ip> )
- Logon to that controller using " logon <controller's ip> "
- Run the following command:
-- show datapath session table <user's IP> and look for Prot 1.


Hopefully that helps, good luck!

​​

------------------------------
Michael Haring

AirHeads MVP 2017, 2019-2021
------------------------------

According to the VMM help it says 1-16384 pings per 30 seconds can be configured, recommended to be 120. In our environment, we do not have anything defined for this, only gratuitous ARPs. I did not modify this though, so by default I guess it's blank. I can't speak to the value becoming less helpful, maybe make a larger hop and scale back over time?

I have not run into this before, but again I don't know that this is a set by default.

Thanks.

------------------------------
Michael Haring

AirHeads MVP 2017, 2019-2021
------------------------------

Original Message:
Sent: Nov 16, 2021 12:56 PM
From: matt pollard
Subject: ping-flood troubleshooting

Managed to try option 2 today and that didnt prove very fruitfull. I could see the session and its connections , but no proto 1.  Just a bunch of proto 17 followed by a disconnect for ping-flood.
I'll try and sync with the end user tomorrow and do option 1.

We seem to be getting more and more of these coming in now from students with new laptops of various brands and they are getting quite frustrated.

Does anyone know how high you can raise the limit before the defense is effectively useless? Currently at 150 per 30 seconds.

------------------------------
matt
------------------------------


Original Message:
Sent: Nov 07, 2021 10:20 AM
From: Michael Haring
Subject: ping-flood troubleshooting

You shouldn't need access to the workstation to run a datapath capture - you can do one of the following:

#1 - Setup remote datapath capture and forward to your workstation running wireshark

- In CLI, identify the user's current UAC ( show user-table | include <user's mac or ip> )
- Logon to that controller using " logon <controller's ip> "
- Run the following commands:
-- packet-capture destination ip-address <your IP address>
-- packet-capture datapath mac <user's mac> all
- Launch wireshark on your PC
- Start a capture and include the following filter:
-- (mac == xx:xx:xx:xx:xx:xx || eth.addr == xx:xx:xx:xx:xx:xx || wlan.addr == xx:xx:xx:xx:xx:xx || wlan.ta == xx:xx:xx:xx:xx:xx || wlan.ra == xx:xx:xx:xx:xx:xx || wlan.sa == xx:xx:xx:xx:xx:xx || wlan.da == xx:xx:xx:xx:xx:xx) && !icmp


#2 -Monitor the datapath session table on the controller for the user and for protocol 1 (ICMP)
- In CLI, identify the user's current UAC ( show user-table | include <user's mac or ip> )
- Logon to that controller using " logon <controller's ip> "
- Run the following command:
-- show datapath session table <user's IP> and look for Prot 1.


Hopefully that helps, good luck!

​​

------------------------------
Michael Haring

AirHeads MVP 2017, 2019-2021

On a fresh install of OS8 mine was set to 120. 
So far increasing the value has just given the end user more time before the kick. Maybe try bumping it up a bit higher.

------------------------------
matt
------------------------------

Original Message:
Sent: Nov 16, 2021 03:08 PM
From: Michael Haring
Subject: ping-flood troubleshooting

According to the VMM help it says 1-16384 pings per 30 seconds can be configured, recommended to be 120. In our environment, we do not have anything defined for this, only gratuitous ARPs. I did not modify this though, so by default I guess it's blank. I can't speak to the value becoming less helpful, maybe make a larger hop and scale back over time?

I have not run into this before, but again I don't know that this is a set by default.

Thanks.

------------------------------
Michael Haring

AirHeads MVP 2017, 2019-2021
------------------------------


Original Message:
Sent: Nov 16, 2021 12:56 PM
From: matt pollard
Subject: ping-flood troubleshooting

Managed to try option 2 today and that didnt prove very fruitfull. I could see the session and its connections , but no proto 1.  Just a bunch of proto 17 followed by a disconnect for ping-flood.
I'll try and sync with the end user tomorrow and do option 1.

We seem to be getting more and more of these coming in now from students with new laptops of various brands and they are getting quite frustrated.

Does anyone know how high you can raise the limit before the defense is effectively useless? Currently at 150 per 30 seconds.

------------------------------
matt


Original Message:
Sent: Nov 07, 2021 10:20 AM
From: Michael Haring
Subject: ping-flood troubleshooting

You shouldn't need access to the workstation to run a datapath capture - you can do one of the following:

#1 - Setup remote datapath capture and forward to your workstation running wireshark

- In CLI, identify the user's current UAC ( show user-table | include <user's mac or ip> )
- Logon to that controller using " logon <controller's ip> "
- Run the following commands:
-- packet-capture destination ip-address <your IP address>
-- packet-capture datapath mac <user's mac> all
- Launch wireshark on your PC
- Start a capture and include the following filter:
-- (mac == xx:xx:xx:xx:xx:xx || eth.addr == xx:xx:xx:xx:xx:xx || wlan.addr == xx:xx:xx:xx:xx:xx || wlan.ta == xx:xx:xx:xx:xx:xx || wlan.ra == xx:xx:xx:xx:xx:xx || wlan.sa == xx:xx:xx:xx:xx:xx || wlan.da == xx:xx:xx:xx:xx:xx) && !icmp


#2 -Monitor the datapath session table on the controller for the user and for protocol 1 (ICMP)
- In CLI, identify the user's current UAC ( show user-table | include <user's mac or ip> )
- Logon to that controller using " logon <controller's ip> "
- Run the following command:
-- show datapath session table <user's IP> and look for Prot 1.


Hopefully that helps, good luck!

​​

------------------------------
Michael Haring

AirHeads MVP 2017, 2019-2021

Had a bit more luck today. Did a Pcap and could see the device was pinging the entire subnet before it was blocked.
I found it slightly easier just to pcap locally and view it on the controller than exporting to a pc with wireshark.

Still have no idea whats causing it though. User says the only thing installed on the PC is office and we know this doesnt affect other users....

Anyone know of a super-easy tool you could give to an end user that could tell them what app was generating traffic? wondering if glasswire might work.

------------------------------
matt
------------------------------

Original Message:
Sent: Nov 18, 2021 06:55 AM
From: matt pollard
Subject: ping-flood troubleshooting

On a fresh install of OS8 mine was set to 120. 
So far increasing the value has just given the end user more time before the kick. Maybe try bumping it up a bit higher.

------------------------------
matt
------------------------------


Original Message:
Sent: Nov 16, 2021 03:08 PM
From: Michael Haring
Subject: ping-flood troubleshooting

According to the VMM help it says 1-16384 pings per 30 seconds can be configured, recommended to be 120. In our environment, we do not have anything defined for this, only gratuitous ARPs. I did not modify this though, so by default I guess it's blank. I can't speak to the value becoming less helpful, maybe make a larger hop and scale back over time?

I have not run into this before, but again I don't know that this is a set by default.

Thanks.

------------------------------
Michael Haring

AirHeads MVP 2017, 2019-2021


Original Message:
Sent: Nov 16, 2021 12:56 PM
From: matt pollard
Subject: ping-flood troubleshooting

Managed to try option 2 today and that didnt prove very fruitfull. I could see the session and its connections , but no proto 1.  Just a bunch of proto 17 followed by a disconnect for ping-flood.
I'll try and sync with the end user tomorrow and do option 1.

We seem to be getting more and more of these coming in now from students with new laptops of various brands and they are getting quite frustrated.

Does anyone know how high you can raise the limit before the defense is effectively useless? Currently at 150 per 30 seconds.

------------------------------
matt


Original Message:
Sent: Nov 07, 2021 10:20 AM
From: Michael Haring
Subject: ping-flood troubleshooting

You shouldn't need access to the workstation to run a datapath capture - you can do one of the following:

#1 - Setup remote datapath capture and forward to your workstation running wireshark

- In CLI, identify the user's current UAC ( show user-table | include <user's mac or ip> )
- Logon to that controller using " logon <controller's ip> "
- Run the following commands:
-- packet-capture destination ip-address <your IP address>
-- packet-capture datapath mac <user's mac> all
- Launch wireshark on your PC
- Start a capture and include the following filter:
-- (mac == xx:xx:xx:xx:xx:xx || eth.addr == xx:xx:xx:xx:xx:xx || wlan.addr == xx:xx:xx:xx:xx:xx || wlan.ta == xx:xx:xx:xx:xx:xx || wlan.ra == xx:xx:xx:xx:xx:xx || wlan.sa == xx:xx:xx:xx:xx:xx || wlan.da == xx:xx:xx:xx:xx:xx) && !icmp


#2 -Monitor the datapath session table on the controller for the user and for protocol 1 (ICMP)
- In CLI, identify the user's current UAC ( show user-table | include <user's mac or ip> )
- Logon to that controller using " logon <controller's ip> "
- Run the following command:
-- show datapath session table <user's IP> and look for Prot 1.


Hopefully that helps, good luck!

​​

------------------------------
Michael Haring

AirHeads MVP 2017, 2019-2021

Have the user send you a screenshot of their add/remove programs list... I guarantee there's more in that list than just MS Office. It's likely some software that came preinstalled that the user isn't aware of.

As I said, if its a Lenovo, check for the "Lenovo Vantage" app and uninstall that if its there. (There's another Lenovo app that has given me problems, but I'm blanking on the name). Also check for printer apps.

There's no 'easy' way to do it from my experience, other than working with the user, either in person or having them send screenshots, and a little trial-and-error figuring out who is sending all the ping traffic.

If you find an 'easier' way to track down the ping culprit, please share here.

It did indeed turn out to be "Lenovo Vantage" that was causing the issue. Thanks for that.
I've not found an easier way than working with the end user yet unfortunately.

------------------------------
matt
------------------------------

Original Message:
Sent: Nov 19, 2021 01:12 PM
From: Cody Ensanian
Subject: ping-flood troubleshooting

Have the user send you a screenshot of their add/remove programs list... I guarantee there's more in that list than just MS Office. It's likely some software that came preinstalled that the user isn't aware of.

As I said, if its a Lenovo, check for the "Lenovo Vantage" app and uninstall that if its there. (There's another Lenovo app that has given me problems, but I'm blanking on the name). Also check for printer apps.

There's no 'easy' way to do it from my experience, other than working with the user, either in person or having them send screenshots, and a little trial-and-error figuring out who is sending all the ping traffic.

If you find an 'easier' way to track down the ping culprit, please share here.

------------------------------
Cody Ensanian
------------------------------


Original Message:
Sent: Nov 19, 2021 12:58 PM
From: matt pollard
Subject: ping-flood troubleshooting

Had a bit more luck today. Did a Pcap and could see the device was pinging the entire subnet before it was blocked.
I found it slightly easier just to pcap locally and view it on the controller than exporting to a pc with wireshark.

Still have no idea whats causing it though. User says the only thing installed on the PC is office and we know this doesnt affect other users....

Anyone know of a super-easy tool you could give to an end user that could tell them what app was generating traffic? wondering if glasswire might work.

------------------------------
matt


Original Message:
Sent: Nov 18, 2021 06:55 AM
From: matt pollard
Subject: ping-flood troubleshooting

On a fresh install of OS8 mine was set to 120. 
So far increasing the value has just given the end user more time before the kick. Maybe try bumping it up a bit higher.

------------------------------
matt


Original Message:
Sent: Nov 16, 2021 03:08 PM
From: Michael Haring
Subject: ping-flood troubleshooting

According to the VMM help it says 1-16384 pings per 30 seconds can be configured, recommended to be 120. In our environment, we do not have anything defined for this, only gratuitous ARPs. I did not modify this though, so by default I guess it's blank. I can't speak to the value becoming less helpful, maybe make a larger hop and scale back over time?

I have not run into this before, but again I don't know that this is a set by default.

Thanks.

------------------------------
Michael Haring

AirHeads MVP 2017, 2019-2021


Original Message:
Sent: Nov 16, 2021 12:56 PM
From: matt pollard
Subject: ping-flood troubleshooting

Managed to try option 2 today and that didnt prove very fruitfull. I could see the session and its connections , but no proto 1.  Just a bunch of proto 17 followed by a disconnect for ping-flood.
I'll try and sync with the end user tomorrow and do option 1.

We seem to be getting more and more of these coming in now from students with new laptops of various brands and they are getting quite frustrated.

Does anyone know how high you can raise the limit before the defense is effectively useless? Currently at 150 per 30 seconds.

------------------------------
matt


Original Message:
Sent: Nov 07, 2021 10:20 AM
From: Michael Haring
Subject: ping-flood troubleshooting

You shouldn't need access to the workstation to run a datapath capture - you can do one of the following:

#1 - Setup remote datapath capture and forward to your workstation running wireshark

- In CLI, identify the user's current UAC ( show user-table | include <user's mac or ip> )
- Logon to that controller using " logon <controller's ip> "
- Run the following commands:
-- packet-capture destination ip-address <your IP address>
-- packet-capture datapath mac <user's mac> all
- Launch wireshark on your PC
- Start a capture and include the following filter:
-- (mac == xx:xx:xx:xx:xx:xx || eth.addr == xx:xx:xx:xx:xx:xx || wlan.addr == xx:xx:xx:xx:xx:xx || wlan.ta == xx:xx:xx:xx:xx:xx || wlan.ra == xx:xx:xx:xx:xx:xx || wlan.sa == xx:xx:xx:xx:xx:xx || wlan.da == xx:xx:xx:xx:xx:xx) && !icmp


#2 -Monitor the datapath session table on the controller for the user and for protocol 1 (ICMP)
- In CLI, identify the user's current UAC ( show user-table | include <user's mac or ip> )
- Logon to that controller using " logon <controller's ip> "
- Run the following command:
-- show datapath session table <user's IP> and look for Prot 1.


Hopefully that helps, good luck!

​​

------------------------------
Michael Haring

AirHeads MVP 2017, 2019-2021