Webclient not working on iOS 15

[bigskookum]

After upgrading to iOS 15 yesterday, hosted glowing-bear (latest and normal versions) are not working either in Safari or Chrome.
Weechat 3.3, SSL, no TOTP, LetsEncrypt cert.

with latest.glowing-bear, if 2.8 compatibility is enabled, it times out with "relay: authentication failed with client" appearing in the weechat console.

without the compatibility mode, it errors out immediately, but after a few seconds "relay: reading data on socket for client 5/ssl.weechat/xxx.xxx.xxx.xxx: error -54 Error in the pull function." appears in the weechat log

Tried with and without the new iOS "hide ip address from trackers" option

[Mikaela]

Is there any chance this is another instance of #1197?

[dotsam]

I'm seeing the same thing, both on a self-hosted Glowingbear instance (running a version from late 2020) and the hosted one at glowing-bear.org. This is connecting to WeeChat 2.7.1, with the websocket proxied through Apache. So that's a lot of different things going on.

I've done some basic tests with a simple websocket echo server/client proxied through the same Apache instance, so I'm reasonable satisfied this isn't a HTTP/TLS issue.

I've found a few references to some possible websocket changes in iOS 15:

• https://developer.apple.com/forums/thread/685403
• https://developer.apple.com/forums/thread/690010

I think my next step is going to be to try a direct non-encrypted websocket and see if that makes any difference.

[dotsam]

Quickly proxied the WeeChat relay port through SSH locally and tested from the plain HTTP glowing-bear.org, and things are working correctly, so this does seem to be encryption-related somehow.

Checking the remote Safari web inspector, the socket does appear to briefly connect, but then errors out. WeeChat logs seem to confirm:

10:54:19 |   | relay: new client on port 8000: 3/weechat/::1
10:54:19 |   | relay: websocket client 3/weechat/::1(x.x.x.x) has real IP address "x.x.x.x"
10:54:19 | =!= | relay: error decoding websocket frame for client 3/weechat/::1(x.x.x.x)
10:54:19 |   | relay: disconnected from client 3/weechat/::1(x.x.x.x)

Since the OP seems to be using WeeChat configured directly with a TLS cert and not through a proxy, this feels like an issue specific to GlowingBear, iOS 15, and encrypted websockets?

[dotsam]

(I've tested with weechatRN and lith and both are working, so it's not like the iOS 15 network stack is completely broken for the WeeChat websocket or something)

[bigskookum]

Correct I'm not using a proxy.
Tried it without SSL (created a new relay) and it worked.

[rscullin]

A workaround until Apple fixes what seems to be a bug with NSURLSession:

Go to Settings > Safari > Advanced > Experimental Features, and set NSURLSession Websocket to Off.

After that change, Glowing Bear works with my setup of Weechat 3.2.1 / NGINX / TLSv1.2 (via LE) / iOS 15.

[bigskookum]

Confirming that NSURLSession Websocket to Off is working as a workaround.

[JayGatsby7]

A workaround until Apple fixes what seems to be a bug with NSURLSession:

Go to Settings > Safari > Advanced > Experimental Features, and set NSURLSession Websocket to Off.

After that change, Glowing Bear works with my setup of Weechat 3.2.1 / NGINX / TLSv1.2 (via LE) / iOS 15.

works for me too. does anyone know if this is safe to turn off?

[yourfate]

I still see that error even with NSURLSession disabled…

relay: error decoding websocket frame for client 1/weechat/127.0.0.1

its localhost because of the nginx proxy I assume. I run weechat 3.3 on freebsd 13.0, valid SSL cert, using glowing-bear.org and latest.glowing-bear.org

I connect from iPad OS 15.1 beta and iOS 15.0.2

I tried connecting with icloud private relay on and off, doesn‘t fix it.

Connections from firefox on windows and linux work fine.

update one day later: it works right now, I didn‘t change any settings…

[Kan18]

This issue also happens for me on macOS 12 - I fixed it using the same "NSURLSession Websocket" workaround, the "Experimental Features" menu is available through the Develop menu in the menu bar (which must be enabled in the preferences)

Edit: This appears to be resolved in macOS 12.4

[xsinmyeyes]

This appears to be resolved in iOS 15.4.