search

signalapp / Signal-Android

A private messenger for Android.
https://signal.org
GNU Affero General Public License v3.0
25.61k stars 6.15k forks source link

Messages are not sent #8365

Closed Mrjelly13 closed 5 years ago

Mrjelly13 commented 5 years ago

Bug description

Messages will not send. Fixed by rebooting phone. The second time it happened I had to reboot and turn the WiFi on and off.. Started after updating to Android Pie.

Steps to reproduce

Unfortunately I'm not sure how to reproduce this bug. It just happens after a while and I haven't figured out anything identifiable.

Actual result: Messages don't send. Expected result: Messages should be sent.

Device info

Device: Nokia TA-1043 (6.1 Europe) Android version: 9.0.0 Signal version: 4.30.4

Link to debug log

https://debuglogs.org/601c1e2779dcbf2b7714b3f603b5e7bc1ec0dc571d4a650c3616240d30c70b40

johanw666 commented 5 years ago

What kind of messages? Something changed between 4.30.3 and 4.30.4 in sending sms messages, is it that or are you talking about Signal messages?

Mrjelly13 commented 5 years ago

Signal messages, sorry for not specifying.

⁣Sent from BlueMail ​

On Nov 14, 2018, 12:33, at 12:33, johanw666 notifications@github.com wrote:

What kind of messages? Something changed between 4.30.3 and 4.30.4 in sending sms messages, is it that or are you talking about Signal messages?

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/signalapp/Signal-Android/issues/8365#issuecomment-438631809

2-4601 commented 5 years ago

Related #8305?

greyson-signal commented 5 years ago

You're getting a generic bad-network exception:

2018-11-14 11:25:44.858 GMT+01:00 I Job: [990f8750-0d23-4891-b773-035aa4e1796e] PushMediaSendJob :: Retrying after a retryable exception. (Time since submission: 1156363 ms, Run attempt: 4, isStopped: false)
2018-11-14 11:25:44.858 GMT+01:00 I Job: org.thoughtcrime.securesms.transport.RetryLaterException: javax.net.ssl.SSLException: Write error: ssl=0xec2d26c8: I/O error during system call, Connection reset by peer
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at org.thoughtcrime.securesms.jobs.PushMediaSendJob.deliver(PushMediaSendJob.java:183)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at org.thoughtcrime.securesms.jobs.PushMediaSendJob.onPushSend(PushMediaSendJob.java:95)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at org.thoughtcrime.securesms.jobs.PushSendJob.onSend(PushSendJob.java:71)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at org.thoughtcrime.securesms.jobs.SendJob.onRun(SendJob.java:49)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at org.thoughtcrime.securesms.jobs.MasterSecretJob.onRun(MasterSecretJob.java:18)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at org.thoughtcrime.securesms.jobmanager.Job.doWorkInternal(Job.java:95)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at org.thoughtcrime.securesms.jobmanager.Job.doWork(Job.java:61)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at androidx.work.Worker$1.run(Worker.java:95)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at java.lang.Thread.run(Thread.java:764)
2018-11-14 11:25:44.858 GMT+01:00 I Job: Caused by: javax.net.ssl.SSLException: Write error: ssl=0xec2d26c8: I/O error during system call, Connection reset by peer
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at com.android.org.conscrypt.NativeCrypto.SSL_write(Native Method)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at com.android.org.conscrypt.NativeSsl.write(NativeSsl.java:414)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at com.android.org.conscrypt.ConscryptFileDescriptorSocket$SSLOutputStream.write(ConscryptFileDescriptorSocket.java:623)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at com.android.okhttp.okio.Okio$1.write(Okio.java:76)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at com.android.okhttp.okio.AsyncTimeout$1.write(AsyncTimeout.java:155)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at com.android.okhttp.okio.RealBufferedSink.emitCompleteSegments(RealBufferedSink.java:176)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at com.android.okhttp.okio.RealBufferedSink.write(RealBufferedSink.java:46)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at com.android.okhttp.internal.http.Http1xStream$FixedLengthSink.write(Http1xStream.java:288)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at com.android.okhttp.okio.RealBufferedSink.emitCompleteSegments(RealBufferedSink.java:176)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at com.android.okhttp.okio.RealBufferedSink$1.write(RealBufferedSink.java:198)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at org.whispersystems.signalservice.api.crypto.DigestingOutputStream.write(DigestingOutputStream.java:29)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at org.whispersystems.signalservice.api.crypto.AttachmentCipherOutputStream.write(AttachmentCipherOutputStream.java:59)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at org.whispersystems.signalservice.internal.push.PushServiceSocket.uploadAttachment(PushServiceSocket.java:623)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at org.whispersystems.signalservice.internal.push.PushServiceSocket.sendAttachment(PushServiceSocket.java:387)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at org.whispersystems.signalservice.api.SignalServiceMessageSender.createAttachmentPointer(SignalServiceMessageSender.java:840)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at org.whispersystems.signalservice.api.SignalServiceMessageSender.createAttachmentPointers(SignalServiceMessageSender.java:821)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at org.whispersystems.signalservice.api.SignalServiceMessageSender.createMessageContent(SignalServiceMessageSender.java:368)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at org.whispersystems.signalservice.api.SignalServiceMessageSender.sendMessage(SignalServiceMessageSender.java:214)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    at org.thoughtcrime.securesms.jobs.PushMediaSendJob.deliver(PushMediaSendJob.java:174)
2018-11-14 11:25:44.858 GMT+01:00 I Job:    ... 10 more

What's your network like during this time? Is it flaky at all? Are other network-using apps working on your phone? Are you running a VPN or anything? Thanks!

Mrjelly13 commented 5 years ago

It's happened on two separate WiFi networks that were working normally for every other app and device and while on 4G data in the center of a major European city. No VPN running at the time.

Mrjelly13 commented 5 years ago

So it has happened again. I was connected to a vpn when it happened, so I tuned off the vpn and it didn't work. I soft rebooted to data, still didn't work, then I shutdown the phone and booted it up again and it still didn't work. It is still not sending 32 minutes later.

Debug log after soft reboot:

Soft reboot

Debug log after shutdown and boot:

Hard restart

I saw this mentioned in #8374 is there anything other information I can provide to help solve this issue?

scytho commented 5 years ago

I have the same problem since I updated to 4.29.7 (I downloaded the apk, because I don't have Google/GApps). I updated to 4.30.7 some days ago, but that didn’t change anything.

In addition to messages not being sent, the app won’t backup messages. I’m going to return to the last working version, 4.24.8, and see if I can backup messages with that.

Edit: Here is the debug log. https://debuglogs.org/f9d5b29e5e3ffaec5d28ddf354f21f5d0b4a1d4896dcc61eb71cd42830d4cf64

PiCob commented 5 years ago

@scytho: Your device info, Android version and a debug log would be really helpful... you can add this information by editing your post.

Mrjelly13 commented 5 years ago

After it happening a few more times I believe it happens after sending a reply via the notification, but not every time I send reply that way.

scytho commented 5 years ago

I’ve added the debug log. I forgot to mention that I can receive messages, and I can send messages with Signal Desktop. I see those on my phone, too. It’s only when sending messages from my phone that the circle keeps spinning.

Mrjelly13 commented 5 years ago

I’ve added the debug log. I forgot to mention that I can receive messages, and I can send messages with Signal Desktop. I see those on my phone, too. It’s only when sending messages from my phone that the circle keeps spinning.

Can confirm this is the same for me.

greyson-signal commented 5 years ago

@Mrjelly13

Debug log after soft reboot:

Soft reboot

Debug log after shutdown and boot:

Hard restart

I looked at both of these logs, and I didn't see any evidence of messages that failed to send? Every message that was sent completed successfully.

The logs spanned from: 2018-11-21 22:56:07.808 GMT+01:00 -> 2018-11-22 14:57:53.231 GMT+01:00

(The hard reset extends log coverage to 2018-11-22 15:25:47.820 GMT+01:00)

Did the incident happen before this window? If it happened during this time, can you confirm whether the recipient received the message that appeared to be stuck?

greyson-signal commented 5 years ago

@scytho You're having a totally separate issue. It seems like you're using Signal without Google Play Services, but something is wrong with the persistent websocket connection. Specifically, I believe there were changes submitted between 4.24.8 and 4.29.7 that changed how this connection was kept alive, and there appears to be a bug. I've opened #8402 on your behalf.

quantalume commented 5 years ago

I've been having this problem on and off for a few months. Previously, I was able to resolve it by clearing all data and uninstalling and reinstalling Signal. It worked for about a month this time, but now I'm experiencing the problem again. Rebooting and turning WiFi and mobile data off and back on have no effect. SMS send/receive is fine as is Signal receive.

Link to logs below. Tried to send message at 12:56 and uploaded the logs at 12:58.

https://debuglogs.org/cdc31b3d7d5579adc19c4a8f8fb73aafca4035193eeef4a07784070923a315c0

greyson-signal commented 5 years ago

@quantalume It looks like your problems are stemming from a situation where you failed to send a message due to poor network a few days before, and WorkManager never rescheduled your message send. I'm currently in a dialog with the WorkManager team to try to get these issues resolved, and in the meantime I'm going to try to think of mitigations.

throwaway189 commented 5 years ago

Im reporting the same issue, cannot send messages, but i can recieve them. Im using lineage 15 without google apps running the latest apk from the signal website. Last working version is 4.25.10. Also, reinstalling and rebooting doesnt solve it.

log:

https://debuglogs.org/457e879f73fe1a4d7cfeed7fc4fed60c58a6d8fd05e14b59d57d1750cfd148f3

scytho commented 5 years ago

@greyson-signal: Thanks. Can you see anything in my log regarding the backups not working?

throwaway189 commented 5 years ago

@grayson-signal: another note that is weird, i cannot send messages(i can recieve messages tho) thru my phones client, but i can send them thru the desktop client. Hope this helps.

CFPrulez commented 5 years ago

LineageOS 15 with MicroG, behaviour after updating the app:

Mobile data: – Receiving messages works – Sending messages not possible

WiFi: – Receiving messages works – Sending messages works

When changing from mobile data to WiFi all pending messages are immediately sent. Staying on mobile data (good connection) keeps them being stuck.

greyson-signal commented 5 years ago

@throwaway189 @CFPrulez I can't do anything without a debug log. Please go to Settings > Advanced > Submit debug log and post the link you get here.

greyson-signal commented 5 years ago

@scytho

Thanks. Can you see anything in my log regarding the backups not working?

I see that the job to run the backup is submitted but never run. Please open a separate ticket and describe the backup problem in more detail.

CFPrulez commented 5 years ago

@throwaway189 @CFPrulez I can't do anything without a debug log. Please go to Settings > Advanced > Submit debug log and post the link you get here.

https://debuglogs.org/12d9c10fa1dfd64bb3612647e9d01fb5e37e433ce7ed80f724106264747bbe33

(App was stopped and restarted several times, sometimes switched between mobile and wifi (e.g. to send debug log)).

throwaway189 commented 5 years ago

@throwaway189 @CFPrulez I can't do anything without a debug log. Please go to Settings > Advanced > Submit debug log and post the link you get here

@greyson-signal I thought my first debug log was enough, anyway heres the newest log where the problem is still occuring, any messages send thru the mobile app are stuck on pending, but it can recieve messages, the desktop client functions normally and can send messages. Let me know if theres anything else i can do to assist, thank you for helping , its very appriciated! :) Log: https://debuglogs.org/42228e8c37a04da50008dd60c56b76589b52e59da232ce74b228283e77463094

greyson-signal commented 5 years ago

@throwaway189 Are you able to send messages on your mobile device when connected to wifi? It looks you and @CFPrulez have a near-identical device+OS combo.

@CFPrulez For whatever reason, the system doesn't think you have an active network connection when connected to mobile data. It's difficult to say if this is a WorkManager-layer problem, or a problem with Lineage's implementation of the system JobScheduler.

I happen to have an original OnePlus One, and Lineage OS 15 is available for it, so I'm going to try to flash it on there when I get some time and see if this is a device/OS issue.

(Also @throwaway189 you're correct, the first log was enough. There's so many people in this thread that I lost track, apologies.)

CFPrulez commented 5 years ago

@CFPrulez For whatever reason, the system doesn't think you have an active network connection when connected to mobile data. It's difficult to say if this is a WorkManager-layer problem, or a problem with Lineage's implementation of the system JobScheduler.

I happen to have an original OnePlus One, and Lineage OS 15 is available for it, so I'm going to try to flash it on there when I get some time and see if this is a device/OS issue.

No need to flash, I could solve the problem, your analysis was the final hint. I think because of firewall restrictions the network check failed on mobile data (indicated by a "x" in the status bar next to "H+") -- all other messenger (including earlier versions of Signal) do (did) not care about that. Deactivating the firewall solved it, so it think I will just have to change the corresponding rule. Note: As I did not modify any firewall rules in the last months, this means that some function in Signal was changed (it now cares about the network status).

throwaway189 commented 5 years ago

@greyson-signal sending via wifi doesnt work, if have disabled my firewall. As a note though, my wifi and data always have an X because i turned of googles connectify check, resulting in the wifi and data always thinking they dont have a connection, while they work fine. could it be the the newer signal checks for connectifity, sees that the device reports there inst internet access, and cause signal to wait with actully sendning the message?

scytho commented 5 years ago

I tried the same, I disabled AFWall+. Now I can send messages via WiFi. All of a sudden downloads I tried to start ages ago are coming in now (Threema updates). Normally, with AFWall+ enabled, I can send messages and do everything, there is only that cross in the status bar next to the mobile symbol, as described by CFPrulez, because I have AFWall+ block the service that checks for an internet connection.

