Timeout with Dutch passports

[myurieff]

Hello there 👋 Thanks for an awesome library! We are doing POCs for scanning documents and only require compatibility with Dutch documents and DG1, DG2 and SOD data groups.
The issue we're facing is that reading Dutch passports takes too long - even with only those three groups enabled - and the nfc session times out. The issue is not there for Dutch IDs. I've also tried with a Bulgarian passport and it takes just a couple of seconds.

Here's a video and verbose level logs (from a specimen passport).

https://user-images.githubusercontent.com/25137824/117128658-5eb48f80-ada6-11eb-9812-5c9a13f9aab9.MP4

passportreaderverbose.log

I hope that's helpful. Let me know if you need any further information. Thank you 🙏

[igashev]

I am also experiencing the same issue for dutch passports. #101 seems to be similar.

[anuragajwani]

I believe the issue is with DG2 possibly being the heaviest datagroup to extract. I am facing the same problem. I do not have the problem of session invalidated when DG2 is excluded. However I need DG2 though.

[jeanm-dev]

This is indeed due to the DG2 data group being very large, but also in part because the number of bytes read is limited to a small amount leading to multiple reading attempts.

I found a solution by increasing the number of bytes that is read for the section (currently 0xA0 160 bytes) in the TagReader file to 0xFF to 255 bytes.

TagReader.swift Original:

var maxDataLengthToRead : Int = 0xA0 

Adjusted:

var maxDataLengthToRead : Int = 0xFF 

I hope this helps someone.

[rbrouwer]

I would like to add that it seems only certain models of dutch passports/IDs are affected and reading just DG2 and no other groups in that session also seems to helps out.

The maxDataLengthToRead also helps out a bit, but in all cases we simple seem to run into a NFC-timeout (set by iOS!).

iOS seems to limit NFC sessions to 30 seconds. Best work-around would probably be to start a new NFC session in case of that timeout, redo PACE/BAC and chip authentication, and then continue reading any unread data-groups. In that case the 160 byte compatibility is also less of an issue.

[AndyQ]

I'm closing this. If you need the higher rate, you can explicitly override the max length using the overrideDataAmountToRead method on TagReader - set this to 0xFF.

The app should in this case automatically drop down to 0XA0 if it gets a Wrong Length or End of file error - 0x6c XX or 0x67 0x00 but this will cause a the read to start from beginning.