Re: OIC support

[Kevin Townsend]

me and Paul brought in constrained iotivity stack few months back
to Mynewt, and I probably should send an update what’s going on.

I’ve been working on getting it more fully integrated. My first
goal is to get the code size/RAM usage down.

Just as a FYI for anyone else interested in understanding 
OIC/Iotivity/etc. a bit more, I found this presentation useful to 
highlight the key concepts: 
https://openconnectivity.org/wp-content/uploads/2016/01/OIC_Specification_Overview_201501131.pdf

Re: OIC support

[Kevin Townsend]

That is a good point. There are data models for different
type of sensors/controls over there. I’m see these are at
http://oneiota.org . Acceleration, humidity, temperature 
etc.

This is very useful, and it should be easy to add another layer on top 
of the base driver to return data in an OIC appropriate format, but this 
at least solves the confusion around SI unit types and scale, etc.

- Are there specific config mechanisms that should be kept in mind?

Current framework provides a way to register resources; you can
register put/get routines for sensor/control. So it would be possible
to have very specific code per sensor.

However, if our sensor framework allowed us to enumerate connected
sensors, with common read interface serving data in known format, we
could export connected sensors to OIC automatically. That might be pretty
exciting.
I think that's what everyone had in mind, yes, and similar to what I've 
done with other systems where I implemented a generic 'read' and 'get 
sensor details' function and a single sample data type across all 
sensors (following what Android does beneath the hood).


With a bit of thought and work, it should be possible to scan the I2C 
bus at startup (for example) and initialise any sensors found on the 
system if desirable, although it does mean maintaining a large list of 
drivers in the firmware so space will become an issue over time.


Thanks for the link above though  it's very useful to start poking 
at a proof of concept, and keep in mind for any first draft APIs.

Re: Mynewt iOS App

[Sashi Ono]

I didn't want to self promote here, but I am anyways :)
We developed a Plug and Play modular sensor Architecture. you can check out
the kickstarter for it here
https://www.kickstarter.com/projects/pureengineering/puremodules-for-dreamers-tinkerers-hackers-and-des
also more info here: https://hackaday.io/project/12808-pure-modules  and
http://www.puremodules.com/

I think you might be interested in the super sensor module as it has 7
sensor chips on it.
I'm planning on working with the mynewt sensor API when I get some more
free time after the kickstarter is over and when I get some more time to
add the nrf52 core support mynewt bsp, although it doesn't seem that
critical as the code compiled for the nrf52dk bsp works fine on it. If
anyone wants a pre-release nrf52 core module to add bsp support send me an
email directly.

Also if you check out the BLE GATT characteristics, they almost have every
sensor type covered.
https://www.bluetooth.com/specifications/gatt/characteristics it would be
worth checking out if your sensor is already covered.



On Thu, Dec 1, 2016 at 4:49 PM, Brian Giori  wrote:

> Ah ok, I thought you were going for some kind of self contained 'Mynewt
> Sensor Service' which would be pretty cool in its own right but for demo
> purposes what you have is all you need.
>
> Brian
>
> On Thu, Dec 1, 2016 at 2:12 PM, David G. Simmons  wrote:
>
> >
> > > On Dec 1, 2016, at 4:00 PM, Kevin Townsend  wrote:
> > >
> > > On 01/12/16 21:35, David G. Simmons wrote:
> > >
> > >>
> > >> Rather than go through every Bluetooth device within range, connect to
> > it, and see if it's offering the right service, I simply check the name
> of
> > the device and, if it's not a mynewt device, move on. This is faster than
> > connecting to each device.
> > >>
> > > Normally you would include a specific service UUID in the advertising
> > packet to solve this problem, and when you collect the advertising data
> you
> > can determine if the service you care about is present, which might be
> less
> > arbitrary than relying on a device name? 128-bit UUIDs do cause a
> problem,
> > but you can still fit one in the main adv. packet, or you can optionally
> > use the scan response for a second payload.
> > >
> > > Just a suggestion about a fairly standard way to solve this problem
> > without having to connect to every device in range. :)
> >
> > True, that is the 'normal' way, but it turns out that almost no one
> > actually does it in practice. At least, looking through the devices in my
> > environment, not a single one advertises any services as part of its
> > advertisement data.
> >
> > I think that, this being a demo app, and not being a real production app,
> > I'm inclined to leave it as is and just check the name for now. Unless
> > there are strenuous objections.
> >
> > I'm much more interested in spending time getting sensors attached to
> > MyNewt than working on the iOS app. So, if anyone has any words of wisdom
> > on *that* front, I'm all ears!
> >
> > dg
> > --
> > David G. Simmons
> > (919) 534-5099
> > Web  • Blog  •
> > Linkedin  • Twitter <
> > http://twitter.com/TechEvangelist1> • GitHub 
> > /** Message digitally signed for security and authenticity.
> > * If you cannot read the PGP.sig attachment, please go to
> >  * http://www.gnupg.com/  Secure your email!!!
> >  * Public key available at keyserver.pgp.com 
> > **/
> > ♺ This email uses 100% recycled electrons. Don't blow it by printing!
> >
> > There are only 2 hard things in computer science: Cache invalidation,
> > naming things, and off-by-one errors.
> >
> >
> >
>



-- 
Sashi Ono
Principal Embedded Systems Engineer
(805) 699-6690
www.pureengineering.com

Re: Mynewt iOS App

[Brian Giori]

Ah ok, I thought you were going for some kind of self contained 'Mynewt
Sensor Service' which would be pretty cool in its own right but for demo
purposes what you have is all you need.

Brian

On Thu, Dec 1, 2016 at 2:12 PM, David G. Simmons  wrote:

>
> > On Dec 1, 2016, at 4:00 PM, Kevin Townsend  wrote:
> >
> > On 01/12/16 21:35, David G. Simmons wrote:
> >
> >>
> >> Rather than go through every Bluetooth device within range, connect to
> it, and see if it's offering the right service, I simply check the name of
> the device and, if it's not a mynewt device, move on. This is faster than
> connecting to each device.
> >>
> > Normally you would include a specific service UUID in the advertising
> packet to solve this problem, and when you collect the advertising data you
> can determine if the service you care about is present, which might be less
> arbitrary than relying on a device name? 128-bit UUIDs do cause a problem,
> but you can still fit one in the main adv. packet, or you can optionally
> use the scan response for a second payload.
> >
> > Just a suggestion about a fairly standard way to solve this problem
> without having to connect to every device in range. :)
>
> True, that is the 'normal' way, but it turns out that almost no one
> actually does it in practice. At least, looking through the devices in my
> environment, not a single one advertises any services as part of its
> advertisement data.
>
> I think that, this being a demo app, and not being a real production app,
> I'm inclined to leave it as is and just check the name for now. Unless
> there are strenuous objections.
>
> I'm much more interested in spending time getting sensors attached to
> MyNewt than working on the iOS app. So, if anyone has any words of wisdom
> on *that* front, I'm all ears!
>
> dg
> --
> David G. Simmons
> (919) 534-5099
> Web  • Blog  •
> Linkedin  • Twitter <
> http://twitter.com/TechEvangelist1> • GitHub 
> /** Message digitally signed for security and authenticity.
> * If you cannot read the PGP.sig attachment, please go to
>  * http://www.gnupg.com/  Secure your email!!!
>  * Public key available at keyserver.pgp.com 
> **/
> ♺ This email uses 100% recycled electrons. Don't blow it by printing!
>
> There are only 2 hard things in computer science: Cache invalidation,
> naming things, and off-by-one errors.
>
>
>

Re: NRF52dk ADC

[marko kiiskila]

Hi David,

I have partial answers:

> On Nov 29, 2016, at 8:37 AM, David G. Simmons  wrote:
> 
> 
> Moving on from the BLE -- which now works perfectly -- and I understand how 
> 'subscribed' values work in nimBLE, thanks to all who responded! 
> 
> Next up is implementing an ADC-based sensor. All the NRF52DK stuff has been 
> moved out of -core and into mynewt-nordic, and I've looked through the source 
> there as well. 
> 
> From my understanding of the board, the ADC pin is P0.03, and I've tested the 
> sensor, and it works. So, only questions are:
> 
> Given the move to external packages, how does the #include work? I've tried 
> about every iteration of #include "drivers/adc/adc_nrf52/adc_nrf52.h" I can 
> think of. :-) 

That should happen through package dependencies.
So add dependency to @mynewt_nordic/hw/drivers/adc_nrf52.

Here’s a sample as I tried this out:

pkg.deps:
- "@apache-mynewt-core/sys/console/full"
- "@apache-mynewt-core/kernel/os"
- "@apache-mynewt-core/sys/shell"
- "@mynewt_nordic/hw/drivers/adc/adc_nrf52"

And then I can include it from my source:

#include 
#include 


> 
> Using the ADC: 
> 
> struct os_dev adc_dev;
> rc = nrf52_adc_dev_init(_dev, void *);
> assert(rc == 0);
> 
> Should then initialize the ADC? Or do I need to nrf52_adc_open() first? 

