Status | Date | Doc Version | Applicable | Confidentiality |
RELEASED | v3.10 | WNT v3.x, v4.x | PUBLIC |
General Information
This document collects the Wirepas Network Tool errata. The document is updated when new errata item is added, or the errata item is updated either work around or information on fix for Wirepas Network Tool release.
Severity has three levels: Low, Medium and High. Severity is provided just for information to understand the impact on Wirepas Network Tool functionality or performance. The workaround outlines if there is a way to overcome the bug visible in Affected Versions (Errata). The Fix Version (Errata) indicates the version where the errata item is resolved (possible workaround is not anymore needed).
Revision history summarizes all the updates to this document.
Errata Summary
Key | errata title | errata description | errata severity | affected versions (errata) | fix version (errata) | errata workaround exists? | errata workaround description |
WNTNG-764 | WNT sends also areas without corner points to WPE, which will discard the whole message | As WNT sends all the area information for floor plan to the WPE in a single message, which may also contain areas without any corner points, the whole area configuration message might be discarded in WPE side as it does not allow areas without corner points. It is not possible to see this issue happening from the WNT UI, but only from the WNT/WPE logs. | High | v4.3.0.62 | v4.4.0.10 | Yes | After deleting all the areas without any corner points and saving the changes in WNT UI, the area configuration will be taken into use successfully in WPE. |
WNTNG-691 | WNT backend does not work correctly when instance is rebooted | When instance is rebooted some WNT and WPE internal connections are not reconnected correctly, and this causes that VerneMQ starts to buffer incoming messages to the disk. When services are started next time, VerneMQ might have buffered so much messages that the starting takes really long time or WNT and WPE services does not work correctly. | High | v4.3.0.62, v4.2.0.141, v4.1.2, v4.1.1.1, v4.1.0.205, v4.1.0.200, v4.0.0.1215 | Yes | Workaround (implemented in WNT 4.3 backend installer):
Workaround, if it is not feasible to change persistent connections expiration time:
| |
WNTNG-617 | Area field in MQTT JSON message contains old area information when tag moves out from area | When tag moves out from floor plan area into a location where there is no area(s) defined, the MQTT JSON message data contains the previous area information. | High | v4.1.1.1, v4.1.0.205, v4.1.0.200, v4.0.0.1215 | v4.1.2 | No | |
WNTNG-605 | Overview page is not always refreshed when all the nodes in the backend goes offline | When all the nodes in the backend goes offline it is possible that WNT client’s Overview page is not refreshed. Due to this it looks that some nodes are online although all of them are offline. Nodes list page shows the correct information. | High | v4.1.0.200, v4.0.0.1215 | v4.1.1.1 | Yes | It is possible to refresh the Overview page by adding and removing a filter. |
WNTNG-600 | WNT backend stops accepting client connections after automatic update of Let's Encrypt certificates | This problem occurs in WNT 4.1 backends that are installed / updated with Wirepas services installer and are using Let’s Encrypt certificates. Also older WNT backends (3.0.X and 4.0) that have been updated with the haproxy security patch are affected. The validity period of Let’s Encrypt certificates is three months. An automatic renewal of certificates is implemented in the backend to make sure that the environment has always valid certifictes. However, in WNT 4.1 backend installation configuration has an issue in the automatic certificate renewal, which leads to a situation that after the certificate renewal WNT backend does not anymore allow new WNT client connections or MQTT connect from gateways. The root cause of the problems is that the automated certificate renewal script sets incorrect file permissions to the bundle.pem file containing the certificates. After the renewal, the file permissions are set to 0600 instead of needed 0644. Due to this, the WNT backend TLS proxy cannot read the file and ceases accepting new TLS connections. | High | v4.1.0.200, v4.0.0.1215, v3.0.3, v3.0.2, v3.0.1.0 | v4.2.0.141 | Yes | There is rather simple workaround for the problem. This workaround should be applied before the certificate renewal is done. In order to make sure that file permissions are set correctly, modify file in /home/ubuntu/wnt/renew_cert.sh (or in WNT installation directory) line 8: Make sure that the file path in the above command is not changed (in case the WNT install path is different from the default path). If the environment has already run into problems, it is possible to fix the backend by running following commands (make sure that you are operating in WNT installation folder, if it differs from the default): |
WNTNG-587 | MQTT JSON data publishing does not always start when the backend services are started | MQTT JSON data publishing does not always start when backend services start. This is caused by timing and/or metadata issue related to multiple floor plans in a single building. It is possible that single realtime situation manager starts to send data, but the others not. Even backend services restart might not fix the issue. | High | v4.1.0.200, v4.0.0.1215 | v4.1.1.1 | No | |
WNTNG-318 | OTAP does not start if all nodes in the network has loaded with scratcpad sequence 255 | Scratchpad update in the Wirepas Mesh does not work in the case, where the scratchpad sequence number in the network is 255. WNT backend will not load any new scratchpads into the network. | High | v3.0.1.0, v3.0.0.24 | v4.0.0.1215 | No | |
WNTNG-777 | Scratchpad status query does not work correctly when using it in a situation where all the sinks are offline | When calling scratchpad status from the WNT client’s Node update page in a situation where all the sinks are offline, the message is sent to the network when first sink becomes online. This also affects to the continuous query in a way that after pressing Start continuous button the button text does not change to Stop continuous and the continuous query is started when the first sink becomes online. | Medium | v4.3.0.62, v4.2.0.141, v4.1.2, v4.1.1.1, v4.1.0.200, v4.0.0.1236, v4.0.0.1215 | No | ||
WNTNG-763 | WNT backend sets tag's positioning role to unknown when its metadata is updated | WNT backend sets tag’s positioning role from tag to unknown when any metadata field for it is changed (e.g. name, description). The positioning role is set back to tag when WNT receives next calculated location from WPE for the node. | Medium | v4.3.0.62, v4.2.0.141, v4.1.2, v4.1.1.1, v4.1.0.200, v4.0.0.1215 | v4.4.0.10 | No | |
WNTNG-746 | MQTT JSON message is not emitted when anchor location changes while optimized mode is off | A MQTT JSON message is not emitted when anchor position is changed using WNT metadata API, and the optimized mode is off. Please note that the message is not sent in this case if optimized mode is on either, as that is the desired functionality. | Medium | v4.3.0.62, v4.2.0.141, v4.1.1.1, v4.1.0.200, v4.0.0.1236, v4.0.0.1215 | v4.4.0.10 | No | |
WNTNG-730 | WNT Backend API allows floating point values for integer fields | WNT Backend API allows floating point values to be used in fields where only integer values are applicable. When using floating point values for integer fields the outcome is indeterministic. | Medium | v4.3.0.62, v4.2.0.141, v4.1.1.1, v4.1.0.200, v4.0.0.1236, v4.0.0.1215 | Yes | Use integer values where applicable. | |
WNTNG-680 | It is possible to start OTAP and RemoteAPI processes to the same network | It is possible to start simultaneous OTAP (Node update) and RemoteAPI (Node configuration) processes to the same network with two different WNT client instances. Example steps:
| Medium | v4.3.0.62, v4.2.0.141, v4.1.2, v4.1.1.1, v4.1.0.205, v4.1.0.200, v4.0.0.1215 | Yes | The actual RemoteAPI/OTAP processes should be started immediately after the process page is opened. | |
WNTNG-658 | Legacy OTAP does not work in WNT with Linux Gateway >= 1.4.1 | Linux Gateway 1.4.1 added sending of configuration to gw-response/set_config/ topic after scratchpad loading has started (as stack is stopped then), and this causes message exchange between WNT and gateway with end result that sink is not on (as stack is stopped). Because of this WNT does not process result of the scratchpad loading, and after several attempts will cause data corruption on the WNT backend. | Medium | v4.1.2, v4.1.1.1, v4.1.0.200, v4.0.0.1215, v3.0.1.0, v3.0.0.24, v2.0.0.189 | v4.2.0.141 | Yes | Use OTAPv2 if possible or use older Linux Gateway releases. |
WNTNG-586 | Multiline measurement visualization is not working in the node information page | Visualizing "Uplink delay for normal priority (min/avg/max)", "Uplink delay for high priority (min/avg/max)", “Reserved slot usage (avg, max)” or “Buffer usage (avg, max)” from node information causes the WNT client to not show the loaded data. | Medium | v4.1.0.200 | v4.1.0.205 | No | |
WNTNG-579 | WNT shows wrong error codes for part of the gateway error codes | Gateway error mapping does not work correctly in WNT. Mapping of gateway error codes to errors visible in WNT: INVALID_PARAM → NO_SCRATCHPAD_PRESENT | Medium | v4.1.2, v4.1.1.1, v4.1.0.205, v4.1.0.200, v4.0.0.1215 | v4.2.0.141 | No | |
WNTNG-525 | WNT backend cannot handle OTAP load for networks that have tens of thousands nodes | Backend load can get too high while running OTAP for network with tens of thousands nodes. Issue have been seen on AWS c5.2xlarge (8 core, 16GB RAM) machine while running OTAP to simulated network with 50k nodes. | Medium | v4.0.0.1215 | v4.1.0.200 | No | |
WNTNG-524 | WNT backend does not work always correctly when host machine is rebooted | Networking in the containers does not work always correctly when the machine is rebooted | Medium | v4.0.0.1215 | v4.1.0.200 | Yes | Containers can be restarted manually by running “docker-compose down” and “docker-compose up -d” after the machine has rebooted and networking is working. |
WNTNG-520 | WNT client is unable to load over 1MB metadata messages | WNT client cannot load over 1MB metadata messages, and this prevents e.g. large floor plan images from loading in the client. | Medium | v4.0.0.1215 | v4.0.0.1236 | Yes | If there are no big floor plan images already in the backend, use metadata below 1MB size i.e. be careful with image sizes by compressing them below 1MB. |
WNTNG-346 | WNT backend does not send Remote API activation message to all the selected nodes in unicast Remote API process | WNT backend sends Remote API unicast activation message only to first node in the internal list although unicast process contains multiple nodes. Other unicast commands work for multiple nodes. | Medium | v3.0.1.0, v3.0.0.24 | v4.0.0.1215 | Yes | Start and handle unicast process per node |
WNTNG-316 | WNT provides "unknown" positioning role for anchors with autorole on via WNT Backend API | WNT provides “unknown” positioning role (via WNT Backend API) for anchor nodes with autorole on when node changes the role. As example, in WNT client the anchor node is shown as “unknown” role. | Medium | v3.0.1.0, v3.0.0.24 | v4.0.0.1215 | No | |
WNTNG-229 | Sink only otap disables otap functionality into network | Sink only OTAP uses scratchpad sequence number 0. The same number is used to denote “OTAP not active” in the network. If sink only OTAP is completed with WNT, it sets sequence number 0 into the sink. This scratchpad sequence number cannot be changed after this operation by WNT. WNT is not able to load any other new scratchpads into the sink (e.g. with sequence number 1) and network. | Medium | v3.0.1.0, v3.0.0.24 | v4.0.0.1215 | Yes | Sink only otap should be planned by using different Area ID for the node and sink application from the beginning. This is a good practice and normal mode of operation. |
WNTNG-211 | It is possible to start multiple Remote API unicast processes for the same node | WNT client lets the user to create multiple unicast Remote API processes to the same node, whereas it should block a new unicast Remote API command to the same node if there is already one unicast process ongoing. | Medium | v3.0.1.0, v3.0.0.24 | v4.0.0.1215 | Yes | Create a new Remote API process to the node only after the old Remote API process has been completed to the node. |
WNTNG-623 | MQTT JSON can contain multiple messages from single positioning message when optimized flag is not on | Single positioning message can cause, depending on the payload, up to three messages in MQTT JSON:
| Low | v4.3.0.62, v4.2.0.141, v4.1.2, v4.1.1.1, v4.1.0.205, v4.1.0.200, v4.0.0.1215 | No | ||
WNTNG-554 | Default Influx rate limiting can cause node comparison to stop working | Default Influx rate limiting limits the connection count for 60 connections per 2 minutes. This can cause connections to be declined when doing a lot of comparisions in short time. | Low | v4.3.0.62, v4.2.0.141, v4.1.2, v4.1.1.1, v4.1.0.205, v4.1.0.200, v4.0.0.1215 | Yes | Rate limiting connection count and time can be changed from the Haproxy configuration in the backend. | |
WNTNG-511 | World map shows node groups while using area filter although there are no nodes in the area | While using area filter in world map node groups level, the node groups are shown in the map although there are no nodes from the selected network in the area. | Low | v4.0.0.1215 | v4.1.0.200 | No | |
WNTNG-483 | When clicking planning node creation fast it can create new node with previously created address | It is possibly to create new planning node by clicking the button fast that the WNT client creates two identical planning nodes. | Low | v4.3.0.62, v4.2.0.141, v4.1.1.1, v4.1.0.205, v4.1.0.200, v4.0.0.1215 | Yes | Click the planning node creation button slower, and not double clicking it. | |
WNTNG-477 | Moving node to map in node management fails if the node gets update at the same time | When approving the node, by moving it to map in node management, fails if the node gets update at the same time. When it fails the node jumps back to the list of unapproved nodes. | Low | v4.1.1.1, v4.1.0.205, v4.1.0.200, v4.0.0.1215 | v4.2.0.141 | Yes | Node can be tried to move to the map again. |
WNTNG-361 | Tag location is not updated when measurement contains only non-approved anchors | When a tag is moves from a zone having approved anchors (where position is possible to compute) to a zone where only un-approved anchors exists (where position is not possible to compute), the reported position by WNT is the last computed position i.e. it points to the previous visited zone. The correct behavior is to report unknown position. | Low | v3.0.1.0, v3.0.0.24, v2.0.0.189, v1.7.0.70 | v4.0.0.1215 | No | |
WNTNG-238 | RSSI tile in the Overview page shows values also for non 2.4GHz bands | The tile should only show the values for 2.4GHz devices, as the limits for the value categorization are for 2.4GHz. Hence, this is valid user experience issue for the sub-gigahertz networks, which are not officially supported in WNT 3.0.x. | Low | v3.0.1.0, v3.0.0.24 | v4.0.0.1215 | No |
29 issues
Revision History
Date | Version | Notes |
v1.0A | 1st version of Wirepas Network Tool Errata document | |
v2.0 | Following errata items updated: WNTNG-211, WNTNG-229, WNTNG-238, WNTNG-316, WNTNG-318, WNTNG-346 and WNTNG-361 Following new errata items added: WNTNG-442, WNTNG-477, WNTNG-483 and WNTNG-511 | |
v3.0 | Following new errata items added: WNTNG-520, WNTNG-524 and WNTNG-525 | |
v3.1 | Removing errata WNTNG-442 as it was not valid based on further testing (not able to reproduce) | |
v3.2 | Following new errata items added: WNTNG-554 and WNTNG-579 Following errata items fixed (in v4.1.0) : WNTNG-511, WNTNG-524 and WNTNG-525 | |
v3.3 | Following new errata item added: WNTNG-586 | |
v3.4 | Following new errata item added: WNTNG-600 | |
v3.5 | Following new errata items added: WNTNG-587, WNTNG-605 | |
v3.6 | Following errata item fixed (in v4.1.2) : WNTNG-617 Following new errata item added: WNTNG-623 | |
v3.7 | Following errata items fixed (in v4.2.0): WNTNG-477, WNTNG-579 and WNTNG-600 Following errata item added & fixed (in v4.2.0): WNTNG-658 Following errata items added: WNTNG-680, WNTNG-691 | |
v3.8 | Following errata items added: WNTNG-730, WNTNG-746 | |
v3.9 | Following errata items added: WNTNG-763 and WNTNG-764 | |
v3.10 | Following errata item added: WNTNG-777 Following errata items fixed (in v4.4.0): WNTNG-746, WNTNG-763 and WNTNG-764 |
Legal Notice
Use of this document is strictly subject to Wirepas’ Terms of Use and Legal Notice.
Copyright © 2024 Wirepas Oy