Signal desktop app says "Disconnected" with active Internet connection

[ATL-Flaneur]

• [x ] I have searched open and closed issues for duplicates
• [x ] I am using Signal-Desktop as provided by the Signal team, not a 3rd-party package.

---

Bug Description

Signal desktop app says "Disconnected" on a machine with an active Internet connection.

Steps to Reproduce

1. Launch Signal
2. Get yellow box: "Disconnected. Check your network connection. Click to reconnect."
3. Click box.
4. Text changes to: "Connecting… Shouldn't be long"
5. Go back to 2.

This is the first time I've had this problem. Perhaps not coincidentally, we're staying at a place with T-Mobile 5G Internet service. Oddly, the Signal app on my WiFi-only iPad is not experiencing this problem and sends/receives Signal messages just fine. It's only my MBP that the app can't connect.

Screenshots

Platform Info

Signal Version:

Signal 6.16.0 production (Apple silicon)

Operating System:

MacOS 13.3.1 (22E261)

Linked Device Version:

Link to Debug Log

debuglog.txt

[indutny-signal]

Sorry about this. I took a look at your log and I see that the Electron reports to us that your online status changes all the time.

It might help us to isolate this to just Electron specifically. In order to so, could you install Electron Fiddle and load and run this gist with it https://gist.github.com/indutny-signal/28067d3147e7348ac713530dbd103cd1 ? It should display something like:

but if you'll keep running it for longer time - it should display "offline"/"online" status changes as well.

Thanks!

[ATL-Flaneur]

We're back from vacation and no longer dealing with the T-Mobile hot spot, so unfortunately I can't test this.

Most other applications on the MBP were working fine. My VPN app wouldn't connect, which makes me think there was some kind of ISP-level filtering happening.

I'll try running this status app if the issue happens again.

[mkurz]

Having the same problem when connecting via USB to my phone (USB tethering) I am using Linux.

3867 might be related.

[PeterBeu]

Problem started for me immediatly after auto-updating 6.18.1 -> 6.19.0 on Windows. I was able to use the client fully 10 seconds before applying the update. Now it will not connect.

Exitting Signal is leaving 3-4 processes running.

Attempting to downgrade back to 6.18.1 throws an SQL version error.

[ebcdic]

I'm having a similar problem and it seems to be IPv6-related. On my Mac:

$ curl -4 -k https://textsecure-service.whispersystems.org/ {"code":404,"message":"HTTP 404 Not Found"} $ curl -6 -k https://textsecure-service.whispersystems.org/ [hangs indefinitely]

And turning off IPv6 on the Mac makes the problem the the Signal app go away.

However, if I run those curl commands on my router (pfsense), they both work just fine, which suggests it's a problem with my Mac or my network, though most (at least) sites work fine with IPv6. I suggest others who encounter this problem try disabling IPv6 to see if it works for them.

[BOFH90]

same problem on my Mac since the last update couple hours ago. IPv4 works fine. I also use a pfSense router (sg-2100).

[rcmcronny]

I have the same problem and my ipv6 works, only signal seems to have an issue since the update to 6.19.0

[mkurz]

For me this problem occurs when using USB tethering (Android<->Linux Laptop). When unplugging the USB cable and switching to a Wifi hotspot instead it works (no other network or wifi networks are active. Both time

• curl -4 -k https://textsecure-service.whispersystems.org/ and
• curl -6 -k https://textsecure-service.whispersystems.org/ both return

  {"code":404,"message":"HTTP 404 Not Found"}

so for me it does not matter that IPv6 is active. Maybe Signal/electron does not consider network connections via USB?

[mkurz]

For Linux users, this might be related:

• https://bugs.chromium.org/p/chromium/issues/detail?id=1423600 (fixed in chromium 114)
• https://bugs.chromium.org/p/chromium/issues/detail?id=1062144 (does you network interface start with "turn"?)
• Related: https://github.com/vladimiry/ElectronMail/issues/237

[scottnonnenberg-signal]

All, thanks for your investigations. We aren't able to reproduce this, so we need more information - we need as much information as you can tell us about your network setup.

And direct curls like what @ebcdic did are extremely useful too - in that case, we know it's not specific to Signal Desktop - it's a computer/network or even Signal Server problem. All of this data helps us narrow things down.

Otherwise, we're just waiting for an Electron upgrade. But I just did a scan across Electron bugs, and didn't see anything like this. So we may need to raise this with them, and we need a lot of very specific detail to do that.

[ebcdic]

I've raised this on the pfsense forum but not had any response yet. The only thing I can think of that might affect IPv6 in this way is an MTU discovery problem, but it seems like it may not be the same problem for everyone.

@BOFH90 - are you in the UK? If so what ISP are you using?

[scottnonnenberg-signal]

What do you see when you going directly to signal servers? This is what I see:

$ curl -6 -k https://chat.signal.org/
curl: (7) Couldn't connect to server
$ curl -4 -k https://chat.signal.org/
{"code":404,"message":"HTTP 404 Not Found"}

There may be a problem with ipv6 connectivity, at the routing layer.

[ebcdic]

What do you see when you going directly to signal servers?

Same as with textsecure-service.whispersystems.org. IPv4 gets 404, IPv6 hangs. Both get 404 when run from the router.

This is what I see:

$ curl -6 -k https://chat.signal.org/
curl: (7) Couldn't connect to server

That's odd, it's what you'd get if you didn't have IPv6 enabled on your computer.

[ebcdic]

Reducing the MTU on my Mac to 1492 fixes the problem (on the Mac - but my phone has the same problem when connected to my home wi-fi. @BOFH90 does it fix it for you?

[BrokenMouseNA]

Not working with Windows 10, Signal v6.19.0 curl is not working and cant connect as well. curl -4 -k https://chat.signal.org {"code":404,"message":"HTTP 404 Not Found"} curl -6 -k https://chat.signal.org no response

[BOFH90]

Reducing the MTU on my Mac to 1492 fixes the problem (on the Mac - but my phone has the same problem when connected to my home wi-fi. @BOFH90 does it fix it for you?

Yes, just tested and seems to be the case. Its working fine with 1492 and IPv6 atm.

[BOFH90]

I've raised this on the pfsense forum but not had any response yet. The only thing I can think of that might affect IPv6 in this way is an MTU discovery problem, but it seems like it may not be the same problem for everyone.

@BOFH90 - are you in the UK? If so what ISP are you using?

I´m in Germany and using a small ISP called GreenFiber. I already had a bad experience with them setting up my own pfSense-Box and not their provided one.

[ebcdic]

I reverted my router to the previous version, and it still doesn't work - so presumably the update was a red herring.

[norstbox]

I just did a scan across Electron bugs, and didn't see anything like this

@scottnonnenberg-signal this issue is most likely caused by a change in the default behavior of Node 17 when resolving DNS. Some workarounds and more info can be found here: https://github.com/nodejs/node/issues/40537.

Problem manifests itself because ipv6 connectivity is still far from perfect and Happy Eyeballs is not enabled by default in Node 18.

[jon-signal]

Hi, folks! I'm Jon from Signal's server engineering team, and I wanted to let you all know that we're looking into this.

@ebcdic @BOFH90 the path MTU discovery angle seems very interesting, and I'm asking folks in some other threads to try the same to see if it's universal. I'm wondering if there's some common piece of network hardware filtering out ICMP somewhere, though the geographic distribution of people reporting this problem is surprising. More data will help narrow things down.

With that in mind, for those of you for whom an MTU adjustment helps, I have a few follow-up questions:

1. What was your initial MTU before you opted for 1492?
2. Are you comfortable sharing both IPv4 and IPv6 traceroutes to chat.signal.org?
3. This is a stretch, but are comfortable sharing packet captures (or, if you feel you have the expertise, your own analysis of packet captures) to see if we can figure out where things are going wrong? We'd be looking for ICMP "destination reachable" and "fragmentation needed" (types 3 and 4 respectively) packets—or the absence thereof—and any un-ACKed TCP packets.

I recognize some of this stuff can be more revealing than you may want to share publicly; you can also share this information with me directly at my-first-name at signal dot org.

Thank you for your patience and all the debugging so far!

[BOFH90]

My network Hardware is a Netgate SG-2100 and some Mikrotik-Switches running SwOS. On the SG-2100 i created a "allow all" rule for ICMP v4 and v6 to and from all with the highest priority. For IPv6 i use SLAAC with "Router Advertisment" on pfSense enabled and Assisted Router mode (RA Flags | manged, other stateful|, Prefix flags | onlink, auto, router)

1. The MTU in my Client (MacBook Pro M1 with CalDigit TB4 Dock and 2.5G Ethernet) was 1500 and on my Netgate SG-2100 is 1492 on the WAN and 1500 on the LAN Interface.
2. Yes, i reverted to MTU 1500 and Signal not working to run the Traceroute: traceroute IPv6:

   traceroute6: Warning: chat.signal.org has multiple addresses; using 2600:9000:a61f:527c:d5eb:a431:5239:3232
   traceroute6 to chat.signal.org (2600:9000:a61f:527c:d5eb:a431:5239:3232) from 2a0f:ff00:220:e700:9c8f:1c3f:1b95:b835, 64 hops max, 12 byte packets
   1  gateway  0.750 ms  0.405 ms  0.332 ms
   2  2a0f:ff00:1338::1  8.028 ms  8.420 ms  7.940 ms
   3  2001:978:2:8::11:1  8.719 ms  9.031 ms  8.769 ms
   4  * * *
   5  2001:978:2:2c::18:2  16.160 ms  16.129 ms  16.594 ms
   6  2a01:578:0:ff::1d9  16.198 ms
   2a01:578:0:ff::1d8  15.776 ms
   2a01:578:0:ff::1de  16.601 ms
   7  2a01:578:0:ff::1  17.623 ms
   2a01:578:0:ff::2  15.095 ms
   2a01:578:0:ff::67  15.263 ms
   8  2a01:578:0:9005::5  15.322 ms
   2a01:578:0:9005::1  15.968 ms  18.225 ms
   9  2a01:578:0:9005::7  22.269 ms
   2a01:578:0:9005::c  16.148 ms
   2a01:578:0:9005::b  15.247 ms
   10  2a01:578:0:9005::1b  16.073 ms
   2a01:578:0:9005::1f  16.052 ms
   2a01:578:0:9005::1b  16.154 ms
   11  2a01:578:0:9005::2c  15.872 ms
   2a01:578:0:9005::2e  15.359 ms
   2a01:578:0:9005::2f  16.385 ms
   12  2a01:578:0:9005::28  15.465 ms
   2a01:578:0:9005::27  15.550 ms
   2a01:578:0:9005::2a  16.181 ms
   13  2a01:578:0:9002::2a  19.312 ms
   2a01:578:0:9002::28  15.191 ms  15.945 ms
   14  2a01:578:0:9002::30  18.701 ms
   2a01:578:0:9002::2b  25.233 ms
   2a01:578:0:9002::2f  20.527 ms
   15  2a01:578:0:9002::1c  16.382 ms
   2a01:578:0:9002::1d  20.852 ms
   2a01:578:0:9002::22  24.891 ms
   16  2a01:578:0:9002::b  21.241 ms
   2a01:578:0:9002::7  18.952 ms
   2a01:578:0:9002::c  15.609 ms
   17  2a01:578:0:9002::4  15.607 ms
   2a01:578:0:9002::5  16.205 ms
   2a01:578:0:9002::1  17.445 ms
   18  2a01:578:0:ff::a  21.429 ms
   2a01:578:0:ff::8  19.402 ms
   2a01:578:0:ff::9  19.005 ms
   19  2a01:578:0:ff::1e7  15.962 ms
   2a01:578:0:ff::1e3  16.259 ms
   2a01:578:0:ff::1e5  20.469 ms
   20  * * *
   21  * * *
   22  * * *
   23  * * *
   24  * * *
   25  * * *
   26  * * *

traceroute IPv4:

traceroute: Warning: chat.signal.org has multiple addresses; using 76.223.92.165
traceroute to chat.signal.org (76.223.92.165), 64 hops max, 52 byte packets
 1  gateway 1.703 ms  0.513 ms  0.403 ms
 2  bng.core.greenfiber.de (45.155.142.1)  7.814 ms  9.136 ms  8.349 ms
 3  te0-16-0-18.ccr41.ham01.atlas.cogentco.com (149.6.142.161)  9.186 ms  8.534 ms  8.526 ms
 4  be2815.ccr41.ams03.atlas.cogentco.com (154.54.38.205)  15.863 ms  16.106 ms  15.928 ms
 5  a100-row.demarc.cogentco.com (149.14.82.82)  15.691 ms  15.976 ms  15.973 ms
 6  * * *
 7  * * *
 8  * * *
 9  54.239.114.101 (54.239.114.101)  21.522 ms
    54.239.114.145 (54.239.114.145)  15.362 ms
    54.239.114.159 (54.239.114.159)  14.970 ms
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  150.222.249.245 (150.222.249.245)  15.595 ms
    52.93.130.127 (52.93.130.127)  15.511 ms
    150.222.249.251 (150.222.249.251)  19.503 ms
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  52.93.0.78 (52.93.0.78)  15.992 ms
    52.93.0.120 (52.93.0.120)  15.749 ms
    52.93.0.122 (52.93.0.122)  17.074 ms
22  * * *
23  * * *

4. I´m not that comfortable sharing a packet capture from my home.

Thank you for your help.

[PeterBeu]

Issue was Pv6 ISP-related. 6.19.0 is connecting as expected now.

I just did a scan across Electron bugs, and didn't see anything like this

@scottnonnenberg-signal this issue is most likely caused by a change in the default behavior of Node 17 when resolving DNS. Some workarounds and more info can be found here: nodejs/node#40537.

Problem manifests itself because ipv6 connectivity is still far from perfect and Happy Eyeballs is not enabled by default in Node 18.

This could explain why the issue surfaced immediately after updating. Thanks!

[ddur]

https://github.com/signalapp/Signal-Desktop/issues/6439#issuecomment-1565348837

Issue is at better_sqlite3.node Error: Error: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by [REDACTED].unpacked/node_modules/@signalapp/better-sqlite3/build/Release/better_sqlite3.node)

[kodama12]

same prob windows 10 after upgrading 6.19

QR code won't charge either if i reinstall the app.

[BOFH90]

Seems to be a problem with MTU Path Discovery and pfSense. I checked wireguard and the Router Advertisments showed a MTU of 1500, but my PPPoE Interface has 1492. I patched pfSense Radvd to always send out 1492 via RA and now all my Clients are working fine and can connect to Signal.

[ebcdic]

@BOFH90 radvd should broadcast the MTU of the interface, so setting the MTU of your LAN interface in the pfsense graphical interface should have the same effect without having to patch anything.

[dns2utf8]

I experience the same issue without VPN on a dual stack mobile network with an MTU of 1420

[geustace]

I have this issue as well since upgrading to 6.19, tried 6.20-beta and same thing. All other dual stack apps working fine. chat.signal.org is pingable over IPv4 and IPv6. Not sure how MTU fits with this. I am using a Mikrotik as my internet router. MacOS 13.3.1(a)

[geustace]

I can confirm that turning off IPv6 gets around the issue but not a fix I can live with. Have turned back on again, and app is still working for now. Fingers crossed

[kodama12]

I would say that to me, something is wrong about my firewall Kaspersky, because when i turn it off, Signal works. I already put Signal in whitelist. Something related to Signal, a third party software, looks unauthorized (and undetected) by kaspersky.

[Tyler-2]

Signal Desktop Beta Version: 6.20.0-beta.1 from https://updates.signal.org/desktop/apt on Debian Linux was getting "Disconnected. Check your network connection." after update on Debian Linux 11.7. Disabling IPv6 via sysctl resolved for now.

# echo 1 > /proc/sys/net/ipv6/conf/default/disable_ipv6
# echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6

[geustace]

I have tried forcing IPv4 by setting the two chat.signal.org addresses in /etc/hosts but it would appear that signal doesnt use the system resolver as it still wants to use the IPv6 addresses if IPv6 is enabled on my computer.

[nputnam]

I have tried forcing IPv4 by setting the two chat.signal.org addresses in /etc/hosts but it would appear that signal doesnt use the system resolver as it still wants to use the IPv6 addresses if IPv6 is enabled on my computer.

I have a similar setup to you and was having a similar issue. I found something that fixed it for me. I updated the MTU setting under IPv6 ->ND to match my ipv6 interface 1472.

[kodama12]

Is there any chance that we have a fix for Signal ? it's like we are discussing all together.

I would say that to me, something is wrong about my firewall Kaspersky, because when i turn it off, Signal works. I already put Signal in whitelist. Something related to Signal, a third party software, looks unauthorized (and undetected) by kaspersky.

[scottnonnenberg-signal]

We've just released 6.20.0-beta.2 and 6.20.0 - please try it out. It should make things work!

[kodama12]

Good evening Scott. On my Windows 10, the 6.20.0-beta1 is not working, i cannot even have the QR code. "QR code cannot be loaded, check your internet access"

[scottnonnenberg-signal]

@kodama12 Please try 6.20.0-beta.2, which we just released! You're still on beta.1.

[geustace]

Thanks heaps, 6.20 seems to be working fine for me.  Are you able to say what was broken/fixed ?

On 1/06/23 10:35 am, Scott Nonnenberg wrote:

We've just released 6.20.0-beta.2 and 6.20.0 - please try it out. It should make things work!

— Reply to this email directly, view it on GitHub https://github.com/signalapp/Signal-Desktop/issues/6393#issuecomment-1571051313, or unsubscribe https://github.com/notifications/unsubscribe-auth/AVDXWMSMTWGTUQEMP6X4GSTXI7BSVANCNFSM6AAAAAAXRATHZQ. You are receiving this because you commented.Message ID: @.***>

--

(√-1) 2^3 ∑ π it was delicious

The world cant be flat, if it was the cats would have pushed everything over the edge by now!

[scottnonnenberg-signal]

@geustace Desktop now prefers to connect via ipv4. Previously it was preferring ipv6, and that was causing major problems.

[kodama12]

@kodama12 Please try 6.20.0-beta.2, which we just released! You're still on beta.1.

sorry, i'm probably dumb, but i get there https://support.signal.org/hc/en-us/articles/360007318471-Signal-Beta#update

there is nos version to download, just basic "beta" exe, that download me beta1 i dont have choice to download something else yesterday.

How i got beta2 and it's not working more. I'm still not able to screen a QR code to link my phone.

[kodama12]

When i clic on "try again" for QR code,

164 C:\Users\XXX\AppData\Local\Programs\signal-desktop-beta\resources\app.asar\preload.bundle.js:76 Uncaught (in promise) HTTPError: connectResource: connectFailed; code: -1 at WebSocketClient. (C:\Users\XXXX\AppData\Local\Programs\signal-desktop-beta\resources\app.asar\preload.bundle.js:76:373568) at WebSocketClient.emit (node:events:513:28) at ClientRequest.handleRequestError (C:\Users\XXXX\AppData\Local\Programs\signal-desktop-beta\resources\app.asar\node_modules\websocket\lib\WebSocketClient.js:227:14) at ClientRequest.emit (node:events:513:28) at TLSSocket.socketErrorListener (node:_http_client:502:9) at TLSSocket.emit (node:events:513:28) at emitErrorNT (node:internal/streams/destroy:151:8) at emitErrorCloseNT (node:internal/streams/destroy:116:3) at process.processTicksAndRejections (node:internal/process/task_queues:82:21) Original stack: Error at connect (C:\Users\XXXXX\AppData\Local\Programs\signal-desktop-beta\resources\app.asar\preload.bundle.js:76:373131) at RP.connectResource (C:\Users\XXXXX\AppData\Local\Programs\signal-desktop-beta\resources\app.asar\preload.bundle.js:76:380655) at RP.getProvisioningResource (C:\Users\XXXXX\AppData\Local\Programs\signal-desktop-beta\resources\app.asar\preload.bundle.js:76:377066) at Object.kl [as getProvisioningResource] (C:\Users\XXXX\AppData\Local\Programs\signal-desktop-beta\resources\app.asar\preload.bundle.js:79:7574) at XU.registerSecondDevice (C:\Users\XXXX\AppData\Local\Programs\signal-desktop-beta\resources\app.asar\preload.bundle.js:79:177480) (

[kodama12]

as i said, was 6.18.1 no issue, updating to 6.19.1 and lasts beta, not working anymore, related to kaspersky. I have to suspend Kaspersky firewall to make it works, maybe something about some components web reputation, because i dont change anything into my firewall settings.

[scottnonnenberg-signal]

@kodama12 I just tried it, and when I go to that beta download page, it gives me 6.20.0-beta.2. When exactly did you last download it?

[kodama12]

yeah i already download beta2, was not able yesterday. Not working. I copy log above , it's like it's never connecting and related to some web reputation around Kaspersky

https://github.com/signalapp/Signal-Desktop/issues/6393#issuecomment-1572529953

[kodama12]

fixed by deleting all rules from kaspersky. very strange, something inside 6.19 was trapped and banned for my Kaspersky configuration that i didn't update for a while.

[lyrabeetle]

hi. after updating to 6.20.1 the connection issue is back for me unfortunately. i'm using signal desktop on a macbook pro m1 with macOS 13.4 / i had the original connection issue after updating to 6.19.0 / after updating to 6.20.0 everything was fine again; not anymore now with 6.20.1

[KlugFR]

I had the issue (since 6.20) and might have fixed it: the "Electron Helper" instance of Signal was blocked by Lulu (could be blocked by any other firewall package). I cleaned the rule and allowed it, it seams to connect now.

[krosseyed]

I am experiencing the exact same issue as well.

I am using pfsense with dual stack IPv4/6 using an HE.net tunnel. Disabling IPv6 'fixes' the issue and changing the MTU does nothing for me.

[indutny-signal]

@krosseyed what Signal version are you on? Could you submit a debug log?

[krosseyed]

@indutny-signal 6.20.1 for Apple Silicon (on an M2 MBA).

Debug log attached

debuglog.txt