Yes, you need to initialize it first. The preferred way to do this would be 
within
BSP's bsp_init(), but you can do it elsewhere early in the init.

I added this to my app’s main():

rc = os_dev_create((struct os_dev *)_dev, "adc0",
OS_DEV_INIT_KERNEL, OS_DEV_INIT_PRIO_DEFAULT,
nrf52_adc_dev_init, _cfg);
assert(rc == 0);

And then once the system has started, I open it from a task:

dev = (struct adc_dev *)os_dev_open("adc0",
OS_TIMEOUT_NEVER,
_cfg);
assert(dev);

> And subsequently, how to read the ADC. Do I nrf52_adc_read_channel(), 
> nrf52_adc_read_buffer() or ?? 
> 

I would go through the function pointers within dev->ad_funcs. Or the 
convenience functions
present in adc/adc.h. I don’t have sample code for this at hand though. Maybe 
someone else
does?

> This is the first ADC Tutorial for the Mynewt docs, so I'd like to get it 
> exactly right. :-) 

Hope this helps.

> Oh, the sensor is this one: https://www.adafruit.com/products/1786 which is a 
> pretty cool liquid level sensor. 
> 
> dg
> --
> David G. Simmons
> (919) 534-5099
> Web  • Blog  • 
> Linkedin  • Twitter 
>  • GitHub 
> /** Message digitally signed for security and authenticity.  
> * If you cannot read the PGP.sig attachment, please go to 
> * http://www.gnupg.com/  Secure your email!!!
> * Public key available at keyserver.pgp.com 
> **/
> ♺ This email uses 100% recycled electrons. Don't blow it by printing!
> 
> There are only 2 hard things in computer science: Cache invalidation, naming 
> things, and off-by-one errors.
> 
> 

Re: Mynewt iOS App

[David G. Simmons]

> On Dec 1, 2016, at 4:00 PM, Kevin Townsend  wrote:
> 
> On 01/12/16 21:35, David G. Simmons wrote:
> 
>> 
>> Rather than go through every Bluetooth device within range, connect to it, 
>> and see if it's offering the right service, I simply check the name of the 
>> device and, if it's not a mynewt device, move on. This is faster than 
>> connecting to each device.
>> 
> Normally you would include a specific service UUID in the advertising packet 
> to solve this problem, and when you collect the advertising data you can 
> determine if the service you care about is present, which might be less 
> arbitrary than relying on a device name? 128-bit UUIDs do cause a problem, 
> but you can still fit one in the main adv. packet, or you can optionally use 
> the scan response for a second payload.
> 
> Just a suggestion about a fairly standard way to solve this problem without 
> having to connect to every device in range. :)

True, that is the 'normal' way, but it turns out that almost no one actually 
does it in practice. At least, looking through the devices in my environment, 
not a single one advertises any services as part of its advertisement data. 

I think that, this being a demo app, and not being a real production app, I'm 
inclined to leave it as is and just check the name for now. Unless there are 
strenuous objections. 

I'm much more interested in spending time getting sensors attached to MyNewt 
than working on the iOS app. So, if anyone has any words of wisdom on *that* 
front, I'm all ears!

dg
--
David G. Simmons
(919) 534-5099
Web  • Blog  • Linkedin 
 • Twitter 
 • GitHub 
/** Message digitally signed for security and authenticity.  
* If you cannot read the PGP.sig attachment, please go to 
 * http://www.gnupg.com/  Secure your email!!!
 * Public key available at keyserver.pgp.com 
**/
♺ This email uses 100% recycled electrons. Don't blow it by printing!

There are only 2 hard things in computer science: Cache invalidation, naming 
things, and off-by-one errors.

Re: OIC support

[marko kiiskila]

> On Dec 1, 2016, at 12:57 PM, Kevin Townsend  wrote:
> 
>> 
>> Hi,
>> 
>> me and Paul brought in constrained iotivity stack few months back
>> to Mynewt, and I probably should send an update what’s going on.
>> 
>> I’ve been working on getting it more fully integrated. My first
>> goal is to get the code size/RAM usage down.
>> 
>> To cut down code size I’m converting it to use MyNewt’s memory pools,
>> timers, and event queues. By default we also left quite a bit logging
>> turned on, so I’ll make that optional (inclusion controlled by syscfg
>> settings).
>> To cut down RAM use I’m going to convert it to use os_mbuf for
>> data packets. This will probably make code size slightly larger,
>> but allows me to share the memory pool with bluetooth stack.
>> 
>> My end goal is to have OIC running over bluetooth in a way which
>> allows us to connect to apps written using iotivity’s framework
>> https://github.com/iotivity/iotivity  
>> > >.
> I'm quite interested in this from a sensor driver point of view. I have no 
> experience with iotivity, but if it will be a core part of Mynewt moving 
> forward, it would be good to get a sense of what kinds of requirements the 
> stack would place on sensors and sensor configuration, since that's the area 
> I'm most likely to get involved with on my end.

