Forum Replies Created

  • Re: Reply To: Changing Offline_Crypto key with OfflineChange key

    24. November 2020 at 10:21
    in reply to: Changing Offline_Crypto key with OfflineChange key
    Hi Vojko,

    I have seen you ask already by taplinx@nxp.com. We continue the conversation via email.

    The TapLinx team

    + 1  |  - 0

    Re: Reply To: Ntag 213tt : How to enable tt message using Taplinx?

    23. November 2020 at 14:06
    in reply to: Ntag 213tt : How to enable tt message using Taplinx?
    Hi Ankit,

    What Li posted is a good example. I recommend to lock the tag only, if you have checked all functions. After locking you cannot write the tag again. With this code snippet I make the configuration settings for test mirroring at NTAG213TT:



    This is the corresponding log output:



    If everything works, you can lock the tag.

    The TapLinx team
    Attachments:
    You must be logged in to view attached files.

    + 1  |  - 0

    Re: Reply To: Authenticate Mifare DESFire with SAM AV3 Returns 6985

    23. November 2020 at 9:34
    in reply to: Authenticate Mifare DESFire with SAM AV3 Returns 6985
    Hi Huang Hy,

    Please write to us via: taplinx@nxp.com for such questions. We cannot discus about NDA classified material on a public forum.

    Thank you
    The TapLinx team

    + 0  |  - 0

    Re: Reply To: DESFire EV3 TapLinx support

    19. November 2020 at 12:57
    in reply to: DESFire EV3 TapLinx support
    Hi Jean-Pierre,

    It is intended to release TapLinx 1.8 end of November this year.

    The TapLinx team
    + 0  |  - 0

    Re: Reply To: Authenticate Mifare DESFire with SAM AV2 Returns 6985

    17. November 2020 at 15:07
    in reply to: Authenticate Mifare DESFire with SAM AV2 Returns 6985
    Hi Harry,

    we cannot discus in detail about MIFARE SAM AV2 commands on this public portal. This material is NDA classified.

    Please write to us: tapLinx@nxp.com

    The TapLinx team

    + 0  |  - 0

    Re: Reply To: Authenticate Mifare DESFire with SAM AV2 Returns 6985

    17. November 2020 at 15:07
    in reply to: Authenticate Mifare DESFire with SAM AV2 Returns 6985
    Hi Harry,

    we cannot discus in detail about MIFARE SAM AV2 commands on this public portal. This material is NDA classified.

    Please write to us: tapLinx@nxp.com

    The TapLinx team

    + 0  |  - 0

    Re: Reply To: TapLinx SDK Desktop sample app error: apdu must be at least 4 bytes long

    17. November 2020 at 9:53
    in reply to: TapLinx SDK Desktop sample app error: apdu must be at least 4 bytes long
    Hi James,

    I have checked the app with a HID Omnikey 5421 reader. The exception you mentioned occurs indeed, but only if no card is present on the reader! I used a MIFARE DESFire EV1 for the test.

    For the impatient reader I summarize the fix which works for me. The class MainPanel.java contains a method tryCardType() where some card types are tested: MIFARE Ultralight, MIFARE DESFire and MIFARE Plus. It is clear that most of the attempts will fail, because only one card type is present on the reader. If you deal with one card type anyway, you can remove the test of other types as shown in the code snippet below. These are intended as examples how to start with the different MIFARE family products.



    When I run the app with no card on the reader, I get this exception:

    javax.smartcardio.CardNotPresentException: No card present

    This exception is non-fatal and the app continues.

    OK, let us have a deeper look onto the issue now. It occurs while checking for a MIFARE Plus in method CardLogic.plusSL3Logic(). The method PlusFactory.getInstance().isCardPlusSL3() sends an APDU command with less than 4 bytes which throws the fatal exception in javax.smartcardio.CommandAPDU.parse().

    Four bytes are the minimum length for a valid APDU command. The other factory methods for the DESFire EV1 and DESFire EV2 do not throws this exception. Therefore this behavior should be fixed for my understanding. I will report this to the development team.

    The TapLinx team
    Attachments:
    You must be logged in to view attached files.

    + 0  |  - 0

    Re: Reply To: TapLinx SDK Desktop sample app error: apdu must be at least 4 bytes long

    16. November 2020 at 8:22
    in reply to: TapLinx SDK Desktop sample app error: apdu must be at least 4 bytes long
    Hi James,

    The message “AWT-EventQueue-0” shows that the issue occurs after triggering a command from GUI (button or combobox). Somewhere an empty APDU must be sent (message “apdu must be at least 4 bytes long”).

    We will check this.

    The TapLinx team

    + 0  |  - 0

    Re: Reply To: NXP lib not working on Android 7+ due to missing Apache HTTP client

    10. November 2020 at 9:38
    in reply to: NXP lib not working on Android 7+ due to missing Apache HTTP client
    Hi Anitha and Norbert,

    I found this post on Stackoverflow:

    https://stackoverflow.com/questions/54806903/java-lang-noclassdeffounderror-failed-resolution-of-lorg-apache-http-params-ba

    It seems that using Apache HTTP client needs some modifications in the project settings for current releases.

    The TapLinx team
    + 0  |  - 0

    Re: Reply To: TapLinx SDK Desktop sample app error: apdu must be at least 4 bytes long

    9. November 2020 at 8:29
    in reply to: TapLinx SDK Desktop sample app error: apdu must be at least 4 bytes long
    Hi James,

    About which “sample app provided with an Omnikey 5022” do we talk? Is it software from NXP?

    The TapLinx team

    + 0  |  - 0

    Re: Reply To: Key incjection from AV2 to Desfire EV2

    5. November 2020 at 10:14
    in reply to: Key incjection from AV2 to Desfire EV2
    Hi Nico,

    MIFARE SAM AV2 supports all features of MIFARE DESFire EV2 = NO
    MIFARE SAM AV3 supports all features of MIFARE DESFire EV2 = YES

    The TapLinx team
    + 0  |  - 0

    Re: Reply To: NTAG424DNATT authenticateEV2First Error

    4. November 2020 at 11:04
    in reply to: NTAG424DNATT authenticateEV2First Error
    Hi Andrea,

    I use version 1.8 for my tests, because it will be released soon. You cannot download it not yet. But your issue has nothing to do with the version of TapLinx. I just checked the same source code with TapLinx 1.7 and it behaves identically.

    There must be something wrong on your device. For instance, error 0x911C means ILLEGAL_COMMAND_CODE (Command code not supported). Can you please run your software on a different device from a different manufacturer to prevent a firmware issue? The reason for this suggestion is, TapLinx is a user library which uses the public interface of the Google NFC adapter. The code behind the NFC interface is based on the NFC implementation of the software of the manufacturer in the firmware. The firmware is unavailable for users and can be updated only with manufacturer updates. Therefore, I would test my Android software on how much other Android devices as possible.

    The TapLinx team
    + 0  |  - 0

    Re: Reply To: Picking the right key for DESFire EV2 cards when UIDs are unreliable/unavailable

    4. November 2020 at 9:03
    in reply to: Picking the right key for DESFire EV2 cards when UIDs are unreliable/unavailable
    Hi Mario,

    An Addendum. What I called as “unique diversification value” is usually the UID of the card or some other constant which is unique for the card in the field. There exists an application note from NXP where the key diversification is explained:

    https://www.nxp.com/docs/en/application-note/AN10922.pdf

    The TapLinx team

    + 1  |  - 0

    Re: Reply To: Nfc service ocassionaly stops working upon receiving error during card reading

    3. November 2020 at 14:46
    in reply to: Nfc service ocassionaly stops working upon receiving error during card reading
    This post was sent twice.
    It is answered in the first.

    + 0  |  - 0

    Re: Reply To: Nfc service ocassionaly stops working upon receiving error during card reading

    3. November 2020 at 14:45
    in reply to: Nfc service ocassionaly stops working upon receiving error during card reading
    Hi Michal,

    The MIFARE Ultralight and the MIFARE Classic uses ISO/IEC 14443-3 protocol (the “-3” is important). This means, if an error occurs or an invalid key was used, the card goes into internal HALT state and terminate any communication. But this should not shutdown the whole NFC communication on your device! Here you must remove the card from reader (this will reset the card) and put into the field again.

    For me it seems that this is an issue in the middleware. Can you check your software on a different device (a different manufacturer)? If both devices behaves different you can identify this as firmware issue. As Android developer you should test your software on so many different devices as possible to prevent device specific issues.

    The TapLinx team

    + 0  |  - 0
Viewing 15 posts - 1 through 15 (of 1,077 total)