[Solved] Not connected to websocket api + EOF error

Hi friends,
I get below error when I want to see live frames for a specific gateway or device:

the redis-server and redis-cli version is 4.0.9 and the ubuntu 18.04.5 LTS. I didn’t have this problem in another machine with the same versions.

image

I have changed external port to 8090, networkserver port to 8200, application server public and internal api port to 8100 and joinserver port to 8003.
below is application server log:

and the network server log:

but last seen parameter value of the gateway/device is properly updated.
can you help me to check and find the problem in this machine?

1 Like

Please note that you are using Redis 4.0.9. As mentioned in the changelog, Redis 5.0.0+ is required.

1 Like

but I have successful experience on another machine with Redis 4.0.9.

edit: I have upgraded the Redis version to 6.2.5 and the issue is resolved.
thank you.

Hello experts,

I’m new to using ChirpStack, so I have the same problem that @msadeghz about Redis 4.0.9. I know that the solution is to update Redis to 6.2.5 but I don’t know how to do it, I don’t know what’s are the correct ssh commands.

NOTE: I’m using Ubuntu 18.0.4 and I installed ChirpStack using the Quickstart Ubuntu Guide.

Can you help me?
@brocaar
@msadeghz

Thank you so much.

Same issue here. Looked all over in terms of upgrading Redis, but no mention on the upgrade process.
Ubuntu 18.0.4
Latest Chirpstack updates.
Don’t want to cause issues on a working server.
I really could use a help file on upgrading Redis.

Thanks

I believe you can get up-to-date Redis packages for Debian / Ubuntu from the Redis website:

As always, make a backup first :slight_smile:

It took me a lot of digging to realize that maybe it’s so unintuitive (aka “hard”) to upgrade redis because they made it so trivial! Reading HERE:

Upgrading nodes in a Redis Cluster

Upgrading replica nodes is easy since you just need to stop the node and restart it with an updated version of Redis. If there are clients scaling reads using replica nodes, they should be able to reconnect to a different replica if a given one is not available.

Upgrading masters is a bit more complex, and the suggested procedure is:

Use CLUSTER FAILOVER to trigger a manual failover of the master to one of its replicas. (See the Manual failover section in this document.)

Wait for the master to turn into a replica.

Finally upgrade the node as you do for replicas.

If you want the master to be the node you just upgraded, trigger a new manual failover in order to turn back the upgraded node into a master.

Following this procedure you should upgrade one node after the other until all the nodes are upgraded.

Above is mirrored in this answer.

There’s a troubleshooting section that I missed originally.

Thanks! I am on an AWS EC2 instance and needed to upgrade anyway, so I upgraded from LTS18.04 to LTS20.04 and that took care of the upgrade for me. I then went on to LTS22.04 and all is well. An oddity is that Grafana 9.1.2 doesn’t seem to work, so staying on 9.1.1 for now. Thanks for the help. Nice to have the instances as they make it extremely easy to backup and restore quickly so I was able to snapshot a testing instance before applying the upgrade to the working server. Thanks again!