wir betreiben eine Pascom ONE mit acht SNOM M900 Basisstationen mit SNOM M65-Mobilteilen.
Firmware ist auf dem aktuellen Stand (M900 auf 670.202 , M65 auf 650.2)
Wir haben seit Anfang an das Problem, dass die Mobilteile ihre SIP-Registrierung nach mal ein paar Tagen, mal ein paar Wochen verlieren. Fehler im Display: SIP-Registrierung fehlgeschlagen. Auf der Basisstation unter Status wechseln die Status aller auf der Basisstation angemeldeten Mobilteile von SIP Registering auf SIP Error.
Nicht alle, sondern immer nur an einigen Basisstationen. Wenn das auftritt betrifft das mind. 2 Basisstationen, immer mal andere. Ich erkenne kein Muster. Wechselt man den Empfangsbereich registrieren sich die M65 wieder.
Ein Reboot der betroffenen Basisstation(en) behebt das Problem sofort.
Teilweise ist auch unsere “Hauptbasis” betroffen, die direkt am Core-Switch hängt. Die anderen M900 hängen in Produktionshallen verteilt. Max. 2 Switches zwischen den Stationen, LAN-Sync, Jitter AVG max. 350 ns.
Ich finde hierzu leider wenig passendes im Forum; hat jemand Tipps, wie man das ganze eingrenzen kann?
Um den Druck hier ein wenig vom Kessel zu nehmen würde ich gern die Basistationen regelmäßig erstmal automatisiert neu starten. Ich hab hier im Forum von einem “Reboot-Script” für die M900 gelesen, das Script selbst aber nie gesehen. Kann das evtl. jemand zur Verfügung stellen?
Hi das Problem haben wir auch festgestellt, nach etwas Troubleshooting mit Snom gab es dann folgende Antwort:
“wir haben in der Vergangenheit ähnliche Probleme in Kombination mit Pascom!
Diese Probleme sollten in der Version 530B7 gelöst sein.”
Tatsächlich scheint in dieser Firmware etwas anders zu sein und es funktioniert wieder ohne Probleme.
Alle aktuelleren Firmwarestände scheinen das Problem mit sich zu bringen, allerdings wie es scheint nur in Mehrzellen mit 2+ Basen.
Korrekt, in einem Firmwarerelease (meine 650.2) stand auch:
handover abort, resources exceeded fix (der Fehler kam in unserer Firmware vorm Update auch)
Wir sind jetzt auf 670.202, da isses immer noch / wieder.
Firewall ist pfSense 2.7
Kein SIP ALG.
Die DECT-Sender hängen in einem eigenen VLAN, das auf “Durchzug” ins Internet steht. Also 1x NAT und fertig.
Die letzte Durchzug-Regel wird aber nicht mal gegriffen, vorher greifen alle gemäß Pascom-Port-Howto konfigurierten Rules. Nochmal gecheckt, da wird nichts geblockt (TCP / UDP / ICMP).
Im Bereich “Server” auf den M900 gibts eine Möglichkeit “NAT Support” zu aktivieren, das ist aktiv.
Unter “Netzwerk” auf den M900 gibt es die Option “Autom. Verbindungsprüfung”, die ist aktiv.
Reregistrierungszeit steht auf 600s.
Diese Werte haben wir nie angepasst, sind also entweder SNOM-Default oder PASCOM-Provisioning-Defaults.
Globale State Timouts in der pfSense sind auf default:
UDP First - 60s
UDP Single - 30s
UDP Multiple - 60s
Bei den Yealink T46 nie ein Problem mit den Settings o.g. globaler Werte.
Hm, da das bei euch wohl nur sehr selten / alle paar Tage/Wochen auftritt, ist das schwer zu finden.
Man könnte dann, wenn es auftritt mal nen Netzwerkmitschnitt machen und/oder im Menu der Basis (wo dann auch Handteile „aufgebucht“ sein müssen) links unten im SiP Log nachschauen, ob die überhaupt noch Re-Registervorgänge versucht.
Dann liegt’s nicht an der Basis, sondern doch „davor“.
Hallo in die Runde, dann hänge ich mal mit dran. Snom DECT 5 Zellen, und sporadisch verlieren die Telefone die SIP Registrierung.
Ich mache dann bei Snom auch noch ein Ticket auf. Sonst wird das ja zur Endlosschleife wie bei Gigaset.
ich habe das Problem mit der SIP-Registrierung M900 und M65 ebenfalls an einer Pascom.
die 3 Sender sind in einer “Zweigstelle”. Alle Sender sind auf 670.202 und die Telefone ebenfalls auf der aktuellsten Firmware.
Die Registrierungsabbrüchesind in unterschiedlichen Zeitabständen. Teilweise wenige Tage, zuletzt fast 2 Monate. Ich habe bereits mit SNOM an dem Thema gearbeitet. Um einen winzigen Traffic zwischen den Basen zu provozieren, habe ich mit dem SNOM-Kollegen einen 2. Server (Dummy) eingerichtet. Dieser kann beliebiges beinhalten, selbst Test in allen benötigten Feldern reicht.
Als weiteres hab wurde von peer-to-peer umgestellt mit dem Master als primäre IP-Adresse.
Wir haben die komplette Kette schon neu aufgebaut. Was allerdings auffällig war, dass immer die gleiche Basis der Auslöser war. Diese Basis wird in den nächsten Wochen ausgetauscht und die Kette neu eingerichtet.
Ich gebe Rückmeldung, wenn dieser Sender getauscht ist. Hoffentlich gibt es dann mal ein Ende. Ich kann die Dame schon mit Namen ansprechen und Sie meint nur: “… Sie können sich sicher schon denken, warum ich anrufe…”
völlig richtig. Heut morgen war es dann auch mal wieder so weit… sämtliche Mobilgeräte an 3 von 8 Basistationen können sich nicht mehr registrieren.
Hier der Auszug ausm SIP-Log vorm Reboot. Die Meldungen sehen alle gleich aus (nat. auĂźer SIP FROM, klar)
Instanz etc. hier mit XXXX unkenntlich gemacht.
Keine ERROR oder FAILURE oder sowas im SIP Log. AusschlieĂźlich wie hier unten.
Sent to tls:18.196.228.33:5061 at 08/12/2023 08:34:54 (605 bytes)
Minutes Pkt/Sec1153, Data/Sec#427309 ]
loc6 .Info 2023-12-08T08:40:15.540Z 76 [ SYNCMGR: Rcv Packets#325143, Data#283317160 Total Pkt/Sec#0000, Data/Sec#0825, Last Minutes Pkt/Sec5416, Data/Sec#4720853 ]
loc2 .Info 2023-12-08T08:40:17.460Z 47 [ Memory Allocated: Used#7536544 Free#7143464 AllocSize#1000000 Ra#c01cc037 ]
loc6 .Warn 2023-12-08T08:40:19.600Z 76 [ SYNCMGR: Dynamic Extension SIP Data Not updated, Owned by this base Idx#0013 from FpIdx016 (2023-12-08 07:40:16):(2023-12-08 07:40:15) ]
loc3 .Info 2023-12-08T08:40:22.460Z 53 [ Registration of user zY07XXXXXX3571 (ExtIdx#0015) on domain XXXX failed ]
loc3 .Info 2023-12-08T08:40:22.460Z 53 [ Registration of user KnXXXXXXXXX579 (ExtIdx#0003) on domain XXXX failed ] loc3 .Info 2023-12-08T08:40:28.700Z 53 [ Registration of user KqXXXXXXXXXX574 (ExtIdx#0013) on domain XXXX failed ]
loc2 .Info 2023-12-08T08:40:33.260Z 47 [ Memory Allocated: Used#7536012 Free#7143996 AllocSize#1000000 Ra#c01cc037 ]
loc3 .Info 2023-12-08T08:40:33.550Z 53 [ Registration of user KqXXXXXXXXXX574 (ExtIdx#0003) on domain XXXX failed ]
loc3 .Info 2023-12-08T08:40:33.780Z 53 [ Registration of user zYXXXXXXXXXX571 (ExtIdx#0015) on domain XXXX failed ]
loc2 .Info 2023-12-08T08:40:38.850Z 47 [ Memory Allocated: Used#7412120 Free#7267888 AllocSize#60000 Ra#c024fe39 ]
Ich sehe hier nix, was mir helfen könnte das einzugrenzen, gern Hilfestellung. Für Netzwerkmitschnitt hab ich gerade nix vorbereitet, werd ich mal angehen.
Naja, nicht ganz das, was ich wollte (da zu kurz) -aber immerhin.
Jedenfalls scheint (!) es NICHT an der Snom Basis zu liegen.
Denn immerhin versucht die sich ja noch zu registrieren.
Hier wären nun weitere Daten interessant.
Vergleich diese Re-Registers mit dem letzten, funktionierenden
Check des DNS Requests und Response mit dem noch funktionierenden
Und ganz einfach (ohne Wireshark zu bemĂĽhen):
kommt auf dieses Re-Register ĂĽberhaupt was zurĂĽck? Also von der Pascom Instanz.
Auch wäre ein Check eurer Firewall hier sicher hilfreich. Stichworte: SIP ALG (aus!), TCP TimeOut (ist doch verschlüsselt?, sonst UDP TimeOut/Aging kontrollieren). Mal hochstellen.
Etc.
Wie gesagt, der Schnipsel ist arg zu wenig.
Immerhin aber scheint es nicht Ursache der Basis zu sein!
Gemeint damit im Bereich “Server” die sog. “Automatische Verbindungsprüfung”. Die ist via default Pascom Template deaktiviert.
Also mal aktiviert und im Pascom-Template im server-Bereich die Ă„nderung auch aktiviert, damits persistent drin bleibt.
Seitdem sehe ich auch kontinuierlich offene Verbindungen in meiner pfSense von jeder M900-Basis zur IP unserer pascom.
Seit dem 22.1. und nur mit der Ă„nderung aktuell Ruhe; alle Basen halten ihre Verbindung, kein SIP-Fehler.
Ich berichte weiter, danke an dieser Stelle nochmal fĂĽr alle Hinweise!
Da hänge ich mich auch mal dran.
Offensichtlich ist der Fehler bei Snom bekannt.
Nachfolgende Antwort habe ich erhalten
Guten Tag,
das Problem wurde seit einiger Zeit an unsere Entwicklung weiter geleitet, um so schnell wie möglich nach einer Lösung zu suchen!
Ich hoffe, dass wir bald Ihnen eine Firmware zur Verfügung stellen, die das Problem löst! Sobald eine Lösung implementiert wird, werde ich Sie umgehend informieren!
bezüglich der Firmware kann ich sagen, dass mir der Pascom Support bereits eine Firmware genannt hat, mit der bei allen Kunden das Problem nun verschwunden ist. Gelistet wird diese Firmware komischerweise nicht auf der SNOM-Seite, aber per M900 kann die Firmwareversion ja einfach eingetragen werden. Testet das gerne mal mit dieser älteren Firmware aus. Bei mir hat es geholfen.
So, finale Rückmeldung; seit dem Setzen des NAT Keepalive (Pascomtest schriebs im Nov. 23 schon) ist - RUHE. Es läuft mit der 670.202 M900-Firmware, die aktuelle hab ich noch gar nicht drauf.
Bei uns lags dann wohl an der Kombination aus nicht vorhandenen Keepalives und dass die Firewall dann dichtgemacht hat.
