Beiträge von Elemir

Zitat von pufferueberlauf

Laut EU Verordnung 2015/2120 ist egal was Du mit Deunem Internetzugang machst, ein ISP kann Dir kaum verbieten Server zu betreiben

Jein, die Unterscheidung per AGB zwischen privat und gewerblich ist schon zulässig, einen Privatkundenzugang gewerblich zu nutzen kann (wird) daher nach AGB tatsächlich unzulässig sein. Nur unter die Definition von "gewerblich" fällt Homeoffice sicher nicht.

Selbst ein Freiberufler ist nicht gewerblich tätig. Pech für die Provider, wenn sie den Begriff "gewerblich" nutzen, aber nicht näher definiert haben.

Manche (viele?) Provider verbieten in den AGB den Betrieb eines Servers. Das Verbot dürfte, solange er keinen gewerblichen Zwecken dient, wg. genannter Regelung nicht haltbar sein, zumal "Server" nicht weiter definiert ist. Technisch ist schon der Remote-Zugang zu einer Fritzbox ein Server, ebenso wie der Port für TR-069.

Zitat von pufferueberlauf

Gut moeglich, dass auch hier erst ein Gericht die BNetzA zum Jagen tragen muss, waere nicht das erste mal dass die BNetzA sehr vorsichtig agiert (und sehr ISP-freundlich)...

Wieso die BNetzA? Wenn ich betroffen und klagebereit wäre, dann doch gleich gegen den Provider. Mit einer gewonnenen Klage gegen die BNetzA hätte man nicht viel gewonnen, die gibt einem keine Zugangsdaten.

Zitat von frank_m

Außer der Kunde haut den Provider übers Ohr, z.B. bei gewerblich genutzten Anschlüssen, dann ist immer alles erlaubt.

Homeoffice oder mobiles Arbeiten ist keine gewerbliche Nutzung, einen Server zu betreiben auch nur, wenn er nicht rein privaten Zwecken dient.

Zitat von frank_m

Wohl kaum. Mit seinem Equipment kommst du an das VLAN, in dem sich die VoIP Server befinden, nicht heran. Du hast dann zwar Zugangsdaten, aber keinen Server, auf dem du dich anmelden kannst.

Der Zugang muss auf "kundeneigener Router" umgestellt werden. In dem Moment werden Zugangsdaten für öffentlich verfügbare Server rausgegeben, und dann kann man alles machen, völlig unabhängig von irgendwelchen VLANs.

Wie der Provider das regelt bleibt dem Provider überlassen. Ich frage mich nur, warum sich ein Provider den Extraaufwand antut, verschiedene Zugangswege zu schaffen.

Zitat von pufferueberlauf

Mmmh, interessant wie das die "grossen Jungs" regeln... Fuer den bescheidenen Bedarf meines Heimnetzes habe ich einen Uputronics GPS PiHat (plus Antenne am Fenster) mit einem Raspberry Pi4 nach dieser Anleitung kombiniert. Und dann noch ausgenutzt, dass der Pi4 PTP mit Software Clock kann... (der Pi5 can Hardware-PTP auf seinem Ethernet-Port aber fuer meine Heoímanwendung ist die Pi4 Loesung schon jenseits von Gut und Boese, da will ich kein zusaetzliches Geld ausgeben fuer einen Pi5 und dessen groesseren Stromverbrauch).

Privat zuhause habe genau das mit einem RPi3 (aus denselben Gründen wie Du keinen 5er willst) am laufen, aber nur mit NTP und nicht PTP. Funktioniert die Software-PTP-Lösung auf einen RPi zuverlässig? Würde ich nämlich ganz gerne versuchen, aber zumindest bei meiner letzten Google-Suche danach mit ziemlich viel Aufwand verbunden.

Den leider geht die Genauigkeit von ca 2-3 Mikrosekunden auf dem Weg über NTP verloren:

Server:

ntpq> pe
    remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
oPPS(0)          .PPS.            0 l   11   16  377    0.000    0.000   0.002
*SHM(0)          .GPS.           12 l   14   16  377    0.000   -3.861   1.003

