SSL state/ decoder states and conditions for failure of ssl decryption

With this link is attached a sample pcap file along with the ssl keylog file and debug file.

I am unable to understand why Wireshark would not decrypt the data for some ssl application data packets. This data was captured with a website request from chromium and some cipher suites blacklisted (0xcca8, 0xcca9). After perusing through the debug file, I found three common ssl states - 0x2BF, 0x3BF, 0x7BF

On seeing, packet number 594 and 1002, I do not understand why one packet was decrypted while the other was not. The keylog file captured the client random and master secret as it was able decrypt some of the packets (decoder exists for those packets).

Can somebody please help me understand the different ssl states that a dissector can obtain and what do they mean. Specifically, what are the cases in which a decoder variable would fail to be created (assume, no memory leaks and memory abundance on the computer).

As I understand, for decryption of ssl packets - You need

1. Capture of the complete handshake.
2. The session key either from the keylog file or the private key from the server/client.

A further concept/follow through for this question is to try to find a solution to this problem.

If there are two computers set up such as this -

Comp A ----------Bridged --------> Comp B -----------> Internet

Computer B has some firewall rules that initially blocks ssl application data packets but after execution of a script, allows all packets to pass through.

Wireshark is running on Comp A and Comp B and capture packets respectively as pcap A and pcap B. pcap B contains all packets (any dropped packets from the firewall rule also).

Then given a keylog file captured on comp A, is it possible to match and verify the decrypted content of all packets captured on both computers. ?

I tried to export the decrypted http objects and do a hash of the contents, but the match would always fail (as some packets would decrypt and some would not).

In particular, I also made the following observations -

1. TCP reassembly happened differently on both computers (Does this lead to a difference in arrival of ssl states for the ssl session).

2. A certain subset of data application packets for a pair of ip addresses contain different lengths. (when matched on both the computers. I do not know why this happens as the computer is only forwarding packets).

3. Because data application packets on both computers have different lengths, they decrypt with different data and a simple hash for decrypted content fails.

What would be the best way to match and verify the decrypted contents on both the computers ?