GTS starting slot in the Beacon frame is not parsed correctly. As per the Spec, in the 3byte gts descriptor value bit 0- 15 refers Device Short address bit 16-19 – Starting slot bit 20-23 – GTS length.
(I Dug out the onliner from the attached file)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8946
svn path=/trunk/; revision=51919
As I looked into the implementation in epan/dissectors/packet-ieee802a.c, there's a bug in the dissect_ieee802a(). After OUI and PID is parsed, it looks for the customized sub-dissector_table by
oui_info = (oui_info_t *)g_hash_table_lookup(oui_info_table, GUINT_TO_POINTER(oui))
The problem is that the oui is defined as an array (guint8 oui[3]), whose value contains the 3-byte customized OUI. However, here GUINT_TO_POINTER(oui) converts the local array oui's address to the hash table key, instead of the value. That cause the search in the hash table to fail, because the ieee802_add_oui() use the OUI value as the key.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9122
svn path=/trunk/; revision=51918
Subject: [PATCH] NFC: PN532: Implement half of PN532 specification
Implement TG_* and RF_* commands/responses.
Also decode "status" field in all commands.
Update USB CCID to decode "escaped" payload.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9119
svn path=/trunk/; revision=51916
(autotools, CMake, nmake, qmake). Throw something at qmake in the hopes
of letting it use GnuTLS in the "follow SSL stream" code.
svn path=/trunk/; revision=51915
when the paint takes a long time (for very large windows, or on older machines)
that doesn't cause every single event to paint (which slows the whole thing to
a crawl). Drop the splash timer to 15ms, since we're no longer counting paints
this seems like a more appropriate value. The old value of 50ms would causing
the splash to only paint once or twice during startup.
svn path=/trunk/; revision=51914
Lastly, try to improve the documentation a bit concerning chopping and provide another example depicting 2 separate chopping regions. *Maybe* this is clearer?
One more example here for posterity: Given the following 75 byte packet, there
are 8 different ways to chop the 2 regions marked as 10 and 20 in a single pass:
<--------------------------- 75 ---------------------------->
+---+-------+-----------+---------------+-------------------+
| 5 | 10 | 15 | 20 | 25 |
+---+-------+-----------+---------------+-------------------+
1) editcap -C 5:10 -C -25:-20 in.pcap out.pcap
2) editcap -C 5:10 -C 50:-20 in.pcap out.pcap
3) editcap -C -70:10 -C -25:-20 in.pcap out.pcap
4) editcap -C -70:10 -C 50:-20 in.pcap out.pcap
5) editcap -C 30:20 -C -60:-10 in.pcap out.pcap
6) editcap -C 30:20 -C 15:-10 in.pcap out.pcap
7) editcap -C -45:20 -C -60:-10 in.pcap out.pcap
8) editcap -C -45:20 -C 15:-10 in.pcap out.pcap
svn path=/trunk/; revision=51886
Add TCP/UDP/SSL Follow feature to QtShark
Known issue :
* Duplicate code with GTK (function need follow_info_t struct but in GTK there is some GWidget variable in struct)
* Sometimes TCP Follow fail...
svn path=/trunk/; revision=51883
