This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Followed steps mentioned at https://supportforums.cisco.com/document/75236/collecting-wireless-sniffer-trace-using-cisco-lightweight-ap-sniffer-mode

Setup used is Cisco WLC 2500 + Cisco LAP 3700 in Sniffer mode.

Win7 (64-bit) machine running Wireshark (v1.11.3) is connected over Ethernet with capture filter "udp port 5555".

The packets after decode with peekremote do not show up correctly. The beacons and other some control packets (RTS/CTS) come up fine, but Data packets are not coming up correctly. Any idea what might be the problem ?

alt text

I have also tried with v1.6.8 as mentioned in the Cisco link, but see the same problem. ALl the 802.11 QoS data packets show up as below:

alt text

asked 09 Jun '14, 23:14

Sudheer's gravatar image

Sudheer
16448
accept rate: 0%

edited 12 Jun '14, 11:37


As the response to bug 10177 says, you used a capture filter of "udp port 5555", which means that only the first fragment of a fragmented IP packet will be captured. This prevents Wireshark from reassembling a UDP packet that requires more than one fragment (in this case, a sufficiently large 802.11 packet sent by the AP would have to be fragmented).

What would be best would be if libpcap/WinPcap supported the PEEKREMOTE protocol as a remote capture protocol, in which case libpcap would listen on a UDP socket to which the AP sent packets, letting the IP layer on the OS of the machine running Wireshark do the reassembly, and not requiring a capture filter (instead, the capture filter would apply to the 802.11 packets encapsulated inside the PEEKREMOTE protocol).

However, remote capture support for libpcap/WinPcap is still a work in progress, so, instead, try a filter that matches either the first fragment of a UDP packet to port 5555 OR fragments other than the first fragment:

udp port 5555 or (ip[6:2] & 0x1fff)  !=  0
permanent link

answered 12 Jun '14, 15:47

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%

Any idea what might be the problem ?

From the link you posted:

Cite: "(Note: you must use wireshark 1.6.8 or earlier, newer versions have this support broken and the packets will not be decoded correctly) follow the steps below:"

So, it looks like the Cisco protocol is not being decoded correctly with Wireshark > 1.6.8. If that is true (please test it with 1.6.8), could you please file a bug report at https://bugs.wireshark.org and attach a sample capture file.

Regards
Kurt

permanent link

answered 12 Jun '14, 07:06

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 12 Jun '14, 07:06

This may have recently been fixed. Try the latest buildbot build.

(12 Jun '14, 08:02) Anders ♦

I have also tried with v1.6.8 as mentioned in the Cisco link, but see the same problem.

Placed a snapshot in the question section.

(12 Jun '14, 11:35) Sudheer

can you post a sample capture file somewhere (google drive, dropbox, cloudshark.org)?

(12 Jun '14, 11:39) Kurt Knochner ♦

I have filed a bug https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10177

Above link has sample pcap files.

(12 Jun '14, 14:28) Sudheer
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×5

question asked: 09 Jun '14, 23:14

question was seen: 2,568 times

last updated: 12 Jun '14, 15:47

p​o​w​e​r​e​d by O​S​Q​A