microsoft / nfc-class-extension-driver Goto Github PK

The NFC Class Extension driver implements all NFC device driver interfaces and standard NFC protocols and formats based on the NFC Forum NFC Controller Interface (NCI) Technical Specification

License: Other

C++ 25.96% C 74.04%

nfc-class-extension-driver's Introduction

NFC class extension (CX) design guide

The NFC CX driver implements all NFC device driver interfaces and standard NFC protocols and formats based on the NFC Forum NFC Controller Interface (NCI) Technical Specification.

The NFC client driver is responsible for transport layer interfacing as well as support for any non-standard vendor-defined extensions for the optimized functioning of the NFC controller.

The NFC class extension driver implements all standard NFC Forum Tag (T1T, T2T, T3T, ISO-DEP) and P2P (LLCP and SNEP) protocols, and RF Management based on the NCI Core specification. The class extension driver implements all the Windows-defined device driver interfaces to interact with the NFC controller, Secure Elements, and Remote RF endpoints.

These topics describe the architecture and public interface between the NFC class extension driver supplied by Microsoft and the NFC client driver supplied by the corresponding chipset manufacturers. The NFC CX driver is designed to support NFC chipsets from various manufacturers, and enables manufacturers to implement non-NCI standard functionality in their NFC client driver for differentiation purposes.

NFC driver DDI

The following are the Windows-defined NFC driver DDI that are implemented by the NFC CX driver:

Near Field Proximity DDI
NFC Secure Element Management DDI
Smart Card DDI for contactless smart card access
NFC Radio Management DDI
DTA DDI for NFC Forum certification

NFC forum specifications

The following are the NFC Forum specifications implemented by the NFC CX driver:

NFC Controller Interface, NCI 1.0 Specification
NFC Data Exchange Format, NDEF
NFC Forum Type 1-4 Tag
Logical Link Control Protocol, LLCP 1.1 Specification
Simple NDEF Exchange Protocol, SNEP 1.0 Specification
ISO/IEC 15693

Supported NFC smart cards and tags

The following are the NFC smart cards and tags supported by the NFC CX driver:

MIFARE Classic family
MIFARE Ultralight family
MIFARE DESFire family
FeliCa family
Jewel/Topaz family
Generic ISO 15693 tags

Contributions

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

nfc-class-extension-driver's People

Contributors

Stargazers

Watchers

nfc-class-extension-driver's Issues

missing the definitionh of DEV_QUERY_RESULT_ACTION_DATA

Dear sir

I am trying to make use of the following API and shall be most grateful if you could me a sample codes of the following APis for my reference:

CFGMGR32.DLL:DevGetObjectProperties
CFGMGR32.DLL:DevCreateObjectQuery

as well as the structur eof tthe follwoing:
DEV_QUERY_RESULT_ACTION_DATA

Many thanks.

Cheers.

Jack

NfcCx reject ISO15693 tags with generic memory area size

When NDEF formatting an ISO15693 tag, phFriNfc_ISO15693_H_ProFormat will return NFCSTATUS_INVALID_DEVICE_REQUEST if the max_data_size does not match ISO15693_SLI_X_MAX_SIZE or ISO15693_SLI_X_S_MAX_SIZE or ISO15693_SLI_X_L_MAX_SIZE.

The default CC byte 3 value should be set by default to 0.

Additionally is ISO15693_INVENTORY_CMD_MASK is a RFU value following NFC Forum T5T specification.

Unneeded 30ms delay at NfcCx initialization waiting for NCI2.0 CORE_RESET_NTF

The 30 ms delay added to wait CORE_RESET_NTF might be unneeded.
The CORE_RESET_NTF could be managed in the NFC Client in the PreInit Sequence portion.
Once received, the sequence could be sequence could signaled as completed to the NfcCx.

NfcCx crash in P2P mode with RF_DISCOVER_NTF

During the NFC Forum Plugfest 2017 in Fremont we found evidence of a NfcCx crash (NULL pointer access).
This is happening in the following conditions at least one RF_DISCOVER_NTF with at least one "RF Technology and Mode" in Poll coming in position 1 or greater.

I have been able to validate a fix but not able to run the HLK again.
Will share a patch for early review.

Tags ST25DV64K are not supported by the NfcCx

During the NFCForum plugfest, we found out that our ST25DV64K are not supported by the NfcCx.
It is using T5T extended commands.
We are waiting for samples to fix that.

Tags ST25DV04K are not supported by the NfcCx

During the NFCForum plugfest, we found out that our ST25DV04K are not supported by the NfcCx.
We are waiting for samples to fix that.

Tags Mifare Desfire EV2 are not supported by the NfcCx

During the NFCForum plugfest, we found out that Mifare Desfire EV2 are not supported by the NfcCx.
We are waiting for samples to fix that.

NFCDEP_OP bit 0 incorrect setting

NFCDEP_OP is by default set as 0x0e.
Following NCI1.x or NCI2.0 specification as well as LLCP 1.1 specification, this setting looks incorrect.
NFCDEP_OP bit 0 (Table 81 in NCI1x and 101 in NCI2.0):

If set to 1b, the NFC-DEP target SHALL NOT send RTOX requests.

In LLCP (1.1) chapter 6.2.1 Restrictions on the use of NFC-DEP item 3:

Waiting Time eXtension (WTX) SHALL not be used.
This configuration can be forced in the NFC Client but we believe it is an incorrect setting.

LoadKey Overwrite always returns status as (00,00)

From any PCSC App ( for instance SpringCard ) , if we send transceive for Load key ( INS -'82') for same P1 & P2 , from 2nd transceive onward, CLX driver returns status is 00, 00 (SW1, SW2).

CMD: FF 82 00 00 06 FF FF FF FF FF FF
RSP: 90 00
CMD: FF 86 00 00 05 01 00 04 60 00
RSP: 69 81
CMD: FF 82 00 00 06 04 07 06 05 07 0F
RSP: 00 00

Tag : Mifare Classic (1K)

[Improvement] Manage least LA_SEL_INFO & LF_PROTOCOL_TYPE using RfDiscoveryConfig

LA_SEL_INFO b6 might be only be set in case we enable NFC_CX_NFCIP_TGT_NFC_A (and NFC_CX_NFCIP_TGT_NFC_ACTIVE_A ?)
LF_PROTOCOL_TYPE b1 might be only be set in case we enable NFC_CX_NFCIP_TGT_NFC_F (and NFC_CX_NFCIP_TGT_NFC_ACTIVE_F ?)

I guess other parameters could be configured dynamically the same way (?)

NFC driver doesn't go into low power state (D3) on system going to Modern standby

Need Win10 Desktop PC with connected standby support.
Issue seen in CLX based NFC Client driver.

Steps to repro:

put system into modern standby & resume from Modern standby
Expected results:
NFC driver shown be in D3 when system is in standby & resumes back to D0 when system resumes from connected standby.
Actual results:
NFC driver remains in D0.

Initial Analysis :-
On Modern standby proximity service sends NFP_DISABLE for all open handles.
But ScardSvr handle still remains open as there is no disable for that.
This causes CLX driver to remain in D0 state so do NFC Client driver also remain in D0.

If we stop ScardSvr manually, CLX driver is able to go into low power mode so do NFC Client driver is able to go into low power mode when system goes into Modern standby.

scardsrv_Disabled_Success_ETL.zip
scardsrv_running_Failed_ETL.zip

Logs are attached for success (scardsrv disbaled) & failed (scardsrv running) cases.