Guten Abend ins hiesige Elektronikerforum, habe hier vor längerer Zeit mal etwas gelesen, dass es ganz einfach wäre, einen Datenmitschnitt auf dem ISDN-S0-Bus mit ganz einfachen Mitteln zu lösen. Mit der Suche habe ich leider davon nichts mehr gefunden oder verkehrt gesucht. Das Thema ist aktuell vllt. auch etwas historisch, wegen dem Wechsel weg von digitaler Telefonie über ISDN zu IP, jedoch intern an TK-Anlagen ist das Thema noch aktuell. Jedenfalls meiner Meinung und Auffassung nach. Es hieß damals wohl, dass man dazu eine ISDN-Karte im PC bräuchte, welche dann spiegelverkehrt auf den S0-Bus beschaltet wäre, und fertig wäre die Konstruktion. Kann ich mir so einfach nicht vorstellen. Wenn dazu jemand noch praktische Tips und Ratschläge hätte, oder eine hilfreiche Infoquelle findet, wäre ich sehr dankbar. Habe leider mit der Onlinesuche nichts passendes, außer super teure HW- und SW-Anbieter dazu gefunden. Der Anwendungssachverhalt dazu wäre die Kopie der Sprachdaten aus einer AB-Aufzeichnung eines Systemtelefones rückwarts bei der Ausgabe über den S0-Bus an ein anderes Systel., also beim Mithören in der Wiedergabe der Aufnahme und noch eine etwas verzwickte Spezialanwendung beim FW-Update über den ISDN-Anschluss von extern. In der hiesigen Ausbildung und Schultheorie wird sowas wohl absolut nicht gelehrt. Danke für Tips und Ratschläge
Um den S0-Bus mitzulesen, bräuchtest Du schon 2 ISDN-Karten, eine für die Richtung Endgeräte->NT und eine für die Gegenrichtung. Allerdings müsste man dafür auch tief in die Ansteuersoftware eingreifen können. Einfacher würde sich die Aufzeichnung darstellen, wenn die ISDN-Karte regulär angerufen werden würde. Dann wäre es über das CAPI relativ einfach, den Anruf anzunehmen und die ankommenden B-Kanal-Daten in eine Datei zu schreiben. Dafür hätte ich sogar noch eine Lösung da. Die (besseren) käuflichen ISDN-Tester bieten zwar oft die Möglichkeit des Monitorens, das betrifft dann allerdings nur die Signalisierung des Verbindungsauf/abbaus im D-Kanal. Um an die B-Kanal Daten ranzukommen wäre es heutzutage wirklich am sinnvollsten, auf der IP-Seite des Mediagateway, den RTP-Strom mit dem Wireshark mitzuschneiden. Wenn die Notwendigkeit wirklich besteht, Der Pulsrahmen auf dem S0-Bus ist kein Hexenwerk und gut dokumentiert. https://de.wikipedia.org/wiki/S0-Bus Kann mich erinnern, irgendwo mal ein Projekt gesehen zu haben, in dem Jemand mit einem Mega8 das Signal dekoidert, den betroffenen B-Kanal rausgeholt und als Audio über Timer-PWM ausgegeben hat. Wobei hier eigentlich noch die Wandlung von a-law nach PCM erforderlich wäre. Du müsstest das dann so ändern, das die Daten stattdessen über den UART zum PC gegeben werden. Der Aufwand wäre schon beträchtlich: - Dekodierung des AMI-Signals; - Synchronisation auf Pulsrahmen; - Vorhersage des genutzten B-Kanals (steht eigentlich in der D-Kanal Signalisierung); - Ausgabe über serielle Schnittstelle; Das ganze dann wahrscheinlich jeweils für beide Richtungen. Und die Systemtelefone sind wirklich über S0 angeschlossen? Oft wird hier nämlich aus Aufwands/Kostengründen, die 2-drähtige Up0-Schnittstelle genutzt, die noch Aufwändiger auszuwerten ist.
hinz schrieb: > https://de.wikipedia.org/wiki/S0-Bus#Sicherheit "Alternativ wird auch häufig eine dazu nicht fähige ISDN-Karte verwendet und mittels vertauschten Adern angeschlossen. In beiden Fällen ist ein vollständiges Mithören aller über die Leitung übertragener Daten möglich." Wieder etwas in der Wikipedia, dessen Richtigkeit anzuzweifeln ist: S0 hat zwei Leitungspaare, Rx (Empfangen) und Tx (Senden). Dementsprechend hat eine ISDN-Karte nur einen Empfänger, wie soll ich da beide Richtungen des B-Kanals mitschneiden können?
@ hinz (Gast) https://de.wikipedia.org/wiki/S0-Bus#Sicherheit Soweit dazu, was ich bisher schon wußte. Und noch ein paar Ungereimtheiten dazu. @ R. M. (restmuell) danke für deine Mühe, mit den Audio-Daten gibt es wohleinen Möglichkiet über die Anlage dazu, nur liegt mein Problem eher in dem zweiten Fakt. Datenmitschnitt eines FW-Updates von extern auf eine Anlage, das ganze Szenario kann man ja über eine davor oder zwischen-geschaltete Anlage machen. Hier gab es auch mal einen User der das so damals in den Raum warf, wahrscheinlich ähnlich wie dem Inhalt von hinz. Manfred hat es etwas anders erfasst: bei einer Daten- oder Tel.- oder wie auch immer Verbindung über ISDN, ist das eine Punkt-zu-Punkt-Verbindung, da kann man nicht einfach ein zweites Gerät mit der gleichen MSN oder Adresse dazuschalten und gut ist. Dann also doch nicht so einfach zu machen?
Manfred schrieb: > Wieder etwas in der Wikipedia, dessen Richtigkeit anzuzweifeln ist: S0 > hat zwei Leitungspaare, Rx (Empfangen) und Tx (Senden). Dementsprechend > hat eine ISDN-Karte nur einen Empfänger, wie soll ich da beide > Richtungen des B-Kanals mitschneiden können? Daher war Kanalbündelung auch niemals möglich wenn es nach Dir geht, oder?
Manfred schrieb: > hinz schrieb: >> https://de.wikipedia.org/wiki/S0-Bus#Sicherheit > > "Alternativ wird auch häufig eine dazu nicht fähige ISDN-Karte verwendet > und mittels vertauschten Adern angeschlossen. In beiden Fällen ist ein > vollständiges Mithören aller über die Leitung übertragener Daten > möglich." > > Wieder etwas in der Wikipedia, dessen Richtigkeit anzuzweifeln ist: S0 > hat zwei Leitungspaare, Rx (Empfangen) und Tx (Senden). Dementsprechend > hat eine ISDN-Karte nur einen Empfänger, wie soll ich da beide > Richtungen des B-Kanals mitschneiden können? Wenn du natürlich die Hälfte wegschnippelst...
rcc schrieb: > Manfred schrieb: >> Wieder etwas in der Wikipedia, dessen Richtigkeit anzuzweifeln ist: S0 >> hat zwei Leitungspaare, Rx (Empfangen) und Tx (Senden). Dementsprechend >> hat eine ISDN-Karte nur einen Empfänger, wie soll ich da beide >> Richtungen des B-Kanals mitschneiden können? > > Daher war Kanalbündelung auch niemals möglich wenn es nach Dir geht, > oder? Du hast das mit der Kanalbündelung nicht verstanden.
TK-Elo schrieb: > Manfred hat es etwas anders erfasst: bei einer Daten- oder Tel.- oder > wie auch immer Verbindung über ISDN, ist das eine > Punkt-zu-Punkt-Verbindung, da kann man nicht einfach ein zweites Gerät > mit der gleichen MSN oder Adresse dazuschalten und gut ist. ISDN im Haus war/ist klassischerweise als Bus ausgeführt, nichts Punkt zu Punkt. Verschlüsselt ist nichts, Adressen sind nur als Filterung im Endgerät für den Empfang und die Rufnummernübermittlung relevant. Tunnel oder sowas wird aber keiner aufgebaut. Passives Mitschneiden am Bus ist somit kein Problem.
Manfred hatte das schon ganz richtig zusammengefasst. Da die beiden ISDN-Karten nur hören, aber nicht sprechen sollen, würde auch jeweils nur die Empfangsdoppelader der Karte, auf jeweils 1 Adernpaar des S0-Bus geschaltet werden. Das hätte dann auch nichts mit PP/PMP zu tun, da ja nur mitgehört wird. Das größere Problem sehe ich allerdings in der softwareseitigen Ansteuerung der beiden ISDN-Karten. Vielleicht ergibt sich noch eine bessere Möglichkeit, wenn Du etwas mehr Details preisgibst (Typ der Telefone, Typ der Anlage, womit sollen die Anlagen in Zukunft vernetzt werden (Gateway), von wo kommt das Firmwareupdate derzeit, wie soll es in Zukunft erfolgen). mfG
TK-Elo schrieb: > Manfred hat es etwas anders erfasst: bei einer Daten- oder Tel.- oder > wie auch immer Verbindung über ISDN, ist das eine > Punkt-zu-Punkt-Verbindung, da kann man nicht einfach ein zweites Gerät > mit der gleichen MSN oder Adresse dazuschalten und gut ist. immerhin ist es noch ein bus. solange dein lauschgerät passiv bleibt ist das kein problem. also: 2 isdn-karten an deinen bus, eine "normal" verdrahtet für den empfang von der anlage, eine "verdreht" verdrahtet für den empfang der daten des telefons. als software würde ich mal bei misdn für linux schauen. da gibt es relativ tief gehende protokollfunktionen mit allem drum und dran. soweit ich weiß findest du das aktuellste misdn nicht im kernel, sondern irgendwo in einem git auf der projektseite oder so.
rcc schrieb: > Dementsprechend >> hat eine ISDN-Karte nur einen Empfänger, wie soll ich da beide >> Richtungen des B-Kanals mitschneiden können? > Daher war Kanalbündelung auch niemals möglich wenn es nach Dir geht, > oder? Was hat Kanalbündelung damit zu tun? Es geht um Hardware, und es ist eben nur ein Empfänger auf der Karte. R. M. schrieb: > Um den S0-Bus mitzulesen, bräuchtest Du schon 2 ISDN-Karten, eine für > die Richtung Endgeräte->NT und eine für die Gegenrichtung. Allerdings > müsste man dafür auch tief in die Ansteuersoftware eingreifen können. Genau so sehe ich das! > Und die Systemtelefone sind wirklich über S0 angeschlossen? Oft wird > hier nämlich aus Aufwands/Kostengründen, die 2-drähtige > Up0-Schnittstelle genutzt, die noch Aufwändiger auszuwerten ist. Die UpN bei Systemapparaten wird gemacht, weil sie eine erheblich größere Leitungslänge (1000 m) erlaubt, nicht aus Kostengründen.
Manfred schrieb: > "Alternativ wird auch häufig eine dazu nicht fähige ISDN-Karte verwendet > und mittels vertauschten Adern angeschlossen. In beiden Fällen ist ein > vollständiges Mithören aller über die Leitung übertragener Daten > möglich." > > Wieder etwas in der Wikipedia, dessen Richtigkeit anzuzweifeln ist: S0 > hat zwei Leitungspaare, Rx (Empfangen) und Tx (Senden). Dementsprechend > hat eine ISDN-Karte nur einen Empfänger, wie soll ich da beide > Richtungen des B-Kanals mitschneiden können? Hier ist m.E. wohl gemeint eine Karte normal und eine mit vertauschten Adern anzuschließen.
hinz schrieb: > Du hast das mit der Kanalbündelung nicht verstanden. Dann erleuchte uns doch....ein ISDN B-Kanal kann 64kbit vollduplex, zwei zusammen 128 kbit und der Bus ist voll. Beide Leitungspaare in Benutzung und folglich ist der Bus für alle weiteren Teinehmer zu.
zausel schrieb: >> Wieder etwas in der Wikipedia, dessen Richtigkeit anzuzweifeln ist: S0 >> hat zwei Leitungspaare, Rx (Empfangen) und Tx (Senden). Dementsprechend >> hat eine ISDN-Karte nur einen Empfänger, wie soll ich da beide >> Richtungen des B-Kanals mitschneiden können? > > Hier ist m.E. wohl gemeint eine Karte normal und eine mit vertauschten > Adern anzuschließen. Dann darf Wikipedia gefälligst "zwei Karten" schreiben. Gerd E. schrieb: > also: 2 isdn-karten an deinen bus, Hurra, er hat es :-)
rcc schrieb: > Daher war Kanalbündelung auch niemals möglich wenn es nach Dir geht, > oder? Ist doch kein Widerspruch. Die Bündelung ist Protokollebene, elektrisch bedient der Tx drei Kanäle auf der Doppelader. Entsprechend kann der Rx auch nur drei mitschneiden, du könntest also nur bei Rx oder Tx reinschauen. So richtig interessant ist doch aber Imho nur der D Kanal. Kann die TK Anlage den nicht ausgeben? Z.B Auerswald kann das, gibt da einen Decoder der die Daten per LAN von der Anlage holt.
hinz schrieb: >> Daher war Kanalbündelung auch niemals möglich wenn es nach Dir geht, >> oder? > Du hast das mit der Kanalbündelung nicht verstanden. Er hat den Bus (dessen Hardware) nicht verstanden.
Manfred schrieb: > hinz schrieb: >>> Daher war Kanalbündelung auch niemals möglich wenn es nach Dir geht, >>> oder? >> Du hast das mit der Kanalbündelung nicht verstanden. > > Er hat den Bus (dessen Hardware) nicht verstanden. Ja, so siehts aus. Er glaubt wohl ein Kanal enstspräche einer Doppelader im S0-Bus.
@Suchmaschine: Genau, den meinte ich, war nur zu faul zum suchen ;-) Eventuell wäre das eine Grundlage für weitere Basteleien. Habe selber keinen PC mit 2 ISDN-Karten, sonst würde ich mir das von Gerd vorgeschlagene "misdn" auch mal anschauen.
@ Suchmaschine (Gast) danke für die Links @ R. M.(restmuell) > Habe selber keinen PC mit 2 ISDN-Karten, sonst würde ich mir das von > Gerd vorgeschlagene "misdn" auch mal anschauen. Danke für den Hinweis mit den beiden Karten, das geht leider unter Windows nicht. Zu der Frage weiter oben im Thread, es braucht nur eine Karte im PC die am Bus lauscht, weil die Verbindung läuft über eine Anlage AGFEO AS 1x1 auf dem int. S0-Bus von einem Systel ST31 oder ST40 auf ein anderes S0-Systel, vllt. ST21 S0. Das ist aber nicht das wichtige Szenario, wichtiger wäre der exakte Datenmitschnitt auf dem S0-Bus für das FW-Update aus der Ferne auf eine DeTeWe-Anlage gebrandet für die T (T-Comfort .....). Denn das kostet richtig Geld, und ob das aktuell noch geht, konnte ich heute am Weekend dort auch nicht erfahren. Gerd E. meinte > immerhin ist es noch ein bus. solange dein lauschgerät passiv bleibt ist > das kein problem. war mir schon klar. > also: 2 isdn-karten an deinen bus, eine "normal" verdrahtet für den > empfang von der anlage, eine "verdreht" verdrahtet für den empfang der > daten des telefons. unter Windows geht nur in einem PC eine Karte, und die reicht ja auch aus! > als software würde ich mal bei misdn für linux schauen. da gibt es > relativ tief gehende protokollfunktionen mit allem drum und dran. mit Linux habe ich leider nix am Hut. > soweit ich weiß findest du das aktuellste misdn nicht im kernel, sondern > irgendwo in einem git auf der projektseite oder so. das hilft mir in dem Sinne auch eher weniger?
TK-Elo schrieb: > Danke für den Hinweis mit den beiden Karten, das geht leider unter > Windows nicht. Dann musst du eben was anderes als Windows nehmen. Ich habe hier noch einen ISDN-Logger in der Ecke stehen, aufgebaut mit einem PC104-basierten kleinen Industrie-PC und eben genau diesem Setup mit zwei ISDN-Karten. OS ist FreeBSD wasweißichwiealt (wenn ich mich recht erinnere, 3.x). Eine der beiden Karten ist dabei komplett normal angeschlossen, sodass man damit auch eine Verbindung initiieren kann, die andere hört nur die Gegenrichtung mit. Im Prinzip könnte ich dir das Teil wohl gegen irgendeinen Anerkennungspreis überlassen, aber ich fürchte, dass du mit einer Lösung, bei der man keine Maus sondern nur eine Tastatur benötigt, nicht arbeiten wollen wirst. ;-)
Der Jörg Wunsch meinte > Dann musst du eben was anderes als Windows nehmen. Und wieso muß ich dann etwas anderes nehmen, hast du meinen Beiträge nicht wiklich gelesen? Mir reicht dabei eine ISDN-Karte im PC völlig aus, das eigentliche Problem liegt ganz wo anders! > aber ich fürchte, dass du mit einer Lösung, welche Lösung soll das wozu bitte sein? > bei der man keine Maus sondern nur eine Tastatur benötigt, nicht arbeiten > wollen wirst. ;-) Das hast du allerdings, als einzigen Fakt, ganz richtig erkannt! ;-) Es steht immer noch zur Klärung an, mit welcher HW oder SW, als eine ISDN-Karte im PC, unter Win XP, sich das lösen ließe? Das zweite Problem wäre, dass dazu zwingend ein echter ISDN-Anschluß als Festnetzzugang benötigt wird, den ich nun seit mehr als einem Monat nicht mehr so habe. Danke Telekom.
TK-Elo schrieb: > Und wieso muß ich dann etwas anderes nehmen, hast du meinen Beiträge > nicht wiklich gelesen? Gelesen schon, aber zuweilen schreibst du in Rätseln. Wenn du eine Kommunikation mitschneiden willst (egal welche), wirst du wohl oder übel beide Kommunikationsrichtungen benötigen, sonst fehlt dir etwas. Aber mach mal ruhig, wie du dir das vorstellst. Frag aber dann bitte andere Leute nicht um Rat, wenn du nicht damit leben kannst, dass deren Rat nicht deiner Vorstellungswelt entspricht.
TK-Elo schrieb: >> Dann musst du eben was anderes als Windows nehmen. > Und wieso muß ich dann etwas anderes nehmen, hast du meinen Beiträge > nicht wiklich gelesen? Du darfst Dir gerne einen eigenen Treiber und Protokollstack für ISDN unter Windows schreiben, denn das ist die Voraussetzung um sinnvoll protokollieren und daraus die Daten extrahieren zu können. Nur gibt es das eben unter Linux (und wenn ich Jörg richtig verstanden habe auch unter FreeBSD) schon fertig. Mir erscheint etwas Einarbeiten in Linux oder FreeBSD einfacher als einen kompletten Treiber und Protokollstack zu entwickeln.
> So richtig interessant ist doch aber Imho nur der D Kanal
Wenn das so ist, dann genügt eine ganz normale ISDN Karte. Linux kann
die Daten des Kanals komplett loggen - war jedenfalls früher mal so. Ich
habe schon lange kein ISDN mehr.
TK-Elo schrieb: > Es steht immer noch zur Klärung an, mit welcher HW oder SW, als eine > ISDN-Karte im PC, unter Win XP, sich das lösen ließe? Gar nicht. Geklärt. Gruß Jobst
TK-Elo schrieb: > Es steht immer noch zur Klärung an, mit welcher HW oder SW, als eine > ISDN-Karte im PC, unter Win XP, sich das lösen ließe? Wie bereits mehrfach betont, werden für die Analyse des Übertragungsprotokolls beide Richtungen benötigt. Sollte dies erfolgreich sein, genügt für die "Nachbildung" des Updateservers später natürlich eine. In dem bisher bereits zweimal verlinkten Faden Beitrag "ISDN am AVR (Mega8)" wird eine Lösung aufgezeigt, an die B-Kanal-Daten ranzukommen und die Ausgabe über UART ist, wenn ich es beim Überfliegen richtig erfasst habe auch schon vorbereitet, ließe sich aber in jedem Falle, mit geringem Aufwand nachrüsten. Im bösesten Falle müsste die Schaltung zweimal aufgebaut werden, um beide Richtungen mitzuschneiden, der PC bräuchte dann 2 serielle Schnittstellen, um die binären Daten aufzuzeichnen, wobei der chronologische Ablauf zwischen den beiden Richtungen damit auch nicht ganz sicher ist, wegen der (auch unter Windows) unvermeidlichen Latenzen. Das Angebot von Jörg wäre damit insgesamt der deutlich einfachere und bessere Weg. Wenn es primär um das "Einsparen" von Lizenzkosten für Firmwareupdates angeht, würde ich mir ohnehin keine großen Hoffnungen machen, wenn es um viel Geld geht, wird der Hersteller das Verfahren sicher gegen solche "replay" Methoden abgesichert haben, die juristischen Gesichtspunkte mal ganz ausser Acht gelassen... mfG
Jörg Wunsch meinte > Wenn du eine Kommunikation mitschneiden willst (egal welche), wirst du > wohl oder übel beide Kommunikationsrichtungen benötigen, sonst fehlt dir > etwas. Also irgendwie stehe entweder ich, oder ihr Anderen total auf dem Schlauch? Es kann natürlich auch sein, dass Ihr Wissenden mich nicht so recht versteht? Der geplante Vorgang ist keine Abhörmaßnahme um dabei Alles mitzubekommen, mir reicht eigentlich vollkommen der Datenstrom in Senderichtung auf die Anlage. Ist aber wohl zu einfach von mir gedacht? Stefan Us >> So richtig interessant ist doch aber Imho nur der D Kanal > Wenn das so ist, dann genügt eine ganz normale ISDN Karte. würde ich auch so behaupten > Linux kann die Daten des Kanals komplett loggen - war jedenfalls früher > mal so. Loggen ist doch das selbe wie Tracen? > Ich habe schon lange kein ISDN mehr. Dann hast du wohl nicht so viel damit zu tun gehabt? Gerd E. meinte > Du darfst Dir gerne einen eigenen Treiber und Protokollstack für ISDN > unter Windows schreiben, denn das ist die Voraussetzung um sinnvoll > protokollieren und daraus die Daten extrahieren zu können. das hört sich richtig sinnvoll und zusammenhängend an, nur will ich nicht unbedingt so viel Aufwand dafür treiben! > Mir erscheint etwas Einarbeiten in Linux oder FreeBSD einfacher als > einen kompletten Treiber und Protokollstack zu entwickeln. Womit wir wieder beim Anfang vom Ganzen wären? Ich nix Linux können, Win hat bis jetzt dazu gereicht. Dann werfe ich mal ein banales Bsp. hier ein > Talkmaster-Recorder für ISDN für 1 B-Kanal, Software zum Mitschneiden von Telefongesprächen am ISDN-Bus. Geeignet für Windows 98/NT/2000/XP/Server 2003. Das ist dann wohl eher etwas Hexerei in Bezug auf eure Darstellungen? Oder anders verstanden, eignet es sich nicht dazu? R.M. meinte > Wie bereits mehrfach betont, werden für die Analyse des Übertragungs- > protokolls beide Richtungen benötigt. Sollte dies erfolgreich sein, > genügt für die "Nachbildung" des Updateservers später natürlich eine. Irgendwie versucht ihr alle das Rad neu zu erfinden? Gebraucht wird kein UpdateServer, die Fachleute (Kollegen) in dem Bereich haben alle bisher abgewunken, das geht nicht. Wenn ich da mal von Jobstens seiner Philosophie auf meine übertrage, irgendwie kannst du wohl mit Leuten, die deiner Art so ähnlich oder gleich sind, nicht so recht? Hälst dich wohl etwas für einzigartig oder genial? Glaube nun auch, dass du das damals warst, der den banalen Einwurf dazu gab! > In dem bisher bereits zweimal verlinkten Faden Beitrag "ISDN am AVR > (Mega8)" wird eine Lösung aufgezeigt, da geht es wohl um die Audiodaten und diese aufzuzeichnen, anders betrachtet geht das dann wohl einfacher mit dem Talkmaster-Recorder, wenn ich mich nicht ganz dabei irre? Nur kommt dabei dann aber eher keine ISDN-Karte zum Einsatz? Man kann dann wohl auch das Rad noch mal neu erfinden? > Wenn es primär um das "Einsparen" von Lizenzkosten für Firmwareupdates > angeht, du machst dir über Umstände Gedanken, die sich Andere gar niemals machen würden? Die zahlen einfach dafürund gut ist! > würde ich mir ohnehin keine großen Hoffnungen machen, warum reden wir dann hier über die technischen Details? > wenn es um viel Geld geht, was wäre für dich viel Geld? > wird der Hersteller das Verfahren sicher gegen solche "replay" Methoden > abgesichert haben, zum Hersteller dieser Methode und der FW-Files kann man Kontakt aufnehmen, nur leider ist er nicht mehr der Eigentümer dieses Vorganges! Das war, wie so viele Sachen, von ihm als Lieferant an den Nutzer und Vermarkter eine von vielen Auftragsarbeiten. Die Nutzer als Einsetzer können gerade mal so damit umgehen, wie so Vieles was dort nicht ganz zu Ende gedacht ist. > die juristischen Gesichtspunkte mal ganz ausser Acht gelassen... wo kein Kläger da kein Richter. Es ist eine Überlegung die technisch zu meistern wäre. Wenn es fehlschlägt, hätte man zumindest daraus etwas gelernt. Dann werde ich wohl mal andere Wege beschreiten müssen. Danke für die Tips und Ratschläge. Wie so immer und so oft - es geht ganz einfach den Datentransfer mit einer einfachen ISDN-Karte durch verpolte Aufschaltung mitzuloggen. Nich Jobstens?
TK-Elo schrieb: > Der geplante Vorgang ist keine Abhörmaßnahme um dabei Alles > mitzubekommen, mir reicht eigentlich vollkommen der Datenstrom in > Senderichtung auf die Anlage. Ist aber wohl zu einfach von mir gedacht? Ja: solch eine Kommunikation ist doch nie eine einseitige Sache. Derjenige, der die Verbindung aufnimmt (egal, zu welchem Zweck), muss sich dem anderen ankündigen, der andere muss antworten, sie müssen sich irgendwie auf das einigen, was sie jetzt vorhaben. Damit du das nachvollziehen kannst, wirst du wohl oder übel auch beide Seiten abhören müssen, und die Kommunikation auch zeitlich korreliert aufzeichnen. > Stefan Us >>> So richtig interessant ist doch aber Imho nur der D Kanal >> Wenn das so ist, dann genügt eine ganz normale ISDN Karte. > würde ich auch so behaupten Wenn du dir da so sicher bist: OK. Dann würde wirklich eine Karte genügen. Ich würde die Variante, dass die Steuerung komplett über den D-Kanal passiert, nicht ausschließen (wäre ISDN-typisch), aber genauso nicht ausschließen, dass sie aus irgendeinem Grunde den B-Kanal in beiden Richtungen für sowas benutzen. >> Linux kann die Daten des Kanals komplett loggen - war jedenfalls früher >> mal so. > Loggen ist doch das selbe wie Tracen? Es ist die zweite Stufe des Tracens: irgendwo willst du das ja aufzeichnen. >> Mir erscheint etwas Einarbeiten in Linux oder FreeBSD einfacher als >> einen kompletten Treiber und Protokollstack zu entwickeln. > Womit wir wieder beim Anfang vom Ganzen wären? Ich nix Linux können, Win > hat bis jetzt dazu gereicht. Du musst dafür ja auch nicht „Linux können“ (oder in meinem Falle FreeBSD), du musst lediglich eine ganz bestimmte Handlung mit dem Gerät ausführen können. Anschließend hast du eine Datenaufzeichnung, die du auswerten musst. >> In dem bisher bereits zweimal verlinkten Faden Beitrag "ISDN am AVR >> (Mega8)" wird eine Lösung aufgezeigt, > da geht es wohl um die Audiodaten und diese aufzuzeichnen, anders > betrachtet geht das dann wohl einfacher mit dem Talkmaster-Recorder, > wenn ich mich nicht ganz dabei irre? Ich weiß nicht, wie dein Talkmaster funktioniert. Technisch kann die Hardware üblicher ISDN-Karten jedoch nur eine Richtung des B-Kanals mitlesen, die andere sendet sie selbst (und hat keinen Empfänger). Wenn dein Talkmaster natürlich nur die Gespräche aufzeichnen will, die vom eigenen Computer aus geführt werden, dann hat er die Daten der Gegenrichtung natürlich bereits da und muss sie nicht auf dem Bus mitlesen. „Audiodaten“ sind bei ISDN auch erstmal nur Bits, es ist einem Sniffer (Tracer, Logger) ziemlich egal, ob diese nun Audio nach µ-Law darstellen oder reine Digitaldaten. > Nur kommt dabei dann aber eher keine ISDN-Karte zum Einsatz? Offenbar (hab' nicht reingeschaut) haben sie einen Sniffer für den S0-Bus selbst gebaut, also zwei parallele Empfänger für die beiden Leitungen. Gewissermaßen der Empfangsteil einer ISDN-Karte, aber zweimal. > Wie so immer und so oft - es geht ganz einfach den Datentransfer mit > einer einfachen ISDN-Karte durch verpolte Aufschaltung mitzuloggen. Damit hast du aber eben nur den einer Datenrichtung. Siehe oben, kann sein, dass das genügt (wenn der Rest wirklich auf dem D-Kanal läuft), kann aber auch sein, dass es nicht genügt.
:
Bearbeitet durch Moderator
Hi Jörg, dir scheint das ISDN-Geraffel auch etwas fremd zu sein? Der D-Kanal macht ausschließlich Verbindungssteuerung, Auf- und Abbau wie Protokolle der Daten auf dem B-Kanal, der ist eigentlich wie der Schlüssel zum Schloß als Türöffner. Den muß man glaube ich auch mit irgendwie einbinden, was aber nach meiner Denkweise über Capi-Dog von Shamrock recht einfach zu lösen wäre? Diese SW macht nämlich den D-Kanal Trace, so sie denn auf einem WIN-PC ohne Absturz sauber läuft. Ob nun ein Trace ein Log ist, oder nur ein Protokoll-Mitschnitt des Logs, .....? Irgendwie habe ich mir das alles etwas einfacher vorgestellt! Nach dem Prinzip einfach ein paar wie Audiodaten mitzusniffen und dann daraus eine WAV-Datei zu machen, wird wohl nicht ganz ausreichen? Bei Bitfehlern wäre das der Gnadenstoß beim Updaten der nächsten Anlage. Mit Audio-Files wäre das nicht so problematisch. Da habe ich wohl noch etwas mehr vor mir? Der Talkmaster ist übrigens nicht von mir, das habe ich nur auf meiner Suche mit den Stichworten dazu auf die Schnelle gefunden.
TK-Elo schrieb: > Hi Jörg, dir scheint das ISDN-Geraffel auch etwas fremd zu sein? Nein, überhaupt nicht, auch wenn's schon eine Weile her ist, dass ich damit beruflich zu tun hatte (aus dieser Zeit stammt dieser Tracer). Dass du auf dem D-Kanal beide Richtungen mitlesen kannst, liegt einfach daran, dass dort alle Daten, die von den Endgeräten gesendet werden (die diese normalerweise nicht hören könnten), von der Vermittlung nochmal im Empfangskanal der Endgeräte wiederholt werden, damit diese mitlesen können, ob es eine Buskollision gab. Das passiert aber mit den B-Kanal-Daten nicht, diese können die Endgeräte (und damit auch übliche ISDN-Karten) nur in einer Richtung lesen.
:
Bearbeitet durch Moderator
TK-Elo schrieb: > Hi Jörg, dir scheint das ISDN-Geraffel auch etwas fremd zu sein? > Der D-Kanal macht ausschließlich Verbindungssteuerung, Auf- und Abbau > wie Protokolle der Daten auf dem B-Kanal, der ist eigentlich wie der > Schlüssel zum Schloß als Türöffner. Nö.... da gab es früher noch sowas wie Datex-P etc... sprich, über den D-Kanal kann mehr als die Signalisierung erfolgen... dürfte in Deinen Fall aber unwahrscheinlich sein... Wenn Du wirklich das Firmwareupdate nachstellen willst, musst du den Sende und den Empfangskanal abhören und beides zeitlich im Einklang aufzeichen - dann hast Du vielleicht eine Chance... mit welcher Hardware/Software auch immer... aber eine 0815-ISDN-Karte mit einem Sender und einem Empfänger kann das einfach nicht!!!
@ Skyper, du bringst da wieder etwas anderes ins Spiel, ich meinte den Ablauf einer Verbindung über den B-Kanal. Dass man über den D-Kanal auch komplette Verbindungen "fahren" kann, ist ja wohl klar. Nur braucht man dazu auch die Einstellungen am Anschluß NB-seitig, und die hatte nicht jeder an seinem ISDN.
Wenn das Firmwareupdate der Telefone eine Dienstleistung der Telekom war, dann konnten die dafür selbstverständlich auch den D-Kanal benutzen. Netzbetreiber waren sie ja selber, konnten also auch dafür sorgen, daß die Vermittlungsstellen mitspielen. Es gab ja auch mal die Option, über den D-Kanal etwas mehr Internet-Bandbreite zu bekommen, natürlich nur bei T-Online. Sinnvollerweise wird ein Firmwareupdate aber über den B-Kanal gehen, einfach weil's schneller geht. Der D-Kanal ist trotzdem interessant, weil es sein kann, daß ein spezielles Dienstmerkmal beim Anruf verwendet wird, um zu kennzeichnen, daß es sich um ein Firmwareupdate handelt.
Nosnibor schrieb: > Sinnvollerweise wird ein Firmwareupdate aber über den B-Kanal gehen, > einfach weil's schneller geht. Die Geschwindigkeit interessiert doch keinen. Ausserdem blockiert man so einen B-Kanal. Das möchte der Kunde im Zweifel gar nicht. (Und die T-kom vermutlich auch nicht, weil ihr dadurch Geld verloren geht) Gruß Jobst
> Die Geschwindigkeit interessiert doch keinen. woher kennst du die Datengröße bei dem Spiel? Bei jedem popeligen MB kostet das auch mehr Arbeitszeit des MA! > Ausserdem blockiert man so einen B-Kanal. Beim FW-Update könnte sogar eine Kanalbündelung greifen, weil dabei prinzipiell keine externe Funktion der Anlage aktiv sein sollte! > Das möchte der Kunde im Zweifel gar nicht. Dem ist das doch sowas von unbekannt, deswegen ist der doch darauf angwiesen, und als Laie wird der das eh nicht kapieren was dahinter steckt! > (Und die T-kom vermutlich auch nicht, weil ihr dadurch Geld verloren geht) Wie soll der T dabei bitte Geld verloren gehen? Bei einem solch lukrativen Geschäft muß man halt immer auch etwas ausgeben. Die AZ des MA und der des Systems wird um Längen über den Verbindungskosten liegen, und die sind im eigenen Netz eh nur das Rauschen im Wind. Ein Reseten einer Eumex 800 wegen vergessener PIN kostete zu letzt wieviel? Nosnibor (Gast) > Wenn das Firmwareupdate der Telefone eine Dienstleistung der Telekom > war, dann konnten die dafür selbstverständlich auch den D-Kanal > benutzen. der hat aber nur ein 1/4 der B-Kanal-Bandbreite! > Netzbetreiber waren sie ja selber, konnten also auch dafür sorgen, daß > die Vermittlungsstellen mitspielen. Und du meinst, die konfigurieren vorher noch den ISDN-Port in der VST auf X31 o.ä. dafür um, und hinterher wieder zurück ? > Es gab ja auch mal die Option, über den D-Kanal etwas mehr Internet- > Bandbreite zu bekommen, natürlich nur bei T-Online. das waren aber noch Zeiten, wo um jedes KB gekämpft und gehauen wurd! > Sinnvollerweise wird ein Firmwareupdate aber über den B-Kanal gehen, > einfach weil's schneller geht. einfach weil es damals zur Einführung der Technik nicht anders ging! Und heute sicherer ist als über IP! > Der D-Kanal ist trotzdem interessant, weil es sein kann, daß ein > spezielles Dienstmerkmal beim Anruf verwendet wird, um zu kennzeichnen, > daß es sich um ein Firmwareupdate handelt. Und wie geht das dann bei den heutigen IP-Anschlüssen? Mit einem SP921 o.ä. Spielkram wird man da wohl aufgeschmissen sein. VPN mit Ruf-Nr. Kennung geht auch nicht über IP, und der Video-Dienst, welchen manche TK-Anlagenhersteller zur Fernwartung einsetzen, ist auch nicht mehr über IP-Anschlüsse möglich. Laut deren Aussage.
TK-Elo schrieb: >> Die Geschwindigkeit interessiert doch keinen. > woher kennst du die Datengröße bei dem Spiel? Bei jedem popeligen MB > kostet das auch mehr Arbeitszeit des MA! Ich hoffe ehr nicht, dass dort jemand daneben sitzen muss. Noch weniger, dass es alle Mitarbeiter in einer Firma tun (müssen). >> Ausserdem blockiert man so einen B-Kanal. > Beim FW-Update könnte sogar eine Kanalbündelung greifen, weil dabei > prinzipiell keine externe Funktion der Anlage aktiv sein sollte! Ich kenne Anlagen, bei denen das geht. Die müssen anschließend nur neu gestartet werden (Bzw. starten sich selbst neu). >> Das möchte der Kunde im Zweifel gar nicht. > Dem ist das doch sowas von unbekannt, deswegen ist der doch darauf > angwiesen, und als Laie wird der das eh nicht kapieren was dahinter > steckt! Meine Annahme beruhte darauf, dass die Anlage während der Datenübertragung noch arbeitet. Egal. Gruß Jobst
> Ich hoffe ehr nicht, dass dort jemand daneben sitzen muss. Noch weniger, > dass es alle Mitarbeiter in einer Firma tun (müssen). das Smilie am Ende deines Satze vergessen? Der Techniker beim FernwartungsService muß aber dafür seine kostbare Zeit sinnloserweise für solche Banalitäten dann opfern? > Ich kenne Anlagen, bei denen das geht. ach da schau her, du auch? > Die müssen anschließend nur neu gestartet werden (Bzw. starten sich selbst > neu). wie soll das anders, auch ohne diesen Vorgang Neustart, auch gehen? > Meine Annahme beruhte darauf, dass die Anlage während der Datenübertragung > noch arbeitet. ja genau so lange, bis die Datei voll geladen ist, und der Vorgang dann alles andere beendet, wie bei einem BIOS-Update auf einem PC.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.