Capturing Packets
For a detailed explanation of all packet capture commands, see the Troubleshooting chapter of the FortiWLC (SD) Command Reference. Packet Capture Profile Example – WireShark
To do this, you need an external system running WireShark. This example creates the packetcapture-profile named Sniffer on a controller and then forwards the captured packets in layer 3 mode from AP-5 to WireShark on port #17777. Port 17777 is the ppi encapsulation port where WireShark is listening for incoming packets in L3 mode on a remote machine with IP address 1.1.1.1.
MC3200(15)# configure terminal
MC3200(15)(config)# packet‐capture‐profile sniffer
MC3200(15)(config‐pcap)# mode l3 destination‐ip 1.1.1.1 port 17777
MC3200(15)(config‐pcap)# ap‐list 5
MC3200(15)(config‐pcap)# enable
MC3200(15)(config‐pcap)# packet‐truncation‐length 0
MC3200(15)(config‐pcap)# exit
MC3200(15)(config)# end
MC3200(15)# sh packet‐capture‐profile sniffer
AP Packet Capture
Profile Name : sniffer
Enable/Disable : enable
Encapsulation : ppi
L2/L3 Mode : l3
Destination IP Address : 1.1.1.1
UDP Destination Port : 17777
Destination MAC for L2 Mode : 00:00:00:00:00:00
Rx only/Tx only/Both : rx
Rate Limiting per station or cumulative : station
Token Bucket Rate : 10
Token Bucket Size : 10
AP Selection (ID) : 5
Extended Filter String : Interface Index :
Packet Truncation Length : 0
Rate Limiting : off
Capture Sibling Frames : on
MC3200(15)#
MC3200(15)#
For a detailed explanation of the packet capture profile commands, see the Troubleshooting chapter of the FortiWLC (SD) Command Reference.
Capturing Packets
What to Look For In Capture-Packet Results
When discovery is via L3, the results of capture-packet should be a UDP port 9292 packet from the AP to the controller followed by a second UDP 9292 packet from the controller to the AP.
After the two UDP packets, there should be about nine UDP port 5000 packets. Check the time deltas between packets; there should only be tenths of a second between packets. Usually, the fifth UDP 5000 packet is from the AP to the controller and is the first one to contain the certificate used for authentication. Immediately following the certificate packet should be a packet from controller to the AP using UDP port 5000 that also contains a certificate.
What to Look For In the Discovery Log
The key messages from a successful discovery message trace are:
COMM: CSDS_REQUEST_DISCOVERY message
COMM: Discovery request from <AP MAC address>/<AP IP Address> received [skip unimportant messages]
COMM: Searching redirect entry for ipAddr 192.168.10.53 [skip unimportant messages]
COMM: Trying to check‐out <n> licenses for feature “ap”.
COMM: lc_checkout OK for feature “ap”. Now, <n> licenses have been checked out
COMM: Response msg to ATS <AP MAC address>/<AP IP Address>
[skip unimportant messages]
COMM: Starting ATS script as: /opt/meru/bin/meru‐wnc‐ats start 3 8 1 1
Result: Registered virtual device ‘<AP MAC address>’
COMM: State file /opt/meru/var/run/discovery.state successfully written.
[skip unimportant messages]
COMM: authentication message 0 with payload type 0 from ‐‐‐ 3:8:37
COMM: /CN=meru AP/ST=California/C=US/Email=support@merunetworks.com ‐ OK [skip unimportant messages] COMM: AuthMgr::ProcessAccept: 3:8 new key 8f 8e eb …
One example of the messages you would see when discovery failed because of a licensing issue is:
COMM: Trying to check‐out 1 licenses for feature “ap”.
COMM: Checking out one more license for AP failed. FlexRetCode = ‐9
COMM: lc_checkout FAIL
COMM: AP‐1 00:0C:E6:00:2C:96 failed licensing
Also, check the following in the discovery log:
- Does the output of the command sh license show the same or more licenses than there are APs?
- Does the output of the command show license-file active show a system ID something like
HOSTID=COMPOSITE=<controller system id> that agrees with the system ID outputted by the command sh controller?
“station-log issues” command works but will not accept any of the arguments. 4200 controller running 8.4.1 software.