| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
On the nrf51, copying the fixed buffer was taking too long for certain
operations. The code changes associated with this commit are due to
this issue.
|
|
|
|
The nimble stack was using mbufs for reception and now uses a
static buffer. The reason behind the change is that we wanted
to be able to receive a frame even though no mbufs were available.
This would allow transmit packets to receive ACKs and thus free
up transmit buffers waiting on connection queues.
There were a number of code changes associated with the phy API.
Implemented a more efficient copy routine to copy words from
the static rx buffer into mbufs. Note that this is not yet done
for transmit frames as we are not sure we could guarantee that
the data pointer is aligned.
|
|
port pin number
|
|
This commit doesn't change any behavior, it just makes it easier to
change UART settings when debugging.
|
|
This bug occurs during secure connections pairing under the following
conditions:
* Initiator
* Pairing algorithm = passkey
The bug is that the host asked the application to input the passkey
before it was ready to accept it. The host was asking for the passkey
immediately after sending its public key, but it isn't ready to accept
it until after the reponder sends its public key. The fix is to wait
until receiving the responder's public key before asking for the
passkey.
This fix isn't ideal. Ideally, the host would continue asking for the
passkey immediately, and would be able to accept it. The easy
short-term fix is to hold off on asking the application.
|
|
|
|
In a previous commit (8b8d887358be1d64e6002fb4efb6b4e0673a1760), the max
event size was reduced from 260 to 45. The belief was that the largest
event the NimBLE controller sends is 45 bytes (advertising report with
one entry, entry has 0x1f data bytes). However, the controller's
response to the read-local-supported-features HCI command is larger:
0x44 + 2 byte header = 0x46 (70).
|
|
Previously, if a peer attempted to enable notifications or indications
for a characteristic that did not support them, the elicited error
response had an error code of 3 (BLE_ATT_ERR_WRITE_NOT_PERMITTED).
Now, the error response has a code of 6 (BLE_ATT_ERR_REQ_NOT_SUPPORTED).
The spec does not appear to indicate the correct error t osend in this
case. I believe req-not-supported is more correct than
write-not-permitted.
|
|
|
|
A previous commit (8ec1b8d9aa8b33a1a26e0d47841331870e97cd88) went a
little overboard in assuming a peer is connected. Some code checks a
peer's MTU without knowing if the peer is connected. A return value of
0 indicates the peer is not connected.
|
|
Merge remote-tracking branch 'bgiori/refactor-services' into develop
* bgiori/refactor-services:
Refactored file structure for premade services.
|
|
Much of the host code repeatedly checks if a peer is connected while it
processes incoming data packets. This is not necessary, because:
1. The peer's connected state is checked at the top level before the
packet is processed.
2. Peer removal and packet processing is done in the same task.
This commit removes a bunch of redundant connectivity checks.
|
|
The host should be configured to allocate the same number of OS events
as there are HCI event buffers. This commit changes the sample apps to
use the RAM transport's configuration to determine how many OS events to
configure the host with.
|
|
For the combined host-controller (RAM HCI transport), the default HCI
event buffer size was much larger than necessary. The largest event the
NimBLE controller will send is 45 bytes, but the default buffer size was
260.
This change:
* reduces the default event buffer size from 260 to 45
* increases the default lo-prio event count from 2 to 12
* increases the default hi-prio event count from 1 to 2
|
|
When the host could not allocate an OS event for the incoming HCI event,
it tried to free the wrong thing, resulting in a null pointer
dereference.
|
|
This fixes a minor bug - the sending of notifications / indications
would cause the tx and rx queues to be processed unnecessarily.
|
|
|
|
|
|
The host would reject an advertising report if it contains a 31-byte
field (maximum size allowed). It was incorrectly limiting fields to 30
bytes.
|
|
Prior to this change, for advertising, connecting, and scanning, the
host didn't update its GAP state until after all HCI commands were sent
to the controller. This creates a race condition, because the
controller may act on the enable command before the host GAP state has
been updated.
For example, as soon as the host tells the controlller to
start scanning, the controller may send an advertisement report event.
If the host has not updated its state yet, the advertising report gets
dropped.
Now, the host updates its state before sending the enable command to the
controller. Unfortunately, this means the host needs to undo the state
update if the enable command fails to be sent.
|
|
While debugging an mbuf leak, I noticed this code was much more
complicated than it needs to be.
|
|
The response has the same contents as the request; only the op code is
different. By reusing the mbuf, it makes failure due to mbuf exhaustion
less likely.
|
|
|
|
|
|
Prior to this change, the HCI transports return code behavior was
inconsistent. Sometimes BLE_ERR codes were returned; other times plain
errno values were returned.
Now only BLE_ERR error codes are returned.
|
|
|
|
An array was missing a '0' terminator.
|
|
When ensuring no mbuf leaks at the end of the att_svr_test suite, also
ensure that each connection's prep list is empty.
|
|
When ensuring that the passage of time causes no effects, the test node
needs to call ble_hs_heartbeat() to let the host know that time has
passed. This is only necessary because the OS is not running during
this test.
|
|
Before, upon receiving a prepare write request, the code was only
verifying that the specified attribute existed. There are a number of
checks that need to be performed in addition to that one:
1. Insufficient authorization.
2. Insufficient authentication.
3. Insufficient encryption key size.
4. Insufficient encryption (check if persisted bond exists for
unencrypted peer).
5. Invalid handle.
6. Write not permitted.
The host does not properly handle 3 and 4 yet (for any writes).
Now the host rejects a prepare write request if any of the above issues
are detected (except for 3 and 4).
|
|
The previous fix didn't fix an mbuf leak. It added one! The real bug
was that an exec-write-response (success) gets sent when a write fails.
This commit fixes the mbuf leak that was introduced.
|
|
This fixes a bug where the GATT client would never send the execute
write command when performing a long-write procedure. Instead, it would
repeatedly send 0-length prepare write requests.
Also, the GATT client is now more strict about when it accepts prepare
write responses and execute write responses. Some unit tests were
passing, despite the bug described in the above paragraph, because an
incoming execute write response was accepted when it should have been.
|
|
This was an mbuf leak. If the device receives an exec-write request,
and the attribute callback fails (or the attribute doesn't allow writes
at all), the mbufs holding the data intended to be written to that
attribute never got freed.
|
|
|
|
Call os_mbuf_prepend_pullup() rather than calling os_mbuf_prepend() and
assuming the resulting buffer is the same as the input.
|
|
This commit does not result in a change in behavior. The fragmentation
code was overly complicated. This change just simplifies the
implementation.
|
|
This fixes a theoretical mbuf leak. In practice, the call to
os_mqueue_put() will never fail.
|
|
This commit does not change any behavior. Some code was re-inventing
os_mbuf_append_from(). Now it just calls the function.
|
|
Prior to this change, both ble_gap_connect() and ble_gap_disc() return
BLE_HS_EALREADY if any master procedure was already in progress (either
connect or discover).
Now, Each function returns:
* BLE_HS_EALREDY if the same procedure is already in progress
* BLE_HS_EBUSY if the other procedure is already in progress
|
|
|
|
This was accidentally included in the initial commit!
|
|
|
|
Events have one of two priorities:
o Low-priority (BLE_HCI_TRANS_BUF_EVT_LO)
o High-priority (BLE_HCI_TRANS_BUF_EVT_HI)
Low-priority event buffers are only used for advertising reports. If
there are no free low-priority event buffers, then an incoming
advertising report will get dropped.
High-priority event buffers are for everything except advertising
reports. If there are no free high-priority event buffers, a request to
allocate one will try to allocate a low-priority buffer instead.
If you want all events to be given equal treatment, then you should
allocate low-priority events only.
Event priorities solve the problem of critical events getting dropped
due to a flood of advertising reports. This solution is likely
temporary: when HCI flow control is added, event priorities may become
obsolete.
Not all transports distinguish between low and high priority events. If
the transport does not have separate settings for low and high buffer
counts, then it treats all events with equal priority.
|
|
This is useful in cases when the mempool is sized according to an
application setting. If the user wants 0 of something, it is easier to
just initialize the mempool with 0 blocks and a NULL buffer, and just
let any attempt to allocate from it to fail.
|
|
|
|
Before, the host code implemented an eventq "peek" operation:
* disable interrupts
* check whether anything is on the eventq
* enable interrupts
* if something was on the queue, call os_eventq_get().
Unlike os_eventq_get(), os_eventq_poll() takes a timeout parameter. Now
the host calls os_eventq_poll() with a timeout of 0 to perform a
non-blocking read of the eventq.
|
|
If the timeout is 0, don't involve the scheduler at all. Grab an event
if one is available, else return immediately.
|
