I have installed the Signal Binding for the first time and I configured everything according to the instructions. Everything seems fine, but there are problems sending and receiving messages.
Error message while receiving a message:
[gnal.internal.protocol.SignalService] - Signal get an exception while receiving message: org.signal.libsignal.protocol.InvalidKeyIdException: No such signed pre key record:
Error message while sending a message:
[gnal.internal.protocol.SignalService] - Cannot send message to +49151xxxxxxx, cause network
I have updated the binding to the new version 0.13, with tears and blood.
Why âtears and bloodâ ? Because signal-cli 0.13 is coded for java 21⊠And openHAB for java 17 ! Looks like Iâm back to my old friend, the backport maintenance mode
I finally have convinced myself that I need help from the forum
I have trouble understanding on how the registration should work with the binding.
Could you point me somewhere where there is something like a step by step guide?
My setup at the moment ist openHAB 4.1.2 running on a Xen virtualized Ubuntu 22.04.4 LTS.
I have made it through the various pitfalls (finding the right captcha generator, sms, wait one minute, voiceâŠ) to register one of my German landline numbers wie the command line version â signal cli
However, when trying to generate the signal account thing, I end up with the error
When I have entered the information upon thing creation, my code looks like this:
UID: signal:signalaccountbridge:13545dd3f1
label: Signal Account
thingTypeUID: signal:signalaccountbridge
configuration:
verificationCodeMethod: TextMessage
phoneNumber: "+4930555123123" (made up :upside_down_face:)
captcha: signalcaptcha://signal-hcaptcha.5f..blablacaptchagoesonforever
deviceName: rnet-signal
verificationCode: ""
channels:
- id: receivetrigger
channelTypeUID: signal:signalreceivetrigger
label: Message Received
description: Triggered when a message is received, in the form "<sender>|<text>"
configuration: {}
Of course I do not know the verification code before I got the call.
Do I also need the âText Message First, Wait 1 Minute, Voice Call requestâ-strategy that I needed to perform with signal-cli?
First, Iâm not really sure of what you did and what you think you need ?
You write about signal-cli. Just to be clear : did you use it, for test purpose, or did you think you need it for this binding ?
To be sure : this binding use the signal cli code internally, but is a stand alone (In fact, the binding and signal-cli cannot even work at the same time)
The documentation has a (very little) step by step. But I agree it can probably be better (Iâm open for proposition).
The error message means that you captcha is either invalid or expired.
They are short lived, so if you generate it during your test with signal-cli, it probably wonât be valid anymore.
They are only used during registration, so their short live is normally not an issue.
What you maybe miss is that it is a several step registration process, and so it needs your input. You need to edit and save your thing at least two times with the added information during your progress.
1- get a valid captcha (again, it is short lived, so get a fresh one)
2- Save your thing a first time, with the captcha inside. The binding will use your captcha to ask for a registration code. (You are at this step : the captcha is not OK.)
If itâs OK, the thing will be in another state (donât remember, maybe âverification code neededâ, or something like that ?)
Anyway, next : If you choose a vocal validation, You donât need the "Text Message First, Wait 1 Minute, Voice Call requestâ-strategy because it is already hard-coded in the binding. The binding will ask for a SMS, wait one minute, and ask for a vocal confirmation code. So be patient.
3- Once you have the verification code, edit your thing again to add it and save.
Now everything should be OK.
UNLESS⊠Several common pitfall are:
signal change their API (and sometimes, error messages may be wrong)
temporary error with signal server
Last pitfall : I never used the file configuration method (I used the GUI), and I donât know if someone on this thread had. But it shouldnât be any different.
So what I âneedâ (i.e. want) is to use the signal binding with my landline number
I followed the signal-cli test only to make sure that in principle everything works and because I thought it would be easier to troubleshot in case of errors.
Is there a way to find out which captcha generator is the valid one without generating rate limitation issues?
I always used the one I put in the documentation (Signal)
But you now have an ExternalServiceFailureException 502. It may relate to anything
1- temporary error from signal
2- rate limitation
3- api mismatch or deeper issue
1 or 2 requires to wait and retry (maybe tomorrow ?)
I will investigate the 3 if it still donât work tomorrow.
I also encountered a strange error when trying to fire up the thing the first time with the verification code entered.
It stayed Initilizing forever:
2024-03-26 07:03:09.917 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.nio.channels.OverlappingFileLockException: null
at sun.nio.ch.FileLockTable.checkList(FileLockTable.java:229) ~[?:?]
at sun.nio.ch.FileLockTable.add(FileLockTable.java:123) ~[?:?]
at sun.nio.ch.FileChannelImpl.tryLock(FileChannelImpl.java:1321) ~[?:?]
at java.nio.channels.FileChannel.tryLock(FileChannel.java:1191) ~[?:?]
at org.asamk.signal.manager.storage.SignalAccount.openFileChannel(SignalAccount.java:993) ~[?:?]
at org.asamk.signal.manager.storage.SignalAccount.load(SignalAccount.java:193) ~[?:?]
at org.asamk.signal.manager.SignalAccountFiles.initManager(SignalAccountFiles.java:97) ~[?:?]
at org.asamk.signal.manager.SignalAccountFiles.initManager(SignalAccountFiles.java:84) ~[?:?]
at org.openhab.binding.signal.internal.protocol.SignalService.start(SignalService.java:148) ~[?:?]
at org.openhab.binding.signal.internal.handler.SignalBridgeHandler.checkAndStartServiceIfNeeded(SignalBridgeHandler.java:162) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
at java.lang.Thread.run(Thread.java:840) [?:?]
The last step is missing⊠Just write with your smartphone zu the new created signal account⊠a new thing will be created automatically. Just create it. Thatâs itâŠ
You can also edit the post title and add something like: " [4.0.0.0;5.0.0.0)". This should filter it so that 3.x users will not see the binding in Add-on Store.
I saw your comment last month in the issue 526 but didnât quite get it
Native library, linking, etc, is not a domain I know. So, maybe I can help, but we will have to work together.
I donât know why, but loading native library in Java is not as simple as âload(library-path)â.
Especially in an OSGi env, where we have to take additional step.
Itâs the signal library that loads the native code library, by calling a system method with a lib name. The classloader, AFAIK, is then responsible to provide the library file from the name. So OSGi classloader enters here.
To choose the library to load, depending on the arch / os, OSGi provides some filter that we have to add on the bundle manifest. Creating a bundle manifest is tricky, and in our case it is automatically build.
So, to add the information to the bundle manifest, we have to add a package-info file. In this package-info file, you can see the path to the library with some conditional filter to help selecting the right one.
It means that we have to provide a filter triggered for the musl build. By looking the documentation, It doesnât seem straightforward.
Maybe we can use the selection-filter ? I saw somewhere that environment variable can be used in the selection filter (but Iâm not totally sure). I can build a test version addon including the musl library if you provide me with a selection filter to put here.
Hi Gwendal,
I managed to avoid looking at OSGi so far and donât have that long weekend to go into it. Looking at the documentation it is indeed a selection-filter that needs to be used. I suggest to invent a global system property like org.osgi.framework.os.libc and test that against musl.
From my reading of the spec, you would need to duplicate your Linux/amd64 entries and list the one testing against musl lexically first (left) from the one not testing against this property. This way all of your users continue to get the standard glibc linked shared object. For the few of us running musl, we would define that global property at startup and get the musl version.
I have briefly looked at autodetection, but it is not straightforward. e.g. the code that I have linked earlier is NOT working in my environment.
I have also looked at my system:property within openHAB and there is no property that could be re-used to detect the environment.
On the long run, OSGi framework should be way more specific in detecting its runtime environment and set more properties like the one I am proposing. If you have pointers to them, you should drop this in as a proposal.
I donât have a build environment to test all of this, but you can test yourself by applying the change and not setting the property (everything will work out just fine), then setting the property (loading libsignal_jni will throw an Exception due to the unsatisied dependency to musl).
Except for musl/glibc you may as well already implement static as a third valid object, in anticipation that exquo will resolve his build issue with static libraries. Static could be the new default candidate and on the long run replace both the musl/glibc objects. This is a particularly big object (6M!!) so the 500k overhead of the static linkage is negligible.
Sorry that I cannot be of more help, OSGi does not look like the beast that you want to tame over a coffee break.
If there is anything I can test, please drop it and I will try my best.
Iâm OK to try to generate a version with the musl library from exquo included, but I canât do it now, because signal-cli still uses libsignal_v0.44.0, and there is no musl version (there is only one for 0.45).
So:
we can wait for signal-cli to use libsignal 0.45.
or If you build a libsignal 0.44 and provide it to me, I will include it in a test version.
If I understand it, a static lib will have no dependancy toward glibc or musl, and thus can be used for all linux x86_64 without additional modification and without the need to filter with arch or env param ? And the cost is itâs a little bigger ?
If itâs that, then itâs good news and Iâm OK
Hi Gwendal,
thanks for the details. exquo by default runs against the newest version. I have cloned his repo and ran it now against v0.44.0.
The artifacts are at https://github.com/kevemueller/signal-libs-build/releases/tag/libsignal_v0.44.0. I have only built the linux libs.
I am not planning to keep this clone any further than strictly needed, this shall not be an authoritative source for these artifacts. Once the tests are successful, we can ask exquo to run his official build against v0.44.0.
The modification for the filter is here.
As you suggest, I use the selection-filter âorg.osgi.framework.os.libcâ with âmuslâ value.
I didnât test to select the musl version to see if it fails, but at least I can say that the glibc version is still OK.
I hope an environment variable is sufficient for you to force the selection of the musl version.
