| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, in LLCP v1.0, the only way to use the SDP (Service
Discovery Protocol) service was to send a CONNECT frame containing
the Service Name to the SDP service. This was implicitly
preforming a connection request to the requested service.
LLCP v1.1 introduced a way to discover services more efficiently
and without implicit connection. It also enables connectionless
services to have a service name. It is based on a new protocol
based on a new SNL frame containing discovery requests and
responses.
This update comes with new APIs:
- phLibNfc_Llcp_DiscoverServices() function can be used to discover
remote services. It can take multiple service names and resolve
all of them in a single call.
- Register service name at bind time. Cache LLCP service name/sap pairs.
In LLCP 1.1 specification defines at section 5.9 that any service
lookup answer must be valid for the whole LLCP session duration.
To enforce this, we cache the SAP/SN pairs locally and make sure
that the applications don't break the cache.
The stack remains fully retro-compatible with v1.0 devices.
Change-Id: I052edd3838013cee65e7415d0ed01fc3e9cad36d
|
| |
|
|
|
|
|
|
|
|
|
| |
LLCP specification mentions that SAP numbers are allocated as follows:
- from 0x00 to 0x0F, used for well-known services
- from 0x10 to 0x1F, used for SDP advertised services
- from 0x20 to 0x3F, used for *non* SDP advertised services
This patch enforce this restriction.
Change-Id: Idd8ab4da4cfa9ad9e2dbf7eddc3c66900bcf9ff8
|
| |
|
|
|
|
|
|
|
|
| |
o Fix most libnfc warnings, from 360 to 18
o Make DAL_DEBUG much less verbose and more useful
o Clean up Android.mk
Done with minimal textual diff to minimize merge conflicts.
Change-Id: I918645500723ff7bb092ad9959628fcabac45bec
|
| |
|
|
|
|
|
|
| |
Valid LLCP Service Access Point values are 0x00 to 0x3F, not 0x2F.
Before this patch, a socket with a local SAP between 0x30 and 0x3F
was unable to communicate (operation callbacks were never called).
Change-Id: Ic3f9b9f353a01e2682e28575152f171d7ec421e4
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before sending a packet, the LLCP stack have to check if the remote
peer is ready to send. To do so, a Receive Window mechanism based on
packet numbering and acknowledgment is used.
Basically, the sender have to make sure that he must have not sent
more than RW-1 unaknowledged frames before sending a new one. This
patch is correcting this test which was failing in some situations.
Change-Id: I525f6b472a909ce48feb938aa02858b9456edc11
|
|
|
Source: Trusted_NFC_Device_Host_AA03.01e02_google.zip code drop (23-Sep-2010)
Change-Id: Ie47f18423f949a8d3e0815d13f55c814312add24
Signed-off-by: Nick Pelly <npelly@google.com>
|
