So, since the pre-shared key is a mismatch you will never be able to reinstall the PTK or GTK because you wouldn't get all the frames you need to replay them. Am I correct?
You are incorrect. Why?
To test the clients, you have to connect to a fake AP but you still need to know the pre-shared key. Of course you know the password, because you created the fake AP. But if you're performing a real attack, and you created a fake AP with the same essid of a real AP, the clients when trying to connect to the fake AP (that act as MITM) won't be able to since the pre-shared key is different.
This is a flawed understanding. The rogue AP is not running as a full infrastructure installation transmitting it's own SSID, rather it is serving as a transparent L2 bridge to the original AP. As such there is no PSK installed on the rogue AP performing the MitM attack.
Same thing for the script to test the real AP. If you know the pre-shared key of the real AP, assuming it supports FT, then you can go ahead and connect to it to do the propers tests regarding packet number reusing. But if you don't know the pre-shared key, if the AP is vulnerable, how are you going to get the all frames of the handshake?
No PSK needed. Anyone can capture the frames of the handshake. Happens all the time. Without the PSK they just aren't very useful. But this is how many attacks against PSKs are performed as once you have the handshake you can then perform any computational task you wish as many times as you like while being "offline" (such as brute forcing the PSK).
In this case, when the rogue AP receives traffic from the client, it passes the traffic along to the real AP and vice versa. It only interferes by rewriting frames for part of the WPA/WPA2 exchange in an attempt to exploit a flaw in the exchange. This makes the PTK more easily calculated (or in the "best case" from the exploits perspective, entirely predictable).
KRACK never provides the PSK when successful. It only gives the PTK allowing you to decrypt that "session's" traffic. The attack needs to be performed for each client that connects and each time a client reconnects as each time the derived PTK should be different (unless it isn't due to the "best case" for the exploit).
I think with a pre-shared key mismatch you would get only message 1 and 2 of the handshake.
If you were trying to set up a rogue AP with a PSK of it's own, you would be correct. As this is not what is going on with KRACK, you are incorrect.
Final commentary: I want to point out that KRACK, while a great find was never a real threat. I still have not heard of a single successful in the wild use of the exploit and updates have relegated the exploit to a historical footnote at this point. Feel free to read my thoughts in another answer on why this was the case nearly three years ago.
