Observations are not using coap proxy

[FRDavid]

Hello,

We have detected that the observation requests are sent from a ports which differs from the server port. This happens due to the use of libcoap as proxy. Read, Write and Execute requests are sent correclty using the coap proxy, but not the observers requests.

Next image illustrate the problem, where the observation requests are being sent from a different port to the LwM2M Server (5684).

Next image illustrate the problem already solved, where the requests pass through the coap proxy (server-to-device communications in red color), so observation requests now proceed from the LwM2M Server.

This represents a problem for some LwM2M Clients, since they are not capable to recognize this packet as a petition from the server. Not manage this can be seen as a security problem where maybe a third party can extract information the devices (in case of non secure communications of course).

Tests are passed correctly in both lwm2m-node-lib and lightweight-iot agent.

Note: After this correction all observations are correctly managed by Lightweight IOTAgent and pushed to Orion Context Broker

LwM2M IOTAgent:

time=2016-11-18T10:14:39.891Z | lvl=DEBUG | corr=n/a | trans=n/a | op=IoTAgentNGSI.NGSIService | msg=Value updated successfully
time=2016-11-18T10:14:39.891Z | lvl=DEBUG | corr=n/a | trans=n/a | op=IOTAgent.LWM2MHandlers | msg=Data handled successfully
time=2016-11-18T10:14:41.876Z | lvl=DEBUG | corr=n/a | trans=n/a | op=LWM2MLib.InformationReporting | msg=New data on resource /3304/0/5700 in device [2]
time=2016-11-18T10:14:41.876Z | lvl=DEBUG | corr=n/a | trans=n/a | op=IOTAgent.LWM2MHandlers | msg=Handling data from device [HOPe0e5cfb1f4df]
time=2016-11-18T10:14:41.876Z | lvl=DEBUG | corr=n/a | trans=n/a | op=IoTAgentNGSI.NGSIService | msg=Updating device value in the Context Broker at [http://127.0.0.1:1026/v1/updateContext]
time=2016-11-18T10:14:41.876Z | lvl=DEBUG | corr=n/a | trans=n/a | op=IoTAgentNGSI.NGSIService | msg=Using the following request:

{
    "url": "http://127.0.0.1:1026/v1/updateContext",
    "method": "POST",
    "headers": {
        "fiware-service": "HOPBeacon",
        "fiware-servicepath": "/hopbeacon",
        "X-Auth-Token": null
    }
}

Orion:

INFO@10:15:37  logMsg.h[1808]: Starting transaction from 127.0.0.1:45690/v1/updateContext
INFO@10:15:37  rest.cpp[785]: Service Path 0: '/hopbeacon'
INFO@10:15:37  connectionOperations.cpp[79]: Database Operation Successful (query: { _id.id: "HOPe0e5cfb1f4df", _id.type: "HOPBeacon", _id.servicePath: { $in: [ /^/hopbeacon$/ ] } })
INFO@10:15:37  connectionOperations.cpp[401]: Database Operation Successful (update: <{ _id.id: "HOPe0e5cfb1f4df", _id.type: "HOPBeacon", _id.servicePath: { $in: [ /^/hopbeacon$/ ] } }, { $set: { attrs.Luminosity Sensor Value: { value: "540.000010", type: "Float", mdNames: [], creDate: 1479462108, modDate: 1479464137 }, modDate: 1479464137 }, $unset: { location: 1 } }>)
INFO@10:15:37  logMsg.h[1892]: Transaction ended

But we note an extrange message appear "Internal Server Error (request is not defined)" after receive an observation. This message do not represent a problem for the LwM2M Clients but can someone clarify the procedence of this message and a way to solve it? Next image illustrates this behaviour.

BR,
David

[FRDavid]

Internal Server Error (request is not defined) problem is solved by upgrading coap library to 0.17.0. Currently is declared as 0.17.0 in package.json but npm-shrinkwrap.json forces to use 0.13.1.

This problem was detected in #93

dmoranj commented on 23 Feb
There seem to be a bug in node-coap, middleware.js, line 54: request.packet should be packet. It raises a "request not defined" error that goes all back to the parseRequest() catch, where it ends up converted in a 5.00 error. Tomorrow, first thing in the morning, I'll make a proposal bugfix to the repository.

Note: Tests carried out by grunt command raises aleatory errors after upgrade coap library to 0.17.0. However, tests are correctly passed when they are runned individually with mocha command.

[fgalan]

PR for this issue #111

[FRDavid]

Sorry @fgalan, I did the PR referencing this issue to link the issue-PR but maybe was not totally clear. My mistake.

[fgalan]

Don't worry, it's ok :)

Now that PR #111 has been merged, should this issue be closed?

[FRDavid]

Since the issue was solved and merged I will close this issue. Thanks you fgalan!