Really old signal-cli stopped working

[mmhere]

OK, so the first step will probly be to upgrade to the latest version of signal-cli available here (although that can be a little bit painful given endpoint re-registration, and verification that all the Java linkages are modern), but...

signal-cli 0.6.2 began throwing this error this morning:

# this is in /bin/bash on a Debian linux platform
signal-cli -u "${ts_send}" send -m 'message' "${ts_recip}";rc=$?;echo $rc
Authorization failed, was the number registered elsewhere?
Failed to send message: org.whispersystems.signalservice.api.push.exceptions.NotFoundException: Not found
3

The shell vars in use resolve to valid senders and receivers, which have been registered properly for many months, whose registrations have not changed, and whose on-board android Signal apps can send and receive properly on their own.

Has the Signal infrastructure aged out some version of the API used by this [admittedly very old] version of signal-cli?

Again, note that the registrations in question have indeed not changed, and are working properly with tthe Android Signal app on the relevant devices. Although this means the $ts_recip devices, as $ts_send was only ever registered with signal-cli on this same Debian linux machine.

Am I forced to upgrade signal-cli? I can, but would prefer not to.

[AsamK]

You probably need to update, the old signal-cli version doesn't support uuid recipients yet, which the server seems to require now.

[mmhere]

Thanks very much for the quick response.

I shall take this opportunity to upgrade signal-cli, at the same time moving it to a much newer machine, which has been on my TODO list for quite some time anyway.

It is easy enough for me to re-register the sender numbers I use with this, but is there a way to move that registration info from signal-cli installation to installation? I have other machines elsewhere that would need such a thing.

For my installation, the registration and current send state resides in ~/.local/share/signal-cli/data/.

Whenever I've upgraded I've had to fiddle with those and usually end up re-registering senders. Is there an easy way to keep the existing state and move it to new signal-cli versions? This is one thing that has stopped me in the past.

In a couple of cases, the sender registration phone#s are not readily accessible unless I go to work and field a voice call on a hand set in the office. Not ideal, I know.

[AsamK]

The location of the signal-cli data gas changed a few times in the past, but newer versions should always be able to read/migrate the old data files.
It should just work if you copy that folder to the new machine. If not that would be a bug ...

[mmhere]

I updated to 0.8.1 successfully. Initially 0.8.5 did not work because of the libclient-signal issues others have reported with that release (I'm on Debian 10.10 64bit intel). I didn't want to chase down 0.8.5 library issues so fell back to the prior release. I re-registered the senders (Ayah, stupid CAPTCHA junk) and all is well.

[prinzema]

Had the same issue, we were already on 0.8.1 however. What else could be wrong?
I am running on CentOS 7.9.2009 so very old glibc, I tried the "exquo/signal-libs-build" solution to install 0.8.5 but it still gives me the "Missing required native library dependency: libsignal-client" error.

OMD[]:~$ /usr/local/signal-cli-0.8.1/bin/signal-cli --verbose -u +sender send -m "test" "+receiver"
2021-08-31T13:51:11.996+0200 [main] WARN LibSignal - [PhoneNumberFormatter]: Got local CC: NL
2021-08-31T13:51:12.118+0200 [main] WARN org.asamk.signal.manager.Manager - Failed to resolve uuids from server, ignoring: java.net.UnknownHostException: api.directory.signal.org: Name or service not known
2021-08-31T13:51:12.119+0200 [main] INFO LibSignal - [WebSocketConnection]: connect()
2021-08-31T13:51:12.126+0200 [main] INFO LibSignal - [WebSocketConnection]: connect()
2021-08-31T13:51:12.276+0200 [main] WARN LibSignal - [SignalServiceMessageSender]: No attachments present...
2021-08-31T13:51:12.552+0200 [OkHttp https://textsecure-service.whispersystems.org/...] INFO LibSignal - [WebSocketConnection]: onOpen() connected
2021-08-31T13:51:12.553+0200 [OkHttp https://textsecure-service.whispersystems.org/...] INFO LibSignal - [WebSocketConnection]: onOpen() connected
2021-08-31T13:51:12.732+0200 [main] INFO LibSignal - [WebSocketConnection]: disconnect()
2021-08-31T13:51:12.733+0200 [main] INFO LibSignal - [WebSocketConnection]: disconnect()
Failed to send message: org.whispersystems.signalservice.api.push.exceptions.NotFoundException: Not found
OMD[]:~$

OMD[]:~$ /usr/local/signal-cli-0.8.1/bin/signal-cli -u +Sender listDevices
- Device 1 (this device):
  Name: null
  Created: 1630410101920 (2021-08-31T11:41:41.920Z)
  Last seen: 1630368000000 (2021-08-31T00:00:00.000Z)
OMD[]:~$

[prinzema]

Opening access to uuid translation api solved this:

Name: api.az.infra.directory.signal.org
Address: 20.62.208.25
Aliases: api.directory.signal.org

I think this warning should become an error:

2021-08-31T13:51:12.118+0200 [main] WARN org.asamk.signal.manager.Manager - Failed to resolve uuids from server, ignoring: java.net.UnknownHostException: api.directory.signal.org: Name or service not known