Wireless Water Cooler

I am trying to get some packet captures of clients. When I start a capture on the controller it doesn't show in the packet capture window as in progress. Search result of packet captures show "none found". Am I missing something?

Aruba 3600 controller.

OS 6.4.1.0

Dazza

what kind of capture are you trying to do ? wireless ? data only ? can you show the CLI command you used to start it ?

regards

-jeff

Hi Jeff,

I was trying to start it from the GUI by choosing a client and clicking on packet capture.

ok, and once you entered the packet capture screen - what additional info did you fill out and which button did you click to kick it off ?

I presume you were trying to send to a PC that is running wireshark for capturing ?

What capture type did you select (depends what you're trying to see - and is subject to another debate elsewhere in the forum - but we will get to that)

Do you really need the wireless capture or are you just interested in the tcp/ip data going to the client ?

Ss your capture PC reachable from the AP IP subnet, it is the AP that will send the traffic directly, so if your capture IP is off subnet it will need to route via def gw and not be blocked by any firewall (including on the laptop)

regards

-jeff

I tried getting an AP capture as well as client capture.

For AP capture: Select the AP, click packet capture. After choosing the BSSID I get the window with  BSSID IS xxx and Packet type is all.

In the target IP I enter the IP of my workstation with wireshark running listening on UDP 5555. I use the start button above and to the right of where I enter Target IP. Nothing happens.

From the doco I have read the capture should show in the search result area of that window. I see nothing.

the easier way to operate this (other than the CLI) is to use the raw packet capture function. Let's assume you are trying to capture on some AP that has some clients associated.

1> go to access points -> select the AP -> packet capture

2> choose "new raw packet capture"

3> fill in the IP, set the port to 5555, choose a format (if unsure choose Omnipeek type 1)

4> press start

After about 3 seconds, you should see something appear in the summary box at the top of the screen, along the lines of

  ID    Type    Radio                Channel    Packets    Status         Target                     Filter
    3   RAW    80211a-VHT-40    161         18        in-progress    192.168.1.3/5555    
 

If you do not see this, log into the SSH CLI and run "show audit-trail 10" and "show ap packet-capture status ap-name <ap_name>"  (i.e. the ap you tried to start the capture on). If you see any error message pop up, please note that it is (for example you cannot force an AP to change channel for a capture unless it's in AM mode)

if you do see the above but don't see anything at the capture PC, then check:

a> ensure windows firewall turned off

b> ensure the windows PC can ping to the AP IP address, that is the mgmt vlan ip address of the AP

c> try moving the capture device to same vlan as the AP mgmt IP address

regards

-jeff

Thanks for your help on this Jeff.

3> The choices I get are "WildPackets" or "Ethereal". I chose Ethereal  which sets the port at 5555.

Nothing shows in the summary box.

Nothing show at the CLI with show ap packet-capture blah.

There is nothing shown using show audit-trail 10 that indicates a capture or anything else relevant.The only lines I see may realte to an earlier attempt to capture from a newly provisioned AM.

So whilst writing this response I commenced a captuire from an AM (the only provisioned AM) using your instructions and I am seeing a capture now on the controller and on my Wireshark.

the ethereal capture is just "pcap", it has no radio header info. if you are only interested in that level of packet data, then you are better off using a datapath capture rather than the wireless capture.

what version are you on ? sounds it might be quite old hence the missing other types of capture. None the less, if you want to see the radio header info then you do need to use type 1. Recent versions of wireshark can handle that to some extent (there is a bug about it thought, you can read about it over here Bug-in-ArubaOS-Packet-Capture

There may also be some bug going on with that older version and launching the capture - based on what you have written that might be involved (the show audit-trail should have shown something, seems ther version you are on may have a webUI bug that causes it to send no command to the controller)

But, sounds like you have it working. In newer versions of AOS (6.3 and higher) you can directly capture the tcpip packets of a user up at the controller before it goes into encryption and directly after it's decrypted, which is a much easier way of trying to look into what the client is doing when they associate etc.

regards

-jeff

Thanks Jeff. We are on 6.4.1.0.

I guess I will just keep at it until I can get the client capture.

it's still not quite clear to me what you're trying to capture exactly, because that dictates which of two methods you are going to use within the controller. If you want to see ACKs, RTS/CTS and all that, you will need the "raw capture" method.

try invoking from the CLI

>> first open port (once per reboot of the controller)

"ap packet-capture open-port 5555"

>> start the capture (here on ap215, relay to 192.168.1.3, port 555, type 1, radio 0 (5ghz)

"ap packet-capture raw-start ap-name ap215 192.168.1.3 5555 1 radio 0"

This assumes that my capture AP (ap215 here) is on the channel that i want to capture on, or is indeed the serving AP. Note that an AP which is serving clients cannot correct capture all TX frames and indeed has wrong FCS on tx frames that are captured (see the thread i referenced earlier).

If you want to narrow on a specific client, get it all into wireshark (make sure to tell wirshark you are using type 1, ie. edit -> preferences-> protocols -> aruba_erm -> capture type 1) and then filter using "wlan.addr == <mac addr in : format>"

I actually have never used the client mac as a filter in the webUI 'interactive capture' - not because it doesn't work but because i dont want to miss the bigger picture by filtering down the capture. Having said that, it does work, maybe your browser is involved in the grief, let's try it this way. note that this catpure uses type 0 (pcap/ethereal) and you will need to use the above steps to set it to type 0 not type 1.

a> find out the IP of the AP where the client is active (i.e. show ap association)

b> run "ap packet-capture open-port 5555" if you havent already done so

c> run the following "ap packet-capture interactive ap-name ap205 "(sta == 5c:c5:d4:00:11:22 and type == all)" 192.168.1.3 5555 radio 0"

here we are sending to 192.168.1.3 @ port 5555 and the capture is executed on radio 0 (5ghz).

Now, here is an alternative. Potentially you are just interested in the packets the client is sending, maybe want to remotely look into DHCP or DNS or captive portal etc. You can use the following feature to send a stream of both pre and post encrypted packets from the datapath to wireshark. this type of capture is missing some info, i.e. you dont see beacons, probes, acks etc - this is more or less just tcpip in, wlan packets out.

(sg-7030) # packet-capture destination ip-address 192.168.1.3 
(sg-7030) # packet-capture datapath wifi-client 00:11:22:33:44:55 all
...
(sg-7030)# no packet-capture datapath wifi-client 00:11:22:33:44:55 all

The datapath will put a GRE header on this and send to wireshark, recent wireshark versions will automatically decode this for you.

Since the example above specified "all" you can see both the incoming tcpip packet and then the subsequent encrypted (assuming psk or dot1x) wlan packet. You can also redirect the packets to the flash so they can be exported within "tar logs" or scp/ftp'ed out of the flash.

hth

-jeff

Jeff, your knowledge sharing is very much appreciated. I have searched quite a bit to get exactly what you are explaining to me.

I really only wanted to get to a point where I can run various packet captures to trouble shoot if required. Your last post gives me the information I was looking for. Most of the doco I came across was fairly simplified and didn't go into the detail you have.

Thanks for your replies