If you haven't already, read Wireshark's How To Decrypt 802.11 document on this and try decrypting the sample capture.
If you can't even get Wireshark to decrypt the frames in the example file, then you're probably running into a Wireshark bug.
Hints on seeing if you've decoded the sample file:
- You can't decode frames 3, 26, or 47; so basically, you won't see anything change in the first screenful of frames even if you're successfully decrypting things. You need to scroll down to after you see the Auth, Assoc, and EAPOL-key handshake.
- The first frame you can decode is 99 (Data, 404 bytes). Fully decrypted and decoded, it's a DHCP Request.
- Frame 102 (Data, 652 bytes) is a DHCP ACK.
Now, about decrypting your own captures:
Note that to decode WPA-PSK or WPA2-PSK frames from your own captures, you must capture all four frames of the EAPOL-key handshake, which happens right after the client associates to the AP. The AP and the client take the PSK and generate some cryptographic nonces, exchange the nonces via the EAPOL-key handshake, and then derive a one-time session key from that (the Pairwise Temporal Key, or PTK). If you don't capture that handshake, there's no way for Wireshark to learn the nonces, so there's no way for it to figure out what PTK the client and AP created for that session, so there's no way for Wireshark to decrypt that session.
You already mentioned that you didn't find any EAPOL frames in your capture. Look and see if you have the 802.11-layer Authenticate and Associate frame pairs. I'll bet you didn't get those either. The EAPOL-key handshake comes right after the Associate frame exchange.
Update: Also make sure you're capturing in promiscuous mode. 802.11 monitor mode will show you 802.11 headers and 802.11-specific frames, but it still might not show you unicasts between other devices unless you also enable promiscuous mode.