That is a good point. There are data models for different
type of sensors/controls over there. I’m see these are at
http://oneiota.org . Acceleration, humidity, temperature 
etc.

> - Are there specific config mechanisms that should be kept in mind?

Current framework provides a way to register resources; you can
register put/get routines for sensor/control. So it would be possible
to have very specific code per sensor.

However, if our sensor framework allowed us to enumerate connected
sensors, with common read interface serving data in known format, we
could export connected sensors to OIC automatically. That might be pretty
exciting.

Protocol allows the client to discover what resources are exported by
the device. So a generic app would not be out of the question.

> - Are there any definitions about power mode and device/driver 'state’?

I have not encountered power management stuff in the spec, but
admittedly I have not studied it in detail.
https://openconnectivity.org/resources/specifications 

> - What are the practical payload limitations given BLE as a transport?

This uses modified CoAP for data transfer, and that allows bluetooth
to do it’s fragmentation without limiting frame size for data on top.
Our current code only does ‘standard CoAP’; I’ll add the support
for TCP-like headers as well. Then it’s just memory consumption which
will be the issue, AFAIK.

> It's too early to probably answer a lot of those things definitively, but it 
> would be good to get the ball rolling as we start throwing some ideas around 
> publicly about a sensor API as well.

Agreed. We can always adjust things later, but it’s better to get
off with the right foot.

Re: Mynewt iOS App

[Kevin Townsend]

On 01/12/16 21:35, David G. Simmons wrote:



Rather than go through every Bluetooth device within range, connect to 
it, and see if it's offering the right service, I simply check the 
name of the device and, if it's not a mynewt device, move on. This is 
faster than connecting to each device.


Normally you would include a specific service UUID in the advertising 
packet to solve this problem, and when you collect the advertising data 
you can determine if the service you care about is present, which might 
be less arbitrary than relying on a device name? 128-bit UUIDs do cause 
a problem, but you can still fit one in the main adv. packet, or you can 
optionally use the scan response for a second payload.


Just a suggestion about a fairly standard way to solve this problem 
without having to connect to every device in range. :)


Kevin

Re: OIC support

[Kevin Townsend]

Hi,

me and Paul brought in constrained iotivity stack few months back
to Mynewt, and I probably should send an update what’s going on.

I’ve been working on getting it more fully integrated. My first
goal is to get the code size/RAM usage down.

To cut down code size I’m converting it to use MyNewt’s memory pools,
timers, and event queues. By default we also left quite a bit logging
turned on, so I’ll make that optional (inclusion controlled by syscfg
settings).
To cut down RAM use I’m going to convert it to use os_mbuf for
data packets. This will probably make code size slightly larger,
but allows me to share the memory pool with bluetooth stack.

My end goal is to have OIC running over bluetooth in a way which
allows us to connect to apps written using iotivity’s framework
https://github.com/iotivity/iotivity .
I'm quite interested in this from a sensor driver point of view. I have 
no experience with iotivity, but if it will be a core part of Mynewt 
moving forward, it would be good to get a sense of what kinds of 
requirements the stack would place on sensors and sensor configuration, 
since that's the area I'm most likely to get involved with on my end.


- Are there specific config mechanisms that should be kept in mind?
- Are there any definitions about power mode and device/driver 'state'?
- What are the practical payload limitations given BLE as a transport?

It's too early to probably answer a lot of those things definitively, 
but it would be good to get the ball rolling as we start throwing some 
ideas around publicly about a sensor API as well.


Kevin

Re: Mynewt iOS App

[David G. Simmons]

Thanks Brian,

Let me try to clarify ... 

> On Dec 1, 2016, at 3:02 PM, Brian Giori  > wrote:
> 
> Hey, this sounds like a really cool project so just wanted to chime in. As
> a preface, I'm not sure if I completely understand what you're going for
> with this app so correct me if I'm wrong (I'm also a bit rusty).
> 
> Here are my suggestions:
> 
> Any MyNewt device that has "nimble" in its name will be seen as a valid
>> MyNewt device -- we can change this, but I based this off of the bleprph
>> tutorial code.
> 
> 
> If the new service will only ever run on mynewt then simply the existence
> of said service should be enough to 'validate' the device as being mynewt.

