devel@lists.zephyrproject.org

Re: Adding own Library to project

König Patrick <Patrick.Koenig@...>

I solved it. I made a mistake while moving some of the function to the separated module. 
While preparing the example I noticed, that some of the functions in the USB CDC_ACM example, which I used as a base for my project, were declared as static, which I did not notice. 
When I added them to my lib, I did not see the static keyword and I forgot to remove it.  This functions gave me the errors as described. 

I apologize for my mistake and I want to thank all of you for your help.

Patrick

-----Ursprüngliche Nachricht-----
Von: Bøe, Sebastian [mailto:Sebastian.Boe@...] 
Gesendet: Donnerstag, 14. Juni 2018 14:39
An: König Patrick <Patrick.Koenig@...>; Li, Jun R <jun.r.li@...>; Patrick Boettcher <patrick.boettcher@...>
Cc: zephyr-devel@...; Sittkus Manuel <Manuel.Sittkus@...>
Betreff: Re: [Zephyr-devel] Adding own Library to project

As far as I am able to understand your description, this is expected to work.

Perhaps you could share a minimal patch to an existing sample to demonstrate when the linker error occurs.

________________________________________
From: devel@... <devel@...> on behalf of König Patrick <Patrick.Koenig@...>
Sent: Thursday, 14 June 2018 10:32:43 AM
To: Li, Jun R; Patrick Boettcher
Cc: zephyr-devel@...; Sittkus Manuel
Subject: Re: [Zephyr-devel] Adding own Library to project

Thanks a lot for your help. I have tried your suggested solution with the CMakeList. Unfortunately, this did not work for me. I got the linker errors as described in my initial mail.

Let me try to illustrate my problem in a bit more detail:

If I add two function to my main.c file, for example usb_send() and usb_receive(), my code works fine. Once I move these functions to independent files like usb_xyz.c for the source and usb_xyz.h for the headers and include the header file in the main.c file, I am no longer able to link my project.

Usually I just need to include usb_xyz.h to my main.c file and add the usb_xyz.c and usb_xyz.h to a Makefile. With Cmake however, I added the usb_xyz.c file to the CMakelist and included header file in my main.c file, which leaves me with linker errors, like undefined reference to usb_send() and usb_receive().
I checked the compiler output, and saw the following line:  “Building C object CMakeFiles/app.dir/src/usb_xyz.c.obj”, which leads me to believe that the file was compiled.

I hope this example makes my issue a bit clearer. Basically I just want to create modular Code that I can reuse in other zephyr projects as well.

Regards,

Patrick

-----Ursprüngliche Nachricht-----
Von: Li, Jun R [mailto:jun.r.li@...]
Gesendet: Mittwoch, 13. Juni 2018 16:59
An: Patrick Boettcher <patrick.boettcher@...>
Cc: König Patrick <Patrick.Koenig@...>; zephyr-devel@...; Sittkus Manuel <Manuel.Sittkus@...>
Betreff: Re: [Zephyr-devel] Adding own Library to project

That is true, this way doesn't support adding a driver module into the application since the app doesn't directly call anything from the driver. I'm wondering why driver modules in zephyr directory can be linked even without specifying dependency relationship. How is a driver module in Zephyr directory linked together?

﻿On 6/13/18, 07:53, "devel@... on behalf of Patrick Boettcher" <devel@... on behalf of patrick.boettcher@...> wrote:

    On Wed, 13 Jun 2018 14:45:43 +0000
    "Li, Jun R" <jun.r.li@...> wrote:

    > Hi Patrick,
    >
    > If you still want to keep your library (module), another way you can
    > do is to add your library as the link dependency for the application
    > library (app) by the following:
    >
    > target_link_libraries(app your_lib_name)

    Well, this way of doing bears a whole of problems in some conditions.

    While it works in probably most cases, including drivers in such a
    library won't work.

    Link-order sometimes messes up things as well if your library requires
    zephyr functions from libraries where explicit dependencies was
    not/could not be declared.

    Sebastian is working on it, there is an issue on github's page for it.

    --
    Patrick.

Why is the CMake-architecture as it is?

Patrick Boettcher <patrick.boettcher@...>

#4776

Hi,

first a disclaimer: I was not there yet when it was decided to go with
CMake replacing what was there before in zephyr. I'm a big user of
CMake.

And with all my ignorance as to why things have been designed as they
are, I must say that I find the CMake-architecture quite complicated
and little bit limited to users.

In my project I'm suffering from different problems
(out-of-tree-drivers, binary-delivery of libraries to clients and other
things). With quite some acrobatics I'm getting what I want, but not
without kludges. These are directly related to the way zephyr imposes
things on the user.

I'm sure there are good reasons why it is like that, very good people
have been working on it.

Could someone point me to the mail-archives and the time-period when
this was discussed - I tried the archives, but might have not dug
deep enough.

Some of my questions are:

Why are we not using toolchain-files for cross-compilation, but
instead are doing the linking "ourselves" by overriding CMake-variables
where the documentation is saying do not override them (well almost)?

Using the standard CMake way of building and linking would give me all
the flexibility I need to face my problems, and I believe we could
still have the app built as it is done today.

