GIGASET DECT hängt sich auf und muss neu gestartet werden

Hallo liebes Forum,

wir betreiben teilweise die Telefone hinter einem Mikrotik Router, der via Wireguard VPN sämtlichen Traffic aus der Filiale über einen VPN Server im Hetzner RZ ins Internet tunnelt. Damit werden auch alle Pascom Connects über diesen Tunnel geschoben.
Als wir die ersten Yealinks eingebunden haben, stießen wir auf das Problem, das teilweise die Verbindung verloren ging.
Die Lösung war dann, dass wir die MTU der Telefone auf 1420 eingestellt haben. Anschließend lief alles sauber schon für einige Monate.

Jetzt haben wir zum ersten Mal ein Gigaset DECT eingebunden, welches sich komisch verhält. In der Pascom wird es als verbunden angezeigt, auch die DECT Handsets werden als verbunden angezeigt.
Allerdings verlieren die Handsets die Verbindung zur Antenne.
Die Antenne antwortet auf Ping, aber das WebInterface ist nicht mehr erreichbar.
Die Antenne muss dann manuell neu gestartet werden.

Firmware der Antenne: 2.42
Firmware der SL800H Pro: 10.04

Bei den Yealinks haben wir
static.network.mtu_value = 1420
provisioniert und damit hat es funktioniert.

In der AutoProv Liste der Gigasets finde ich nichts von MTU.

Hat jemand von Euch eine Idee, ob man das provisionieren kann? Wie?

Grüße
Seb

Ich habe keine Lösung, kann mich aber einreihen. Ich habe einige Gigaset DECT-Setups. Alle bis auf eines funktionieren ohne Probleme. Die Probleme sind exact die gleichen wie die, die @seppos beschreibt. Nur ohne den ganzen die fancy Wirgurad-Tunnel etc. Das problematische Gigaset-DECT (N870 IP pro) läuft beim Kunden einfach hinter einer Unifi Dream Machine, wie bei anderen Kunden auch, bei denen es keine Probleme gibt. Erst heute musse ich die Basis per POE-Reset neu starten, da sie nicht mehr reagiert hat und keine Gespräche mehr möglich waren. Das war das dritte Mal seit Inbetriebnahme vor ca. drei Monaten. Eine interessante Gemeinsamkeit des Setups ist, dass das problematische Setup auch nur SL800H Handsets hat. Die anderen ohne Probleme haben andere Handsets bzw. nicht nur SL800H.

Ich wäre auch an einer Lösung interessiert und werde das Problem parallel beim Gigaset-Support einwerfen.

Interessant.
Ich hatte die Antenne, um die es geht, vorher zum Testen bei uns im Büro, da lief sie sauber für ein paar Wochen. Die DECT Handsets im Büro sind SL750H Pro ! !
Das wäre ja was. Danke für den Hinweis.
Dann kann der fancy Wireguard Tunnel ja bleiben :slight_smile:
Würde mich freuen, wenn du mich auf dem Laufenden hältst, was der Support Case bei Gigaset so ergibt.
Grüße
Seb

Guten Morgen,

Wir haben das gleiche Problem bei einigen Gigaset Dect Systemen. Die inaktivität erfolgt nach 30 Tagen auch mit Release 2.42, allerdings sind bei uns nicht nur SL800H. Aber der Fehler ist der gleiche.

Gruß Markus

Hallo allerseits,

same here: An einem Standort mit 2x N870 (2.42.0) und sieben R650H PRO Handsets haben wir nun schon das zweite Mal den beschriebenen Ausfall (Basisstationen sind noch pingbar, aber WebGUI antwortet nicht, und die Handsets können sich nicht verbinden). Aus- und Einschalten via PoE behebt das Problem.

Vielleicht interessant: An einem weiteren Standort (1x N870 und zwei R650H PRO, gleiche pascom.cloud) trat das Problem bislang nicht auf.

Beide Umgebungen sind unspektakulär hinter einer pfSense mit dem Internet und so mit einer pascom.cloud verbunden.

Hat jemand Kontakt zum Gigaset-Support? Ich erinnere mich, dass ich in einer anderen Sache als “Endkunde” dort mal abgewimmelt wurde und zu meinem Reseller gehen sollte. Das hab’ ich nicht gemacht, weil ich mir nicht vorstellen kann, dass dieser Gigaset-Knowhow hat. :smiley:

Liebe Grüße
Stephan

Es gab ja schon mal einen ähnlichen Thread hier im Forum. Die Lösung war dort ein Skript auf der Basis, dass jede Nach einen Reboot durchführt. Einbindung der Gigaset N870 - #20 by mahescho
Mag Zufall gewesen sein, bei unserem Kunden hatte sich das Thema nach dem Austausch der Switche erledigt. Ubiquity, D-Link, Netgear und mikrotik sind rausgeflogen und wurden durch HP ersetzt.

Hallo hinam,

danke für den Hinweis auf den anderen Thread; da sind interessante Infos enthalten.
Dieser “Sync”, von dem da die Rede ist: Meint das Kommunikation zwischen den Basisstationen? Das würde erklären, warum das Problem bei einem Setup mit nur einer Basis nicht auftritt.
Das mit den “speziellen Switches” halte ich - falls das von Gigaset kommt - für eine faule Ausrede. Bei uns hängen beide Basisstationen am selben Switch, und es ist kein ganz preiswerter (Juniper EX3300-24P).
Nächtliches Neustarten? Puh…