Rather than go through every Bluetooth device within range, connect to it, and 
see if it's offering the right service, I simply check the name of the device 
and, if it's not a mynewt device, move on. This is faster than connecting to 
each device. 


So in my office, I don't have to connect to -- or attempt to connect to -- each 
device. I can just look for the one named 'nimble-bleadc` and go there. 

> 
> 
>>   - Each sensor should publish 2 UUIDs as follows:
>> 
>> 
>>   - UUID 0x2Axx is considered a 'configuration UUID', should be
>>   readable, and should return a String containing the name of the sensor as
>>   you would like it to be displayed in the app
>> 
>> 
>>   - UUID 0x4Axx is considered a 'data UUID'  and should be subscribable
>>   and subsequently updated with the sensor readings associated with its
>>   0x2Axx config UUID
>> 
>> 
> In general, services should have fixed characteristics with fixed UUIDs. We
> should not be dynamically creating characteristics inside a service. This
> is because (at least in the case of Android) the mobile device caches the
> service and characteristic information, including the number of
> characteristics and all UUIDs so that it does not need to re-discover the
> service (noticeably slower than connecting to the cached service). For
> example, if my Android device first discovers the service with 1 sensor
> (i.e two characteristics), I will only ever see the service having two
> characteristics with the initial UUIDs even If I have added four more and
> changed the UUIDs for all characteristics.

The Characteristics are not dynamically created. In fact, they are immutable. 
/* Sensor Data */
/* e761d2af-1c15-4fa7-af80-b5729002b340 */
static const uint8_t gatt_svr_svc_sns_uuid[16] = {
0x40, 0xb3, 0x20, 0x90, 0x72, 0xb5, 0x80, 0xaf,
0xa7, 0x4f, 0x15, 0x1c, 0xaf, 0xd2, 0x61, 0xe7 };
#define ADC_SNS_TYPE  0xDEAD
#define ADC_SNS_STRING "eTape Water Level Sensor"
#define ADC_SNS_VAL   0xBEEF
#define SPI_SNS_TYPE  0xDE48
#define SPI_SNS_STRING "SPI Sensor"
#define SPI_SNS_VAL   0xBE48

The 0xDExx UUID will return the NAME of the sensor. 
The 0xBExx UUID will return values from the sensor.

This lets the app itself do the layout on-the-fly and have valid names.

See the attached image and movie showing the iOS app in action.

Note that the values returned are dummy values as I don't have ADC or SPI 
sensors actually working yet. 

> 
> Therefore, I suggest making a service with a single characteristic, either
> READ or NOTIFY, with a unique 128-bit UUID, that either stores (in the case
> of READ) or publishes (in the case of NOTIFY) a list of "sensor" structures
> which hold the sensor name and value. From there the mobile device can
> display the list accordingly.

I've made a single service, that holds multiple characteristics that are 
'paired' such that one is the name of the sensor, the other is the sensor 
values. The name is a READ characteristic, and the values are A NOTIFY 
characteristic.

I have a small screen-capture movie of what the above-defined 
service/characteristics look like in the iOS app, but I can't send it to the 
list. You can view it here: 
https://drive.google.com/open?id=0B9Hl75onlTTkMDR2UnZDZnhBU3M 
 

dg


> 
> Again take everything I just said with a grain of salt, I haven't used
> MyNewt in a number of months.
> 
> Finally, great idea for a project. This would be very useful for new
> developers as a tool and a reference point for other applications.
> 
> Brian Giori
> 
> 
> 
> On Thu, Dec 1, 2016 at 7:03 AM, David G. Simmons  > wrote:
> 
>> Doh!!
>> 
>> Ok, so since actually complying with BLE standards is sort of important
>> :-) the UUID to use is E761D2AF-1C15-4FA7-AF80-B5729020B340 which is
>> unique, and is 128-bits.
>> 
>> That being said, it is also noted that defined characteristics are all
>> (save one) in the 0x2Axx range. So my choice there was bad too.
>> org.bluetooth.characteristic.fitness_machine_control_point defined as
>> 0xEE1D is the outlier there.
>> 
>> 128-bit UUIDs are a pain in the *** if you ask me. They are easy to
>> generate via 

OIC support

[marko kiiskila]

Hi,

me and Paul brought in constrained iotivity stack few months back
to Mynewt, and I probably should send an update what’s going on.

I’ve been working on getting it more fully integrated. My first
goal is to get the code size/RAM usage down.

To cut down code size I’m converting it to use MyNewt’s memory pools,
timers, and event queues. By default we also left quite a bit logging
turned on, so I’ll make that optional (inclusion controlled by syscfg
settings).
To cut down RAM use I’m going to convert it to use os_mbuf for
data packets. This will probably make code size slightly larger,
but allows me to share the memory pool with bluetooth stack.