The current way of building things limits the build of one application
with one zephyr-build. I understand that for the vast majority this is
enough. I, however, would love to build several apps with one zephyr
build.

Thanks for any response in advance.

best regards,
--
Patrick.

Re: How does the app get notified if authentication failed?

Li, Jun R

#4775

Hi Johan, 
Thanks for help! 

It seems the function " pairing_complete" in your proposal is enough to cover both failure and success cases, with the parameter "bool bonded", right? 

And I'm not sure why it is not proper to place the new api function in the API " bt_conn_auth_cb". Can you explain it a bit more? 

Sure I'll create a new issue to request this. 

Regards, 
Jun 


﻿On 6/14/18, 02:58, "Johan Hedberg" <johan.hedberg@...> wrote:

    Hi Jun,
    
    On Wed, Jun 13, 2018, Li, Jun R wrote:
    > In my BLE project, a passkey is required to access the NRF51 device;
    > thus the callback functions of “struct bt_conn_auth_cb” were
    > implemented to achieve secured paring. What I observed is that
    > 
    >   1.  The function “cancel” will be called if the other peer canceled
    >   the pairing process.
    >   2.  The function “security_changed” will be called if the passkey
    >   was successfully entered.
    
    The second one is a bit ambiguous, since it'll also be called for
    subsequent connections when the connection gets encrypted, even though
    pairing is not in progress (it already happened over some earlier
    connection).
    
    > However, my application was NOT notified if a wrong passkey was
    > entered, thus the BLE connection is still kept. Ideally, I hope to
    > immediately disconnect the connection if the passkey is wrong.
    > However, I can’t find a callback function to notify the application if
    > the passkey was wrong.
    > 
    > With more debugging logs, I can see the function
    > “smp_pairing_complete” got status (-4) when pairing failed while this
    > status is zero when successful.
    > 
    > Can anyone enlighten me what kind of function can be used to notify
    > the application that pairing failed?  Thank you!
    
    This seems to be an oversight in the API. I'd propose to add two new
    entries to bt_conn_auth_cb, something like the following:
    
    	void (*pairing_complete)(struct bt_conn *conn, bool bonded);
    	void (*pairing_failed)(struct bt_conn *conn);
    
    For the second one we might want to add another parameter for the
    reason. An SMP error comes to mind, but then that wont be reusable for
    BR/EDR (which we have experimental support for).
    
    Actually, now that I think about it, bt_conn_auth_cb could be
    problematic since it's possible to do just-works pairing without
    registering such a structure. I wonder if our bt_conn_cb would be
    better. That said, these callbacks are strictly about pairing..
    
    Could you open a github issue to track this, so we get it done for 1.13?
    
    Johan

Re: Different BLE pairing behaviors on iPhone 6 and iPhone 7

Carles Cufi

#4774

Yes, that is exactly it.

In that case I am not sure about the issue. Perhaps Johan can bring some light into it.

Carles

From: "Li, Jun R" <jun.r.li@...>
Date: Thursday, 14 June 2018 at 17:32
To: "Cufi, Carles" <Carles.Cufi@...>, "devel@..." <devel@...>
Subject: Re: Different BLE pairing behaviors on iPhone 6 and iPhone 7

Yes, every time when I did the tests, I let iPhone “forget the device”, which I suppose to erase the bond info, right?

Regards,

Jun

From: "Cufi, Carles" <Carles.Cufi@...>
Date: Thursday, June 14, 2018 at 08:29
To: Jun Li <jun.r.li@...>, "devel@..." <devel@...>
Subject: RE: Different BLE pairing behaviors on iPhone 6 and iPhone 7

Hi there,

Have you tried erasing the bond from iOS settings? I find that sometimes bonding fails if the device is already bonded, for whatever reason.

Regards,

Carles

Show quoted text

From: devel@... <devel@...> On Behalf Of Li, Jun R
Sent: 14 June 2018 17:23
To: devel@...
Subject: [Zephyr-devel] Different BLE pairing behaviors on iPhone 6 and iPhone 7

Hi everyone,

I’m trying to test the secured pairing with a NRF51 device by using an iPhone 6 and 7, and noticed different behaviors on different phones:

iPhone 7: secured pairing is always successful.

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 2d4b2a7aa0172202b7ae895f0e7e89eb cfm 2d4b2a7aa0172202b7ae895f0e7e89eb

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 23b40cb4113ebf87a79eee3322c405a0

[bt] [DBG] bt_smp_encrypt_change: (0x20001908) chan 0x2000093c conn 0x20000684 handle 0 encrypt 0x01 hci status 0x00

Security changed: 69:2e:88:bc:dd:7f (random) level 3

iPhone 6: paring always fails with the following errors:

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 66ff28447187fdc8964f3aa4024912fe cfm 66ff28447187fdc8964f3aa4024912fe

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 60c3fed7191023bf5b38969ac8a383f5

[bt] [ERR] bt_smp_update_keys: Unable to get keys for 6c:82:85:45:2a:97 (random)

[bt] [DBG] smp_pairing_complete: (0x20001908) status 0x8

It seems most logs are almost same except that an error occurred (in red color) when pairing is initiated by iPhone 6. I’m using the “BT_SECURITY_MEDIUM” level for security setting.

Can anyone point me to what makes the difference between iPhone 6 and iPhone 7? Both phones are running on the same software version: 11.4.

More logs can be referred below. Thank you!

Regards,

Jun

Pairing results with iPhone 7:

[bt] [DBG] bt_smp_accept: (0x20001908) conn 0x20000684 handle 0

[bt] [DBG] bt_smp_connected: (0x20001908) chan 0x2000093c cid 0x0006

Connected

[bt] [DBG] bt_smp_send_security_req: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x01 len 7

[bt] [DBG] smp_pairing_req: (0x20001908)

[bt] [DBG] smp_init: (0x20001908) prnd cd01fcf3ecfda76163f273083a8ae3ea

[bt] [DBG] legacy_pairing_req: (0x20001908)

Passkey for 69:2e:88:bc:dd:7f (random): 043945

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x03 len 17

[bt] [DBG] smp_pairing_confirm: (0x20001908)

[bt] [DBG] legacy_pairing_confirm: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r cd01fcf3ecfda76163f273083a8ae3ea

[bt] [DBG] smp_c1: (0x20001908) ia 69:2e:88:bc:dd:7f (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce7fddbc882e6900000000

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x04 len 17

[bt] [DBG] smp_pairing_random: (0x20001908)

[bt] [DBG] legacy_pairing_random: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r 6dbcecdc91beea980b22d3987165e432

[bt] [DBG] smp_c1: (0x20001908) ia 69:2e:88:bc:dd:7f (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce7fddbc882e6900000000

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 2d4b2a7aa0172202b7ae895f0e7e89eb cfm 2d4b2a7aa0172202b7ae895f0e7e89eb

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 23b40cb4113ebf87a79eee3322c405a0

[bt] [DBG] bt_smp_encrypt_change: (0x20001908) chan 0x2000093c conn 0x20000684 handle 0 encrypt 0x01 hci status 0x00

Security changed: 69:2e:88:bc:dd:7f (random) level 3

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x06 len 17

[bt] [DBG] smp_encrypt_info: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x07 len 11

[bt] [DBG] smp_master_ident: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x08 len 17

[bt] [DBG] smp_ident_info: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x09 len 8

[bt] [DBG] smp_ident_addr_info: (0x20001908) identity 40:4d:7f:a6:0f:7e (public)

Identity resolved 69:2e:88:bc:dd:7f (random) -> 40:4d:7f:a6:0f:7e (public)

[bt] [DBG] smp_pairing_complete: (0x20001908) status 0x0

Paring results with iPhone 6

[bt] [DBG] bt_smp_accept: (0x20001908) conn 0x20000684 handle 0

[bt] [DBG] bt_smp_connected: (0x20001908) chan 0x2000093c cid 0x0006

Connected

[bt] [DBG] bt_smp_send_security_req: (0x20001908)

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x01 len 7

[bt] [DBG] smp_pairing_req: (0x20001908)

[bt] [DBG] smp_init: (0x20001908) prnd 6ec402b8025b75b991b7ae84ff139f5a

[bt] [DBG] legacy_pairing_req: (0x20001908)

Passkey for 6c:82:85:45:2a:97 (random): 043945

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x03 len 17

[bt] [DBG] smp_pairing_confirm: (0x20001908)

[bt] [DBG] legacy_pairing_confirm: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r 6ec402b8025b75b991b7ae84ff139f5a

[bt] [DBG] smp_c1: (0x20001908) ia 6c:82:85:45:2a:97 (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce972a4585826c00000000

[bt] [DBG] bt_smp_recv: (0x20001908) Received SMP code 0x04 len 17

[bt] [DBG] smp_pairing_random: (0x20001908)

[bt] [DBG] legacy_pairing_random: (0x20001908)

[bt] [DBG] smp_c1: (0x20001908) k a9ab0000000000000000000000000000 r 4ae51a076090285b947bfbb98819933b

[bt] [DBG] smp_c1: (0x20001908) ia 6c:82:85:45:2a:97 (random) ra ce:e4:6d:15:ac:0f (random)

[bt] [DBG] smp_c1: (0x20001908) preq 01040005100303 pres 02000005100301

[bt] [DBG] smp_c1: (0x20001908) p1 01010104000510030302000005100301

[bt] [DBG] smp_c1: (0x20001908) p2 0fac156de4ce972a4585826c00000000

[bt] [DBG] legacy_pairing_random: (0x20001908) pcnf 66ff28447187fdc8964f3aa4024912fe cfm 66ff28447187fdc8964f3aa4024912fe

[bt] [DBG] legacy_pairing_random: (0x20001908) generated STK 60c3fed7191023bf5b38969ac8a383f5

[bt] [ERR] bt_smp_update_keys: Unable to get keys for 6c:82:85:45:2a:97 (random)

[bt] [DBG] smp_pairing_complete: (0x20001908) status 0x8

Re: Different BLE pairing behaviors on iPhone 6 and iPhone 7

Li, Jun R

#4773