| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In some situations, the working buffer may be full and some packets
are stored in the receive window when trying to read from upper
layer.
In this case, the receive function first reads data from the working
buffer and if possible, also tries to read data stored in the receive
window. The previous receive window data extraction algorithm could
lead to an infinite loop. With this fix, we can ensure that this won't
happen any more.
Change-Id: Iddb412213f4e9cb5fb42691bd282dbf0a21a936e
|
|\ \ \ \
| |/ / / |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Send failures on LLCP sockets were not dealt with at all - the transport
was just left in a state where it thought there was a pending send
and a pending callback. Before we typically only did one send and
it didn't bite us so much, but now with multiple sockets we run
into this frequently.
This really just fixes part of the problem - we should also look
if state rollbacks are necessary, as those are not done either
on send failures.
Change-Id: I484ca598e043ead835251aedaabe47d3a1da7a8f
|
|\ \ \ \
| |/ / /
|/| / /
| |/ /
| | |
| | |
| | | |
on Multiple protocol TAG
* commit '0c4a5508f22e067ab9b31581807b53406d161501':
Patch to support multiple connection on Multiple protocol TAG
|
| |\ \
| | |/
| | |
| | |
| | | |
* commit '34caeca8a5ec2aedade68a77393d0aff03f9bd72':
Patch to support multiple connection on Multiple protocol TAG
|
| | |
| | |
| | |
| | | |
Change-Id: I0f09869458ebbc6d77363338975754335569b6a6
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixed the SAP automatic allocation algorithm which could previously
allocate the same SAP twice in some situations (e.g.: if first socket
in socket table was bound to SAP 0x21 and second socket to 0x20, then
autobind was allocating SAP 0x21 again).
Change-Id: Ic94bbc7eaca260c69cb0ce22931e9241f459bbf5
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Bug: 4492175
Change-Id: I7f85fc32bfaabeac8fa4da6c1509992d5523afa3
|
|/ / /
| | |
| | |
| | |
| | |
| | | |
This is to support 32 byte FW download.
Change-Id: Id27e7d2673c37aab02d98fcbac9031af6153fea0
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 294b456a3692cd69f45713bc8e9700132a0e5aec.
@#$% the pn544.
This patch to execute FW download mode with 64 byte frames has some kind of
side-affect. It causes the pn544 to send
> NFC I2C Received buffer: 0xB2 0x83 0x53 0xC9 0x6B
every 2 seconds. We do not yet know what this command means, it is undocumented.
This side affect appear permanent - even after reverting to a 512 byte FW
download, the NFC controller continues to send these messages.
Reverting ASAP to minimize damage.
Change-Id: I139a4a76c045f580df9760dc11d1c6df7b317a50
|
| | |
| | |
| | |
| | |
| | |
| | | |
This was preventing reliable FW download.
Change-Id: I28e5cb1e5855974f51578f5d45f2c581a75b2d07
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This patch permit to decrease the max packet size to 64 bytes from 512 bytes and
to fix an issue faced in response_data buffer with the new packet size.
Change-Id: Ifc5cc9910b3b1a71b88624cd04c2bada7f1a413f
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
|\ \ \
| |/ /
| | |
| | |
| | |
| | |
| | | |
firmware events
* commit '51c0ca53011b86464dcf14aeb33944a69861a8f4':
Patch to support the new PN544 firmware events
|
| |\ \
| | |/
| | |
| | |
| | | |
* commit '967359c892ff74962b4f4243d989f447ffe4ae11':
Patch to support the new PN544 firmware events
|
| | |
| | |
| | |
| | | |
Change-Id: I6e5a976721fb52f2da30081276bb2ac15d27d186
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This patch enables windowing of LLC packets send from chipset to host.
The host will now wait for up to 4 LLC packets from the chipset before
sending an ACK (S-Frame RR).
Change-Id: I6a70e1d780847a104e3ec8e403593a69e222aec9
|
| | |
| | |
| | |
| | | |
Change-Id: Id1ab6a1176fe4e7c559e2348261d0902bdffb03c
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Also clean up some UART and I2C DAL functions.
o Re-enable FW download
o Use /system/vendor/firmware for pn544 firmware now
o Clean up read() and write() paths for both I2C and UART
o Use new sysfs entry for power and FW control on I2C platforms
o Remove userspace sleep()'s on power control toggle. They are now
done in the kernel as they should be.
Change-Id: I39956d36e02c1eb526a5c546bd3cb74edce4ff18
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
o Fix uart read() implementation
o Temporarily disable firmware update
o Rename ttySx to ttyOx (this should be properly abstracted later)
o Bug fix in #ifdef code
o Update verbose logging arguments
Change-Id: I87814e2be9ddbf5036d5586a2fd82311d56ec47f
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Adds an interface for setting the NfcA timeout, which
is called "mifare raw" in libnfc. Also changed the default,
since it was set to only 2 ms, which is too short for most
commands. Current setting is around 600ms.
Change-Id: I00ccd85cd47a70895a3aca0f0bc34e1b0eab82c7
|
|\ \ \
| |/ /
| | |
| | |
| | |
| | |
| | | |
firmware cannot be loaded."
* commit '055a5f9542ba8fcfd2972111b707049732255ebe':
Prevent NFC crash-loop if firmware cannot be loaded.
|
| |\ \
| | |/
| |/|
| | |
| | | |
* commit '80c2d4090d6292a3fd2e20a18a981bc19e0a0429':
Prevent NFC crash-loop if firmware cannot be loaded.
|
| | |
| | |
| | |
| | |
| | |
| | | |
Don't crash - just run off whatever firmware is in the chip now.
Change-Id: I0d24c13452271aed63a5a0aea236db7b1cbd432c
|
|\ \ \ |
|
| |/ /
| | |
| | |
| | | |
Change-Id: I1a88ae0807d5ba53a635e31f3c5284906bd40ea2
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Always add a ISO14443-3A device handle for tags that are
found through the A-gate. This allows the upper stack
to connect and maintain a connection to the NfcA technology,
even if the tag has IsoDep on top of NfcA. The reason this
can work is that libnfc does do the IsoDep activation in
software, and if the NfcA target is on a separate handle
this activation will not take place if you connect to
this handle.
Bug: 4195403
Change-Id: I00015e74bdadc6666c2971f8102244670a76e340
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
At some points, the V(RA) socket counter (used for Receive Window
checking in connection-oriented sockets) was not properly updated,
thus leading to sometimes reject (FRMR) inbound I-frames with valid
sequence numbers.
This patch factorize the I-frame emission and update V(RA) in the
factorized code to ensure this is done at any time.
Change-Id: Ic7ef92cb136c32e524a14e31a8d350f7b165c367
|
| |
| |
| |
| |
| |
| |
| | |
This patch permit to display the NFC frames exchanged through the I2C line.
To enable that, you just need to enable LOW_LEVEL_TRACES macro.
Change-Id: Ica2ff2e6d111b76c056161ec557346f23d21ada0
|
|/
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a NFCIP frame is received (NXP_EVT_NFC_RCV_DATA event) before a call to
phHal4Nfc_Receive() function, the frame was lost. This could happen if the local
host acts as a Target and the remote peer sends its first frame too fast.
The data is actually saved in a temporary buffer but, when the phHal4Nfc_Receive()
is eventualy called, it triggers a callback with a status code
NFCSTATUS_MORE_INFORMATION, which is handled as an error.
This patch fixes this behaviour and makes sure that the correct status
code is provided with the frame itself.
Change-Id: I5311762ca70c71f98dea0287b0844eb1c8dddb6b
|
|
|
|
|
|
|
|
|
|
|
| |
The LLCP specification defines that if a TLV cannot be interpreted,
it shall be ignored rather than generating an error.
This patch removed all error reporting on TLV interpretation. The
only error that can still happen is length inconsistency in the
whole TLV array buffer.
Change-Id: Ibf289fceb2283bfddcdc0ddee9e687ece3e90887
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The parsing algorithm for AGF frames has been fixed. It was previously
only working if aggregated frames were 4-bytes long.
The current stack only support mandatory de-aggregation. It does not
send aggregated frames, so there won't be interop issue with previous
versions.
This fix prevents reading erroneous de-aggregated frames and rejecting
them using FRMR when communicating with an LLCP implementation
using aggregation mechanism.
Change-Id: Ia5728496a2917b6a57f478cc51dc0aaa0fcc165a
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
P2P target 106 passive appears as an ISO 14443-3A target to reader/writers
in the field. This can confuse some terminals, especially when we also have
card emulation turned on, since it looks like we have two -3A targets in
the field.
P2P target 106 passive is just one of many P2P sub-modes. We do not know of any
P2P devices that only initiate using only 106 passive, so this should not
present inter-op issues.
Change-Id: I1cb84ed791a86a7f225a51806e99bab031dcb6ca
|
| |
|
|
|
|
| |
Change-Id: I2a7a185ead5de8f2b165c81dcc8ab8fb46c1ddc0
|
|
|
|
|
|
| |
This patch allows reading and writing of NDEF messages on ICODE tags.
Change-Id: I43b4845c898c2bf268f609a5a81e991460059ff6
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During extensive testing we found that some ISO15693 tags do not react
to some commands. However, they do send an error code to the PN544 indicating
they do not support the command. The PN544 in turn sends one specific error code
over the HCI interface. However, libNFC maps that error code always
to NFCSTATUS_TARGET_LOST, which in the end maps to the application API reporting
a TargetLostException.
This fix maps only the timeout return values from the PN544 to NFCSTATUS_TARGET_LOST;
all other values are mapped to NFCSTATUS_FAILED, which in turn maps to an
IOException at API level.
In effect, a timeout is still not the same as a target lost; libNFC does not do any
additional internal presence check to make sure the tag is really gone, although
it usually is. I'll submit a separate fix on packages/apps/Nfc to take care of this.
Change-Id: If64857658d683aff29134f74b42efd99b695e634
|
|
|
|
|
|
|
|
| |
Wired Mode.
This fix permit to detect the Secure Element in Wired Mode, even we are in front of a RF Reader
Change-Id: I8f87e043ff24724addd179ce025cf3d038a82a5e
|
|
|
|
| |
Change-Id: I57eaa3ccd65b89510e198f7ebf24f7266c4dad2e
|
|
|
|
| |
Change-Id: If6b490d906fcc37960a1120e9344470d68c825f6
|
|
|
|
|
|
|
|
|
|
| |
This allows for reading/writing more than 255 bytes of NDEF data on an
NFC Forum Type 2 tag.
This fix overrides https://partner.source.android.com/g/#change,4907 ,
since that fix only worked for reading.
Change-Id: I7fb2ea1bc04f35ba6e6be56e0c89abab567e3ac7
|
|
|
|
|
|
| |
This should avoid calling a irrelevant callback at abort.
Change-Id: Ied8d54268613f248fd505d4b25d0ab8a0905a336
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The phLibNfc_Llcp_Send() function is expected to trigger a callback
when the packet is actually sent but, in some situations, the callback
was triggered by another frame sending (such as RR or DM frames).
This patch fixes the following socket internal flags handling:
- pfSocketSend_Cb: set to non-NULL value when a send operation is
pending,
- bSocketSendPending: set to TRUE if the LLCP link layer is not
available for sending and reset to FALSE once the frame is
actually forwarded to the LLCP link layer.
The send callback triggering has been updated to ensure it is only
done for the expected data frame (i.e.: send pending and already
forwarded to link layer).
Change-Id: Id7410ee4075fbbbc9de382abf54e89a97f6a8b37
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Moved data allocation from stack memory to heap in order
to avoid invalid memory access.
Previously, When trying to send a DM (acknowledgment to
socket disconnect request), the stack was allocating some
frame data on the stack but these data were used after the
function returned.
Other calls to the same function are already using variables
allocated on heap.
Change-Id: Id7356a876fdecdd979ed3ddc6dbe100d6e92d43d
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
The correct behavior of asynchronous functions should be:
Immediate operation => function returns with success/error status,
callback never invoked
Delayed operation => function returns with pending status,
callback is invoked at the end of operation
Some minor fixes are also included in this commit (code style).
Change-Id: Ieb801ab759045c5c5d9fc59b4715f3c142d5b33e
|
|
|
|
|
|
|
|
|
| |
The listen callback is a notification callback, not an
end-of-operation callback so, when the socket is closed,
it should not be triggered since there is no connection
event.
Change-Id: I6e6994f6bcb09f9fadda04800d22528d76aff121
|