greyson-signal commented 5 years ago

@throwaway189 @scytho That's almost certainly it. The system JobScheduler won't even attempt a job if it thinks there's no network, so if you've changed something to make the system think there's no network, then jobs won't run.

scytho commented 5 years ago

I reenabled AFWall+ and was still able to send a message (via WiFi).

throwaway189 commented 5 years ago

After messing with afwall here, it seems to work again(when disabled), whats the name of the service that should be allowed in afwall? @scytho

throwaway189 commented 5 years ago

@greyson-signal is there anything that caused this behavior, because earlier signal versions didnt mind this.

CFPrulez commented 5 years ago

After messing with afwall here, it seems to work again(when disabled), whats the name of the service that should be allowed in afwall? @scytho

For me it is a single entry with a huge list of services (Android system, advanced settings, setup wizard, Call manager, Keyring, LineageOS settings, combined location services, poweroff alarm, Dev Tools etc.). Allowing/Disallowing this entry decides whether the connectivity check fails or succeeds.

greyson-signal commented 5 years ago

@throwaway189

is there anything that caused this behavior, because earlier signal versions didnt mind this.

The migration to API 26, which requires that we use JobScheduler to run jobs in response to network changes. This was done in Signal 4.29.x.

throwaway189 commented 5 years ago

Ah, i see, anyway thanks for helping us find the issue, its very appriciated!!!!

@cfprulez thanks, seems to be working here to.

scytho commented 5 years ago

Is there really no alternative? Take K-9 and Threema, they are still working.

pascalwhoop commented 5 years ago

its sort of a bummer because the "Android System" is combined with half of Samsungs Bloatware and who knows what's running in those packages.

revuwa commented 5 years ago

I had he same behavior on three different (Samsung, Sony, Motorola) mobiles, with (Gapps free) custom ROMs (Android 8.1 - 9.0) installed and using AFWall+.

Thanks to the hints in this thread, I was able get encrypted messages to work as mentioned from people before:

  1. inside of AFWall+, I gave the following two positions full networking access:
    • "[-11] (kernel) - Linux kernel"
    • "[1000] Android System, ..."

After rebooting the devices the cross next to the mobile networking symbol was gone and Signal was able to send encrypted messages again.

But I accidentally found another workaround:

  1. Using an (always-on) VPN instead. I don‘t know why but it works for me using a VPN, while:
    • giving the VPN full networking access, and
    • giving Signal VPN access only (inside of AFWall+)

In my case, no other permissions are required to bring back sending encrypted messaged with Signal.

pycadelic commented 5 years ago

It's a real bummer that Signal now requires Android System to be able to communicate with the network.

It's either allowing the phone to repeatedly phone home to google or be able to use Signal.

Great..

scytho commented 5 years ago

If there isn’t any way around that, I can just as well install GApps or microG and use WhatsApp.

greyson-signal commented 5 years ago

To be clear, JobScheduler isn't part of Google Play Services or anything -- it's part of the Android OS. Non-GApps phones can use it too. Now that all apps in the Play Store are forced to target API 26 and above, the only way to be notified of network changes is to use JobScheduler. Sounds like @revuwa gave plenty of good tips on how to configure your firewall appropriately.

Regardless, OP's issue seems to be with a specific phone model having trouble making network requests randomly after an update. I don't know if there's much action for us to take here, so I'm going to close this.

pycadelic commented 5 years ago

@greyson-signal while it might not be part of job schedular, privacy-savvy android users block the "Android System" (collection of) processes at the firewall level because among other unknown things, it phones home to google repeatedly, that's how it does the connectivity check.

Because it's a system process these checks cannot be sent through a VPN easily, maybe with a always-on one, but I haven't checked.

As a privacy conscious user, ANYTHING to do with google is an immediate no in my book, I don't want any of my devices doing as much as establishing a TCP connection to google servers. Or facebook, for that matter.

In light of recent revelations and scandals this has proven to be a wise choice indeed.

If the price to use signal is repeatedly announcing to google (and whoever cares to listen) whenever I have wifi enabled on the android device then personally I'll stop using the Signal app, and I'm sure other privacy-conscious users (sort of the whole point with Signal really) will move in the same direction.

There is only one application which has stopped sending messages with that API 26 mininum level change that you have mentioned, and it is Signal. Every other app is, supposedly, subject to the very same restriction, and yet all of them keep working as before.

This tells me that there ought to be an alternative to how Signal is currently delivering messages.

