Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Certificates support added (only LoRaServer.io) #18

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

diego-gv
Copy link

Tell me any question or change that you consider appropriate.

I have also added the standart gitignore file for javascript projects.

@diego-gv diego-gv closed this Nov 19, 2018
@diego-gv diego-gv reopened this Nov 19, 2018
@diego-gv
Copy link
Author

My proposal is to follow this example:

Type1: {
    service: 'service',
    subservice: '/servicepath',
    attributes: [
        {
            'name': 'temperature',
            'type': 'Number'
        }
    ],
    internalAttributes: {
        lorawan: {
            application_server: {
                host: 'mosquitto',
                username: 'user',
                password: 'password',
                provider: 'loraserver.io',
                options: {
                    port: 1883,
                    clientId: 'MQTT_client1',
                    ca: fs.readFileSync('docker/certs/ca.pem'),
                    cert: fs.readFileSync('docker/certs/mqtt-client.pem'),
                    key: fs.readFileSync('docker/certs/mqtt-client-key.pem'),
                    rejectUnauthorized: true,
                    protocol: 'mqtts'
                }
            },
            app_eui: '**************',
            application_id: '****'
        }
    }
},

This type of configuration allows us to play with the MQTT's configurations. We would have to describe the MQTT broker for each type, but this is a simple solution.

An other hand, I tried to write simple tests to check my implementation, but because of my experience like Javascript developer is limited (I'm mainly Python Developer) I don't know very well how to do it and I'm still looking for a correctly way to implement it following the tests already done by you.

I'm sorry for the possible inconveniences.

@diego-gv diego-gv changed the title Certificates support added Certificates support added (only LoRaServer.io) Nov 20, 2018
@diego-gv
Copy link
Author

Hello!

I have been looking at my previous proposal and I have decided to change the way in which certificates are indicated. In this case we will have to indicate the certificates as a list of ASCII numbers.

options: {
   port: 1883,
   clientId: 'MQTT_client1',
   ca: [45,45,45,45,45,66,69,71,73,78,32,67,69,82,84,73,70,73,67,65,84,69,45,....],
   cert: [45,45,45,45,45,66,69,71,73,78,32,67,69,82,84,73,70,73,67,65,84,69,.....],
   key: [45,45,45,45,45,66,69,71,73,78,32,82,83,65,32,80,82,73,86,65,84,69,32,.....],
   rejectUnauthorized: true,
   protocol: 'mqtts'
}

This way , for example, we could send the certificates in a Device Provisioning by means of a POST request from Postman.

In addition, in the static provisioning we can continue indicating the certificates as indicated above (as a file).

Bests regards

@dcalvoalonso
Copy link
Collaborator

Hi @garvi-x,

First of all, sorry for the delay to review this PR.

In principle, I am OK with your proposal, but I don't like too much the last change to indicate the certificates as a list of ASCII numbers. I would prefer to use the first option and pass the certificates using a volume.

What do you think?

@diego-gv
Copy link
Author

diego-gv commented Jan 8, 2019

Hi @dcalvoalonso,

My proposal is that we can have both options, certificates in a volume and as a list of ASCII numbers.

The first option is for static provisioning, while the second option is for device and service provisioning. Since certificates in a volume are not available from outside using, for example, Postman.

@StWiemann
Copy link

Hi I am fairly new to this and wanted to use the LoRaWan-IoT-Agent with an existing LoRaServer.io I can get my hands on. Did you manage to provision a device with your method?

The mqtt-server uses a root signed CA and mqtts. Also the mqtt-broker needs user credentials to log on and the port needs to be 8883. Is there any headway with this?
To be honest I am a bit lost, for all I get is an empty response after what I think is a timeout.

@diego-gv
Copy link
Author

Hi @StWiemann,

The method that I used for device provisioning was the same that it is explain in the documentation of this project in this link: https://fiware-lorawan.readthedocs.io/en/latest/users_manual/index.html

On the other hand, I am not a expert in this materia, only I have read the documentation of LoRaWAN IoTAgent and LoRaServer.io for deployment my scenary.

I hope I helped you.

@StWiemann
Copy link

StWiemann commented Mar 26, 2019

Thanks @garvi-x,
I managed to connect to my own mqtt-broker by using the iotagent-json instead with some additional environmentals:

  • IOTA_MQTT_HOST=hostaddress.de # The host name of the MQTT Broker
  • IOTA_MQTT_PORT=8883 # The port the MQTT Broker is listening on to receive topics
  • IOTA_MQTT_PROTOCOL=mqtts
  • IOTA_MQTT_USERNAME=Mqtt-Account
  • IOTA_MQTT_PASSWORD=Mqtt-Password

That works for me as a starting point. LoRaWAN might come later.

@chopmann
Copy link

@garvi-x Maybe Base64 would be the better option.
https://nodejs.org/api/buffer.html#buffer_class_method_buffer_from_string_encoding

@chicco785
Copy link
Collaborator

@diego-gv

can you rebase your changes to the current up-to-date code base? thx

1 similar comment
@chicco785
Copy link
Collaborator

@diego-gv

can you rebase your changes to the current up-to-date code base? thx

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants