Unable to send or receive since latest upgrade
maristieuvelonde opened this issue · 5 comments
Ever since upgrading to the latest release (0.54.1) I am unable to send or receive notifications and messages sent to the registered number never go through (with auto-receive on, or by polling the REST API - single check-mark in Signal)
Addon logs:
+ set -e
+ [ -z /data ]
+ chown 1000:1000 -R /data
+ cat
+ cap_prefix=-cap_
+ cat /proc/sys/kernel/cap_last_cap
+ seq -s ,-cap_ 0 40
+ caps=-cap_0,-cap_1,-cap_2,-cap_3,-cap_4,-cap_5,-cap_6,-cap_7,-cap_8,-cap_9,-cap_10,-cap_11,-cap_12,-cap_13,-cap_14,-cap_15,-cap_16,-cap_17,-cap_18,-cap_19,-cap_20,-cap_21,-cap_22,-cap_23,-cap_24,-cap_25,-cap_26,-cap_27,-cap_28,-cap_29,-cap_30,-cap_31,-cap_32,-cap_33,-cap_34,-cap_35,-cap_36,-cap_37,-cap_38,-cap_39,-cap_40
+ [ native = json-rpc ]
+ exec setpriv --reuid=1000 --regid=1000 --init-groups --inh-caps=-cap_0,-cap_1,-cap_2,-cap_3,-cap_4,-cap_5,-cap_6,-cap_7,-cap_8,-cap_9,-cap_10,-cap_11,-cap_12,-cap_13,-cap_14,-cap_15,-cap_16,-cap_17,-cap_18,-cap_19,-cap_20,-cap_21,-cap_22,-cap_23,-cap_24,-cap_25,-cap_26,-cap_27,-cap_28,-cap_29,-cap_30,-cap_31,-cap_32,-cap_33,-cap_34,-cap_35,-cap_36,-cap_37,-cap_38,-cap_39,-cap_40 signal-cli-rest-api -signal-cli-config=/data
time="2021-12-31T13:02:26-05:00" level=info msg="Started Signal Messenger REST API"
[GIN] 2021/12/31 - 13:02:37 | 200 | 4.224059571s | 172.30.32.1 | GET "/v1/receive/+XXXXXXXXXXX"
Supervisor logs
21-12-31 13:02:25 INFO (SyncWorker_5) [supervisor.docker.addon] Starting Docker add-on ghcr.io/haberda/signal_messenger/amd64 with version 0.54.1
21-12-31 13:02:25 WARNING (MainThread) [supervisor.addons.options] Option 'native_mode' does not exist in the schema for Signal Messenger (1315902c_signal_messenger)
Additionally the following error shows up when polling for received messages:
java.lang.NoClassDefFoundError: Lorg/whispersystems/libsignal/InvalidKeyException;
at com.oracle.svm.jni.functions.JNIFunctions.FindClass(JNIFunctions.java:346)
at org.signal.client.internal.Native.SealedSessionCipher_DecryptToUsmc(Native.java)
at org.signal.libsignal.metadata.SealedSessionCipher.decrypt(SealedSessionCipher.java:146)
at org.whispersystems.signalservice.api.crypto.SignalSealedSessionCipher.decrypt(SignalSealedSessionCipher.java:58)
at org.whispersystems.signalservice.api.crypto.SignalServiceCipher.decrypt(SignalServiceCipher.java:201)
at org.whispersystems.signalservice.api.crypto.SignalServiceCipher.decrypt(SignalServiceCipher.java:152)
at org.asamk.signal.manager.helper.IncomingMessageHandler.handleEnvelope(IncomingMessageHandler.java:138)
at org.asamk.signal.manager.ManagerImpl.receiveMessagesInternal(ManagerImpl.java:1062)
at org.asamk.signal.manager.ManagerImpl.receiveMessages(ManagerImpl.java:980)
at org.asamk.signal.manager.ManagerImpl.receiveMessages(M...
I tried switching between normal, native, and json-rpc modes to no avail. Calling the REST-API manually using curl to check groups still works.
Can you send using the API directly? Also, how long has it been since you updated the profile (there is an API call for that)? Json-rpc is pretty sensitive to having the most updated profile. Otherwise, I am often told by the upstream dev that the best thing you can do is register the number again from scratch.
In terms of the logs, you can clear that by setting the options back to default.
If you do that, choose your options again and start, it will replace the options file and the warning in the supervisor will go away.
Can you send using the API directly?
No, in either native or json-rpc mode, I get a timestamp but the message doesn't go through.
Also, how long has it been since you updated the profile (there is an API call for that)? Json-rpc is pretty sensitive to having the most updated profile.
Less than a month?
In terms of the logs, you can clear that by setting the options back to default.
That did do the trick. 👍
the upstream dev that the best thing you can do is register the number again from scratch.
Ugg that sucks :( Gotta reinvite everyone to a new group, loose the history and what not :/
So I went into the container to use signal-cli directly. I'm able to update the profile without issues and this is reflected on another device with an "Account updated profile blah blah" message. Linking to the desktop app works as well.
Sending directly from signal-cli (not even the rest api) results in the same thing (timestamp shows up but no message is delivered)
Well, if it doesn't send by directly accessing via the cli, then I have to assume it's either an upstream issue, or something at least somewhat unique to your configuration. For now, can you roll back to the previous version? You may also want to open an issue in the upstream project. All I do that is different from the upstream is set environment variables by using the options in the Home Assistant UI.
In terms of the groups and such, yeah that sucks. I decided some time ago to not use signal groups for this very reason.
There hasn't been any activity on this issue recently, so we clean up some of the older and inactive issues.
Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thanks!