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.
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.
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.