My end goal is to have OIC running over bluetooth in a way which
allows us to connect to apps written using iotivity’s framework
https://github.com/iotivity/iotivity .

Re: Mynewt iOS App

[Brian Giori]

Hey, this sounds like a really cool project so just wanted to chime in. As
a preface, I'm not sure if I completely understand what you're going for
with this app so correct me if I'm wrong (I'm also a bit rusty).

Here are my suggestions:

Any MyNewt device that has "nimble" in its name will be seen as a valid
> MyNewt device -- we can change this, but I based this off of the bleprph
> tutorial code.


If the new service will only ever run on mynewt then simply the existence
of said service should be enough to 'validate' the device as being mynewt.


>- Each sensor should publish 2 UUIDs as follows:
>
>
>- UUID 0x2Axx is considered a 'configuration UUID', should be
>readable, and should return a String containing the name of the sensor as
>you would like it to be displayed in the app
>
>
>- UUID 0x4Axx is considered a 'data UUID'  and should be subscribable
>and subsequently updated with the sensor readings associated with its
>0x2Axx config UUID
>
>
In general, services should have fixed characteristics with fixed UUIDs. We
should not be dynamically creating characteristics inside a service. This
is because (at least in the case of Android) the mobile device caches the
service and characteristic information, including the number of
characteristics and all UUIDs so that it does not need to re-discover the
service (noticeably slower than connecting to the cached service). For
example, if my Android device first discovers the service with 1 sensor
(i.e two characteristics), I will only ever see the service having two
characteristics with the initial UUIDs even If I have added four more and
changed the UUIDs for all characteristics.

Therefore, I suggest making a service with a single characteristic, either
READ or NOTIFY, with a unique 128-bit UUID, that either stores (in the case
of READ) or publishes (in the case of NOTIFY) a list of "sensor" structures
which hold the sensor name and value. From there the mobile device can
display the list accordingly.

Again take everything I just said with a grain of salt, I haven't used
MyNewt in a number of months.

Finally, great idea for a project. This would be very useful for new
developers as a tool and a reference point for other applications.

Brian Giori



On Thu, Dec 1, 2016 at 7:03 AM, David G. Simmons  wrote:

