Lorawan-stack: Un webhook écrase un autre paramètre ?

Créé le 6 juil. 2019  ·  5Commentaires  ·  Source: TheThingsNetwork/lorawan-stack

Merci d'avoir soumis un rapport de bogue. Veuillez remplir le modèle ci-dessous, sinon nous ne pourrons pas traiter ce rapport de bogue.

Résumé

Résumez le problème en quelques phrases :

J'essaie de créer sur la même instance de lorawan-stack :

  • 1ère application + webhook pour environnement de production (échange de données standard)
  • Application 2'd + webhook pour la mise à jour du micrologiciel du microcontrôleur
  • le même terminal appartient aux deux applications (le même nom/eui - autre application eui/clés)

Après avoir effectué l'initialisation complète d'une application, il semble qu'il écrase les droits d'accès du webhook précédent (il ne signale aucun droit d'accès - état 403 sur la console du serveur)

Étapes pour reproduire

Comment peut-on reproduire le problème ?

Créez ap2 pour la mise à niveau du micrologiciel et un webhook pour cela :

ttn-lw-cli end-devices create ap2 dv1 \
  --dev-eui 00217E00000003FF \
  --app-eui 800000000000008C \
  --frequency-plan-id EU_863_870 \
  --root-keys.app-key.key 852BAEC23EAE7964AF27C325F4C23C9A \
  --lorawan-version 1.0.2 \
  --lorawan-phy-version 1.0.2-b
{
  "ids": {
    "device_id": "dv1",
    "application_ids": {
      "application_id": "ap2"
    },
    "dev_eui": "00217E00000003FF",
    "join_eui": "800000000000008C"
  },
  "created_at": "2019-06-26T07:49:08.966Z",
  "updated_at": "2019-06-26T07:49:09.197889667Z",
  "attributes": {
  },
  "network_server_address": "localhost",
  "application_server_address": "localhost",
  "join_server_address": "localhost",
  "lorawan_version": "1.0.2",
  "lorawan_phy_version": "1.0.2-b",
  "frequency_plan_id": "EU_863_870",
  "supports_join": true,
  "root_keys": {
    "app_key": {
      "key": "852BAEC23EAE7964AF27C325F4C23C9A"
    }
  }
}

ttn-lw-cli applications api-keys create \
  --name link \
  --application-id ap2 \
  --right-application-link

  INFO API key ID: LHUIKUKWZ62A2LXUYP4ZFC54423D3A3J36G33JY
  INFO API key value: NNSXS.LHUIKUKWZ62A2LXUYP4ZFC54423D3A3J36G33JY.NGYQQRDUJW36KJC3UP6PZYP2DNUYZTGISDJEXACL2TB5BB5EWQCA
  WARN The API key value will never be shown again
  WARN Make sure to copy it to a safe place
{
  "id": "LHUIKUKWZ62A2LXUYP4ZFC54423D3A3J36G33JY",
  "key": "NNSXS.LHUIKUKWZ62A2LXUYP4ZFC54423D3A3J36G33JY.NGYQQRDUJW36KJC3UP6PZYP2DNUYZTGISDJEXACL2TB5BB5EWQCA",
  "name": "link",
  "rights": [
    "RIGHT_APPLICATION_LINK"
  ]
}

ttn-lw-cli applications link set ap2 --api-key NNSXS.LHUIKUKWZ62A2LXUYP4ZFC54423D3A3J36G33JY.NGYQQRDUJW36KJC3UP6PZYP2DNUYZTGISDJEXACL2TB5BB5EWQCA
{
  "api_key": "NNSXS.LHUIKUKWZ62A2LXUYP4ZFC54423D3A3J36G33JY.NGYQQRDUJW36KJC3UP6PZYP2DNUYZTGISDJEXACL2TB5BB5EWQCA"
}

ttn-lw-cli applications api-keys create --name wh-client --application-id ap2 --right-application-link --right-application-all --right-application-delete --right-application-devices-read --right-application-devices-read-keys --right-application-devices-write --right-application-devices-write-keys --right-application-info --right-application-link --right-application-settings-api-keys --right-application-settings-basic --right-application-settings-collaborators --right-application-traffic-down-write --right-application-traffic-read --right-application-traffic-up-write

  INFO API key ID: CLCIYOYYEDPLJSSWRNMYS5KCDI45HOE6M3WZIDY
  INFO API key value: NNSXS.CLCIYOYYEDPLJSSWRNMYS5KCDI45HOE6M3WZIDY.E6DXAAZ4HSX2V6VL7C3244HGNKBO24SEROTXOZURJHWWOMWZQSPA
  WARN The API key value will never be shown again
  WARN Make sure to copy it to a safe place
{
  "id": "CLCIYOYYEDPLJSSWRNMYS5KCDI45HOE6M3WZIDY",
  "key": "NNSXS.CLCIYOYYEDPLJSSWRNMYS5KCDI45HOE6M3WZIDY.E6DXAAZ4HSX2V6VL7C3244HGNKBO24SEROTXOZURJHWWOMWZQSPA",
  "name": "wh-client",
  "rights": [
    "RIGHT_APPLICATION_DEVICES_WRITE",
    "RIGHT_APPLICATION_DEVICES_READ",
    "RIGHT_APPLICATION_TRAFFIC_DOWN_WRITE",
    "RIGHT_APPLICATION_SETTINGS_BASIC",
    "RIGHT_APPLICATION_DEVICES_WRITE_KEYS",
    "RIGHT_APPLICATION_INFO",
    "RIGHT_APPLICATION_SETTINGS_API_KEYS",
    "RIGHT_APPLICATION_SETTINGS_COLLABORATORS",
    "RIGHT_APPLICATION_TRAFFIC_READ",
    "RIGHT_APPLICATION_TRAFFIC_UP_WRITE",
    "RIGHT_APPLICATION_DELETE",
    "RIGHT_APPLICATION_LINK",
    "RIGHT_APPLICATION_ALL",
    "RIGHT_APPLICATION_DEVICES_READ_KEYS"
  ]
}

ttn-lw-cli applications webhooks set \
  --application-id ap2 \
  --webhook-id fwup \
  --format json \
  --base-url http://192.168.0.8/IoT/ \
  --join-accept.path lorafw.php \
  --uplink-message.path lorafw.php

{
  "ids": {
    "application_ids": {
      "application_id": "ap2"
    },
    "webhook_id": "fwup"
  },
  "created_at": "2019-06-26T07:54:51.099460917Z",
  "updated_at": "2019-06-26T07:54:51.099460917Z",
  "base_url": "http://192.168.0.8/IoT/",
  "format": "json",
  "uplink_message": {
    "path": "lorafw.php"
  },
  "join_accept": {
    "path": "lorafw.php"
  }
}

TEST:

curl http://localhost:1885/api/v3/as/applications/ap2/webhooks/fwup/devices/dv1/down/push -X POST   -H 'Authorization: Bearer NNSXS.CLCIYOYYEDPLJSSWRNMYS5KCDI45HOE6M3WZIDY.E6DXAAZ4HSX2V6VL7C3244HGNKBO24SEROTXOZURJHWWOMWZQSPA'  --data '{"downlinks":[{"frm_payload":"vu8=","f_port":15,"priority":"NORMAL"}]}'

Les webhooks fonctionnent bien maintenant

Créer ap3 pour l'environnement de production :
*Travail normal *

**ttn-lw-cli applications create ap3 --user-id admin**

{

  "ids": {

    "application_id": "ap3"

  },

  "created_at": "2019-07-06T09:45:28.540Z",

  "updated_at": "2019-07-06T09:45:28.540Z"

}

**ttn-lw-cli end-devices create ap3 dv1 \
  --dev-eui 00217E00000003FF \
  --app-eui 100000000000001C \
  --frequency-plan-id EU_863_870 \
  --root-keys.app-key.key 152BAEC23EAE7964AF27C325F4C23C9A \
  --lorawan-version 1.0.2 \
  --lorawan-phy-version 1.0.2-b**

{

  "ids": {

    "device_id": "dv1",

    "application_ids": {

      "application_id": "ap3"

    },

    "dev_eui": "00217E00000003FF",

    "join_eui": "100000000000001C"

  },

  "created_at": "2019-07-06T09:46:16.897Z",

  "updated_at": "2019-07-06T09:46:17.144655816Z",

  "attributes": {

  },

  "network_server_address": "localhost",

  "application_server_address": "localhost",

  "join_server_address": "localhost",

  "lorawan_version": "1.0.2",

  "lorawan_phy_version": "1.0.2-b",

  "frequency_plan_id": "EU_863_870",

  "supports_join": true,

  "root_keys": {

    "app_key": {

      "key": "852BAEC23EAE7964AF27C325F4C23C9A"

    }

  }

}

**ttn-lw-cli applications api-keys create \
  --name link \
  --application-id ap3 \
  --right-application-link**
  INFO API key ID: 77EPVZXEKOCAD7G6G4UGAKERJGNL3MHNYIWA7YI

  INFO API key value: NNSXS.77EPVZXEKOCAD7G6G4UGAKERJGNL3MHNYIWA7YI.UFJ2Y5ITTD6DKTMIPSH3UOUMVGPAIOGBQGF547KWPCAZ6WZE6VXQ

  WARN The API key value will never be shown again

  WARN Make sure to copy it to a safe place

{

  "id": "77EPVZXEKOCAD7G6G4UGAKERJGNL3MHNYIWA7YI",

  "key": "NNSXS.77EPVZXEKOCAD7G6G4UGAKERJGNL3MHNYIWA7YI.UFJ2Y5ITTD6DKTMIPSH3UOUMVGPAIOGBQGF547KWPCAZ6WZE6VXQ",

  "name": "link",

  "rights": [

    "RIGHT_APPLICATION_LINK"

  ]

}

**ttn-lw-cli applications link set ap3 --api-key NNSXS.77EPVZXEKOCAD7G6G4UGAKERJGNL3MHNYIWA7YI.UFJ2Y5ITTD6DKTMIPSH3UOUMVGPAIOGBQGF547KWPCAZ6WZE6VXQ**

{

  "api_key": "NNSXS.77EPVZXEKOCAD7G6G4UGAKERJGNL3MHNYIWA7YI.UFJ2Y5ITTD6DKTMIPSH3UOUMVGPAIOGBQGF547KWPCAZ6WZE6VXQ"

}

**ttn-lw-cli applications api-keys create --name wh-client --application-id ap3 --right-application-link --right-application-all --right-application-delete --right-application-devices-read --right-application-devices-read-keys --right-application-devices-write --right-application-devices-write-keys --right-application-info --right-application-link --right-application-settings-api-keys --right-application-settings-basic --right-application-settings-collaborators --right-application-traffic-down-write --right-application-traffic-read --right-application-traffic-up-write**


INFO API key ID: JIXW5XX3UITDZASY4L4A3FZ4Z53YF2S63ZASO3Y
  INFO API key value: NNSXS.JIXW5XX3UITDZASY4L4A3FZ4Z53YF2S63ZASO3Y.7TDNWLRAKDETDFJXHVWHYQ3J47CDD7SRQR66FGT7F72BHTZMSYGQ
  WARN The API key value will never be shown again
  WARN Make sure to copy it to a safe place
{

  "id": "JIXW5XX3UITDZASY4L4A3FZ4Z53YF2S63ZASO3Y",

  "key": "NNSXS.JIXW5XX3UITDZASY4L4A3FZ4Z53YF2S63ZASO3Y.7TDNWLRAKDETDFJXHVWHYQ3J47CDD7SRQR66FGT7F72BHTZMSYGQ",

  "name": "wh-client",

  "rights": [

    "RIGHT_APPLICATION_TRAFFIC_READ",

    "RIGHT_APPLICATION_SETTINGS_API_KEYS",

    "RIGHT_APPLICATION_DEVICES_READ",

    "RIGHT_APPLICATION_SETTINGS_BASIC",

    "RIGHT_APPLICATION_DEVICES_READ_KEYS",

    "RIGHT_APPLICATION_TRAFFIC_DOWN_WRITE",

    "RIGHT_APPLICATION_ALL",

    "RIGHT_APPLICATION_INFO",

    "RIGHT_APPLICATION_LINK",

    "RIGHT_APPLICATION_SETTINGS_COLLABORATORS",

    "RIGHT_APPLICATION_TRAFFIC_UP_WRITE",

    "RIGHT_APPLICATION_DEVICES_WRITE_KEYS",

    "RIGHT_APPLICATION_DELETE",

    "RIGHT_APPLICATION_DEVICES_WRITE"

  ]

}

**ttn-lw-cli applications webhooks set \
  --application-id ap3 \
  --webhook-id production \
  --format json \
  --base-url http://192.168.0.8/IoT/ \
  --join-accept.path join.php \
  --uplink-message.path up.php**



{

  "ids": {

    "application_ids": {

      "application_id": "ap3"

    },

    "webhook_id": "production"

  },

  "created_at": "2019-07-06T09:57:36.729241177Z",

  "updated_at": "2019-07-06T09:57:36.729241177Z",

  "base_url": "http://192.168.0.8/IoT/",

  "format": "json",

  "uplink_message": {

    "path": "up.php"

  },

  "join_accept": {

    "path": "join.php"

  }

}

**ttn-lw-cli applications api-keys create --name wh-prod --application-id ap3 --right-application-link --right-application-all --right-application-delete --right-application-devices-read --right-application-devices-read-keys --right-application-devices-write --right-application-devices-write-keys --right-application-info --right-application-link --right-application-settings-api-keys --right-application-settings-basic --right-application-settings-collaborators --right-application-traffic-down-write --right-application-traffic-read --right-application-traffic-up-write**

  INFO API key ID: SC626ESUGY3E5RO2NB6NOMCPKT6SDR3MJWTAQZA

  INFO API key value: NNSXS.SC626ESUGY3E5RO2NB6NOMCPKT6SDR3MJWTAQZA.VCUMNMSQQFDNBD7BSKKXEXCCMJH77254DEVTDCUICO45RDAT2TVA

  WARN The API key value will never be shown again

  WARN Make sure to copy it to a safe place

{

  "id": "SC626ESUGY3E5RO2NB6NOMCPKT6SDR3MJWTAQZA",

  "key": "NNSXS.SC626ESUGY3E5RO2NB6NOMCPKT6SDR3MJWTAQZA.VCUMNMSQQFDNBD7BSKKXEXCCMJH77254DEVTDCUICO45RDAT2TVA",

  "name": "wh-prod",

  "rights": [

    "RIGHT_APPLICATION_DELETE",

    "RIGHT_APPLICATION_LINK",

    "RIGHT_APPLICATION_DEVICES_WRITE",

    "RIGHT_APPLICATION_TRAFFIC_READ",

    "RIGHT_APPLICATION_TRAFFIC_UP_WRITE",

    "RIGHT_APPLICATION_SETTINGS_COLLABORATORS",

    "RIGHT_APPLICATION_DEVICES_WRITE_KEYS",

    "RIGHT_APPLICATION_TRAFFIC_DOWN_WRITE",

    "RIGHT_APPLICATION_DEVICES_READ_KEYS",

    "RIGHT_APPLICATION_SETTINGS_API_KEYS",

    "RIGHT_APPLICATION_SETTINGS_BASIC",

    "RIGHT_APPLICATION_DEVICES_READ",

    "RIGHT_APPLICATION_ALL",

    "RIGHT_APPLICATION_INFO"

  ]

}

a) La liaison descendante du webhook de l'application AP2 cesse de fonctionner (liaison descendante - avec problème de droits d'accès)b) Le webhook de l'application AP3 commence à fonctionnerc) Lorsque vous modifiez la clé API AP1 et l'échangez sur le fichier php du webhook et redémarrez le serveur réseau, AP2 se remet au travail et AP3 arrête le fonctionnement de la liaison descendante (liaison descendante - avec problème de droits d'accès)

API de manipulation

Que voyez-vous maintenant?

...

Que veux-tu voir à la place ?

...

Environnement


Non pertinent Ubuntu 16/kerlink/Telit/1.0.2 Classe A
...

Comment proposez-vous de mettre cela en œuvre ?

...

Pouvez-vous le faire vous-même et soumettre une Pull Request ?

...

blocking release bug application server
Source
picture ecities

Commentaire le plus utile

Je peux confirmer que j'ai pu reproduire ce bug sur le v3.0.3 . Ma course peut être trouvée ici . Je vais enquêter et je reviens avec les résultats.

picture adriansmares le 9 juil. 2019
👍2

Tous les 5 commentaires

Je peux confirmer que j'ai pu reproduire ce bug sur le v3.0.3 . Ma course peut être trouvée ici . Je vais enquêter et je reviens avec les résultats.

adriansmares picture adriansmares le 9 juil. 2019
👍2

@adriansmares Merci.

ecities picture ecities le 9 juil. 2019

J'ai migré ma configuration de v3.0.3 vers la dernière version de master et apparemment, le bogue a été corrigé entre-temps.

adriansmares<strong i="8">@A98BCD2222F1</strong>:~/go/src/go.thethings.network/lorawan-stack$ git checkout master
Previous HEAD position was e8450dac8 all: Bump to version 3.0.3
Switched to branch 'master'
Your branch is up to date with 'ttn/master'.
adriansmares<strong i="9">@A98BCD2222F1</strong>:~/go/src/go.thethings.network/lorawan-stack$ curl http://localhost:1885/api/v3/as/applications/app1/webhooks/wh1/devices/dev1/down/push   -X POST   -H 'Authorization: Bearer NNSXS.PRF4BDQMASLMRWXTV5HRM4TQUROQAHNTDR7EZTY.JK6XNLQYXQSNCAWZHFOXG6LCBINIEMVSDPR3OIORDVQF5FJCI6YA'   --data '{"downlinks":[{"frm_payload":"vu8=","f_port":15,"priority":"NORMAL"}]}'
adriansmares<strong i="10">@A98BCD2222F1</strong>:~/go/src/go.thethings.network/lorawan-stack$ curl http://localhost:1885/api/v3/as/applications/app2/webhooks/wh1/devices/dev1/down/push   -X POST   -H 'Authorization: Bearer NNSXS.V3ZM2DMCSFK4YEBB55WA6MMY34YXQ6SARLJS4TQ.OILYCKNO5R25HYYZB6BPOJN5XLKWQZFXOIB77TJ464IDQBQ2YI7A'   --data '{"downlinks":[{"frm_payload":"vu8=","f_port":15,"priority":"NORMAL"}]}'
adriansmares<strong i="11">@A98BCD2222F1</strong>:~/go/src/go.thethings.network/lorawan-stack$ git checkout v3.0.3
Note: checking out 'v3.0.3'.
...
HEAD is now at e8450dac8 all: Bump to version 3.0.3
adriansmares<strong i="12">@A98BCD2222F1</strong>:~/go/src/go.thethings.network/lorawan-stack$ curl http://localhost:1885/api/v3/as/applications/app1/webhooks/wh1/devices/dev1/down/push   -X POST   -H 'Authorization: Bearer NNSXS.PRF4BDQMASLMRWXTV5HRM4TQUROQAHNTDR7EZTY.JK6XNLQYXQSNCAWZHFOXG6LCBINIEMVSDPR3OIORDVQF5FJCI6YA'   --data '{"downlinks":[{"frm_payload":"vu8=","f_port":15,"priority":"NORMAL"}]}'
adriansmares<strong i="13">@A98BCD2222F1</strong>:~/go/src/go.thethings.network/lorawan-stack$ curl http://localhost:1885/api/v3/as/applications/app2/webhooks/wh1/devices/dev1/down/push   -X POST   -H 'Authorization: Bearer NNSXS.V3ZM2DMCSFK4YEBB55WA6MMY34YXQ6SARLJS4TQ.OILYCKNO5R25HYYZB6BPOJN5XLKWQZFXOIB77TJ464IDQBQ2YI7A'   --data '{"downlinks":[{"frm_payload":"vu8=","f_port":15,"priority":"NORMAL"}]}'
error:pkg/auth/rights:no_application_rights (no rights for application `app2`)

J'ai cependant regardé quels commits ont résolu ce problème, et ils sont a2e7e4c6b8929dfd52ba62046cc70d4529c4f25e et fe95aafb9959e841e920eaad39eb2e39b6ed24e6

adriansmares<strong i="17">@A98BCD2222F1</strong>:~/go/src/go.thethings.network/lorawan-stack$ git checkout v3.0.3
...
HEAD is now at e8450dac8 all: Bump to version 3.0.3
adriansmares<strong i="18">@A98BCD2222F1</strong>:~/go/src/go.thethings.network/lorawan-stack$ git cherry-pick a2e7e4c6b8929dfd52ba62046cc70d4529c4f25e
[detached HEAD d8f1ee6fc] as: Use request context in webhook downlink
 Author: Johan Stokking <[email protected]>
 Date: Mon May 27 14:39:05 2019 +0200
 4 files changed, 27 insertions(+), 4 deletions(-)
adriansmares<strong i="19">@A98BCD2222F1</strong>:~/go/src/go.thethings.network/lorawan-stack$ git cherry-pick fe95aafb9959e841e920eaad39eb2e39b6ed24e6
[detached HEAD dce35a353] as: Fill Webhook downlink queue request context
 Date: Tue Jul 2 11:44:10 2019 +0200
 1 file changed, 1 insertion(+), 1 deletion(-)
adriansmares<strong i="20">@A98BCD2222F1</strong>:~/go/src/go.thethings.network/lorawan-stack$ curl http://localhost:1885/api/v3/as/applications/app1/webhooks/wh1/devices/dev1/down/push   -X POST   -H 'Authorization: Bearer NNSXS.PRF4BDQMASLMRWXTV5HRM4TQUROQAHNTDR7EZTY.JK6XNLQYXQSNCAWZHFOXG6LCBINIEMVSDPR3OIORDVQF5FJCI6YA'   --data '{"downlinks":[{"frm_payload":"vu8=","f_port":15,"priority":"NORMAL"}]}'
adriansmares<strong i="21">@A98BCD2222F1</strong>:~/go/src/go.thethings.network/lorawan-stack$ curl http://localhost:1885/api/v3/as/applications/app2/webhooks/wh1/devices/dev1/down/push   -X POST   -H 'Authorization: Bearer NNSXS.V3ZM2DMCSFK4YEBB55WA6MMY34YXQ6SARLJS4TQ.OILYCKNO5R25HYYZB6BPOJN5XLKWQZFXOIB77TJ464IDQBQ2YI7A'   --data '{"downlinks":[{"frm_payload":"vu8=","f_port":15,"priority":"NORMAL"}]}'

Puisque nous n'avons pas d'image docker master , devrions-nous avoir une version v3.0.3b qui inclut ces correctifs ? @johanstokking @htdvisser

adriansmares picture adriansmares le 9 juil. 2019

J'ai enquêté sur _pourquoi_ les deux commits résolvent réellement ce problème, et j'ai constaté que la vraie cause n'est en fait pas liée directement à eux, mais plutôt au fait que dans v3.0.3 le contexte utilisé pour la vérification des droits est partagé entre les requêtes .

Dans v3.0.3 , le contexte utilisé par le composant Webhooks pour vérifier les droits de la requête est w.ctx , qui si on suit sa création, est le contexte du Component , puis rempli avec FillContext .
https://github.com/TheThingsNetwork/lorawan-stack/blob/e8450dac84c1d7ec685121957d7e8cd4ef67c013/pkg/applicationserver/applicationserver.go#L163
Cela semble inoffensif (ou du moins regardé jusqu'à aujourd'hui), jusqu'à ce que vous réalisiez que l'un des remplisseurs de contexte est un cache de droits, _qui reste à l'intérieur du contexte après la première utilisation_.
https://github.com/TheThingsNetwork/lorawan-stack/blob/e8450dac84c1d7ec685121957d7e8cd4ef67c013/pkg/identityserver/entity_access.go#L46 -L69
https://github.com/TheThingsNetwork/lorawan-stack/blob/e8450dac84c1d7ec685121957d7e8cd4ef67c013/pkg/identityserver/identityserver.go#L146 -L150

Ce qui se passe, c'est que la première requête (par app1 , ou app2 - n'a pas vraiment d'importance) définit le cache du contexte Webhooks ( w.ctx ). w.ctx est FillContext ed lors de la création, et contient le cache d'authentification - donc une fois la première requête effectuée, les droits sont enregistrés dans le contexte.
https://github.com/TheThingsNetwork/lorawan-stack/blob/e8450dac84c1d7ec685121957d7e8cd4ef67c013/pkg/identityserver/entity_access.go#L64 -L68
Les demandes de suivi ne sont plus servies par la base de données IS et sont plutôt remplies à partir du cache. Mais comme la clé API qui a fait la première requête n'a pas de droits sur la seconde application, la 2ème requête échoue. Le corollaire est que toute autre demande qui n'est pas effectuée par la première clé API échouera par défaut.

TLDR : probablement https://github.com/TheThingsNetwork/lorawan-stack/pull/902/commits/e6ab950fa76bc8cdbe6dc519ec71b9deed2e7231 devrait également être fusionné dans la version du correctif rapide.

adriansmares picture adriansmares le 9 juil. 2019
👍1

Publié dans https://github.com/TheThingsNetwork/lorawan-stack/releases/tag/v3.0.4

johanstokking picture johanstokking le 10 juil. 2019
Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

johanstokking picture johanstokking  ·  6Commentaires
johanstokking picture johanstokking  ·  3Commentaires
ZeroSum24 picture ZeroSum24  ·  3Commentaires
bafonins picture bafonins  ·  5Commentaires
kschiffer picture kschiffer  ·  7Commentaires