über das Forum des Custom-ROMs /e/OS bin ich auf adminforge aufmerksam geworden.
/e/OS bietet mit push.murena.com und ntfy einen eingebauten UnifiedPush-Support. Die Registrierung bei MollySocket von adminforge war problemlos möglich. (ntfy in /e/OS hat die Kennung foundation.e.ntfy.)
Einige /e/OS-User und ich haben aber festgestellt, dass nach einiger Zeit die Push-Nachrichten in Molly verzögert oder gar nicht mehr angekommen sind (auch wenn Molly von der Akkuoptimierung in Android ausgenommen gewesen ist).
Ein Blick auf die Website des UnifiedPush-Kanals hat gezeigt, dass die Molly-Benachrichtigungen dort entsprechend verspätet oder gar nicht aufgetaucht sind.
Es scheint also auf dem Weg Signal-Server → MollySocket → Murena-Push zu einer Verzögerung zu kommen.
Als Gegenprobe haben verschiedene User (auch ich) MollySocket von yourdevice.ch genutzt, was bisher problemlos funktioniert hat, auch mit Murena-Push.
Zudem nutze ich den FOSS Public Alert Server von adminforge, was zuverlässig funktioniert im Zusammenspiel mit Murena-Push.
Sind euch solche MollySocket-Probleme bekannt? Wie können wir diesen Sachverhalt genauer analysieren?
Trotz dieses seltsamen Verhaltens: Natürlich ein großes Dankeschön für diese tolle Seite!
Ich habe schon mehrfach versucht das Problem zu beheben.
Problem:
Die Verzögerung der Push-Nachrichten liegt nicht an einem „Offline-Server“, sondern an einer instabilen WebSocket-Verbindung zwischen MollySocket und den Signal-Servern.
Sobald der Keepalive fehlschlägt, bricht die Verbindung ab. Signal puffert die Nachrichten währenddessen in einer Warteschlange. Die „Verspätung“ ist genau das Zeitfenster, in dem MollySocket versucht, den unterbrochenen Handshake wiederherzustellen. Erst nach dem Reconnect werden alle gestauten Nachrichten auf einmal zugestellt.
Was ich jetzt nochmal zur Abhilfe versucht habe:
Umzug: Von Apache auf Nginx.
Nginx-Tuning: WebSocket-Header (Upgrade/Connection) aktiv und Timeouts (proxy_read_timeout) auf 3600s gesetzt, um vorzeitige Abbrüche durch den Proxy zu verhindern.
MTU-Anpassung: Die MTU im Docker-Netzwerk wurde auf 1420 reduziert, um Probleme mit Paket-Fragmentierung auszuschließen.
IPv4-Zwang: IPv6 wurde innerhalb des Containers via sysctls deaktiviert, um Routing-Probleme zu umgehen.
Debug-Analyse: Das Log zeigt weiterhin Handshake not finished, was auf eine serverseitige Ablehnung durch Signal (z. B. wegen Session-Kollisionen oder Rate-Limiting) hindeutet.
Ich habe unter https://mollysocket.adminforge.de einen Mollysocket mit neuer Datenbank aufgesetzt. Testet bitte einmal ob es damit funktioniert.
Ersteindruck nach 15h: Bisher scheint es zu funktionieren , was bei molly.adminforge.de bei meinem letzten Versuch leider nicht der Fall war. Schauen wir, welche Erfahrungen die Mitglieder der /e/OS-Community und ich in den nächsten Tagen machen.
P.s.: Da ich beruflich mit dem Zusammenspiel von Reverse Proxy, Firewall, Authentication Server & Applikationsserver zu tun habe, kenne ich (zumindest oberflächlich) die Erfahrung, dass man oft an Kleinigkeiten drehen muss, bis alles fehlerfrei läuft.
Vielen Dank deswegen nochmal für den tollen Einsatz!
Heute gab es bei mollysocket.adminforge.de auch keine Probleme: Alle Nachrichten kamen innerhalb weniger Sekunden an, wenn ich ihre Eigenschaften geprüft habe.
Gib Bescheid, sobald wieder molly.adminforge.de genutzt werden sollte. Ich werde das der /e/OS-Community mitteilen, und wir sammeln weitere Erfahrungen.
Kann man sich im Zweifelsfall eigentlich mit yourdevice.ch austauschen, um weitere mögliche Fehlerquellen zu identifizieren?
Seit gestern Mittag (12. April) habe ich beobachtet, dass manche Chatnachrichten mit bis zu einer Minute Verzögerung ankommen, doch immerhin nicht verloren gehen. Ich hoffe, das Problem renkt sich wieder ein.
Richtig eingerenkt hat es sich bisher leider nicht. Die Zustellungen scheinen Verzögerungen zwischen 20 Sekunden bis etwas mehr als 2 Minuten zu haben. Positiv aber: Nachrichten scheinen bisher keine verloren gegangen zu sein.
Heute trat der Fehler wieder mit deutlicher Verzögerung der Zustellung auf.
Jetzt habe ich meine Molly-Instanz wieder neu beim MollySocket von Adminforge registriert (den genauen Ablauf weiß ich nicht, es hat erst beim zweiten oder dritten Mal geklappt, mit yourdevice(punkt)ch als Zwischenschritt und manueller Deregistrierung des MollySocket in den gekoppelten Geräten). Jetzt kommen die Nachrichten wieder relativ zeitnah an.
, was bei 