> Doh!!
>
> Ok, so since actually complying with BLE standards is sort of important
> :-) the UUID to use is E761D2AF-1C15-4FA7-AF80-B5729020B340 which is
> unique, and is 128-bits.
>
> That being said, it is also noted that defined characteristics are all
> (save one) in the 0x2Axx range. So my choice there was bad too.
> org.bluetooth.characteristic.fitness_machine_control_point defined as
> 0xEE1D is the outlier there.
>
> 128-bit UUIDs are a pain in the *** if you ask me. They are easy to
> generate via the website Chris so generously provided. They are annoying to
> translate into 16-byte arrays, but generating 128-bit UUIDs with a common
> prefix/suffix is, as best I can tell, not possible. This all makes the iOS
> app more complicated if not impossible without requiring users to generate
> their own UUIDs, then go edit the iOS source files, build and deploy the
> app to a device.
>
> I see 2 possible solutions here:
>
> 1) we flaunt standards, a bit, and use 16-bit characteristic IDs that are
> NOT within the pre-defined characteristic ranges, say 0xDExx and 0xADxx as
> our Config and data prefixes -- keep in mind that this is *only* for a demo
> app and would not be used for any production application.
> 2) We generate 2 128-bit UUIDs, say  559557e5-2ae2-4d4b-bda2-d432e8577be3
> and d5e9608f-6e41-490f-88e2-4281c8ebe2c6, then clip off the start,
> 559557e5- and d5e9608f- for config and data prefixes, and folks can
> generate their own 128-bit UUIDs, then replace the prefixes.
>
> 1 seems a lot more straight-forward and easier to explain to people who
> are trying to work through the tutorials. 2 would have a lower chance of a
> UUID collision, though even with 1, the collision chances are nearly
> non-existent.
>
> Happy to take suggestions here.
>
> dg
>
> > On Nov 30, 2016, at 1:03 PM, Christopher Collins 
> wrote:
> >
> > That sounds great!  My only comment is that the app probably shouldn't
> > use those 16-bit UUIDs.  There is a registry of standardized bluetooth
> > service UUIDs (https://www.bluetooth.com/specifications/gatt/services <
> https://www.bluetooth.com/specifications/gatt/services>),
> > and 0x1811 is reserved for the Alert Notification Service.
> >
> > For non-standard services and characteristics, you will need to use
> > 128-bit UUIDs.  You can generate unique 128-bit UUIDs using a site like
> > this one: https://www.uuidgenerator.net/  >.
>
> --
> David G. Simmons
> (919) 534-5099
> Web  • Blog  •
> Linkedin  • Twitter <
> 

If using develop, upgrade newt and core at the same time

[Christopher Collins]

Hello all,

TL;DR: If you pull core develop, be sure to pull newt develop at the
same time.  Otherwise, your builds will fail.

I just pushed a fix to the develop branch for this issue:
https://issues.apache.org/jira/browse/MYNEWT-365

Unfortunately, this fix introduces an incompatibility with the core
repo.  Specifically, the compiler.yml definitions had to change a bit.
More details are available in the ticket and the commit messages.

Please let me know if there are any questions.

Thanks,
Chris

Re: Subscription Request and Question.

[Mike Ryan]

Your link confounds different Bluetooth versions and different attacks.
The TL;DR:

LE Legacy Pairing is broken and has been known to be broken since its
inception. I wrote on it in 2013[1] and released crackle[2] to
demonstrate it.

LE Secure Connections address all the weaknesses of legacy pairing. If
both hosts support LE SC, you are invulnerable to a _passive_ attacker.
Without a display, an _active_ attacker can still MitM you. This is a
much more challenging attack.

Based on my reading of the spec, it's not possible to mandate LE SC even
if both stacks support it. Thus an active attacker can attempt a pairing
downgrade attack to force the use of the weaker legacy pairing. However
in this scenario the attacker can fully MitM the connection, so a
pairing downgrade is basically pointless.

Finally, all of these attacks are only against the pairing phase. Once
two devices have paired and exchanged keys, the runtime
encryption/authentication (based on AES-CCM) is not vulnerable to any
attacks.

[1] https://www.usenix.org/conference/woot13/workshop-program/presentation/ryan
[2] https://github.com/mikeryan/crackle

On Thu, Dec 01, 2016 at 11:18:30AM +, Tim Hutt wrote:
> See https://pomcor.com/2015/06/03/has-bluetooth-become-secure/
> 
> Basically its a mess. As far as I can tell, the actual encryption (AES-128
> CCM) is fine, but the key exchange (pairing) methods are all broken in
> various ways. Just Works is vulnerable to MitM by design (a reasonable
> trade-off for the improved usability in some cases). Numeric Comparison is
> actually secure, but it requires Bluetooth 4.2, a screen and "yes/no"
> buttons on both devices which is very often not possible. Passkey Entry
> (i.e. a PIN) is totallly broken. OOB is secure but you can't use it anyway
> because of lack of support on Android and iOS.
> 
> Also note that the 'LE Secure Connections' feature is optional even in
> Bluetooth 4.2. So even if you have a phone or peripheral that supports
> Bluetooth 4.2, it might still use the legacy methods.
> 
> On 30 November 2016 at 17:06, Mike Ryan  wrote:
> 
> > This is the first I've heard of LE Secure Connections having any
> > weakness. Can you elaborate and/or provide a citation?
> >
> > On Wed, Nov 30, 2016 at 12:23:06PM +, Tim Hutt wrote:
> > > Just in case you weren't aware, OOB is not available on iOS or Android
> > > (except via NFC). Also all BLE pairing methods except OOB and Numeric
> > > Comparison (which requires a screen) are apparently broken in various
> > ways,
> > > even with LE Secure Connections.
> >

Re: [VOTE] Release Apache Mynewt 1.0.0-b1-incubating-rc2

[marko kiiskila]

+1

> On Nov 30, 2016, at 12:35 PM, Peter Snyder  wrote:
> 
> +1
> 
>> On Nov 30, 2016, at 8:31 AM, Vipul Rahane  wrote:
>> 
>> +1 (binding)
>> 
>>> On Nov 30, 2016, at 7:09 PM, David G. Simmons  wrote:
>>> 
>>> +1
>>> 
 On Nov 29, 2016, at 9:30 PM, Christopher Collins  
 wrote:
 
 [ ] +1 Release this package
 [ ]  0 I don't feel strongly about it, but don't object
 [ ] -1 Do not release this package because...
>>> 
>>> --
>>> David G. Simmons
>>> (919) 534-5099
>>> Web  • Blog  • 
>>> Linkedin  • Twitter 
>>>  • GitHub 
>>> /** Message digitally signed for security and authenticity.  
>>> * If you cannot read the PGP.sig attachment, please go to 
>>> * http://www.gnupg.com/  Secure your email!!!
>>> * Public key available at keyserver.pgp.com 
>>> **/
>>> ♺ This email uses 100% recycled electrons. Don't blow it by printing!
>>> 
>>> There are only 2 hard things in computer science: Cache invalidation, 
>>> naming things, and off-by-one errors.
>>> 
>>> 
>> 
> 

Re: Mynewt iOS App

[David G. Simmons]

Doh!! 

Ok, so since actually complying with BLE standards is sort of important :-) the 
UUID to use is E761D2AF-1C15-4FA7-AF80-B5729020B340 which is unique, and is 
128-bits.

That being said, it is also noted that defined characteristics are all (save 
one) in the 0x2Axx range. So my choice there was bad too. 
org.bluetooth.characteristic.fitness_machine_control_point defined as 0xEE1D is 
the outlier there. 

128-bit UUIDs are a pain in the *** if you ask me. They are easy to generate 
via the website Chris so generously provided. They are annoying to translate 
into 16-byte arrays, but generating 128-bit UUIDs with a common prefix/suffix 
is, as best I can tell, not possible. This all makes the iOS app more 
complicated if not impossible without requiring users to generate their own 
UUIDs, then go edit the iOS source files, build and deploy the app to a device. 

I see 2 possible solutions here:

1) we flaunt standards, a bit, and use 16-bit characteristic IDs that are NOT 
within the pre-defined characteristic ranges, say 0xDExx and 0xADxx as our 
Config and data prefixes -- keep in mind that this is *only* for a demo app and 
would not be used for any production application.
2) We generate 2 128-bit UUIDs, say  559557e5-2ae2-4d4b-bda2-d432e8577be3 and 
d5e9608f-6e41-490f-88e2-4281c8ebe2c6, then clip off the start, 559557e5- and 
d5e9608f- for config and data prefixes, and folks can generate their own 
128-bit UUIDs, then replace the prefixes. 

1 seems a lot more straight-forward and easier to explain to people who are 
trying to work through the tutorials. 2 would have a lower chance of a UUID 
collision, though even with 1, the collision chances are nearly non-existent. 

Happy to take suggestions here. 

dg

> On Nov 30, 2016, at 1:03 PM, Christopher Collins  wrote:
> 
> That sounds great!  My only comment is that the app probably shouldn't
> use those 16-bit UUIDs.  There is a registry of standardized bluetooth
> service UUIDs (https://www.bluetooth.com/specifications/gatt/services 
> ),
> and 0x1811 is reserved for the Alert Notification Service.
> 
> For non-standard services and characteristics, you will need to use
> 128-bit UUIDs.  You can generate unique 128-bit UUIDs using a site like
> this one: https://www.uuidgenerator.net/ .

--
David G. Simmons
(919) 534-5099
Web  • Blog  • Linkedin 
 • Twitter 
 • GitHub 
/** Message digitally signed for security and authenticity.  
* If you cannot read the PGP.sig attachment, please go to 
 * http://www.gnupg.com/  Secure your email!!!
 * Public key available at keyserver.pgp.com 
**/
♺ This email uses 100% recycled electrons. Don't blow it by printing!

There are only 2 hard things in computer science: Cache invalidation, naming 
things, and off-by-one errors.

Re: Subscription Request and Question.

[Tim Hutt]

See https://pomcor.com/2015/06/03/has-bluetooth-become-secure/

Basically its a mess. As far as I can tell, the actual encryption (AES-128
CCM) is fine, but the key exchange (pairing) methods are all broken in
various ways. Just Works is vulnerable to MitM by design (a reasonable
trade-off for the improved usability in some cases). Numeric Comparison is
actually secure, but it requires Bluetooth 4.2, a screen and "yes/no"
buttons on both devices which is very often not possible. Passkey Entry
(i.e. a PIN) is totallly broken. OOB is secure but you can't use it anyway
because of lack of support on Android and iOS.

Also note that the 'LE Secure Connections' feature is optional even in
Bluetooth 4.2. So even if you have a phone or peripheral that supports
Bluetooth 4.2, it might still use the legacy methods.

On 30 November 2016 at 17:06, Mike Ryan  wrote:

> This is the first I've heard of LE Secure Connections having any
> weakness. Can you elaborate and/or provide a citation?
>
> On Wed, Nov 30, 2016 at 12:23:06PM +, Tim Hutt wrote:
> > Just in case you weren't aware, OOB is not available on iOS or Android
> > (except via NFC). Also all BLE pairing methods except OOB and Numeric
> > Comparison (which requires a screen) are apparently broken in various
> ways,
> > even with LE Secure Connections.
>