LCOS 10.34.0308-SU5 vs. 10.42.1036-RU9

[plumpsack]

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.

Deine Aussage ist einfach falsch!

Selbst wenn man einen Timer im Router setzt (Neustart) wird die Verbindung nicht langsamer.

Mir ging es eigentlich darum aufzuzeigen, das "Internet-on-Demand"*, also wenn man es wirklich benötigt, immer noch funktioniert.

* Telefonleitung läuft parallel!

[hyperjojo]

hi,

Deine Aussage ist einfach falsch!

woran machst du deine Aussage denn fest? Gibt es hierzu Quellen?

Ich würde die These aufstellen, dass Assia eingreift, wenn der Sync häufiger ausfällt. Das erkennt es als Störung. Und ein Neustart bewirkt genau das. Ob es einen Unterschied macht, wenn du den Router tagelang ausgeschaltet hast und nur bei Bedarf einschaltest, weiß ich nicht. Meine These kann ich auch nicht mit Quellen belegen, das ist eher Berufserfahrung.

Ob Assia eingreift ist oftmals ersichtlich, wenn die Verbindung im Wartungsfenster Nachts (glaube zwischen 2 und 5 Uhr) kurz getrennt wird.

Lasst bitte sachlich bleiben und Dinge nur dann behaupten, wenn sie belegbar sind. Ansonsten kann man es ja als Vermutung, These, Glauben o.ä. deklarieren.

Gruß hyperjojo

[Dr.Einstein]

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

Der Aufbau ist direkt am Anfang von https://www.ietf.org/rfc/rfc2782.txt beschrieben.

Soweit mir bekannt ist, gibt es keinen Befehl zum Abfragen aller verfügbaren SRV-Resource Records. Und selbst wenn, eine Software würde ja nie alle Records abfragen nur um dann sich doch z.B. SIP rauszusuchen. Die Software weiß ja im Vorfeld, nach was sie für einen Dienst sucht, sprich das Zusammensetzen macht schon ansatzweise Sinn.

Hast du denn mal

Code: Alles auswählen

show vcm dns

vor und nach einer solchen Logmeldung ausgeführt über das LCOS damit wir dein Problem endgültig aus der Welt schaffen können?

[Dr.Einstein]

Ich würde die These aufstellen, dass Assia eingreift, wenn der Sync häufiger ausfällt. Das erkennt es als Störung. Und ein Neustart bewirkt genau das. Ob es einen Unterschied macht, wenn du den Router tagelang ausgeschaltet hast und nur bei Bedarf einschaltest, weiß ich nicht. Meine These kann ich auch nicht mit Quellen belegen, das ist eher Berufserfahrung.

Mir wäre nicht bekannt, dass EWE Assia einsetzt.

[hyperjojo]

hi,

Mir wäre nicht bekannt, dass EWE Assia einsetzt.

Das weiß ich nicht. Aber wenn die Leitung von der Telekom angemietet ist (wie hier von 5624 geschrieben), dann könnte es ein. Ist aber in dem Fall bisher nicht bekannt...

Gruß hyperjojo

[plumpsack]

woran machst du deine Aussage denn fest? Gibt es hierzu Quellen?

An meinen Reboots wenn hier zuviele "Darmausgang-IP-Adressen" herumpopeln!

Meistens IP-Adressen aus Ost-Europa, Asien oder Süd-Amerika!

Leitung ist "immer" nach einem Reboot stabil, also immer über 90% von einer z.B. 100mbit-Leitung.

[plumpsack]

Hast du denn mal

Code: Alles auswählen

show vcm dns

vor und nach einer solchen Logmeldung ausgeführt über das LCOS damit wir dein Problem endgültig aus der Welt schaffen können?

Sorry - Nein, hab ich noch nicht ...

Kommt noch ... sorry for delay ..

[plumpsack]

An meinen Reboots wenn hier zuviele "Darmausgang-IP-Adressen" herumpopeln!

"Darmausgang-IP-Adressen" hatte ich nicht geschrieben.

ich hatte

"**********-IP-Adressen" geschrieben !!!

Wer ändert hier in meine Texte?

[plumpsack]

Hast du denn mal

Code: Alles auswählen

show vcm dns

vor und nach einer solchen Logmeldung ausgeführt über das LCOS damit wir dein Problem endgültig aus der Welt schaffen können?

Also vor, und das kommt nur einmal in der LCOS 10.34.0308-SU5 vor und danach gibt es kein "nach".

Die SIP-Leitung bleibt stabil.

LCOS 10.34.0308-SU5:

Code: Alles auswählen

show vcm dns

Code: Alles auswählen

DNS Cache:
1. Cache Entry:
    SRV string:  _sip._udp.sipreg3.voice.ewetel.de
    Routing Tag: 0
    Use Count:   1 SIP registrar line depends on this cache entry

    Pending DNS queries:
        None.

    Cached SRV records for this key (sorted by preference):
          Priority |     Weight |        TTL |  Port | Target
                10 |         50 |        674 |  5060 | regs02.voice.ewetel.de
                10 |         50 |        674 |  5060 | regs01.voice.ewetel.de

    No CNAME records cached for this key.

    Cached address records for this key (sorted by DNS name, then IPv6 first):
        Address                                 |        TTL | DNS name
        85.16.254.28                            |        674 | regs01.voice.ewetel.de
        85.16.254.8                             |        674 | regs01.voice.ewetel.de
        85.16.254.17                            |        674 | regs01.voice.ewetel.de
        85.16.254.20                            |        674 | regs01.voice.ewetel.de
        85.16.254.60                            |       1640 | regs02.voice.ewetel.de
        85.16.254.52                            |       1640 | regs02.voice.ewetel.de
        85.16.254.40                            |       1640 | regs02.voice.ewetel.de
        85.16.254.49                            |       1640 | regs02.voice.ewetel.de

mache ich am PC:

A) dig SRV sipreg3.voice.ewetel.de

bekomme ich:

Code: Alles auswählen

sipreg3.voice.ewetel.de. 198	IN	CNAME	regs05.voice.ewetel.de.

B) nslookup -type=SRV sipreg3.voice.ewetel.de

bekomme ich:

Code: Alles auswählen

sipreg3.voice.ewetel.de	canonical name = regs05.voice.ewetel.de

Aber als Antwort nie etwas mit regs01.voice.ewetel.de bzw. regs02.voice.ewetel.de

Auch "SRV string: _sip._udp.sipreg3.voice.ewetel.de", also "_sip._udp.sipreg3.voice.ewetel.de" bekomme ich nicht als Antwort.

Da das alles "früher" also vor 10.42 bzw. der LC-R883VAW-10.42.0284 für meinen alten R883VAW, wunderbar funktionierte bekomme ich so langsam kalte Füße, da die 10.34.0308-SU5 ja jetzt EOL ist.

[alf29]

ich hatte

"**********-IP-Adressen" geschrieben !!!

Wer ändert hier in meine Texte?

Eben. Lass das. Und nimm Deine Pillen.

[Dr.Einstein]

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

Folgendes aktuelles Ergebnis bei Abfrage:

Code: Alles auswählen

_sip._udp.sipreg3.voice.ewetel.de       SRV service location:
          priority       = 10
          weight         = 50
          port           = 5060
          svr hostname   = regs01.voice.ewetel.de
_sip._udp.sipreg3.voice.ewetel.de       SRV service location:
          priority       = 10
          weight         = 50
          port           = 5060
          svr hostname   = regs02.voice.ewetel.de

Die Rückgabe der Reihenfolge dreht sich hin und wieder. Das LCOS scheint hier ab 10.42? die Reihenfolge nicht mehr alphanummerisch festzuschreiben bei gleicher Prio/Gewicht sondern wertet dann die Reihenfolge der Rückgabewerte aus, zu erkennen an deiner Ausgabe:

Code: Alles auswählen

    Cached SRV records for this key (sorted by preference):
          Priority |     Weight |        TTL |  Port | Target
                10 |         50 |        674 |  5060 | regs02.voice.ewetel.de
                10 |         50 |        674 |  5060 | regs01.voice.ewetel.de

Oder das LCOS hat jetzt erstmalig überhaupt einen Algorithmus implementiert bekommen zur Auswertung der Reihenfolge nach erfolgter Registrierung.
Nicht schön von EWE, der Fehler liegt aber meiner Meinung nach im LCOS. Du solltest ein Ticket beim Hersteller Lancom eröffnen.

[plumpsack]

Eben. Lass das. Und nimm Deine Pillen.

@alf29

Zensier mal ruhig weiter, wie gewohnt ... du kennst das ja so von früher ...

Wird aber nichts daran ändern, das hier ein deutsches Unternehmen/Behörde/Krankenhaus/etc., nach dem anderen von diesen "hcolhcsrA-IP-Adressen" gehäckt wird!

Ja, ich nehme jetzt brav meine Pillen und die bringen mich jetzt nur noch zum Lachen!

[plumpsack]

Nicht schön von EWE, der Fehler liegt aber meiner Meinung nach im LCOS.

Das sag ich doch schon die ganze Zeit!

[Dr.Einstein]

Da du eh kein Ticket aufmachen wirst: Kannst du eigentlich auch den externen Registrar nutzen obwohl du dich im EWEtel Netz befindest?

Der Ext SIP-Line und der SIP-Trunk SRV Eintrag sieht Lancom-kompatibel aus:

Code: Alles auswählen

_sip._udp.ext-sipreg3.voice.ewetel.de   SRV service location:
          priority       = 10
          weight         = 50
          port           = 5060
          svr hostname   = sip2-ext-sipreg3.voice.ewetel.de
_sip._udp.ext-sipreg3.voice.ewetel.de   SRV service location:
          priority       = 20
          weight         = 50
          port           = 5060
          svr hostname   = sip1-ext-sipreg3.voice.ewetel.de

Code: Alles auswählen

_sip._udp.siptrunk3.voice.ewetel.de     SRV service location:
          priority       = 20
          weight         = 50
          port           = 5060
          svr hostname   = sip2gk.voice.ewetel.de
_sip._udp.siptrunk3.voice.ewetel.de     SRV service location:
          priority       = 10
          weight         = 50
          port           = 5060
          svr hostname   = sip1gk.voice.ewetel.de

Ich vermute ja fast, dass Ewe das gar nicht bemerkt hat und es sich um ein Versehen handelt.

[plumpsack]

... nimm Deine Pillen.

@alf29

nur für dich:

https://konbriefing.com/de-topics/hacke ... hland.html

Ist schon "fast" ein Live-Ticker

Und dass sind nur die offiziell gemeldeten Hackings.

Ansonsten guckst du hier:

https://noc.rub.de/cgi-bin/showextblocked

Die prangern die "Arschl*ch"- IP-Adressen wenigsten an