This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
home [2021/07/02 16:51] tda |
home [2025/09/30 11:53] (current) ehe |
||
|---|---|---|---|
| Line 2: | Line 2: | ||
| \\ | \\ | ||
| + | ===== Firmware Support Rules ===== | ||
| + | //**At Kerlink, we are committed to supporting all our customers, regardless of the software version they are currently using.**\\ | ||
| + | To ensure you benefit from the latest improvements and corrections, new features and defect fixes are provided exclusively on the most recent official release.\\ | ||
| + | For certain investigations, Kerlink may request that your equipment be updated to the latest release in order to guarantee efficient and accurate support.\\ | ||
| + | **We strongly recommend keeping your equipment up to date with the latest official version to enjoy optimal performance, security, and access to the newest functionalities.**\\ | ||
| + | To stay informed about new releases, you can easily subscribe here: [[https://notification.docs.kerlink.com/welcome-to-kerlink-wiki-news/|Kerlink Wiki News]].\\ | ||
| + | For more details on the software versions currently supported from a security perspective, please visit: [[https://keros.docs.kerlink.com/en/security_support|Kerlink Security Support]].\\ | ||
| + | // | ||
| + | |||
| + | |||
| + | |||
| ===== How to know the password to connect in SSH according to the product and the version? ===== | ===== How to know the password to connect in SSH according to the product and the version? ===== | ||
| Line 782: | Line 793: | ||
| ===== Can you use MQTT without a broker? ===== | ===== Can you use MQTT without a broker? ===== | ||
| No. | No. | ||
| + | |||
| + | ===== Which version of MQTT is implemented ===== | ||
| + | |||
| + | The WMC implements MQTT v3.1.1. | ||
| ===== Can multiple clients publish to the same topic? ===== | ===== Can multiple clients publish to the same topic? ===== | ||
| Line 1158: | Line 1173: | ||
| 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. | 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. | 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. | ||
| Line 1244: | Line 1261: | ||
| + | ===== 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}} | ||