Client:

ntpq> pe
    remote           refid      st t when poll reach   delay   offset   jitter
===============================================================================
RAW_DCF77(0)    .DCFa.           0 l  10h   64    0   0.0000  -2.5838   0.0000
LOCAL(0)        .LOCL.          10 l  10d   64    0   0.0000   0.0000   0.0000
*xxxxxxxxxxxxxx .PPS.            1 u   23   64  377   0.6545  -2.0400   0.0326

(Ja, eine DCF hängt am Client noch dran, aber die macht schon länger Stress)

Edit: die verd.... Formatierung mit den Codeblöcken ...

Zitat von Phino

Immer gut, den Techniker freundlich mit einer Tasse Kaffee zu begrüßen.

Der Tipp ist zwar gut, ist aber bei uns an zwei Dingen gescheitert: erstens kam der völlig unangekündigt, da war kein Kaffee fertig und er hatte keine Zeit. "Habe heute noch so viel zu tun". Deswegen wollte der auch nicht bohren und war schon froh, dass ich dem Verzicht auf den Mauerdurchbruch zugestimmt habe. "Spart viel Zeit und Arbeit".

Zitat von Phino

Je nachdem was der Techniker vor Ort so hat und baut, kann auch gespleißt werden. War bei meiner Mutter so. Eine Leitung aus dem Keller bis in Treppenhaus und die andere aus der Wohnung bis Treppenhaus und dort verbunden. Damit gab es keine Stecker und sie haben die GF zusätzlich durch das 60 Jahre alte Leerrohr der Telefonleitung geschoben.
Es geht vieles, hängt viel vom Geschick/Willen des Technikers ab. An der Stelle hat er wohl lieber ein wenig herumgefummelt, als ein Loch vom Treppenhaus zu bohren.

Kann ich hier (für einen anderen Anbieter natürlich) bestätigen. Vorgesehen war ein Wanddurchbruch, weil der bestehende nicht groß genug für das Glasfaserkabel mit Stecker war und der noch verfügbare Platz auch nicht der vorgegebenen Mindestgröße entsprach.

Da hat der Techniker dann doch lieber ewig mit einen Zugdraht verbracht, um die Faser in den bestehenden Durchbruch reinzufummeln ("das reicht noch, das bekomme ich da durch") und auf der anderen Seite dann zu spleißen, als einen neuen Durchbruch zu bohren, nur um mit Stecker durchzukommen.

War mir natürlich lieber so, aber bei der Hausbegehung noch ein absolutes "geht nicht".

Zitat von HubeBube

Wobei dies im Falle Meinberg eine teure Variante ist. Warum benötigt ihr diese hohe Präzision, wenn ich fragen darf?

Nachweispflichten gegenüber Aufsichtsbehörde.

Zitat von HubeBube

Wir haben in zwei Standorten jeweils einen MR(S)300. Wo wir die Hoheit über das Gebäude haben wird mittels GPS das Zeitsignal bezogen, im anderen Standort via NTP. Das ganze ist als Master-Slave Cluster aufgesetzt und wenn ein externes Zeitsignal wegbricht wird der Partner MRS300 als Stratum 1 verwendet. Das alles mit den Standardquarzen. Läuft seit Jahren hervorragend und ist im Betrieb bis auf gelegentliche (kostenlos zu beziehende) Updates wartungsfrei.

Ich weiß es tatsächlich nicht genau, da ich "auf der anderen Seite" stehe und nur die Seite habe, die die Daten verwendet. Ich weiß nur, dass NTP nicht genau genug war und daher auf PTP umgestellt werden musste.

Die Uhren stehen auch nicht bei uns, sondern bei dem RZ-Dienstleister, über den wir auch die entsprechenden Daten per Schnittstelle angeliefert bekommen, damit die Zeitstempel wirklich die exakte Zeit des Eingangs bei uns tragen und nicht noch Wege dazwischen sind.

