AsamK / signal-cli

signal-cli provides an unofficial commandline, JSON-RPC and dbus interface for the Signal messenger.
GNU General Public License v3.0
3.06k stars 289 forks source link

Recipients don't receive messages when sent from a server #650

Closed QuentinDubes closed 2 years ago

QuentinDubes commented 3 years ago

Hi,

I'm using the release signal-cli 0.8.4 (more precisely the signal-cli wrapped as an API by bbernhard https://github.com/bbernhard/signal-cli-rest-api, but I used signal-cli commands to be sure that the issue is not coming from the wrapper)

My workflow is quite simple: we use a Signal number registered in the server to send some app notifications through Signal. In other words, we just want to send messages to users (these users are registered on Signal).

The package is working fine locally: register, verify, send, receive, everything is working as excepted, and recipients receive messages. On my AWS server, the same workflow seems to work fine (got no errors), but messages are never received by recipients.

Here are the logs:

root@xxxxxxxx:/#  echo 'Test for getting logs ' | signal-cli --verbose --config /home/.local/sharsignal-cli -u +336xxxxxxxx send +336yyyyyyyy +336zzzzzzzz +336aaaaaaaa +336bbbbbbbb
2021-06-22T10:42:32.814Z [main] INFO LibSignal - [libsignal-client]: rust/bridge/jni/src/logging.rs:173: Initializing libsignal-client version:0.8.1
2021-06-22T10:42:37.178Z [main] WARN LibSignal - [PhoneNumberFormatter]: Got local CC: FR
2021-06-22T10:42:37.185Z [main] WARN LibSignal - [PhoneNumberFormatter]: Got local CC: FR
2021-06-22T10:42:37.187Z [main] WARN LibSignal - [PhoneNumberFormatter]: Got local CC: FR
2021-06-22T10:42:37.190Z [main] WARN LibSignal - [PhoneNumberFormatter]: Got local CC: FR
2021-06-22T10:42:37.195Z [main] INFO LibSignal - [WebSocketConnection]: connect()
2021-06-22T10:42:37.213Z [main] INFO LibSignal - [WebSocketConnection]: connect()
2021-06-22T10:42:37.564Z [main] WARN LibSignal - [SignalServiceMessageSender]: No attachments present...
2021-06-22T10:42:37.624Z [OkHttp https://textsecure-service.whispersystems.org/...] INFO LibSignal - [WebSocketConnection]: onOpen() connected
2021-06-22T10:42:37.624Z [OkHttp https://textsecure-service.whispersystems.org/...] INFO LibSignal - [WebSocketConnection]: onOpen() connected
2021-06-22T10:42:37.693Z [main] INFO LibSignal - [libsignal-client]: rust/protocol/src/session_cipher.rs:51: Building PreKeyWhisperMessage for: aaf1c155-d6b9-45eb-8068-1a54bb0b45bc.1 with preKeyId: 11298701
2021-06-22T10:42:37.952Z [main] WARN LibSignal - [SignalServiceMessageSender]: No attachments present...
2021-06-22T10:42:37.955Z [main] INFO LibSignal - [libsignal-client]: rust/protocol/src/session_cipher.rs:51: Building PreKeyWhisperMessage for: a89b5d1e-ade2-4edf-b2f8-4cd186018070.1 with preKeyId: 12632492
2021-06-22T10:42:38.170Z [main] WARN LibSignal - [SignalServiceMessageSender]: No attachments present...
2021-06-22T10:42:38.414Z [main] WARN LibSignal - [SignalServiceMessageSender]: No attachments present...
2021-06-22T10:42:38.416Z [main] INFO LibSignal - [libsignal-client]: rust/protocol/src/session_cipher.rs:51: Building PreKeyWhisperMessage for: 29451a04-3eac-4a51-bcd5-3f076cf1614b.1 with preKeyId: 4816459
1624358557194
2021-06-22T10:42:38.521Z [main] INFO LibSignal - [WebSocketConnection]: disconnect()
2021-06-22T10:42:38.524Z [main] INFO LibSignal - [WebSocketConnection]: disconnect()

So i tried to open all ports and disable incoming and outgoing firewall on my AWS server, but messages are still stuck.

Another weird thing, happening only on AWS server, is that once i got a message from someone, this person is able to receive messages from the server. But this work around is not possible, as I don't want to ask my users to send a message first, in order to receive messages later.

After that I decided to make a new try from another server (from OVH, a big hoster in France), and it's works fine, all recipients receive all messages, even if i never send messages to these recipients.

Is anyone facing a similar behavior from the CLI ? Am I forgetting a step ? Or should I configure something special for AWS instances ?

Any help would be very much appreciated :)

In case it is relevant, my local environment AWS and OVH servers are based in France.

AsamK commented 3 years ago

That's strange ... Did you try sending a message from the aws server to another signal-cli instance? Does that instance show any sign of receiving the message? Could help diagnose if it's an encryption session issue or some other issue.

PeteJStewart commented 3 years ago

We're having a very similar issue! I can't send from our servers unless the recipient has already sent a message the the number signal-cli is using on the server. I was wondering is this was to do with a lack of entropy?

What's also odd, is that I thought this was working a week or two ago.

We're using Linode servers and Cloudflare for the DNS. We're not currently using Cloudflare CDN, though.

I have tried sending from one signal-cli to another, and I just get the same result. Messages send from the server seem to send, but are never received by the other number. As with @QuentinDubes, I receive a timestamp and it looks like it was sent without error, but it never gets to the other number.

If I then send a message from my desktop signal-cli to the server signal-cli I can recieve it and then I can send messages from that server to my desktop.

I did get a slightly unusual output a couple of times when sending messages with --verbose

2021-06-24T09:29:30.989Z [main] WARN LibSignal - [PhoneNumberFormatter]: Got local CC: GB
2021-06-24T09:29:31.008Z [main] INFO LibSignal - [WebSocketConnection]: connect()
2021-06-24T09:29:31.030Z [main] INFO LibSignal - [WebSocketConnection]: connect()
2021-06-24T09:29:31.389Z [main] WARN LibSignal - [CascadingFuture]: java.io.IOException: No connection!
    at org.whispersystems.signalservice.internal.websocket.WebSocketConnection.sendRequest(WebSocketConnection.java:206)
    at org.whispersystems.signalservice.api.SignalServiceMessagePipe.getProfile(SignalServiceMessagePipe.java:256)
    at org.asamk.signal.manager.helper.ProfileHelper.getPipeRetrievalFuture(ProfileHelper.java:102)
    at org.asamk.signal.manager.helper.ProfileHelper.lambda$retrieveProfile$5(ProfileHelper.java:82)
    at org.whispersystems.signalservice.internal.util.concurrent.CascadingFuture.doNext(CascadingFuture.java:69)
    at org.whispersystems.signalservice.internal.util.concurrent.CascadingFuture.<init>(CascadingFuture.java:33)
    at org.asamk.signal.manager.helper.ProfileHelper.retrieveProfile(ProfileHelper.java:82)
    at org.asamk.signal.manager.helper.ProfileHelper.retrieveProfileSync(ProfileHelper.java:51)
    at org.asamk.signal.manager.Manager.retrieveProfileAndCredential(Manager.java:614)
    at org.asamk.signal.manager.Manager.retrieveEncryptedProfile(Manager.java:604)
    at org.asamk.signal.manager.Manager.getRecipientProfile(Manager.java:575)
    at org.asamk.signal.manager.Manager.getRecipientProfile(Manager.java:551)
    at org.asamk.signal.manager.helper.UnidentifiedAccessHelper.getTargetUnidentifiedAccessKey(UnidentifiedAccessHelper.java:41)
    at org.asamk.signal.manager.helper.UnidentifiedAccessHelper.getAccessFor(UnidentifiedAccessHelper.java:83)
    at org.asamk.signal.manager.Manager.sendMessage(Manager.java:1484)
    at org.asamk.signal.manager.Manager.sendMessage(Manager.java:1418)
    at org.asamk.signal.manager.Manager.sendMessage(Manager.java:1052)
    at org.asamk.signal.dbus.DbusSignalImpl.sendMessage(DbusSignalImpl.java:97)
    at org.asamk.signal.commands.SendCommand.handleCommand(SendCommand.java:121)
    at org.asamk.signal.commands.DbusCommand.handleCommand(DbusCommand.java:15)
    at org.asamk.signal.App.handleLocalCommand(App.java:203)
    at org.asamk.signal.App.init(App.java:163)
    at org.asamk.signal.Main.main(Main.java:51)

2021-06-24T09:29:31.467Z [OkHttp https://textsecure-service.whispersystems.org/...] INFO LibSignal - [WebSocketConnection]: onOpen() connected
2021-06-24T09:29:31.469Z [OkHttp https://textsecure-service.whispersystems.org/...] INFO LibSignal - [WebSocketConnection]: onOpen() connected
2021-06-24T09:29:31.925Z [main] WARN LibSignal - [SignalServiceMessageSender]: No attachments present...
1624526971007
2021-06-24T09:29:32.110Z [main] INFO LibSignal - [WebSocketConnection]: disconnect()
2021-06-24T09:29:32.112Z [main] INFO LibSignal - [WebSocketConnection]: disconnect()

usually the verbose output is as follows:

2021-06-24T09:15:59.501Z [main] WARN LibSignal - [PhoneNumberFormatter]: Got local CC: GB
2021-06-24T09:15:59.512Z [main] INFO LibSignal - [WebSocketConnection]: connect()
2021-06-24T09:15:59.525Z [main] INFO LibSignal - [WebSocketConnection]: connect()
2021-06-24T09:15:59.827Z [main] WARN LibSignal - [SignalServiceMessageSender]: No attachments present...
2021-06-24T09:15:59.928Z [OkHttp https://textsecure-service.whispersystems.org/...] INFO LibSignal - [WebSocketConnection]: onOpen() connected
2021-06-24T09:15:59.930Z [OkHttp https://textsecure-service.whispersystems.org/...] INFO LibSignal - [WebSocketConnection]: onOpen() connected
1624526159511
2021-06-24T09:16:00.076Z [main] INFO LibSignal - [WebSocketConnection]: disconnect()
2021-06-24T09:16:00.077Z [main] INFO LibSignal - [WebSocketConnection]: disconnect()

Any ideas?

PeteJStewart commented 3 years ago

So a slight update on that is that I do actually have haveged already running on the servers I'm using, I've also check that rdtsc is working as expected. So I guess it's not an issue with the entropy.

@AsamK do you have any more ideas for debugging this issue?

derchrisuk commented 3 years ago

I have a similar issue. We use the CLI to send a message into a GroupChat. It appears from time to time messages are no longer delivered to either all or just a fraction of users inside the group. So far I have not figured out what is going on. As a workaround in the past i removed and re-added the bot back to the group, and did run a receive to have the latest messages. This was all with 0.8.1 Currently trying out the latest 0.8.4.1, but right now the bot does not even send a single message anymore after kicking him from the group.

PeteJStewart commented 3 years ago

Any news on this issue? It seems like the system isn't currently working on servers or perhaps virtual machines? @QuentinDubes you mentioned that you have managed to get it working on one server? Is that a virtual machine or not? Perhaps we can work out why it's not working on most servers if we can workout why it is working on that one?

piechologist commented 3 years ago

I don't think this issue depends on running signal-cli in a VM or on missing entropy.

In my case, I can't receive messages from signal-cli any more after provisioning a new signal-cli slave device. As @PeteJStewart mentioned, if I send a message to the signal-cli client I can receive the client's messages again.

I guess this is similar to @derchrisuk's issue. Removing and adding a bot to a group may have the same side effect as provisioning a slave.

So, how can we debug this? This must have been introduced in one of the last releases, probably 0.8.3 or 0.8.4 EDIT: I see this issue even with 0.8.1. Is it possible that the Signal service has changed and that it's not a regression on signal-cli's side?

PeteJStewart commented 3 years ago

I see this issue even with 0.8.1. Is it possible that the Signal service has changed and that it's not a regression on signal-cli's side?

I feel like it's quite likely something to do with Signal, rather than signal-cli, but perhaps if we can workout what's changed, we can then update signal-cli to account for it?

I seem to have no issue using signal-cli on my desktop or laptop, it's only when using on our servers that I can't send messages.

That's why I was wondering if it's an issue with sending from virtual machines. Also, the company @QuentinDubes mention -- OVH -- seem to offer mainly dedicated servers.

I can try running up a few new servers next week and see if I can get any of them to work. I could also try running it from a virtual machine on my desktop.

I wouldn't be surprised if Signal has blocked the ability to send messages from virtual machines unless they have received a message. I believe Signal has been under attack recently, and stopping virtual machine spamming might mitigate some of that.

piechologist commented 3 years ago

That's why I was wondering if it's an issue with sending from virtual machines. Also, the company @QuentinDubes mention -- OVH -- seem to offer mainly dedicated servers.

My VMs are running with DigitalOcean and once I send a message from my laptop to the signal-cli instance I can reliably receive messages from that instance. Tested this with signal-cli 0.8.1/2/3/4/4.1 on VMs in the US and Germany this morning .

QuentinDubes commented 3 years ago

I wouldn't be surprised if Signal has blocked the ability to send messages from virtual machines unless they have received a message. I believe Signal has been under attack recently, and stopping virtual machine spamming might mitigate some of that.

Yeah, I had this idea too. I don't know how to validate this theory, and find a solution. Otherwise, I thought about servers configuration because I got this special behavior only on t2.micro AWS ec2 with ubuntu and not on :

So, I disabled all firewall of the t2.micro AWS ec2 instance, but it won’t change anything.

Overall, server configuration is not my main expertise, so I’m not able to fully validate this theory neither. Any advice or help would be appreciated :)

derchrisuk commented 3 years ago

Just an update on my part. I'm now running 0.8.4 for over a week. I run 2 commands in a 5 min delay

PeteJStewart commented 3 years ago

I've just tried on a new server and I'm having a very similar issue in that I can't send. Although this time I'm also note really able to receive either. When running the receive command, I can see the received tick appear on the device I send the message from, but on the server I've running the receive command from, I see 'No message content' and Rate limit exceeded: 413

signal-cli -u +4477656xxxxx receive
Envelope from: +4477656xxxxx (device: 1)
Timestamp: 1625476988839 (2021-07-05T09:23:08.839Z)
Exception: null (ProtocolInvalidMessageException)
No message content

WARN Manager - Message action failed.
org.whispersystems.signalservice.api.push.exceptions.RateLimitException: [413] Rate limit exceeded: 413
    at org.whispersystems.signalservice.internal.push.PushServiceSocket.validateServiceResponse(PushServiceSocket.java:1566)
    at org.whispersystems.signalservice.internal.push.PushServiceSocket.makeServiceRequest(PushServiceSocket.java:1556)
    at org.whispersystems.signalservice.internal.push.PushServiceSocket.makeServiceBodyRequest(PushServiceSocket.java:1541)
    at org.whispersystems.signalservice.internal.push.PushServiceSocket.makeServiceRequest(PushServiceSocket.java:1483)
    at org.whispersystems.signalservice.internal.push.PushServiceSocket.makeServiceRequest(PushServiceSocket.java:1477)
    at org.whispersystems.signalservice.internal.push.PushServiceSocket.getPreKeys(PushServiceSocket.java:579)
    at org.whispersystems.signalservice.api.SignalServiceMessageSender.getEncryptedMessage(SignalServiceMessageSender.java:2119)
    at org.whispersystems.signalservice.api.SignalServiceMessageSender.getEncryptedMessages(SignalServiceMessageSender.java:2094)
    at org.whispersystems.signalservice.api.SignalServiceMessageSender.sendMessage(SignalServiceMessageSender.java:1754)
    at org.whispersystems.signalservice.api.SignalServiceMessageSender.sendNullMessage(SignalServiceMessageSender.java:789)
    at org.asamk.signal.manager.Manager.sendNullMessage(Manager.java:1779)
    at org.asamk.signal.manager.Manager.renewSession(Manager.java:1344)
    at org.asamk.signal.manager.RenewSessionAction.execute(HandleAction.java:201)
    at org.asamk.signal.manager.Manager.receiveMessages(Manager.java:2105)
    at org.asamk.signal.commands.ReceiveCommand.handleCommand(ReceiveCommand.java:162)
    at org.asamk.signal.App.handleLocalCommand(App.java:214)
    at org.asamk.signal.App.init(App.java:174)
    at org.asamk.signal.Main.main(Main.java:51)

I also see rate limit exceeded when trying to send a message

signal-cli --verbose -u +4477656xxxxx send -m "One more test message" +4477426xxxxx
2021-07-05T09:22:47.172Z [main] INFO LibSignal - [libsignal-client]: rust/bridge/jni/src/logging.rs:173: Initializing libsignal-client version:0.8.1
2021-07-05T09:22:49.557Z [main] WARN LibSignal - [PhoneNumberFormatter]: Got local CC: GB
2021-07-05T09:22:49.560Z [main] INFO LibSignal - [WebSocketConnection]: connect()
2021-07-05T09:22:49.573Z [main] INFO LibSignal - [WebSocketConnection]: connect()
2021-07-05T09:22:49.862Z [main] WARN LibSignal - [SignalServiceMessageSender]: No attachments present...
2021-07-05T09:22:50.040Z [OkHttp https://textsecure-service.whispersystems.org/...] INFO LibSignal - [WebSocketConnection]: onOpen() connected
2021-07-05T09:22:50.047Z [OkHttp https://textsecure-service.whispersystems.org/...] INFO LibSignal - [WebSocketConnection]: onOpen() connected
2021-07-05T09:22:50.362Z [main] INFO LibSignal - [WebSocketConnection]: disconnect()
2021-07-05T09:22:50.367Z [main] INFO LibSignal - [WebSocketConnection]: disconnect()
Failed to send message: [413] Rate limit exceeded: 413

This was also on a virtual machine with digital ocean. I'm provisioning a dedicated server, so I will test that later this week.

PeteJStewart commented 3 years ago

I've just tested on a dedicated server and ended up with the same result. That is the system doesn't work for sending or receiving. I can register and verify, and when I run the receive command, I can see it marked as received on the device that sent a message to the server, but I can't actually receive or send any messages.

However, I can still then register the same number on my desktop and send and receive perfectly fine straight away. This seems to be an isolated problem with all servers but not desktop/laptops.

I guess it could be due to server firewalls. I don't think the office network I'm on has a firewall, but most servers are setup with firewalls by default. I can try to disable the firewall on one of my servers to test that theory later.

Any other ideas?

@AsamK have you got any thoughts on this?

PeteJStewart commented 3 years ago

Slight update that setting the firewall to allow 'Any' doesn't make a difference either, so I guess it's probably not the firewall.

PeteJStewart commented 2 years ago

@AsamK Is there any update on this? As far as I can tell, the whole system is not working on any server due to this issue.

Do you have a contact at Signal, or any ideas about debug this issue?

Many thanks in advanced, Pete

jaaop commented 2 years ago

I have a quite similar issue, the strange thing is that all Australian numbers I've tested are receiving my messages from the server with no problems, and all UK numbers are not, the sender is a Twilio US number and my server is hosted in Australia..

derchrisuk commented 2 years ago

I'm using German numbers, and since my last workflow change had no further issues.

PeteJStewart commented 2 years ago

I'm using German numbers, and since my last workflow change had no further issues.

Are you saying you were experiencing this issue and now are not for some reason? If so, could you explain what's changed?

derchrisuk commented 2 years ago

The issue I had was that some members of a Group did not receive the message sent by the bot. Now with the latest release, and running a receive 5 min prior to the send, every Group member does get the message. Before I had to unregister/register the bot from the Group occasionally

QuentinDubes commented 2 years ago

Finally, I'm getting the error on OVH Server too. I tested 0.8.3 to 0.8.5 versions, and I got the same behavior as I describe before : I can send messages to unknown numbers from my local, but the server can't send messages to unknown numbers and once the unknown number sent a message to the number registered in the server, sending messages from server to this contact work.

Here is the log with 0.8.5 on my server. I got 413, but it looks like a connection problem in SignalServiceMessageSender. But registration and verification work fine, and sending message work after receiving a message, so I'm now pretty sure that the issue is not from the server configuration.

2021-08-10T21:20:14.681Z [main] INFO LibSignal - [libsignal-client]: rust/bridge/jni/src/logging.rs:173: Initializing libsignal-client version:0.8.1
2021-08-10T21:20:17.718Z [main] WARN LibSignal - [PhoneNumberFormatter]: Got local CC: FR
2021-08-10T21:20:17.723Z [main] INFO LibSignal - [WebSocketConnection]: connect()
2021-08-10T21:20:17.736Z [main] INFO LibSignal - [WebSocketConnection]: connect()
2021-08-10T21:20:18.047Z [main] WARN LibSignal - [SignalServiceMessageSender]: No attachments present...
2021-08-10T21:20:18.153Z [main] INFO LibSignal - [libsignal-client]: rust/protocol/src/session_cipher.rs:51: Building PreKeyWhisperMessage for: 0deb11c0-1409-49e2-8432-8ff45a687a91.1 with preKeyId: 2
2021-08-10T21:20:18.174Z [main] WARN LibSignal - [SignalServiceMessageSender]: java.io.IOException: No connection!
    at org.whispersystems.signalservice.internal.websocket.WebSocketConnection.sendRequest(WebSocketConnection.java:209)
    at org.whispersystems.signalservice.api.SignalServiceMessagePipe.send(SignalServiceMessagePipe.java:224)
    at org.whispersystems.signalservice.api.SignalServiceMessageSender.sendMessage(SignalServiceMessageSender.java:1765)
    at org.whispersystems.signalservice.api.SignalServiceMessageSender.sendDataMessage(SignalServiceMessageSender.java:385)
    at org.asamk.signal.manager.Manager.sendMessage(Manager.java:1763)
    at org.asamk.signal.manager.Manager.sendMessage(Manager.java:1697)
    at org.asamk.signal.manager.Manager.sendMessage(Manager.java:1292)
    at org.asamk.signal.dbus.DbusSignalImpl.sendMessage(DbusSignalImpl.java:101)
    at org.asamk.signal.commands.SendCommand.handleCommand(SendCommand.java:122)
    at org.asamk.signal.commands.DbusCommand.handleCommand(DbusCommand.java:15)
    at org.asamk.signal.App.handleLocalCommand(App.java:214)
    at org.asamk.signal.App.init(App.java:174)
    at org.asamk.signal.Main.main(Main.java:51)

2021-08-10T21:20:18.175Z [main] WARN LibSignal - [SignalServiceMessageSender]: [sendMessage] Pipe failed, falling back... (IOException: No connection!)
2021-08-10T21:20:18.232Z [OkHttp https://textsecure-service.whispersystems.org/...] INFO LibSignal - [WebSocketConnection]: onOpen() connected
2021-08-10T21:20:18.233Z [OkHttp https://textsecure-service.whispersystems.org/...] INFO LibSignal - [WebSocketConnection]: onOpen() connected
2021-08-10T21:20:18.575Z [main] INFO LibSignal - [WebSocketConnection]: disconnect()
2021-08-10T21:20:18.577Z [main] INFO LibSignal - [WebSocketConnection]: disconnect()
Failed to send message: [413] Rate limit exceeded: 413

I don't know how to debug this.

@PeteJStewart Ours logs seem very similar.

PeteJStewart commented 2 years ago

My guess was that Signal themselves have put a block on messages until the API has received a message from the user. They've probably done that by setting rate limit to 0.

I suspect this is a security measure to stop spam bots.

Hopefully they will bring in a system for legitimate users at some point.

QuentinDubes commented 2 years ago

I get the same suspicion as you because there is less spam in Signal than before. I wanted to use Signal to notify website users instead of using SMS, and the server will never be a legitimate user. I will look for other messaging solutions, thanks anyway 😉

PeteJStewart commented 2 years ago

@AsamK I don't know if you have any connections with Signal core team, but as you have contributed to the code, perhaps you do? If my assumption above is roughly correct, then it would be great if we could suggest to Signal that they setup a whitelisting system so legitimate organisation can get a phone number whitelisted to be able to send messages from a server. This would likely still resolve the spamming issue, but would also allow people to use the API for app and website communications.

Our system will make it easier for users to transition from WhatsApp to Signal, so there's definite benefit for Signal to allow us access to send messages, and no doubt many other app integrations would be beneficial to Signal, too.

AsamK commented 2 years ago

I don't have any contact to the Signal team, except via public issues/PRs. There's some code in the signal server repo for stopping rate limiting with a captcha, that might be helpful here. Can you check if you now get different output with the latest signal-cli master?

PeteJStewart commented 2 years ago

I seem to be getting a similar situation, although it definitely seems to be working much smoother, as I can send to people who have contacted me, and I can also receive receipts.

Sending a message with --verbose, I get the following response:

2021-08-19T10:32:48.458Z [main] INFO LibSignal - [libsignal-client]: rust/bridge/jni/src/logging.rs:173: Initializing libsignal-client version:0.8.1
2021-08-19T10:32:52.538Z [main] WARN LibSignal - [PhoneNumberFormatter]: Got local CC: GB
2021-08-19T10:32:52.548Z [main] INFO LibSignal - [WebSocketConnection]: connect()
2021-08-19T10:32:52.561Z [main] INFO LibSignal - [WebSocketConnection]: connect()
2021-08-19T10:32:52.890Z [main] WARN LibSignal - [SignalServiceMessageSender]: No attachments present...
2021-08-19T10:32:53.002Z [OkHttp https://textsecure-service.whispersystems.org/...] INFO LibSignal - [WebSocketConnection]: onOpen() connected
2021-08-19T10:32:52.995Z [OkHttp https://textsecure-service.whispersystems.org/...] INFO LibSignal - [WebSocketConnection]: onOpen() connected
2021-08-19T10:32:53.018Z [main] INFO LibSignal - [libsignal-client]: rust/protocol/src/session_cipher.rs:51: Building PreKeyWhisperMessage for: 71f1ccdd-7e30-4530-9270-c315c69825a9.1 with preKeyId: 8834216
2021-08-19T10:32:53.052Z [main] INFO LibSignal - [libsignal-client]: rust/protocol/src/session_cipher.rs:51: Building PreKeyWhisperMessage for: 71f1ccdd-7e30-4530-9270-c315c69825a9.2 with preKeyId: 2
1629369172547
2021-08-19T10:32:53.179Z [main] INFO LibSignal - [WebSocketConnection]: disconnect()
2021-08-19T10:32:53.181Z [main] INFO LibSignal - [WebSocketConnection]: disconnect()

I'm going to attempt to re-register the number as I haven't done that since updating to the latest version of signal-cli, so just to make sure it's fully tested.

PeteJStewart commented 2 years ago

So it seems that I still can't send messages from a server without first receiving a message from the user. However, with a new feature that allows you to create share links for Signal, I have settled on an acceptable work around where we ask the user to click a link that then opens Signal with our number populated and then they can send us a message that we use to fulling register the user and can then communicate with them via the CLI. This is slightly less than ideal UX, but not too bad.

The link structure is as follows:

https://signal.me/#p/+15555555555

apparently you can also use:

sgnl://signal.me/#p/+15555555555

Hope that helps someone.

Edit: The Signal link currently only works for Android devices. It will no doubt be implemented on desktop and iOS at some point soon, but hasn't yet.

AsamK commented 2 years ago

I've added some additional functionality to handle rate limiting. In some cases it can now be lifted, if the server responds with a 428 status code (#708). I don't see anything else that can be done here from signal-cli side.

redradist commented 2 months ago

I see that happens sometimes when new user added to chat like in the following issue: https://github.com/AsamK/signal-cli/issues/1516

Happens issue:

java.lang.AssertionError: RecipientAddress without identifier
    at org.asamk.signal.manager.api.RecipientIdentifier$Single.fromAddress(RecipientIdentifier.java:55)
    at org.asamk.signal.ReceiveMessageHandler.formatContact(ReceiveMessageHandler.java:634)
    at java.base/java.util.Optional.map(Optional.java:260)
    at org.asamk.signal.ReceiveMessageHandler.handleMessageInternal(ReceiveMessageHandler.java:38)
    at org.asamk.signal.ReceiveMessageHandler.handleMessage(ReceiveMessageHandler.java:31)
    at org.asamk.signal.manager.internal.ManagerImpl.lambda$receiveMessages$14(ManagerImpl.java:1252)
    at org.asamk.signal.manager.helper.IncomingMessageHandler.checkAndHandleMessage(IncomingMessageHandler.java:272)
    at org.asamk.signal.manager.helper.IncomingMessageHandler.handleEnvelope(IncomingMessageHandler.java:188)
    at org.asamk.signal.manager.helper.ReceiveHelper.receiveMessagesInternal(ReceiveHelper.java:213)
    at org.asamk.signal.manager.helper.ReceiveHelper.receiveMessages(ReceiveHelper.java:104)
    at org.asamk.signal.manager.internal.ManagerImpl.receiveMessages(ManagerImpl.java:1250)
    at org.asamk.signal.manager.internal.ManagerImpl.receiveMessages(ManagerImpl.java:1222)
    at org.asamk.signal.commands.ReceiveCommand.handleCommand(ReceiveCommand.java:86)
    at org.asamk.signal.commands.CommandHandler.handleLocalCommand(CommandHandler.java:35)
    at org.asamk.signal.App.handleLocalCommand(App.java:278)
    at org.asamk.signal.App.handleCommand(App.java:179)
    at org.asamk.signal.App.init(App.java:144)
    at org.asamk.signal.Main.main(Main.java:56)