PN532.TryDecode106kbpsTypeA - bug decoding ATS not possible

[flo-so]

Describe the bug

Pn532.cs - line 578ff

if ((5 + nfcId.Length) > toDecode.Length)
{
    ats = new byte[toDecode[5 + nfcId.Length]];

the > in line 578 in incorrect, it would mean there is less data than what has been decoded yet.
and the length of the new byte array too is incorrect as the length byte (toDecode[5 + nfcId.Length]) is part of its own length (refer to "NXP 141520.pdf" page 116)

Steps to reproduce
Mifare card data with ATS has f.ex. 18 bytes (= toDecode.Length)
without ATS it has 12 bytes
5 of them Header
7 of them UUID ( =nfcId.Length)
(+ 6 byte ATS)

Expected behavior
It must be a <, correct would be

if ((5 + nfcId.Length) **<** toDecode.Length)
{
    ats = new byte[toDecode[5 + nfcId.Length]**-1**];

(there is more data than what have been decoded)
(decrement length of data-byte-array by one, the length-byte)

Actual behavior
Actually, ATS can never be decoded because of that bug

Versions used

• dotnet --info on the machine being used to build
  .NET SDK: Version: 8.0.400
• Version of System.Device.Gpio package
  3.2.0
• Version of Iot.Device.Bindings package (not needed if bug is in System.Device.Gpio)
  3.2.0

[krwq]

[Triage] @jdbruner @Ellerbach is this already fixed by #2347?

[jdbruner]

Yes, the intent of #2347 was to fix this issue. The difference relative to the way the proposed fix is described in this issue is that the length byte is included as the first byte of the decoded ATS. I fixed it this way to be consistent with how the ATS is specified in ISO 14443-4.

[raffaeler]

Thank you for confirming. I will then close this issue. You can still re-open it in case you need it.