search

sm0svx / svxlink

Advanced repeater system software with EchoLink support for Linux including a GUI, Qtel - the Qt EchoLink client
http://svxlink.org/
Other
439 stars 173 forks source link

Incompatible protocol version :-( #372

Open pe1chl opened 6 years ago

pe1chl commented 6 years ago

Recently when installing a new system and using the trunk version I found that there apparently has been a change in the remotetrx protocol. When a new version svxlink or remotetrx is installed, the connection fails with: *** ERROR: Incompatible protocol version. Disconnecting from 1.2.3.4:5210

I understand that a protocol change has been made and both versions do no longer communicate. However that is "a little" inconvenient to us, as we have over 30 systems running svxlink and/or remotetrx (5 or 6 copies of svxlink and several remotetrx, also often cross-linked in the sense that one site's svxlink connects to the other site's remotetrx and also vice-versa).

This makes it very difficult to update past this change. Would it not be possible to have backward compatibility in one direction, e.g. new svxlink can still connect to 1 version older remotetrx? That would enable us to do a sequential update instead of updating over 30 systems "at the same time"...

pe1chl commented 4 years ago

Is there any chance for backward compatibility in once direction? So we can e.g. install current remotetrx and use it with older svxlink (v1.5.99.17)? That would enable us to upgrade the network step by step...

sm0svx commented 4 years ago

I'd rather not do that since it's much trickier to design a protocol that is backwards compatible. It's designed from the beginning so that the whole network should be updated in one go.

What you should take a look at is my Ansible structure that I recently published on GitHub. With an ansible setup you can manage any number of nodes efficiently. In our network, I can update the OS, build latest version of Svxlink, install it and apply configuration on all nodes with a single command:

ansible-playbook site.yml

Of course there are some work involved in getting to this update nirvana but when you're there it's a joy just sitting down watching Ansible do all the work.

pe1chl commented 4 years ago

I know about such systems, but unfortunately our network is quite complicated. We run 6 repeaters (10m,2x2m,70cm,23cm and a "dummy" that has only internet stream output). Of these, 10m and the "dummy" are currently not really operating. but it remains 4 active repeaters which consist of an svxlink and several remotetrx but they are largely overlapping (e.g. many combined 2m/70cm receiver sites, main svxlink sites are also remotetrx for other repeaters). So the only way of updating would be to set this whole ansible thing up and fire it all at one go, and watch the result. When it goes wrong, all the repeaters are down. And I expect some things to go wrong, e.g. around the COMMAND_PTY and STATE_PTY where there have been changes. In itself the update would not be that difficult (all systems are individually compiled from git source, so it would just require a "git pull", and "rebuildsvxlink" at all sites, I can probably do that even without ansible e.g. using "expect") but I just do not dare such a big operation without any possibility to prepare and pre-test. So at least I need to setup a test at home (e.g. my PC and a Raspberry Pi) to see if basically our config still works....

With remotetrx compatibility, I would update a minor receive site and experiment with the new squelch feature, then gradually extend this to all other receive sites until I can update a single svxlink site (repeater) and get it working again, then do the other repeaters one by one.