Liebe Grüße
Stephan

An meinen eigenen Post nicht mehr gedacht :slight_smile:

Hier ist es nur so, dass es eine einzelne Basis ist also im Gegensatz zu dem dem anderen Thread kann es hier keine Sync-Probleme geben. Zumindest bei meinem Problem-Setup ist das so.

Zum Thema Switche: Ich habe überall Ubiquity (auch als Gateway) und nur an der einen Stelle Probleme (gut, eigentlich an zwei, bei der zweiten aber nur sehr selten). Wenn ich solche Probleme habe dann mit Gigaset DECT, mit Yealink und Snom Tischtelefonen nie. Dann habe ich wieder Gigaset-Setups bei denen tritt das nie auf. Bei meinem eigenen mit 4 Basen zum Beispiel.

Ja, bei dem Sync geht es um die Kommunikation zwischen den Basen bei einem Mehrzellen-Setup.

Was mir bei dem Sync noch aufgefallen ist, dass es hier bei Sync über DECT häufig zu Problemen kommt, wenn andere Funkzellen in der Nähe sind oder wenn die Abstände zwischen den einzelnen Basen zu groß oder klein gewählt werden.
Bestes Beispiel, ein billig China Babyfon mit “super Reichweite” .

Auch wir haben wie die Kollegen ebenfalls das Problem mit den Gigaset Sendern. Gut, viele unserer Switche sind PoE und lassen sich über diese resetten (hat vorteile, wenn die Sender an schwer zugänglichen Stellen montiert sind.

Kann aber nicht die Lösung sein.

LG Markus

Ich diskutiere noch mit dem Gigaset-Support, der zunächst nach der devise verfährt: keep the customer bussy :slight_smile: Ausserdem weisst mit der Gigaset-Support auf folgendes hin:

Wir weisen darauf hin das die verwendete PASCOM Anlage von uns nicht getestet oder zertifiziert ist und daher inkompatibilitäten auftreten können.

Das hat uns der Gigaset Support auch so gesagt. Das sieht aber auf der Website von Gigaset ganz anders aus.
Interop Overview Germany - Gigaset PRO - Public Wiki - Confluence

1 Like

Danke @JonasPlaum, genau so ist das. Ich werde die Herr*innen umgehend an unsere Partnerschaft erinnern…

LG
Mathias

1 Like

Update: Mir wurde die eben frisch erschienene Firmware empfohlen und ich wurde gebeten das dann zu beobachten. Also: keep the customer bussy :slight_smile:

https://teamwork.gigaset.com/gigawiki/pages/viewpage.action?pageId=1281524878

Falls bei jemandem das Problem wieder auftritt - mir wurde noch folgende Frage gestellt, die ich nicht beantworten konnte:

Was zeigen die Mobilteile in dem Moment an wenn keine Gespräche mehr geführt werden können, wie ist das genaue Verhalten?

Unglaublich! In den Releasnotes steht SUOTA wird unterstütz. Endlich kein Update per USB mehr:

https://teamwork.gigaset.com/gigawiki/display/GPPPO/FAQ+Nx70+-+SUOTA

Hallo zusammen,

habe eben Rückmeldung von Gigaset. Die Probleme sind tatsächlich schon bekannt und sollten in der 2.44 behoben sein. Also bitte tatsächlich diese Firmware testen und Feedback geben.

Bitte an mich per PM die Ticket-Nummern bei Gigaset senden. Gigaset würde den Aussagen zu unserer Kompatibilität im Team gerne nachgehen.

LG
Mathias

Servus!

Habt Ihr evtl. Eco DECT aktiviert?

Grüßle

Christian

Ich habe die 2.44 am 20.01. installiert, heute hat sich das System wieder weg gehangen. In der Pascom waren die Endgeräte alle noch als Online zu sehen, die DECT-Sender auch im Netz per Ping erreichbar, aber der Aufruf der Konfigurationsoberfläche war nicht möglich. Genauso wenig abgehende / ankommende Telefonie. Erst ein Neustart der DECT-Station dem dem DECT-Manager hat dann für Abhilfe gesorgt.

Fazit: So richtig glücklich bin ich derzeit weder mit SNOM noch mit Gigaset. Funktionsfähige Firmware scheint ein echtes Problem zu sein über alle Hersteller hinweg. Im nächsten Leben werde ich Gärtner…

Hi ihr,

danke, dass ihr hier so am Ball bleibt!
Ich wollte kurz einwerfen, dass wir mit unserem Problem-Cluster zwar immer noch auf 2.42 sind, ich kürzlich widerwillig einen nächtlichen Reboot konfiguriert habe - und heute dennoch wieder in das beschriebene Problem hereingelaufen bin. :frowning:
Ich habe gerade eben mal diesen “Sync Slave”-Eintrag von “DECT” auf “LAN” gestellt und schau’, dass ich zeitnah das Firmware-Update installiere.

Liebe Grüße
Stephan

Sollten wir es aktivieren oder sollten wir es besser lassen ? :wink: