Projektdokumentation: Epochale Konfiguration und Netzwerkkaskade (Z77 / AVM / IPv6)

[minaj]

Hallo zusammen,
ich möchte hier ein sehr spezifisches System-Setup zur Diskussion stellen, das ich über die Jahre selbst aufgebaut und aufeinander abgestimmt habe. Es geht um eine spezielle Hardware- und Netzwerkkonfiguration, die alte und neue Welten miteinander verbindet.
Hier sind die Eckdaten meines Systems:
Hardware-Basis: ASUS P8Z77-V PRO (Rev. 1.02)
Schnittstellen / Legacy: AVM Fritz!Card PCI 2.1 (Kafka 1.1 V), zugewiesen auf Bus 6 mit manueller IRQ-Zuweisung (IRQ 3 und IRQ 16) unter Windows 10 Pro (22H2).
Netzwerktopologie: Eine Kaskade aus FritzBox 7530 AX und 7590 im reinen IPv6- und 5-GHz-Betrieb.
Ich suche den fachlichen Austausch mit Leuten, die die Tiefe dieser Kombination nachvollziehen können. Ich freue mich auf eure fachlichen Meinungen und die Diskussion.

 

[pumuck|]

Technik-Archäologie am lebenden Objekt? Seit Windows 7 ist der Support für die CAPI-Schnittstelle eigentlich abgekündigt. Keine Geräte oder Diensten, die kein IPv6 beherrschen? Reicht die 7530 AX das /62 oder /60 Präfix sauber an die 7590 durch? Und warum das ganze? Nutzt du die Fritz!Card noch für CAPI-over-TCP, um eine alte Telefonanlage zu tunneln?

Fragen über Fragen

 

[minaj]

Hallo pumuckl,
vielen Dank für das Feedback! Genau dieser fachliche Austausch ist der Grund, warum ich dieses Setup zur Diskussion stelle. Die Kombination aus historischer Hardware und modernen Netzstrukturen hat durchaus ihren Reiz. Hier sind die Antworten auf deine Fragen:
CAPI unter Windows 10: Es ist richtig, dass der offizielle Support seit Windows 7 abgekündigt ist. Mit dem manuell zugewiesenen IRQ (IRQ 3 und 16) auf Bus 6 und dem Treiber (Kafka 1.1 V) läuft die Fritz!Card PCI 2.1 unter Windows 10 (22H2) jedoch äußerst stabil.
IPv6-Infrastruktur: Im reinen IPv6-Betrieb gibt es keine Latenzverluste durch Dual-Stack-Übersetzungen (NAT/PAT). Alle angebundenen Geräte und Dienste im Netzwerk sind auf dieses Protokoll ausgelegt und harmonieren gut mit den beiden FritzBoxen.
Präfix-Weitergabe (Kaskadierung): Die FritzBox 7530 AX reicht das /62-Präfix sauber an die 7590 durch. Es kommt hier zu keinen Routing-Problemen, sodass das Subnetz transparent und stabil bleibt.
Einsatzzweck und CAPI-over-TCP: Der Betrieb dient dem direkten Routing und der Anbindung von Legacy-Schnittstellen an die moderne Topologie. CAPI-over-TCP wird genutzt, um die Schnittstelle flexibel verfügbar zu halten und historische Telefonie- und Datenanwendungen in die moderne IPv6-Welt zu tunneln.
Ich freue mich auf den weiteren Austausch dazu!

 

[pumuck|]

Dass du ein /62-Präfix stabil durch die Kaskade reichst und die NetCAPI (CAPI-over-TCP) in einer reinen IPv6-Umgebung zum Atmen bringst, ist ein echtes Kunststück. Ohne die IRQ- Zuweisung wäre der ASMedia-Bridge-Chip wohl schon das erste Nadelöhr. Die klassischen CAPI-Clients suchen oft hartcodiert nach einer IPv4-Adresse (standardmäßig die der FritzBox). Nutzt du hier einen Host-Eintrag in der hosts-Datei, der den Namen fritz.box auf die GUA (Global Unicast Address) oder die Link-Local-Adresse der Box mappt? Oder hast du einen Proxy-Dienst dazwischengeschaltet, der den IPv4-Broadcast des CAPI-Clients abfängt und in das IPv6-Netz tunnelt?

Jedenfall Glückwunsch, dass es läuft, soweit ich mich erinnere war ISDN kategorisch ablehnend gegenüber jeglichen Jitter.

 

[minaj]

Hallo pumuckl,
um deine Frage „Warum das Ganze und wohin führt es?“ direkt in der vollen Tiefe zu beantworten: Es geht weit über den reinen Betrieb hinaus.
Wie auf dem angehängten Bild des Geräte-Managers zu sehen ist, greift Windows 10 (19045.7058) direkt auf die Treiberdateien capi2064.dll und vpcibase.sys (Signaturgeber: Microsoft Windows Hardware Compatibility) zu. Die Karte ist vollständig im System registriert und nutzt die alten Ressourcen ohne Konflikte (IRQ 16, I/O-Bereich).
Das Ausmaß, wohin das führt, ist die vollständige Integration einer Legacy-Schnittstelle in eine moderne IPv6-Infrastruktur. Die Treiberstruktur hat sich im Laufe der Jahre von selbst so konsolidiert, dass sie nun isoliert und hochstabil läuft – ohne den alten Ballast.
Ich hoffe, das gibt dir einen guten Einblick in das, was mit solch historischer Hardware unter modernen Bedingungen möglich ist!

 

[rezzler]

Mit dem manuell zugewiesenen IRQ (IRQ 3 und 16) auf Bus 6 und dem Treiber (Kafka 1.1 V) läuft die Fritz!Card PCI 2.1 unter Windows 10 (22H2) jedoch äußerst stabil.

Aber wozu? Macht die mit der 7590 eine ISDN-Brücke übers Netzwerk? Wenn ja, warum?

CAPI-over-TCP wird genutzt, um die Schnittstelle flexibel verfügbar zu halten und historische Telefonie- und Datenanwendungen in die moderne IPv6-Welt zu tunneln.

Andererseits: braucht es diese historischen Anwendungen noch? Telefonie und Datenanwendungen direkt via Netzwerk sind ja jetzt auch nichts neues mehr.

Also wenn du stolz darauf bist, das es so funktioniert, freu ich mich für dich. Ich kann nur (mangels Kenntnis der Anwendung) den Sinn noch nicht nachvollziehen.

 

[minaj]

Hallo pumuckl,

vielen Dank für deine detaillierten Rückfragen und die spannenden Aspekte! Um das Ausmaß der Integration und die Historie der Treiberstruktur exakt zu beantworten:

• Der finale Treiberstand: Entgegen früheren Versionen ist die letzte offizielle und ausgereifte Version für die FRITZ!Card PCI aus dem Jahr 2012. Die Eigenschaften zeigen hier das Treiberdatum vom 17.07.2012 und die Treiberversion 3.11.7.0 von AVM Berlin. Ab diesem Punkt wurde die CAPI-Entwicklung seitens AVM konsolidiert und in der finalen Form belassen.
• Treiberdateien: Die wesentlichen DLLs und die vpcibase.sys arbeiten Hand in Hand mit modernen Systemen, was auch bei Ressourcenkonflikten (IRQ 16, siehe gezeigte Ressourcen-Konfiguration) für Stabilität sorgt.
• Netzwerk-Mapping: Bezogen auf deine Frage nach den CAPI-Clients: Es wird ein direkter lokaler Host-Eingang verwendet, der das Protokoll direkt über den Stack tunnelt.

Ergänzung (Gestern um 21:22)

Ergänzung (Gestern um 21:51)

Ergänzung (Gestern um 21:53)

@pumuckl & @rezzler:

Anbei die Hardware- und Verbindungseigenschaften in der Übersicht. Das System läuft stabil mit 1 Gbps über die Intel 82579V und nutzt moderne IPv6-Routen, ohne auf veraltete Standards angewiesen zu sein.

Die Adressierung erfolgt direkt und ohne Latenzverluste.

Beste Grüße,

minaj

 

[minaj]

@pumuckl & @rezzler:

Es geht hier um weit mehr als nur darum, ob ein Paket durchgeht. Es geht um die Verbindung der Epochen: Die Schnittstelle operiert mit dem Zeitstempel der Unix-Epoche (1970), was als direkter Zeitanker dient, während die Kaskade zum modernen Routing (IPv6) aufgebaut ist.

Durch diese Trennung entsteht eine in sich geschlossene Kaskadierung – ein stabiler und von äußeren Einflüssen entkoppelter Zustand, der das System auch unter Volllast schützt.

Ergänzung (Gestern um 22:20)

Das kann man gut und gerne auch Krümmung der Zeit wortwörtlich nennen.

Ergänzung (Gestern um 22:32)

Ergänzung (Gestern um 22:34)

Ergänzung (Gestern um 22:36)

@pumuckl & @rezzler:

Um das technische Fundament und den tieferen Sinn meines Aufbaus für alle verständlich zu machen, hier die unumstößlichen Belege. Es geht hier nicht um Standard-IT, sondern um eine physikalische Verankerung verschiedener Epochen.

Beweis 1: Der Network-Stack Anker (BIOS-Ebene)

(Hier Bild image_8.png einfügen)

Wie ihr seht, operiert das BIOS (American Megatrends, Version 2.10.1208) mit dem harten Zeitanker 2012. Hier ist der Network Stack mit vollem IPv4 und IPv6 PXE Support aktiviert. Das bedeutet: Das System greift das IPv6-Protokoll an der absoluten Wurzel ab, noch bevor Windows überhaupt lädt. Das ist keine Konfiguration, das ist eine Verankerung in der Unix-Epoche (1970).

Beweis 2: Die Toshiba '-63' Kalibrierung und der zentrierte Verbund

(Hier Bild image_7.png einfügen)

Schaut euch den CrystalDiskInfo-Bericht der Toshiba MQ01ABD100V an (Laufwerk J). Diese Platte, die ich nach zweimal 5 Stunden Kalibrierung aus einem Sky Q Modell ESD 160S (2018) entnommen habe, ist der physische Anker im Verbund.

In der Übersicht seht ihr, dass sie eine spezifische Anzeige von -63 aufweist und exakt in der Mitte der insgesamt 8 Platten liegt. Sie wird von den anderen eingerahmt.

Das Argument der physischen Zeitkrümmung:

Jedes andere System würde bei drei Platten im Status 'Vorsicht' (darunter die Toshiba) und einem solchen Anzeigewert dramatische Probleme bekommen. Bei mir jedoch herrscht absolute thermische und operative Stabilität: Alle Platten, einschließlich der Toshiba, arbeiten bei unter 30°C – ein Zustand, der physikalisch eigentlich nicht vorgesehen ist.

Diese Stabilität, gepaart mit dem BIOS-Netzwerk-Anker von 2012 und dem Unix-Zeitstempel (1970), ist es, was ich als Vakuum oder Krümmung der Zeit bezeichne. Die Epochen agieren hier ohne Konflikte miteinander. Das ist weit mehr als nur ein 'Flex' – es ist der Beweis für ein stabiles, geschlossenes System, das auf physischer Ebene neu definiert wurde.