Differences

This shows you the differences between two versions of the page.

--- home [2021/04/07 18:33]
tda
+++ home [2024/03/07 17:02] (current)
ehe [How to check OpenVPN certificates validity?]
@@ Line 782: / Line 782: @@
 ===== Can you use MQTT without a broker? =====
 No.
+===== Which version of MQTT is implemented   =====
+The WMC implements MQTT v3.1.1.
 ===== Can multiple clients publish to the same topic? =====
@@ Line 1082: / Line 1086: @@
 If you hesitate and don't not know what to do, perform an ofono reset and a reboot!
+===== How the Push configuration check button works ? =====
+To make the check button works, it is necessary to define 2 routes on the Application server (AS):
+   * 1 route for uplink messages
+   * 1 route for downlink messages
+If one of these routes is missing, the check button will return an error.
+The 2 routes that must exist are the routes defined in the WMC push configuration.
+For instance:
+{{:images:push_configuration_1.png?600|}}
+When the fields are left empty, that means that this is the default routes that will be used:
+    * /dataUp  for the uplink route,
+    * /dataDownEvent for the downlink route.
+Those 2 routes should exist on your application server from the ROOT_DIRECTORY path.
+**Example with NODERED:**
+Here is the push configuration defined WMC side:
+{{:images:push_configuration_2.png?600|}}
+Here are the 2 objects (routes) to define in NODERED:
+{{:images:push_configuration_3.png?800|}}
+and their definition:
+{{:images:push_configuration_4.png?400|}}     \\
+{{:images:push_configuration_5.png?400|}}
+And here's the final result of pressing the push configuration check button:
+{{:images:push_configuration_6.png?1000|}}
+{{:images:push_configuration_8.png?100|}}
+The following message should be displayed at the bottom of the screen:
+{{:images:push_configuration_7.png?300|}}
+===== How to make confirmed downlink messages work ? =====
+Confirmed downlink messages are downlink messages that are acknowledged by an end-device.
+To acknowledge a confirmed downlink message, the end-device should set a specific bit (ACK) in the FCtrl field of an Unconfirmed Uplink message header as the LoRaWAN specification shows:
+{{:images:confirmed_downlink_messages_1.png?800|}}
+{{:images:confirmed_downlink_messages_2.png?800|}}
+Here is an example of an acknowledge message received by the Packet Forwarder:
+<code>
+-06-29T13:21:24.192091+00:00 klk-lpbs-060434 lorafwd[1178]: <6> Received uplink message:
+-06-29T13:21:24.192234+00:00 klk-lpbs-060434 lorafwd[1178]: <6> | lora uplink (45E0470C), payload 31 B, channel 868.3 MHz, crc ok, bw 125 kHz, sf 10, cr 4
+-06-29T13:21:24.192312+00:00 klk-lpbs-060434 lorafwd[1178]: <6> | Unconfirmed Data Up, DevAddr 24000258, FCtrl [ADR] [ACK], FCnt 48, FPort 1
+-06-29T13:21:24.192371+00:00 klk-lpbs-060434 lorafwd[1178]: <6> | - radio (00000016)
+-06-29T13:21:24.192469+00:00 klk-lpbs-060434 lorafwd[1178]: <6> | - demodulator counter 421267796, UTC time 2021-06-29T13:21:24.110863Z, rssi -52 dB, sn
+-06-29T13:21:24.192544+00:00 klk-lpbs-060434 lorafwd[1178]: <6> | - localization unknown, rssi -50 dB, frequency offset -2779 Hz, status (00000047)
+-06-29T13:21:24.201154+00:00 klk-lpbs-060434 lorad[1113]: <6> Sent 1 uplink message
+-06-29T13:21:24.202002+00:00 klk-lpbs-060434 lorafwd[1178]: <6> Uplink message (6C0C) sent
+</code>
+Caution: when creating the confirmed downlink message, it is very important to set properly the timeout value if you don't want to see a KO as the final status of the sending message.
+To create a confirmed downlink message, you have to **enable the option "Acknowlegement".**
+For class A end-devices, the timeout value must be greater than the time period of uplink messages. For instance, if your uplink messages periodicity  is 60s, you must set a timeout value at least equal to 60s.
+{{:images:confirmed_downlink_messages_3.png?400|}}  \\
+{{:images:confirmed_downlink_messages_4.png?800|}}   \\
+{{:images:confirmed_downlink_messages_5.png?800|}}   \\
+In this example, the periodicity of uplinks is 8s, so the timeout value has been set to 8s.
+===== How to make the Multicast Class C works ? =====
+The Multicast Class C has the objective to send a single message as a brodcasting manner to a group of end-devices.
+To achieve this, you must define a Multicast group with the following definition:
+    * A cluster name: the same cluster that the end-devices belong to.
+    * A multicast address: DevAddr, a 32 bit network address (must be unique and not belong to an existing end-device)
+    * An application session key (AppSKey) and a network session key (NWkSKey) used for frames encryption, 32 digits hexadecimal string.
+    * A fixed frequency in MHz (float32) and a DataRate (a string formatted as "SFxxBWyyy" with xx from 7 to 12 and yyy = 125/250/500 for LoRa modulation or yyy=5000 for FSK modulation)
+    * A frame counter (optional): FCntDown
+    * The LoRaWAN MAC version: for Europe 868 MHz, select 1.0.2 MAC version and Regional parameters B revision to be compatible with WMC 2.x
+The multicast address and associated network session key and application session key must come from the application layer.
+Class-C multicast downlinks SHALL NOT carry MAC commands.
+For instance:
+{{:images:multicast_1.png?800|}}
+Note that all the end-devices must be flashed with 2 pairs of keys:
+    * The end-device's own keys (OTAA or ABP keys).
+    * the Multicast group keys defined above.
+So each end-device has 2 devAddr:
+    * its own devAddr.
+    * the Multicast group devAddr.
+We recommend to use a channel frequency which duty cycle is the most permissive: for instance using 869.525Mhz allows a duty cycle of 10% instead of using 868.1Mhz that allows a duty cycle of only 1%.
+In the same order, we recommend to use a SF7BW125 instead of SF12BW125 to use the highest datarate as possible and to minimize the duty cycle.
+The Multicast class C uses Unconfirmed downlink messages and not Confirmed downlink messages.
+That's why you have no timeout and no retry count to specify.
+{{:images:multicast_2.png?400|}}
+So there is no information about the fact that the downlink message has been correctly received by the end-devices.
+**Care to not use FPort 0 reserved for MAC commands.**
+Example:
+Using Semtech Nucleo class C end-devices:
+<code>
+Device Nucleo Semtech 151
+    devEUI : 1136C04218030151
+    devAddr : 0033004D
+    AppSKey : 00000000000000000000000000000000
+    NwkSKey : 00000000000000000000000000000000
+    Class C
+</code>
+{{:images:multicast_3.png?400|}}
+Adding end-devices in the Multicast group:
+{{:images:multicast_4.png?600|}}
+Sending data down messages:
+{{:images:multicast_5.png?1000|}}
+===== How to switch the cellular backhaul from 4G to 3G ? =====
+Connect to the gateway (for instance over the remote shell) and type the following command:
+For stations using a quectel modem (**Wirnet iStation, Wirnet iFemtoCell Evolution**):
+<code>
+dbus-send --system --type=method_call --print-reply --dest=org.ofono /quectelqmi_0 org.ofono.RadioSettings.SetProperty string:"TechnologyPreference"  variant:string:"umts"
+</code>
+For stations using a sierra modem (**Wirnet iBTS**):
+<code>
+dbus-send --system --type=method_call --print-reply --dest=org.ofono /sierra_0 org.ofono.RadioSettings.SetProperty string:"TechnologyPreference"  variant:string:"umts"
+</code>
+Note that this configuration is persistent (is not removed when rebooting the gateway).
+\\
+===== How to switch the cellular backhaul from 3G to 4G ? =====
+Connect to the gateway (for instance over the remote shell) and type the following command:
+For stations using a quectel modem (**Wirnet iStation, Wirnet iFemtoCell Evolution**):
+<code>
+dbus-send --system --type=method_call --print-reply --dest=org.ofono /quectelqmi_0 org.ofono.RadioSettings.SetProperty string:"TechnologyPreference"  variant:string:"lte"
+</code>
+For stations using a sierra modem (**Wirnet iBTS**):
+<code>
+dbus-send --system --type=method_call --print-reply --dest=org.ofono /sierra_0 org.ofono.RadioSettings.SetProperty string:"TechnologyPreference"  variant:string:"lte"
+</code>
+Note that this configuration is persistent (is not removed when rebooting the gateway).
+===== How to acknowledge an alarm using GMS API =====
+Acknowledging an alarm using GMS API can be useful to remove the alarm from the active alarms list.
+The main advantage of doing this over GMS API is the fact that this task can be done using a script (bash, python, javascript, java, etc...) at the application level on any remote machine. No human action is required (selecting the bell icon to cancel the alarm).
+Here is the procedure:
+  - Call the Login web service to get your session token
+  - Copy the token value in the Authorize field
+  - Call the web-service **getGatewayLastEvents**  to get the list of the last events of a given gateway
+  - Get the eventID in the response
+  - Put this eventID in the **patchLastEvent** request
+For instance :
+I want to acknowledge the "POWER_LOST" alarm for the gateway 707600FF54040023
+{{:images:gateway_alarms.png|}}
+I'm skipping the login procedure that is explained in the WMC WIKI here:
+[[https://wikikerlink.fr/wanesy-ran/doku.php?id=wiki:wiki3:swaggerui&s[]=login| GMS API Login]]
+I'm calling the web service **getGatewayLastEvents** passing the gateway EUI as parameter:
+{{:images:getgatewaylastevents.png|}}
+It is possible to filter events using the search field (filtering on the event category, for instance).
+The response is :
+{{:images:power_lost_event.png|}}
+From the response, I can get the eventID (here 619) that will be used in the following request.
+Calling the **patchLastEvent** webservice with the "eventID" parameters and "read" parameter with the value "true":
+{{:images:patchlastevent.png|}}
+If the response is 20x then the request has been correctly executed.
+{{:images:patchlastevent_response.png|}}
+The event has been removed from the active alarms list :
+{{:images:gateway_alarms_2.png|}}
+Note: I have also acknowledged the "GPS_UNLOCKED" alarm in the same manner.
+===== How to get unsent push messages using GMS API =====
+For some unknown reasons, the push can fail for instance when an outage occurs on the customer's Application server. \\
+To avoid losing application messages, the following procedure can be applied to retrieve unsent messages over GMS API.
+The webservice to use is **getDataUp** with a specific search criteria to get unsent message :
+<code>
+{"operand":"pushed","operation":"eq","values":["false"]}
+</code>
+This search criteria will return all the unsent messages since the WMC was turned online.
+Maybe you will desire to filter on a given time period.
+To achieve this, the following search criteria can be used :
+<code>
+{"operator": "AND","conditions": [{"operand": "pushed","operation": "EQ","values": ["false"]},{"operand": "recvTime","operation": "GTE","values": ["<TIME START in ms>"]},{"operand": "recvTime","operation": "LTE","values": ["<TIME END in ms>" ]} ]}
+</code>
+A more readable search criteria :
+<code>
+  {
+			  "operator": "AND",
+			  "conditions": [
+			    {
+			      "operand": "pushed",
+			      "operation": "EQ",
+			      "values": [
+			        "false"
+			      ]
+			    },
+			    {
+			      "operand": "recvTime",
+			      "operation": "GTE",
+			      "values": [
+			        "<TIME START in ms>"
+			      ]
+			    },
+							    {
+			      "operand": "recvTime",
+			      "operation": "LTE",
+			      "values": [
+			        "<TIME END in ms>"
+			      ]
+			    }
+			  ]
+}
+</code>
+For instance:
+Filtering messages from:  2022-01-05 13:28:18 UTC+2 to: 2022-01-06 13:27:13 UTC+2 \\
+Note: use EPOCH Converter tool to convert these dates to Epoch timestamps in ms and don't forget to use GMT/UTC values !
+<code>
+{"operator": "AND","conditions": [{"operand": "pushed","operation": "EQ","values": ["false"]},{"operand": "recvTime","operation": "GTE","values": ["1641382098000"]},{"operand": "recvTime","operation": "LTE","values": ["1641468433000" ]} ]}
+</code>
+Testing:
+{{:images:unsent_messages_1.png|800}}
+{{:images:unsent_messages_2.png|}}
+===== How to configure DIVERSITY on iBTS? =====
+Please see in **iSeries Wiki FAQ**: [[https://wikikerlink.fr/wirnet-productline/doku.php?id=wiki:support:faq#how_to_configure_diversity_on_ibts|How to configure DIVERSITY on iBTS?]]
+===== How to check OpenVPN certificates validity? =====
+You can use following commands, depending on the KerOS version installed on the gateways.
+On version 3x:
+<code>
+openssl pkcs12 -info -in /etc/openvpn/client-openvpn.p12 -nokeys -password pass: | openssl x509 -noout -enddate
+</code>
+On version 4x:
+<code>
+grep 'Not After' /.update/update.log | awk 'END {print}'
+</code>
+On version 5x:
+<code>
+openssl pkcs12 -info -in /etc/openvpn/bscc.p12 -nokeys -password file:/etc/openvpn/bscc.password| openssl x509 -noout -enddate
+</code>
+===== Which network configuration should be done to connect my gateway to Wanesy™ Management Cockpit? =====
+[[https://wikikerlink.fr/wanesy-management-cockpit/doku.php?id=wiki:network|Wanesy™ Management Cockpit - Network management]]
+===== Administrative information =====
+You can find in following document, the administrative information you should know as a user of Kerlink’s products:
+{{ :wiki:administrative_information20211006.pdf |Administrative information}}

Kerlink FAQ

User Tools

Site Tools

Differences

Page Tools