Ich hatte am Anschluss der DGN am Samstag, 26.10., also einen Tag vor der Zeitumstellung, eine doppelte Zwangstrennung (3:55h durch Fritzbox, 4:35h durch DGN). Dadurch hatte ich am Sonntag (27.10.) nur eine Trennung um 3:33h durch die FB).

Zitat von Jung-Fernmelder

nicht themenbezogener Inhalt

Das mag sein. Gibt es denn einen NTP-Server, der aus Deiner Sicht der genaueste ist?

Hast Du bestimmte Empfehlungen für das Vorgehen, wenn man Uhren möglichst exakt mit der gesetzlichen Uhrzeit synchronisieren muss?

Warum hattest Du zwei Zwangstrennungen in dieser besonderen Nacht?

Irgendwie lässt sich das hier nicht in Absätze trennen, daher die Antworten gesammelt:

- Welcher NTP-Server der genaueste ist, lässt sich nicht allgemein sagen. Die Verbindung von Dir zu dem Server hat mehr Einfluss als die Genauigkeit des Servers, und das hängt vom Provider ab. Die größte Genauigkeit lässt sich somit erreichen, wenn der NTP-Server bei Dir läuft und über GPS oder DCF-77 versorgt wird, weil da der Weg über das Internet entfällt. Aber braucht man eine solche Genauigkeit? Für "Zuhause" reicht eigentlich jeder NTP-Server im Internet.

Am besten de.pool.ntp.org - ist eine dynamische Liste aller öffentlichen NTP-Server in .de

- Wenn man es etwas genauer will, installiert man sich zuhause selber einen NTP-Server, nimmt mehrere Server von de.pool.ntp.org oder europe.ntp.pool.org, beobachtet im NTP-Server deren Genauigkeit und die Netzwerklatenz zu diesen Servern, und legt sich irgendwann auf die fest, die mit der geringsten Latenz und geringstem Jitter aus dem eigenen Netzwerk erreichbar sind.

Wenn man die Zeit noch genauer braucht, dann reicht NTP nicht, dann nutzt man PTP (Precision Time Protocoll) mit einer lokalen GPS-Uhr z.B. von Meinberg. https://www.meinbergglobal.com/english/glossary/ptp.htm

DCF-77 ist dafür als Quelle schon zu ungenau, die Uhren und das Protokoll sind genauer als die Laufzeit der Signale von Frankfurt zum eigenen Standort und die Schwingung einer Welle im KHz-Bereich.

Haben wir in der Firma, aber die Preise will man als Privatperson nicht bezahlen

- Eine Zwangstrennung hat man in der Nacht unter Umständen 2x, weil die Zwangstrennung alle 24h vorgenommen wird, der Tag aber 25h lang ist. Wenn man dann den Router von sich aus automatisch zu festen Zeiten trennen lässt, dann ist das logisch gar nicht anders machbar, als dass es irgendwann zwei Trennungen geben muss.

Zitat von HubeBube

Ich hatte einen Knoten im Hirn, sorry.

Natürlich muss der Client in der Lage sein je nach Ziel/Kommunikationspartner die richtige IPv6 Adresse zu verwenden. Vor allem dann, wenn mehrere IPv6 Adressen dem Client zugewiesen sind.

Ja. Ist trotzdem nicht trivial, denn wenn das interne Netz aus mehreren Segmenten besteht, muss die Route für diese anderen Segmente an alle Clients verteilt werden, dass diese auch über dessen ULA und nicht über die Defaultroute per GUA geroutet werden (wg. Firewall).

Alles ziemlicher Mist und hat bei mir dazu geführt, dass ich (hoffentlich vorübergehend) wieder auf IPv4-only zurück bin und es jetzt (wenn ich Zeit finde) über NAT66 versuchen werde.

Zitat von HubeBube

Das die Hardware sich unterscheidet ist klar, warum dann jedoch im Falle der 5590 zwei ProductIDs verwendet werden, leuchtet mir immer noch nicht ein.

Ist ja in #3 schon erklärt.

Zitat von HubeBube

Der SoC (Falcon) erhält in der 5590 die HardwareID 272 und in der 5530 die ID 257.

