During processing incoming RSET frame chip, possibly due to
its internal timout, can retrnasmit an another RSET which
is next queued for processing in shdlc layer.
In case when we accept processed RSET skip those remaining on
the rcv queue until chip will send it's first S or I frame.
This will mean the chip completed connection as well.
Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
Signed-off-by: Samuel Ortiz <[email protected]>
As queue_work() does not guarantee immediate execution of sm_work it
can happen in crossover RSET usecase that connect timer will constantly
change the shdlc state from NEGOTIATING to CONNECTING before shdlc has
chance to handle incoming frame.
Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
Acked-by: Eric Lapuyade <[email protected]>
Signed-off-by: Samuel Ortiz <[email protected]>
xmit callback provided by a driver encapsulates upper layers
data and sends it to the hardware. So, HCI does not know the
exact amount of data being sent and thus can't handle partially
sent frames properly.
Therefore, the driver must return 0 for completely sent frame or
negative for failure.
Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
Acked-by: Eric Lapuyade <[email protected]>
Signed-off-by: Samuel Ortiz <[email protected]>
Driver must handle its data added to the frame, so at this point
removeing control field of shdlc frame is enough.
Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
Acked-by: Eric Lapuyade <[email protected]>
Signed-off-by: Samuel Ortiz <[email protected]>
Checksum is specific for a chip spcification and it varies
(in size and type) between different hardware. It should be
handled in the driver then.
Moreover, shdlc spec doesn't mention crc as a part of the frame.
Update pn544_hci driver as well.
Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
Acked-by: Eric Lapuyade <[email protected]>
Signed-off-by: Samuel Ortiz <[email protected]>
Checking conn->pending_sec_level if there is no connection leads to potential
null pointer dereference. Don't process pin_code_request_event at all if no
connection exists.
Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
Acked-by: Marcel Holtmann <[email protected]>
Signed-off-by: Gustavo F. Padovan <[email protected]>
If the link key is secure (authenticated or combination 16 digit)
the sec_level will be always BT_SECURITY_HIGH. Therefore, instead
of checking the link key type simply check the sec_level on the link.
Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
Signed-off-by: Gustavo F. Padovan <[email protected]>
As we cannot relay on a userspace mgmt api implementation we should verify
if pin_code_reply in fact contains the secure pin code.
If userspace replied with unsecure pincode when secure was required we will
send pin_code_neg_reply to the controller.
Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
Signed-off-by: Gustavo F. Padovan <[email protected]>
Replace if(conn) with if(!conn) checking to avoid too many nested statements
Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
Signed-off-by: Gustavo F. Padovan <[email protected]>
Legacy devices don't re-authenticate the link properly if a link key
already exists. Thus, don't update sec_level for this case even if
hci_auth_complete_evt indicates success. Otherwise the sec_level will
not reflect a real security on the link.
Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
Signed-off-by: Gustavo F. Padovan <[email protected]>
In case of pre v2.1 devices authentication request will return
success immediately if the link key already exists without any
authentication process.
That means, it's not possible to re-authenticate the link if you
already have combination key and for instance want to re-authenticate
to get the high security (use 16 digit pin).
Therefore, it's necessary to check security requirements on auth
complete event to prevent not enough secure connection.
Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
Signed-off-by: Gustavo F. Padovan <[email protected]>
Extend the mgmt_pin_code_request interface to require secure
pin code (16 digit) for authentication.
This is a kernel part of the secure pin code requirement notification
to user space agent.
Code styling fix by Johan Hedberg.
Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
Signed-off-by: Johan Hedberg <[email protected]>
Signed-off-by: Gustavo F. Padovan <[email protected]>
If host requires MITM protection notify that to controller in
io capabilities reply even if the remote device requires no bonding.
If it is not respected, host can get an unauthenticated link key while
it expects authenticated one.
Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
Signed-off-by: Gustavo F. Padovan <[email protected]>
High security level for pre v2.1 devices requires combination link key
authenticated by at least 16 digit PIN code.
It's also necessary to update key_type and pin_length when the key
exists and is sufficently secured for the connection as there will be
no link key notify event in that case.
Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
Signed-off-by: Gustavo F. Padovan <[email protected]>
Keep the link key type together with connection and use it to
map security level to link key requirements. Authenticate and/or
encrypt connection if the link is insufficiently secure.
Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
Signed-off-by: Gustavo F. Padovan <[email protected]>
If authentication fails the security level should stay as it was set
before the process has started. Setting BT_SECURITY_LOW can hide real
security level on a link eg. having BT_SECURITY_MEDIUM on the link,
re-authenticate with failure to get BT_SECURITY_HIGH, as a result we
get BT_SECURITY_LOW on the link while the real security is still medium.
Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
Signed-off-by: Gustavo F. Padovan <[email protected]>
Introduce the link key types defs and use them instead of magic numbers.
Signed-off-by: Waldemar Rymarkiewicz <[email protected]>
Signed-off-by: Gustavo F. Padovan <[email protected]>
