That's a very known "limitation". The rejection test will occur as soon as possible and in most of the cases makes perfect sense since otherwise too short plains will be transfered to the GPUs. Since hashcat also has a GPU-based rule engine it is not easy to display also the correct number of rejected plains that were filtered on GPU-site and therefore for performance reasons the rejection will be done as soon as possible.
But since it won't be done before the -j/-k manipulation you still can use this workaround: https://hashcat.net/forum/thread-5744-po...l#pid30925 or you could just pipe the correct password candidates to hashcat. Both "workarounds" should work perfectly and since we are speaking about a slow hash type it won't affect performance at all.
Also try to use the search function next time, since these are really very common questions that were answered a couple of times. Furthermore you are mixing in here a lot of unrelated questions that have nothing to do with the original topic.
But since it won't be done before the -j/-k manipulation you still can use this workaround: https://hashcat.net/forum/thread-5744-po...l#pid30925 or you could just pipe the correct password candidates to hashcat. Both "workarounds" should work perfectly and since we are speaking about a slow hash type it won't affect performance at all.
Also try to use the search function next time, since these are really very common questions that were answered a couple of times. Furthermore you are mixing in here a lot of unrelated questions that have nothing to do with the original topic.