Das, weil da zwar derselbe SoC verbaut ist, die sich aber in der Hardware trotzdem unterscheiden.

Ich denke mal, die unterscheiden das, weil so drei unterschiedliche Firmwares benötigt werden. 2 für die 5590, eine für die 5530

Zitat von HubeBube

Hast Du eine Quelle hierfür? Ich kann mich ganz schwach daran erinnern, das Ende der 80er auch kundeneigener Telefone angeschlossen werden durften. Das war noch vor der Förderung in Höhe von 700 DM für ISDN-Telefonanlagen für Privatkunden?

Richtline 88/301/EWG

Richtlinie - 88/301 - EN - EUR-Lex

Zitat von HubeBube

Ja der "normale Nutzer" denkt jedoch er könne die Nummer nur zu dem neuen ISP mitnehmen. Der Clevere lässt diese zu einem unabhängigen Anbieter portieren.

Kommt auf den Tarif an. Warum sollte ich auf die im Tarif enthaltene Flat in alle Netze (auch Mobilfunk) verzichten?

Bei einem Tarif ohne Telefonie hast Du recht.

Zitat von HubeBube

Zumal die ULA Bereiche auch bekannt sind und WAN-seitig immer dem Global-Scope weichen sollten, ja sogar müssen.

Mit WAN-seitig meinst Du auf dem Client?

Denn wenn der Router eine ULA-IP als Quell-IP sieht, kann er nicht mehr viel machen, da IPv6 ja nicht genattet werden soll. Das muss schon der Client richtig machen, sonst ist es zu spät.

Einem Gerät ULAs und GUAs parallel zu vergeben lässt sich gar nicht immer vermeiden, zum Beispiel wenn man interne Server betreibt und kein IPv6-Netz statisch zugewiesen hat.

Die Lösung NAT66 gilt ja als "böse" und wird daher nicht überall unterstützt.

Zitat von HubeBube

Gut, dann eine Verständnisfrage: Warum hat eine 5530 die HW Revision 257, obwohl sie nur den Falcon Prozessor (Modemteil) beinhaltet?

Aus https://boxmatrix.info/wiki/FRITZ%21Box_5590_Fiber

HWRevision: 272 - HWSubRevision: 2

ProductID: Fritz_Box_HW272, Fritz_Box_HW273

Verstehe mich bitte nicht falsch, ich versuche lediglich eine Systematik zu erkennen.

Ich verstehe jetzt die Frage nicht ganz. Sollte sie dieselbe HW-Revision tragen wie der Falcon-Teil der 5590? Bestimmt nicht, die HW unterscheidet sich ja.

Zitat von frank_m

Eben. 2016 hatten gabs die ersten Glasfaseranschlüsse in unserer Gemeinde schon über 2 Jahre, und bei den meisten Providern ist die Entscheidung für GPON schon Jahre vorher gefallen. Das meinte ich mit zu spät.

Die Endgerätefreiheit gibt es nicht erst seit 2016. Sie wurde nur 2016 eindeutiger in einem Gesetz abgefasst.

Die ersten Regelungen zu diesen Thema gab es bereits 1988, als es der damaligen EWG beispielsweise nicht gefiel, dass man sein Telefon bei der Deutschen Bundespost mieten musste und kein eigenes Gerät anschließen durfte. Modems nur mit FTZ-Prüfzeichen.

Aber selbst wenn es erst 2016 eindeutig war, einerseits sollten 8 Jahre ausreichen, das auch umzusetzen, andererseits kann man dann nicht 2024 neue Netze aufbauen und so tun, als ob nichts wäre. 2024 aufgebaute Netze werden nicht mehr mit einem Rahmenvertrag von 2016 gebaut, da gab es bestimmt inzwischen Neuausschreibungen. Das hat dann der Einkauf bei der Ausschreibung versemmelt.

Die Tatsache, dass man 2023 versucht hat, eine Ausnahme zu erwirken, bedeutet, dass man von 2016 bis 2023 keinerlei(*) Maßnahmen unternommen hat, einen gesetzeskonformen Zustand herzustellen.

