(non-DH cipher) SSL won’t decrypt even though master secret found

Question

On Ubuntu Linux, wireshark fails to decrypt an SSL session which does NOT use a DH cipher.
I'm using Firefox with sslkeylogfile.
Looking at the debug file, it appears that wireshark CAN find master secret, yet fails to decrypt.
Here's the relevant snippet from the debug file:

...
 checking keylog line: CLIENT_RANDOM 51fec5231f20bd12d79c7de8ea8d55433b99c06c47bf5a087aa1e1fd209bde01 2df2f3ad233352799947aecf5b831e971170f089cf17ec98d82e5e312a8005663920d14f66e21eecdfb2f06efda72f72
found master secret in key log
ssl_generate_keyring_material not enough data to generate key (0x31 required 0x37 or 0x57)
dissect_ssl3_handshake can't generate keyring material
  record: offset = 267, reported_length_remaining = 47
...

Firefox uses a Squid proxy server. The connection between Firefox and Squid takes place over a Stunnel's SSL tunnel.
Firefox -----(wireshark on loopback)---------> stunnel A ---> stunnel B --> Squid --> Internet

The interesting thing is that when I remove stunnel and connect:
Firefox ------(wireshark on loopback)--------> Squid --> Internet
(Without changing a single setting in wireshark), then I CAN decrypt successfully.

Here are links to wireshark capture with stunnel (failed to decrypt):
http://cloudshark.org/captures/745529928d7f

SSLkeylogfile generated during this session:
http://pastebin.com/6wkpsUah

Debug file (frame 22 is of interest):
http://pastebin.com/3pEVdkqB

Accepted Answer

The solution turned out to be a bizarre one. stunnel A was listening on a random port 33308 when decryption was failing. As soon as I would make stunnel A listen on ports 80 or 8080, the decryption would succeed, for any other ports it would fail. I'm completely mistified. How can a port number influence the decryption of an SSL session?