Unfortunately it seems to me that privacvy-conscious users who refuse to run google spyware on their devices will once again get the shaft from Signal with this change, which is unfortunate since we are precisely those who most ardently supported the philosophical aims of the project.

scytho commented 5 years ago

ACK, thanks. That’s what I intended to say. Signal to me feels somewhat like Firefox. Both are getting more and more uncool, seriously degrading in those feature departments I chose both for in the first place. It sucks, profoundly.

And, yep, Threema doesn’t need JobScheduler. Maybe because it offers polling (?) as an alternative to push messages.

CFPrulez commented 5 years ago

I'm with you, guys. However, it is correct to close this issue as the problem has been solved.

There should be a new issue like "Signal does not work with 'Android System' having no internet" where this problem can be addressed.

tomturbu commented 5 years ago

Hi,

you don't have to allow that in your firewall, you can just disable captive portal mode. ...

In Pie: settings put global captive_portal_mode 0

After the reboot, the network check is disabled and you can send messages without any Google connection. ....

CFPrulez commented 5 years ago

According to the AFwall+ wiki[1]:

//Android 4+
settings put global captive_portal_detection_enabled 0
settings put global captive_portal_server localhost

//Since Android 7
settings put global captive_portal_mode 0

[1]https://github.com/ukanth/afwall/wiki/FAQ#61-what-is-androids-captive-portal-check

tomturbu commented 5 years ago

it seems that settings put global captive_portal_mode 0 is not very consistent. i can send messages, but no pictures.

When i try to send a picture it's only in "pending"-state....

biaq commented 5 years ago

Cancelling the JobScheduler's tasks

As this issue occurs because of signal offloading sending its messages to JobScheduler which then gets blocked by the firewall, I was wondering if it could be (temporarily) resolved by canceling signal's jobs that are currently registered in JobScheduler. That way signal can be restored to a 'fresh install' state, internet-connectivity-wise, and we know that signal does work for a while after a fresh install.

The list of pending jobs can be accessed via adb shell dumpsys jobscheduler. In my output I see a bunch of signal's scheduled jobs:

Registered jobs:
    ...
    113..:[ComponentInfo{org.thoughtcrime.securesms/androidx.work.impl.background.systemjob.SystemJobService},jId=6374,u0,R=(-5:36:53,none),N=1,C=false,I=false,F=0,P=false,ANI=true]
    206..:[ComponentInfo{org.thoughtcrime.securesms/androidx.work.impl.background.systemjob.SystemJobService},jId=6378,u0,R=(-5:36:53,none),N=1,C=false,I=false,F=0,P=false,ANI=true]
    458..:[ComponentInfo{org.thoughtcrime.securesms/androidx.work.impl.background.systemjob.SystemJobService},jId=6368,u0,R=(-5:36:53,none),N=1,C=false,I=false,F=0,P=false,ANI=true]
    576..:[ComponentInfo{android/com.android.server.backup.FullBackupJob},jId=20536,u0,R=(none,none),N=2,C=true,I=true,F=0,P=true,ANI=true]
    ...

This is after a reboot, without Signal running in the background. Note that there's also a 'FullBackupJob' in the list, which would explain why the backups also stop working when sending messages stops working: I guess JobScheduler tries to send those messages out first and do the backup afterwards.

Canceling those jobs is not very straightforward though, and AFAIK has to be done through adb shell service call which is a hot mess: it can call functions of services by their sequance of appearance in the source code which changes from version to version of android OS. [This also did not work for me, so if somebody knows how to fix it or knows a better way, it would be great to try this potential remedy] JobScheduler has a service, listed in adb shell service list: 

$ adb shell service list | grep jobscheduler
41      jobscheduler: [android.app.job.IJobScheduler]

The IJobScheduler's functions are in android's source code. The link is for android v6; for a different version, the 'marshmallow-release' in the URL needs to be changed to 'nougat-release' or whatever your version is (this matters because the functions order differs between the versions). The cancelAll() function is the third in the source code, and does not require any arguments, so it's called like this:

adb shell service call jobscheduler 3

However, the jobs list in dumpsys jobscheduler does not get modified... Maybe somebody else can try it on a different ROM / android version? Mine is Replicant v6.0

Links:

thomasfrandsen commented 4 years ago

This happened to me today for the 3rd time with an almost 5 day lag with other messages sent and received just fine. This is still an issue. I'm out. I can't trust this app if it can't handle sending a message.

greyson-signal commented 4 years ago

@thomasfrandsen This ticket is largely about people having issues with firewalls and stuff on their phone, or the specific phone model OP used. Does that apply to you? If not, would love to see a debuglog to see why your messages are stuck.