Da kann ich in Richtung der Provider nur sagen: Pech gehabt, Bogen überspannt. Ohne den Antrag an die BNetzA wäre das womöglich noch länger unter dem Radar gelaufen, aber jetzt ist es auf dem Tisch und sie bekommen die 8 Jahre Untätigkeit unter die Nase gerieben.

(*) Und warum ich sicher sagen kann, dass sie untätig waren: wäre es nicht so, hätten sie ihre Bemühungen und deren Ergebnisse als Gründe der BNetzA gemeldet. Davon ist aber nichts zu lesen.

Die ganzen behaupteten Inkompatibilitäten sind in dem Antrag an die BNetzA nur ohne konkrete Beispiele genannt, auch auf Anfrage der BNetzA kam da wohl nichts. Tja, Ergebnis war so natürlich absehbar.

Zitat von mbo77

Und der konnte das fehlerhafte IPv6-Routing beheben?

Hat er doch nicht geschrieben. Er schreibt von 2 verschiedenen Ausfällen. 1x IPv6, 1x Totalausfall.

Zitat von frank_m

Besonders interessant ist der Test mit kleinen Datenmengen. Da sieht man, ab wann der Algorithmus bei der DG greift, um meine Anschlussgeschwindigkeit zu regulieren. Bei 10 MB Datenmenge erreicht mein Anschluss nämlich noch über 600 MBit/s - bei einem 400er Tarif.

Ich glaube, bei kleinen Datenmengen spielen noch andere Faktoren hinein: Rundungsfehler, Reordering von Paketen oder whatever.

Anders hätte ich nicht schonmal 2 GBit/s als "Ergebnis" erhalten, bei einen 500-er GPON-Anschluss.

Zitat von frank_m

Da bin ich skeptisch. Das TKG sieht vor, dass Zugangsdaten für zugelassene und kompatible Endgeräte zur Verfügung gestellt werden. Dass irgendwelche SFP Module per Cloning andere Geräte vorgaukeln, ist damit wohl nicht abgedeckt.

Dem TKG nach müssen die Zugangsdaten unabhängig vom Endgerät bereitgestellt werden. Es gibt kein "zugelassene". Für "kompatibel" muss der Provider die Anforderungen benennen.

Cloning ist Notwehr gegen Provider, die das nicht wahrhaben wollen und wäre unnötig, wenn die Provider damit korrekt umgehen würden.

Zitat von HubeBube

Und das mit 2 Batterien, Wahnsinn...
Was die Chinesen alles bauen!

Als ganz ganz ganz gaaaaaanz kurzer Impuls halt.

Zitat von Gruni22

Bedenke das Telefon…

DECT reicht nicht zwingend über mehrere Etagen.

Möglich, muss man testen. Allerdings weiter als WLAN.

Weitere Möglichkeit, was ich auch schon gemacht habe: als Repeater eine weitere (alte/gebrauchte) Fritzbox, dann kann man deren Telefoniefunktion nutzen. Entweder direkt über Mesh oder als IP-Client.

Weitere Geräte müssen am bzw. über den Router angeschlossen werden, am ONT darf nur der Router hängen.

Entweder den Router dann in den Keller stellen und von dort (ggf. über einen weiteren Switch, falls die Anschlüsse am Router nicht reichen) per LAN-Kabel in alle Stockwerke, im Erdgeschoss dann einen WLAN-Accesspoint (ggf Repeater) per LAN an den Router angeschlossen.

Oder alternativ, wenn der Router zwingend im EG stehen soll, von dort die weitere Verkabelung. Da könntest Du auch zwei LAN-Kabel vom Keller in das EG legen, über eines ist der Router am ONT angeschlossen, über das andere könntest Du das LAN wieder "zurück" in den Keller bringen, um von dort weiter in das OG zu gehen, falls das einfacher zu verbinden ist.

Ich habe bei mir von jedem Zimmer (bzw jeder Dose) zwei LAN-Kabel in den Keller, so dass ich bedarfsweise einfach flexibel umstecken könnte, wenn sich die Anforderungen ändern.