RELEASE

23 Sep 2024

v3.13

WNT v4.x

PUBLIC

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.4.2.4, v4.4.1.7, v4.4.0.10, 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):

1. Shut down WNT with cd ~/wnt && docker-compose down
2. Edit prestart.sh and add to the end line: export DOCKER_VERNEMQ_PERSISTENT_CLIENT_EXPIRATION=1h
   1. This will make that disconnected persistent connections will be automatically deleted after one hour

3. Restart WNT services with docker-compose up -d

Workaround, if it is not feasible to change persistent connections expiration time:

1. Shut down WNT and possible WPE services with cd ~/wnt && docker-compose down and cd ~/wpe && docker-compose down
2. Reboot the machine
3. Restart first WNT services then WPE ones (if any) with cd ~/wnt && docker-compose up -d and cd ~/wpe && docker-compose up -d
4. Wait for 10 minutes and check connection status on the MQTT broker with docker exec -it wnt_mqttbroker vmq-admin session show --client_id --clean_session --offline_messages
5. If unwanted persisted session are reported (i.e clean_session=false) shut down again WNT and possible WPE services and delete the VerneMQ volume with docker volume rm wnt_vernemq_data
6. Restart all services
7. Wait for 10 minutes and check again connection status

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:
chmod 600 /home/ubuntu/wnt/bundle.pem
to
 chmod 0644 /home/ubuntu/wnt/bundle.pem

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):
cd /home/ubuntu/wnt
chmod 0644 bundle.pem
 docker-compose restart haproxy

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-797

Timeseries data is not shown when only Influx is restarted

If only Influx is restarted the WNT authentication manager does not fetch the new authentication token from it, but returns the old one during the WNT client login handshake.

Medium

v4.4.2.4, v4.4.1.7, v4.4.0.10

Yes

Token refresh can be forced by restarting WNT authentication manager: docker compose restart auth_manager

WNTNG-793

WNT does not renew Let's Encrypt certificates because of missing HAProxy config

Required HAProxy config to enable Runtime API is missing which prevents the Let’s Encrypt certificate renewal.

Medium

v4.4.1.7, v4.4.0.10

v4.4.2.4

Yes

Put config line ofstats socket :9999 level admin expose-fd listeners underglobal section of wnt/haproxy.cfg with same indentation of 2 spaces and restart haproxy service: docker compose restart haproxy.

WNTNG-792

Support for NRF52840_4dBm, NRF52840_8dBm and EFR32_DMP stack profiles removed in WNT 4.4.1

NRF52840_4dBm, NRF52840_8dBm and EFR32_DMP stack profiles were removed from WNT 4.4.1 although they are still used by some customers. Removal of these stack profiles causes that WNT cannot parse sink configuration from gateway, and will not work correctly due to that (only affecting to customers using those stack profiles).

Medium

v4.4.1.7

v4.4.2.4

Yes

Workaround is to use WNT 4.4.0 which contains the removed stack profiles.

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.4.0.10, 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

v4.4.1.7

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.4.2.4, v4.4.1.7, v4.4.0.10, 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:

• Client 1 - Go to Node configuration and select network A
• Client 2 - Go to Node update and select the same network A
• Client 2 - Select scratchpad file and press Continue button
• Client 1 - We can start the RemoteAPI process
• Client 2 - We can start the OTAP process

Medium

v4.4.2.4, v4.4.1.7, v4.4.0.10, 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
NO_SCRATCHPAD_PRESENT → ACCESS_DENIED
ACCESS_DENIED → REQUEST_NEEDS_SINK_ID
REQUEST_NEEDS_SINK_ID → FIRST_INVALID_ENUM_VALUE
INVALID_MAX_HOP_COUNT → ERROR_UNKNOWN
SINK_OUT_OF_MEMORY → ERROR_UNKNOWN
 SINK_TIMEOUT ->ERROR_UNKNOWN

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-791

MQTT JSON API does not update metadata of a tag on gateway change in the first JSON response

MQTT JSON API doesn’t always update the metadata (Sink address and Gateway ID) in the first JSON response when a tag is moved from one gateway to another. Starting with the 2nd JSON response after the tag is moved to another gateway, results are as expected. The location data including lat/long/alt, building, floor and so on are updated as expected. This happens because WPE location response does not contain sink address nor gateway id. If WNT internally receives location update before information about the original measurement message, sink and gateway information will not be up-to-date. Fix also requires WPE >= 1.7.1.

Low

v4.4.1.7, v4.4.0.10, 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

v4.4.2.4

No

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:

• Update with positioning measurement time change
• Update with location and positioning calculation time change
• Update with voltage change from the positioning payload

Low

v4.4.2.4, v4.4.1.7, v4.4.0.10, 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.4.2.4, v4.4.1.7, v4.4.0.10, 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.4.2.4, v4.4.1.7, v4.4.0.10, 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

11 Jan 2021

v1.0A

1^st version of Wirepas Network Tool Errata document

08 Jun 2021

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

21 Jun 2021

v3.0

Following new errata items added: WNTNG-520, WNTNG-524 and WNTNG-525

31 Aug 2021

v3.1

Removing errata WNTNG-442 as it was not valid based on further testing (not able to reproduce)

30 Sep 2021

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

06 Oct 2021

v3.3

Following new errata item added: WNTNG-586

16 Nov 2021

v3.4

Following new errata item added: WNTNG-600

13 Dec 2021

v3.5

Following new errata items added: WNTNG-587, WNTNG-605

11 Feb 2022

v3.6

Following errata item fixed (in v4.1.2) : WNTNG-617

Following new errata item added: WNTNG-623

07 Nov 2022

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

13 Apr 2023

v3.8

Following errata items added: WNTNG-730, WNTNG-746

03 Oct 2023

v3.9

Following errata items added: WNTNG-763 and WNTNG-764

04 Jan 2024

v3.10

Following errata item added: WNTNG-777

Following errata items fixed (in v4.4.0): WNTNG-746, WNTNG-763 and WNTNG-764

03 May 2024

v3.11

Following errata items fixed (in v4.4.1): WNTNG-777

01 Aug 2024

v3.12

Following errata items fixed (in v4.4.2): WNTNG-791, WNTNG-792, WNTNG-793

23 Sep 2024

v3.13

Following errata item added: WNTNG-797