LCOS 10.34.0308-SU5 vs. 10.42.1036-RU9

Forum zu aktuellen Geräten der LANCOM Router/Gateway Serie

Moderator: Lancom-Systems Moderatoren

plumpsack
Beiträge: 569
Registriert: 15 Feb 2018, 20:23

LCOS 10.34.0308-SU5 vs. 10.42.1036-RU9

Beitrag von plumpsack »

Und ich "dachte" schon der Fehler wären in der 10.42.1036-RU9 gefixed ...

Code: Alles auswählen

AUTHPRIV 	Notice 	[VCM] SIP-Line xx-xy switched to status 'registered'
LOCAL0 	Error 	[VCM] SIP-Line xx-xy switched to status 'un-registered'
LOCAL0 	Error 	[VCM] SIP-Line xx-xy switched to status 'server order changed'
Die 10.42.1036-RU9 hat die VOIP-Konfiguration aus der 10.34.0308-SU5 auch nicht übernommen.

Man beharrt wohl auf die SRV-Konfiguration, auch wenn diese gar nicht existiert.

Die 10.34.0308-SU5 meldet sich, wie alle Versionen vorher (auch noch die LC-R883VAW-10.42.0284), einmal für 24h (Zwangstrennung) beim ISP an der Sip-Leitung an.

Wie deaktiviere ich denn nun diese "neue" SRV-Konfiguration - ich finde das nicht in den Dokumentationen von Lancom :(
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: LCOS 10.34.0308-SU5 vs. 10.42.1036-RU9

Beitrag von Dr.Einstein »

plumpsack hat geschrieben: 11 Dez 2022, 21:26 Wie deaktiviere ich denn nun diese "neue" SRV-Konfiguration
Es gibt keinen Schalter, um die alte DNS-SRV Konstellation aus der 10.34 wiederzubeleben, da diese fehlerhaft war. Die Implementierung ist, frage SRV-Record SIP (UDP) ab, wenn keine Antwort bzw. Domain ungültig, dann frage A-Record ab. Dein Provider (Ewetel, Osnatel) scheint DNS SRV zu wollen, sonst würde via A-Record abgefragt werden, wobei dort keine Prioritäten und Gewichtungen existieren. Laut Schnittstellenbeschreibung von Ewe ist dies auch korrekt.

https://business.ewe.de/dokumente/telek ... p_line.pdf
https://business.ewe.de/dokumente/telek ... _trunk.pdf

Gruß Dr.Einstein
plumpsack
Beiträge: 569
Registriert: 15 Feb 2018, 20:23

Re: LCOS 10.34.0308-SU5 vs. 10.42.1036-RU9

Beitrag von plumpsack »

Dr.Einstein hat geschrieben: 12 Dez 2022, 09:41 Dein Provider (Ewetel, Osnatel) scheint DNS SRV zu wollen, sonst würde via A-Record abgefragt werden, wobei dort keine Prioritäten und Gewichtungen existieren. Laut Schnittstellenbeschreibung von Ewe ist dies auch korrekt.

https://business.ewe.de/dokumente/telek ... p_line.pdf
https://business.ewe.de/dokumente/telek ... _trunk.pdf
Mach doch mal eine SRV-Abfrage auf sipreg3.voice.ewetel.de.

Da bekommst du einen CNAME (Alias) auf ...

Bei mir:
regs01.voice.ewetel.de
oder
regs05.voice.ewetel.de

so, und jetzt mach mal ein DIG auf regs01.voice.ewetel.de bzw. regs05.voice.ewetel.de.

Da kann ich doch gleich eine von den IP-Adressen einsetzen.

Mich wundert dann nicht, das ich einen Telefonanruf via 85.16.254.8 und nicht via regs01.voice.ewetel.de oder sipreg3.voice.ewetel.de bekomme !!!


BTW:
business.ewe.de liegt auf Amazon AWS - Amazon AWS ist grundsätzlich gesperrt - soviel zu einem "eigenständigen ISP" mit "eigenem Rechenzentrum"!
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: LCOS 10.34.0308-SU5 vs. 10.42.1036-RU9

Beitrag von Dr.Einstein »

Aber da sieht man doch genau dein Problem:

Code: Alles auswählen

_sip._udp.sipreg3.voice.ewetel.de       SRV service location:
          priority       = 10
          weight         = 50
          port           = 5060
          svr hostname   = regs02.voice.ewetel.de
_sip._udp.sipreg3.voice.ewetel.de       SRV service location:
          priority       = 10
          weight         = 50
          port           = 5060
          svr hostname   = regs01.voice.ewetel.de
Die Server haben beide die gleiche Priorität und das gleiche Gewicht. Prüfe mittels Abfrage vor und nach einem Logeintrag (changed server order), ob sich die Abfrage geändert hat. Wenn nicht, Ticket bei Lancom auf, Algorithmus / interne Sortierung falsch. Falls sich etwas geändert hat, alles korrekt vom LCOS. Ich wette, Lancom macht intern keine Sortierung anhand des DNS-Namens, sondern anhand der Reihenfolge der Abfrage.

Die RFC sagt, gleiche Prios und Weights sind erlaubt:

Code: Alles auswählen

This is because records that
   contain the same priority have no specified order.  The stateless
   proxy MUST define a deterministic order to the records in that case,
   using any algorithm at its disposal.  One suggestion is to
   alphabetize them, or, more generally, sort them by ASCII-compatible
   encoding.  To make processing easier for stateless proxies, it is
   RECOMMENDED that domain administrators make the weights of SRV
   records with equal priority different (for example, using weights of
   1000 and 1001 if two servers are equivalent, rather than assigning
   both a weight of 1000), and similarly for NAPTR records. 
Es ist empfohlen, dass Providerseitig nicht zu machen, aber es ist erlaubt.
plumpsack
Beiträge: 569
Registriert: 15 Feb 2018, 20:23

Re: LCOS 10.34.0308-SU5 vs. 10.42.1036-RU9

Beitrag von plumpsack »

Was hast du denn da eingegeben um eine Antwort wie

Code: Alles auswählen

_sip._udp.sipreg3.voice.ewetel.de
zu erhalten?

wenn ich

Code: Alles auswählen

nslookup -type=SRV sipreg3.voice.ewetel.de
oder

Code: Alles auswählen

dig SRV sipreg3.voice.ewetel.de
mache, dann erhalte ich nur cname antworten auf

Code: Alles auswählen

regs05.voice.ewetel.de
aber nie auf

Code: Alles auswählen

regs02.voice.ewetel.de
oder

Code: Alles auswählen

regs01.voice.ewetel.de
Noch auf

Code: Alles auswählen

_sip._udp.sipreg3.voice.ewetel.de
?

Ausserdem bin ich echt gerade am überlegen ob ich nicht alles wieder auf POTS umstellen sollte.

Diese ganze 24/7-online-Kacke ist echt nicht mehr mein Ding.

Ich will auch mal wieder ruhig schlafen können!
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: LCOS 10.34.0308-SU5 vs. 10.42.1036-RU9

Beitrag von Dr.Einstein »

plumpsack hat geschrieben: 17 Dez 2022, 18:44

Code: Alles auswählen

nslookup -type=SRV sipreg3.voice.ewetel.de
nslookup -q=SRV _sip._udp.sipreg3.voice.ewetel.de

Der Aufbau ist in einer RFC für Service Locations definiert. Zuerst kommt der Dienst (SIP, FTP, LDAP), danach das Protokoll (UDP, TCP)

Führe

Code: Alles auswählen

show vcm dns
vor und nach dem Logeintrag aus.
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: LCOS 10.34.0308-SU5 vs. 10.42.1036-RU9

Beitrag von Jirka »

Hallo Dr. Einstein,
Dr.Einstein hat geschrieben: 12 Dez 2022, 09:41 Es gibt keinen Schalter, um die alte DNS-SRV Konstellation aus der 10.34 wiederzubeleben, da diese fehlerhaft war.
was war/ist denn da fehlerhaft?

P. S.: Wie erkennt man eigentlich aus dem ersten Posting den Provider (Ewetel, Osnatel)?

Vielen Dank und viele Grüße
Jirka
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: LCOS 10.34.0308-SU5 vs. 10.42.1036-RU9

Beitrag von Dr.Einstein »

Hi Jirka,

schön, dass du noch lebst. Dachte, du wärst verloren gegangen.
Jirka hat geschrieben: 17 Dez 2022, 23:58 was war/ist denn da fehlerhaft?
In der 10.42 wurde einiges auseinandergenommen, leider nochmal on top in der 10.50, z.B.:

Code: Alles auswählen

Wenn sich während einer TTL-DNS-Periode die Prioritäten-Reihenfolge der
angebotenen DNS SRV-Records änderte, wurde dies im LANCOM Voice Call
Manager nicht bemerkt, sodass sich der LANCOM Router nach Ablauf der
TTL nicht mit der neuen höchstgewichteten Site verbunden hat. In der Folge
schlug eine SIP-Registrierung fehl.
Bin aber der Meinung, der Callmanager hält sich noch nicht wirklich an die RFC. In den vergangenen Monaten hatte ich zu viele Ausfälle, wo der Callmanager keinen Backupserver (Priorität) gewählt hat, oder einfach auf einen falschen Server aus dem Cache hängen geblieben ist.
Jirka hat geschrieben: 17 Dez 2022, 23:58 P. S.: Wie erkennt man eigentlich aus dem ersten Posting den Provider (Ewetel, Osnatel)?
Ach, der Threadersteller eröffnet seit Monaten jede 2. Woche einen neuen Post zu dem Thema. Aber ich glaube, nun hört er zum ersten Mal zu und merkt, dass man hier das Problem wirklich identifizieren könnte, wenn man mal ein wenig mitarbeitet. In einem seiner anderen vielen Posts stand EWE, Osnatel und noch ein 3. Provider von da oben, den ich schon wieder vergessen habe.

Wünsche dir erholsame Feiertage
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: LCOS 10.34.0308-SU5 vs. 10.42.1036-RU9

Beitrag von Jirka »

Hallo Dr. Einstein,
Dr.Einstein hat geschrieben: 18 Dez 2022, 10:49 schön, dass du noch lebst. Dachte, du wärst verloren gegangen.
:D So schnell noch nicht... Ich mache ja auch nach wie vor LANCOM, nur nicht mehr so viel im Forum. Aber es wirkt offenbar noch einiges nach, die Leute schreiben mir gerade zum Jahresabschluss mal eine E-Mail und bedanken sich dann auch für meine Beiträge im LANCOM-Forum, die sie gelesen hätten, wo ich auch so bei mir denke, hä? ich habe doch schon seit einem Jahr nichts mehr geschrieben und nicht mal reingeschaut. Aber das sind manchmal so grundsätzliche Sachen, dass wohl viel ältere Beiträge gelesen werden. Es stellt ja auch jeden Monat einer die gleiche Frage mit VLAN...
Backslash war vor wenigen Tagen so nett und hat mir unbürokratisch geholfen bei einer kleinen Frage, da hatte ich auch gedacht, hättest ja auch ins LANCOM-Forum schreiben können, aber da kommen dann immer tausend andere Sachen und wenn man erst mal eine gewisse Distanz hat und nicht ständig ins Forum schaut, dann kommt man so leicht auch nicht wieder hin. Wobei ich im Sommer schon mal einen fetten Beitrag hier reinsetzen wollte und auch zu 80 % fertig geschrieben hatte (ist hier irgendwo abgespeichert), aber irgendwie fehlte dann wiedereinmal die Zeit. Weiß nicht mehr, ob ich gerade Kirschen pflücken musste in meiner Freizeit oder was gerade so anlag, aber es verschwand dann wieder von der Bildfläche. Das Thema waren diese OS-Panics ohne Angabe des Grundes, wie ich sie hier seit vielen Jahren verfolge und mich frage, was sowas auslösen könnte. Jetzt hatte ich mal einen Fall, wo ich das sauber analysieren konnte, weil es alle 20 Minuten zu so einem OS-Panic kam, wo LANCOM immer sagt keine Ahnung. Ursache war ein Wackelkontakt im Ethernet, also in einer Buchse. Fakt war jedenfalls, dass dieser Wackelkontakt einem LANCOM an einem anderen Port des Switches ohne Wackelkontakt regelmäßig zum Absturz brachte. Also kaputte Ethernet-Pakete führten letztlich dazu. Und das kann ich alles eindeutig sagen, weil ich zuvor alles ausgetauscht habe, Gerät, Netzteil usw. Du weißt, ja, da mangelt es hier nicht. Das war ein echt wahnsinniger Erkenntnisgewinn. Man kann einen LANCOM also von außen softwaretechnisch manipulieren und er stürzt ab und LANCOM weiß nicht warum, aber ich habe es gesehen und alles mit einem Aufwand von mehreren Tagen mit mehreren Anreisen untersucht. Folgt dann nächstes Jahr noch der Bericht, wenn ich Zeit habe... Wo war ich stehen geblieben? Ach ja, bei Backslashs Hilfe. Eine meines Wissen undokumentierte Änderung von 10.34 auf 10.4x (extra noch mal die Release-Notes durchsucht und gelesen) führte bei mir immer wieder zu DNS-Problemen, weil Firewall-Regeln zugeschlagen hatten, die vorher nicht zuschlugen. Hatte ich fast 2 Jahre schon das "Phänomen" und dachte immer das wäre ein Bug. Da ich Bugs ja nicht mehr so häufig melde, und eher Workarounds baue, wenn möglich, kam ich nie dahinter, dass das Verhalten hier tatsächlich geändert wurde. Dass der LANCOM-eigene DNS-Server und Firewall-Regeln schon immer ein besonderes Thema war, wusste ich ja, aber so im Detail dann doch wieder nicht, also insbesondere nicht, dass "die Filter beim DNS greifen *bevor* eine Routingentscheidung getroffen wird - d. h. es werden nur die Adressen berücksichtigt, nicht aber sonstige Bedingungen wie "nur auf VPN" oder "nur wenn Verbindung nicht besteht"" (ab 10.4x).
Dr.Einstein hat geschrieben: 18 Dez 2022, 10:49 In der 10.42 wurde einiges auseinandergenommen, leider nochmal on top in der 10.50, z.B.:

Code: Alles auswählen

Wenn sich während einer TTL-DNS-Periode die Prioritäten-Reihenfolge der
angebotenen DNS SRV-Records änderte, wurde dies im LANCOM Voice Call
Manager nicht bemerkt, sodass sich der LANCOM Router nach Ablauf der
TTL nicht mit der neuen höchstgewichteten Site verbunden hat. In der Folge
schlug eine SIP-Registrierung fehl.
Ach diese Problematik meinst Du. Na ja, für mich stellte sich dieses Problem so dar: In der 10.34 merkte ich nichts von der Problematik, warum auch immer und mit der 10.50 kam es dann bei ganz bestimmten Kunden mit speziellen Konstellationen zu Problemen. Zum Beispiel Telekom-Kunde, R883+, 10.50-RU7 (vorher 10.34), zwei WAN-Leitungen und die DNS-Server lösten die SIP-SRV-Sachen unterschiedlich auf und so sprang der LANCOM ständig hin und her. Gesprächsabbrüche usw. Als ich nachher nicht mehr weiter wusste (also Workaround hatte ich dann nach einiger Zeit hinbekommen, war simpel, man brauchte nur die DNS-Server einschränken), habe ich Deinen Ex-Kollegen, der, der jetzt die Seiten gewechselt hat, mal um Hilfe gebeten. Hat er auch gemacht, Problem war am Ende irgendwie trotzdem noch, ich sollte wieder Traces machen, aber irgendwie war keine Zeit mehr, der Kunde wollte nicht mehr, nun hat er irgendwelche Cloud-Telefonie und keinen LANCOM mehr...
Dr.Einstein hat geschrieben: 18 Dez 2022, 10:49 Bin aber der Meinung, der Callmanager hält sich noch nicht wirklich an die RFC. In den vergangenen Monaten hatte ich zu viele Ausfälle, wo der Callmanager keinen Backupserver (Priorität) gewählt hat, oder einfach auf einen falschen Server aus dem Cache hängen geblieben ist.
Ok, das hört sich gut an, und ich dachte schon ich wäre mit eben geschildertem Problem alleine auf weiter Flur. Bei der Telekom konnte man ihm nicht mehr helfen, ich hatte immerhin den Workaround, so dass er wieder ungestört telefonieren konnte. Zur ganz genauen Problemanalyse kam es leider nicht mehr.
Dr.Einstein hat geschrieben: 18 Dez 2022, 10:49 Ach, der Threadersteller eröffnet seit Monaten jede 2. Woche einen neuen Post zu dem Thema. Aber ich glaube, nun hört er zum ersten Mal zu und merkt, dass man hier das Problem wirklich identifizieren könnte, wenn man mal ein wenig mitarbeitet. In einem seiner anderen vielen Posts stand EWE, Osnatel und noch ein 3. Provider von da oben, den ich schon wieder vergessen habe.
Ah, jetzt habe ich zumindest einen der anderen Threads gelesen gehabt. Der ist wirklich krass. Verstehe nicht, wie man als offensichtlicher Unternehmer so komisch sein kann und sich auch überhaupt nicht helfen lässt. Ich meine ihr wart doch da wirklich hilfsbereit. Unternehmer lerne ich immer anders kennen, das sind in der Regel gescheite Menschen, die sich sogar gerne helfen lassen.
Dr.Einstein hat geschrieben: 18 Dez 2022, 10:49 Wünsche dir erholsame Feiertage
Danke, ebenfalls.

Vielen Dank und viele Grüße
Jirka
plumpsack
Beiträge: 569
Registriert: 15 Feb 2018, 20:23

Re: LCOS 10.34.0308-SU5 vs. 10.42.1036-RU9

Beitrag von plumpsack »

Dr.Einstein hat geschrieben: 17 Dez 2022, 19:00
nslookup -q=SRV _sip._udp.sipreg3.voice.ewetel.de
nochmal , wie hast du den "_sip._udp.sipreg3.voice.ewetel.de" ermittelt?

Und das mit dem POTS-Anschluss war kein Witz!
"Die Telekom wird auch künftig reine Sprachanschlüsse anbieten"
Auch wenn die Deutsche Telekom uns diese Anschlüsse reihenweise gekündigt hatte, war denen wohl zu teuer.

Call Start auf Basis MSAN POTS Technologie
Call Start Standard
Call Start Universal
Früher hatten die Router von Lancom noch ein "besonderes Feature" zum Thema Internet - bei den 172x, z.B., war das 0/I.

Kennt heute keiner mehr ... weil 24/7/365 ja heute ein "must have" ist.

Und wenn es dann wieder einmal knallt - huch, ... wie konnte ...
:L)
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: LCOS 10.34.0308-SU5 vs. 10.42.1036-RU9

Beitrag von Dr.Einstein »

Wie bereits beschrieben, aber ich bau es dir noch einmal visuell auf.

_<dienst>._<protokoll>.<domainname>

Gemäß Schnittstellenbeschreibung sipreg3.voice.ewetel.de als Domainnamen für den Registrar,UDP als Protokoll https://business.ewe.de/dokumente/telek ... p_line.pdf und der Dienst SIP sollte denke ich klar sein, wir wollen ja kein LDAP.

Also ergibt sich:

_sip._udp.sipreg3.voice.ewetel.de

Gruß Dr.Einstein
5624
Beiträge: 865
Registriert: 14 Mär 2012, 12:36

Re: LCOS 10.34.0308-SU5 vs. 10.42.1036-RU9

Beitrag von 5624 »

Kennt heute keiner mehr ... weil 24/7/365 ja heute ein "must have" ist.
Falsch.

Wenn du bei einem DSL-Anschluss den Router/das Modem häufiger mal abschaltest oder von der Telefonleitung trennst, wird das in der heutigen Zeit als mögliche Störung erkannt und veranlasst ASSIA dazu, die Sync-Rate herunterzuregeln.
Also je weiter entfernt du von 24/7/365 entfernt bist, umso langsamer wird dein Anschluss.

ASSIA kennt auch nur einen Weg und zwar langsamer.

Wenn du einen Anschluss hast, der nicht über einen MSAN der Telekom geschaltet wird, kann es durchaus auch sein, dass kein ASSIA zum Einsatz kommt, da aber der größte Teil der KVz bei der Umstellung auf Vectoring durch die Telekom betrieben werden, egal wie dein Provider heißt, ist es höchstwahrscheinlich, dass es so kommen wird.
LCS NC/WLAN
Benutzeravatar
hyperjojo
Beiträge: 801
Registriert: 26 Jul 2009, 02:26

Re: LCOS 10.34.0308-SU5 vs. 10.42.1036-RU9

Beitrag von hyperjojo »

hi,
5624 hat geschrieben: 19 Dez 2022, 23:33ASSIA kennt auch nur einen Weg und zwar langsamer.
meines Wissens nach regelt Assia auch nach oben, wenn ein Anschluss zuvor runter geregelt wurde und seit langer Zeit wieder störungsfrei läuft.

Gruß hyperjojo
plumpsack
Beiträge: 569
Registriert: 15 Feb 2018, 20:23

Re: LCOS 10.34.0308-SU5 vs. 10.42.1036-RU9

Beitrag von plumpsack »

Dr.Einstein hat geschrieben: 19 Dez 2022, 23:25 Wie bereits beschrieben, aber ich bau es dir noch einmal visuell auf.

_<dienst>._<protokoll>.<domainname>
Ok, da war ich evtl. zu blond/blöd.

Ich dachte immer mit einer "SRV-Abfrage" bekommt man auch die Dienste geliefert.
Das man sich das selber "zusammenbauen" muss war mir nicht bekannt.

Auch bin ich kein Business-Kunde und wie bereits gesagt AWS (Amazon) ist gesperrt.
plumpsack
Beiträge: 569
Registriert: 15 Feb 2018, 20:23

Re: LCOS 10.34.0308-SU5 vs. 10.42.1036-RU9

Beitrag von plumpsack »

Bitte löschen - "quote" war falsch!
Zuletzt geändert von plumpsack am 21 Dez 2022, 19:44, insgesamt 1-mal geändert.
Antworten