Hi Joseph, I couldn't find the error code but I did look into the error=ERROR flag which is described as a "generic error". Precisely, this one: "org.iotivity.base.OcException: stack error in onGetCallback ERROR". I don't know about the [introspection].dat file but I did look at that server_fopen() code before. I'm did convert the UUID to a string but it's not really human readable, probably because the OcPlatform.getDeviceId() is returning a random generated ID. On my client app, when the OnResourceFound() callback is triggered and I print the ocResource.getServerId() it comes out as "5fd82524-0f91-050b-bc3c-2707d57ac132", which is nothing like the ID in the ACL. I may be confused about that since I don't know if the ServerId should be the same. Nevertheless, I'm sending the .dat files and .json ACL just in case someone want to have a look and possibly find something wrong. Oh, and about the introspection file, do I need to set it up if I want the ACL to work?
Thank you, A. Lapprand Em ter, 26 de dez de 2017 às 15:11, Morrow, Joseph L < joseph.l.mor...@intel.com> escreveu: > Hi Arthur, > > Quick Tip: Most of the errors are OCStackErrors. If you have a non > HTTP-looking error (eg. 404, 501, …4.04, 5.01, …), then it is likely > defined in octypes.h. Please compare to the enumeration found in > <iotivity>/resource/csdk/include/octypes.h. > > A common error is ’46’ which means “Unauthorized.” This has occurred to me > in many cases: > > > - IoTivity has overwritten your SVR *.dat file and therefore corrupted > all of your configurations > - This can happen if you’re providing your own “[arthurs_cbor].dat" > file but forget about the [introspection].dat file. Please verify you > use a > similar if-check as found in > <iotivity>/resource/examples/lightserver.cpp:server_fopen(). > - This can also happen if for some reason your *.dat file doesn’t > follow correct CBOR format or if something in there isn’t the right > format. > Perhaps your device ID is wrong, for instance. To verify the SVR was > loaded > correctly, please see that your Device ID is as you’ve defined it by > calling (C++ SDK). You can either debug or convert the UUID to a string > and > print it out. > > “ > OCUUIdentity id; > > OC::OCPlatform::getDeviceId(&id); > “ > > - The ACLs in your config are set up correctly. I will defer to > someone else for that info. > - If any symmetric keys (ie. Raw) or pins are being used in your SVR > file, make sure they match on both sides (server & client). > > Thanks, > > Joey Morrow > > From: Arthur Barros Lapprand <a...@cin.ufpe.br> > Date: Tuesday, December 26, 2017 at 5:04 AM > To: Joseph L Morrow <joseph.l.mor...@intel.com> > Cc: Tonny Tzeng <tonny.tz...@gmail.com>, iotivity < > iotivity-dev@lists.iotivity.org>, Rami Alshafi <ralsh...@vtmgroup.com>, > "Matthews, Michael L" <michael.l.matth...@intel.com> > > Subject: Re: [dev] FW: Android SECURED mode > > Hi Joseph, > > I have done as you described and it indeed changed the situation. The > error which before had the UNAUTHORIZED_REQ flag now has the ERROR flag. I > don't really know what this flag means but I'm searching it. > > Regards, > A. Lapprand > > Em seg, 25 de dez de 2017 às 14:38, Morrow, Joseph L < > joseph.l.mor...@intel.com> escreveu: > >> Hi Arthur, >> >> My coworker Michael and I just found the following solution. We placed >> this in our Client’s Discovery Callback for the timebeing. As you may >> notice, you can call setHost() at any time after discovery has occurred. >> >> The reason you need to perform the setHost() function, is because the C++ >> SDK doesn’t automatically assume you want to use the "coaps://“ (ie. Secure >> communications) version of the Resource’s URI. It assumes you want to use >> the “coap://“ version and the Server will reject this if your resource(s) >> were created with the OC_SECURE flag. (Note: I’ve just recently heard you >> no longer need to specify the “OC_SECURE” flag as all resources are created >> as Secure Resources now by default.) >> >> foo( std::shared_ptr<OC::OCResource> resource ) >> >> { >> >> // >> >> // Find the first secure coaps endpoint in the list of hosts. If it's >> there >> >> // then use it; otherwise use the unsecure coap endpoint. >> >> // >> >> auto resourceHostList = resource->getAllHosts(); >> >> >> >> for (auto &host : resourceHostList) >> >> { >> >> if (std::string::npos != host.find("coaps://")) >> >> { >> >> resource->setHost(host); >> >> >> >> break; >> >> } >> >> } >> >> >> // If you keep a single copy of your discovered resource, take the copy >> of it here for you to use later in your application. >> >> MyDiscoveredResources.push_back(resource); // For a quick test, just call >> "resource.get()" and see if the server side is honoring your request now. >> >> >> } >> >> Thanks, >> >> Joey Morrow >> >> From: <iotivity-dev-boun...@lists.iotivity.org> on behalf of Arthur >> Barros Lapprand <a...@cin.ufpe.br> >> Date: Sunday, December 24, 2017 at 6:51 PM >> To: Tonny Tzeng <tonny.tz...@gmail.com> >> Cc: iotivity <iotivity-dev@lists.iotivity.org>, Rami Alshafi < >> ralsh...@vtmgroup.com> >> Subject: Re: [dev] FW: Android SECURED mode >> >> I am using both OC_NONSECURE and OC_SECURE flags when registering the >> resources and attempting a GET request with the OcResource I get from the >> OnResourceFound callback. Odd, isn't it? >> >> Thank you, >> A. Lapprand >> >> Em dom, 24 de dez de 2017 às 23:46, Tonny Tzeng <tonny.tz...@gmail.com> >> escreveu: >> >>> What flags did you pass to the registerResource() function? note that if >>> you want to communicate over non-secure endpoint, you need to pass >>> OC_NONSECURE flag explicitly while registering the resource. The >>> simpleserver server doesn't work in non-secure mode for the same reason, no >>> passing OC_SECURE flag doesn't imply the use of non-secured endpoint. Hope >>> this helps. >>> >>> Regards, >>> Tonny >>> >>> On 25 December 2017 at 10:09, Arthur Barros Lapprand <a...@cin.ufpe.br> >>> wrote: >>> >>>> Hi all, >>>> >>>> I got to test the ACLs Rami provided while changing the server json by >>>> adding these ACEs: >>>> >>>> { >>>> "aceid": 6, >>>> "subject": {"conntype": "anon-clear"}, >>>> "resources":[ >>>> { "href":"*"} >>>> ], >>>> "permission": 14 >>>> }, >>>> { >>>> "aceid": 7, >>>> "subject": {"conntype": "auth-crypt"}, >>>> "resources":[ >>>> { "href":"*"} >>>> ], >>>> "permission": 14 >>>> } >>>> >>>> So in theory I guess my server should respond to any request. Sadly that >>>> didn't >>>> work so now I'm somewhat confused. I noticed the UNAUTHORIZED_REQ message >>>> is sent to the client by a COAP host (not COAPS). Maybe I'm compiling >>>> IoTivity >>>> with the wrong scons settings? Also, how do I know my client is using >>>> COAPS? I've >>>> seen someone asking this recently but I don't remember where. Is it also >>>> obligatory >>>> for me to do the pairing/onboarding/credentials stuff aside setting them >>>> through the json? >>>> >>>> Thank you, >>>> >>>> A. Lapprand >>>> >>>> >>>> Em qui, 21 de dez de 2017 às 15:11, Rami Alshafi <ralsh...@vtmgroup.com> >>>> escreveu: >>>> >>>>> That’s a mistake! Thanks for pointing that out! I will fix it. The “1” >>>>> at the beginning should not be there J >>>>> >>>>> Thanks, >>>>> >>>>> -Rami >>>>> >>>>> >>>>> >>>>> *From:* Arthur Barros Lapprand [mailto:a...@cin.ufpe.br] >>>>> *Sent:* Thursday, December 21, 2017 8:02 AM >>>>> *To:* Rami Alshafi <ralsh...@vtmgroup.com> >>>>> *Subject:* Re: FW: [dev] Android SECURED mode >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> I just noticed the sample you linked has "rowneruuid": >>>>> "132323232-3232-3232-3232-323232323232" in the pstat section. Is there an >>>>> explanation to that "1" at the beginning of the id? shouldn't it be the >>>>> same as the client's id? >>>>> >>>>> Thanks again, >>>>> >>>>> A. Lapprand >>>>> >>>>> >>>>> >>>>> Em qui, 21 de dez de 2017 às 10:18, Arthur Barros Lapprand < >>>>> a...@cin.ufpe.br> escreveu: >>>>> >>>>> Hi Rami, >>>>> >>>>> Sorry for the delayed answer. I'm pretty overcrumbed these days so I >>>>> can't test it right now, but the email was very useful! Like I said to the >>>>> others I'll give feedback once I manage to test those suggestions. >>>>> >>>>> Thank you, >>>>> >>>>> A. Lapprand >>>>> >>>>> >>>>> >>>>> Em ter, 19 de dez de 2017 às 15:42, Rami Alshafi < >>>>> ralsh...@vtmgroup.com> escreveu: >>>>> >>>>> Arthur, >>>>> >>>>> I meant to send this e-mail to you but I just learned it did not make >>>>> to you. Hopefully, this one will. >>>>> >>>>> Thanks, >>>>> >>>>> -Rami >>>>> >>>>> >>>>> >>>>> *From:* Wouter van der Beek (wovander) [mailto:wovan...@cisco.com] >>>>> *Sent:* Tuesday, December 19, 2017 5:22 AM >>>>> *To:* Rami Alshafi <ralsh...@vtmgroup.com> >>>>> *Subject:* RE: [dev] Android SECURED mode >>>>> >>>>> >>>>> >>>>> This is email is now on the dmtools reflector and not on the iotivity >>>>> reflector.. >>>>> >>>>> Hence Arthur can’t see this email >>>>> >>>>> >>>>> >>>>> *From:* Rami Alshafi [mailto:ralsh...@vtmgroup.com >>>>> <ralsh...@vtmgroup.com>] >>>>> *Sent:* 18 December 2017 18:43 >>>>> *To:* Wouter van der Beek (wovander) <wovan...@cisco.com>; >>>>> dmtools...@members.openconnectivity.org >>>>> *Subject:* RE: [dev] Android SECURED mode >>>>> >>>>> >>>>> >>>>> Arthur, >>>>> >>>>> Please reference my sample applications at >>>>> https://gerrit.iotivity.org/gerrit/#/c/22513/ >>>>> <https://urlf.duocircle.io/?url=https%3A%2F%2Fgerrit.iotivity.org%2Fgerrit%2F%23%2Fc%2F22513%2F&id=31d5&rcpt=ralsh...@vtmgroup.com&tss=1513689724&msgid=99c3285a-e4bf-11e7-8fcd-5f906d21262c&html=1&h=b068c5c2> >>>>> >>>>> For convenience, I will explain the server’s SVR database. >>>>> >>>>> There are 4 main sections which are ACL, Pstat, Doxm and Cred. >>>>> >>>>> Assuming your client cannot onboard devices, the server\device needs >>>>> to be in RFNOP state which is reflected in the following settings. >>>>> >>>>> The ACL must have an ACE giving the client the right permissions >>>>> >>>>> Aceid: whatever number >>>>> >>>>> Subject: set it to {“uuid”: The uuid of the client} >>>>> >>>>> Resources: information of the resource like its href >>>>> and interface and resource type. >>>>> >>>>> Permission: this is bitmask >>>>> >>>>> Set the rowneruuid of the ACL to the uuid of the client >>>>> >>>>> In the pstat section, set the dos.s to 3 and isop to true and cm to 0 >>>>> and the rowneruuid to the uuid of the client >>>>> >>>>> In the doxm section, set the owned flag to true and the devowneruuid >>>>> and rowneruuid to the uuid of the client. >>>>> >>>>> Assuming you want to use the “justworks” security model, set the cred >>>>> section like in the sample applications. >>>>> >>>>> Thanks, >>>>> >>>>> -Rami >>>>> >>>>> >>>>> >>>>> *From:*dmtools...@members.openconnectivity.org [ >>>>> mailto:dmtools...@members.openconnectivity.org >>>>> <dmtools...@members.openconnectivity.org>] *On Behalf Of *Wouter van >>>>> der Beek (wovander) >>>>> *Sent:* Monday, December 18, 2017 2:38 AM >>>>> *To:* dmtools...@members.openconnectivity.org >>>>> *Subject:* [OCF dmtools_tg] FW: [dev] Android SECURED mode >>>>> >>>>> >>>>> >>>>> FYI >>>>> >>>>> >>>>> >>>>> *From:*iotivity-dev-boun...@lists.iotivity.org [ >>>>> mailto:iotivity-dev-boun...@lists.iotivity.org >>>>> <iotivity-dev-boun...@lists.iotivity.org>] *On Behalf Of *Tonny Tzeng >>>>> *Sent:* 17 December 2017 08:16 >>>>> *To:* Max Kholmyansky <max...@gmail.com> >>>>> *Cc:* iotivity <iotivity-dev@lists.iotivity.org> >>>>> >>>>> >>>>> *Subject:* Re: [dev] Android SECURED mode >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> We just posted an article at 01.org >>>>> <https://urlf.duocircle.io/?url=https%3A%2F%2F01.org%2Fblogs%2Fttzeng%2F2017%2Fsecurely-accessing-iot-devices-based-javascript&id=31d5&rcpt=ralsh...@vtmgroup.com&tss=1513593475&msgid=8131ebd8-e3df-11e7-8fcd-5f906d21262c&html=1&h=7e525f59> >>>>> talking >>>>> few security concept in IoTivity. Though we were using iotivity-node as an >>>>> example, I think the following steps would get your Client accesses to the >>>>> Server securely: >>>>> >>>>> (1) your Server need to register the resource with >>>>> ResourceProperty.SECURE flag in order to use the secured endpoint; >>>>> >>>>> (2) allow the "auth-crypt" connection requests in the SVD dB; >>>>> >>>>> (3) use an Onboarding Tool to establish ownership with both the Client >>>>> and the Server; >>>>> >>>>> (4) mutual install the credentials of each other by pairing the >>>>> devices with the OBT >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Tonny >>>>> >>>>> >>>>> >>>>> On 17 December 2017 at 14:38, Max Kholmyansky <max...@gmail.com> >>>>> wrote: >>>>> >>>>> Hi Arthur, >>>>> >>>>> >>>>> >>>>> You should be able to communicate between the client and the server on >>>>> Android, using SECURED=1 library. >>>>> >>>>> >>>>> >>>>> First, to set your "di" (client or server) - you need to specify the >>>>> "di" value inside the DAT file (containing security information) - you can >>>>> look at the samples. I never succeeded with setting the "di" using API, >>>>> and >>>>> I don't know if it's supported. >>>>> >>>>> >>>>> >>>>> Second, even using SECURED=1, in the server, you can allow any client >>>>> (even not authenticated) to access any resource. >>>>> >>>>> The relevant ACL entry looks like: (you may need to change the >>>>> "aceid"): >>>>> >>>>> { >>>>> >>>>> *"aceid"*: 5, >>>>> *"subject"*: { *"conntype"*: *"anon-clear" *}, >>>>> *"resources"*: [ >>>>> { *"href"*: *"*" *} >>>>> ], >>>>> *"permission"*: 14 >>>>> } >>>>> >>>>> This is definitely not the way to configure it in production, but it >>>>> should allow you to keep developing, without caring about access >>>>> permissions for a while. >>>>> >>>>> >>>>> >>>>> Max >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Dec 14, 2017 at 8:54 PM, Arthur Barros Lapprand < >>>>> a...@cin.ufpe.br> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> I have a few beginner-leveled questions about secure mode in Android. >>>>> Let me explain the situation: >>>>> >>>>> I have created two apps (one for Server/Controlee and the other for >>>>> the Client/Controller) and I'm able to FIND and GET/POST/OBSERVE them >>>>> without problems. As this is a simple example, I now want to do the same >>>>> things but with SECURED=1. I should note that I am usually running both >>>>> apps in the same device (not the emulator, but my cellphone). >>>>> >>>>> So I started looking everywhere and discovered I could do this with a >>>>> local ACL and supposedly everything would be ok. Turns out it didn't, >>>>> which >>>>> is why I am here. So my questions are: >>>>> >>>>> - Do I need anything else to use the SECURED flag in Android apart >>>>> from registering resource as secure and passing the ACL to the >>>>> PlatformConfig and configure it? >>>>> >>>>> - I read that when configuring the Platform with an ACL the DeviceID >>>>> should be set with the ID inside it. So as it failed I tried debugging the >>>>> ID, which led me to confusion about PlatformID and DeviceID. When loading >>>>> the ACL the DeviceID comes as a random byte[]. However, I can set the >>>>> DeviceID in the code and retrieve it just fine. The thing is, the ID >>>>> recieved by the Client (ServerID) isn't the same I set in the code. I'm >>>>> not >>>>> sure if it's something about the encoding tricking me or if it's something >>>>> else. Can someone please shed me some light? >>>>> >>>>> >>>>> >>>>> In short, the Client can find the resources (they are registered with >>>>> SECURE type) but can't make a correct GET/POST/OBSERVE request, returning >>>>> UNAUTHORIZED_REQ. Any tips about this flag and Android are welcome. >>>>> >>>>> Sorry for the long post, thank you in advance! >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> iotivity-dev mailing list >>>>> iotivity-dev@lists.iotivity.org >>>>> https://lists.iotivity.org/mailman/listinfo/iotivity-dev >>>>> <https://urlf.duocircle.io/?url=https%3A%2F%2Flists.iotivity.org%2Fmailman%2Flistinfo%2Fiotivity-dev&id=31d5&rcpt=ralsh...@vtmgroup.com&tss=1513593475&msgid=8131ebd8-e3df-11e7-8fcd-5f906d21262c&html=1&h=0ab5454f> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> iotivity-dev mailing list >>>>> iotivity-dev@lists.iotivity.org >>>>> https://lists.iotivity.org/mailman/listinfo/iotivity-dev >>>>> <https://urlf.duocircle.io/?url=https%3A%2F%2Flists.iotivity.org%2Fmailman%2Flistinfo%2Fiotivity-dev&id=31d5&rcpt=ralsh...@vtmgroup.com&tss=1513593475&msgid=8131ebd8-e3df-11e7-8fcd-5f906d21262c&html=1&h=0ab5454f> >>>>> >>>>> >>>>> >>>>> >>>
svr_db_client.dat
Description: Binary data
svr_db_client.json
Description: application/json
svr_db_server.dat
Description: Binary data
svr_db_server.json
Description: application/json
_______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev