problem finding 17 letter password with hashcat 3.10

[arnor]

I was running some tests to crack some passwords and stumbled upon an issue I can't find a solution for.
I already know the passwords I'm cracking and cracking them was not a problem until I tried it with version 3.10.
I noticed some words were rejected and by reducing the wordlist to the correct password I found out that the correct password was rejected.
Trying to find a reason why they would be rejected, I read in the faq that length might be an issue. So I made a very simple test with two hashes, one which came from a password aaaaaaaaaaaaaaaa (16xa) and another from aaaaaaaaaaaaaaaaa (17xa). Turns out the 16 character password can be found and the 17 character password cannot be found.
I should mention that the hashes come from the shadow file of the linux system hashcat runs on. The hashes are of type sha512crypt $6$ (1800).
When I do the exact same test with hashcat v2, I find both passwords.

output from the test using v3.10:

hashcat -a 0 -m 1800  hash list

hashcat (v3.10) starting...

OpenCL Platform #1: Mesa, skipped! No OpenCL compatible devices found

OpenCL Platform #2: Intel(R) Corporation
========================================
- Device #1: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz, 499/1996 MB allocatable, 2MCU

Hashes: 2 hashes; 2 unique digests, 2 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 1
Applicable Optimizers:
* Zero-Byte
* Uses-64-Bit
Watchdog: Temperature abort trigger disabled
Watchdog: Temperature retain trigger disabled

Generated dictionary stats for list: 35 bytes, 2 words, 2 keyspace           

ATTENTION!                                                
  The wordlist or mask you are using is too small.
  Therefore, hashcat is unable to utilize the full parallelization power of your device(s).
  The cracking speed will drop.
  Workaround: https://hashcat.net/wiki/doku.php?id=fre...full_speed

INFO: approaching final keyspace, workload adjusted       

$6$ykNrLai6$hJJnsRf0Gk0fnZTDfTARnCYt7n3sFDAduBAx4EJ86XhQ2.Q4rzwrUWpTaRhKiWtZ6F0Ft7ghwFtX5XvSxvXKg1:aaaaaaaaaaaaaaaa
                                                          
Session.Name...: hashcat
Status.........: Exhausted
Input.Mode.....: File (list)
Hash.Target....: File (hash)
Hash.Type......: sha512crypt, SHA512(Unix)
Time.Started...: 0 secs
Speed.Dev.#1...:        0 H/s (0.11ms)
Recovered......: 1/2 (50.00%) Digests, 1/2 (50.00%) Salts
Progress.......: 4/4 (100.00%)
Rejected.......: 2/4 (50.00%)

Started: Thu Nov 10 14:18:36 2016
Stopped: Thu Nov 10 14:18:38 2016

output from the test using hashcat v2.0:
hashcat -m 1800 -a 0 hash list

Initializing hashcat v2.00 with 2 threads and 32mb segment-size...

Added hashes from file hash: 2 (2 salts)

$6$ykNrLai6$hJJnsRf0Gk0fnZTDfTARnCYt7n3sFDAduBAx4EJ86XhQ2.Q4rzwrUWpTaRhKiWtZ6F0Ft7ghwFtX5XvSxvXKg1:aaaaaaaaaaaaaaaa
$6$yRW0nCy/$he1hAnN6wA225UMnL88i5yZgR3ofraYdD0l3DNo2ZVUSloQZp.wyoYePlhBqT0jMuhVv1zqMrwZasS66kTzg51:aaaaaaaaaaaaaaaaa
                                             
All hashes have been recovered

Input.Mode: Dict (list)
Index.....: 1/1 (segment), 2 (words), 35 (bytes)
Recovered.: 2/2 hashes, 2/2 salts
Speed/sec.: - plains, - words
Progress..: 2/2 (100.00%)
Running...: 00:00:00:01
Estimated.: --:--:--:--


Started: Thu Nov 10 14:55:03 2016
Stopped: Thu Nov 10 14:55:04 2016

I also tested if truncating has anything to do with it, but it doesn't seem like that. Truncating didn't help v3.10 to find the passwords and v2 only finds the 17 character password if the 17 character password is in the list and is not truncated. Which seems logical, since I don't think linux is truncatin the password when I enter it.

I can't seem to find another explanation for what is happening or how I can solve this.

[atom]

Everything's fine, the mode 1800 is limited to 16 characters in hashcat, see here: https://hashcat.net/wiki/doku.php?id=fre...ord_length

PS: That what hashcat shows Rejected.......: 2/4 (50.00%)

[arnor]

Thanks, that was what the symptoms pointed to, but I could not find the confirmation. Pretty stupid considering the name of the topic and the fact I read both the item above and below it.

If I understand this correctly, this is an implementation choice which means there's no workaround for longer passwords in v3.10 (for this type of password).

[atom]

Correct