LAN-Anbindung

[Jens Hartmann]

So, und nochmal ich.

Ich sitze momentan vor einer ToDo Liste und versuch mal ein wenig zu definieren, auf welche Punkte ich momentan mein Augenmerk bei der Weitereinwicklung von meinem Programm legen sollte.

Einer in meinen Augen schönste Punkt, wäre die Anbindung meiner Hardware über LAN. Momentan, lese ich von einer Hardware über eine Druckerschnittstelle Ereignisdaten der Hardware ein.

Diese Hardware, bietet allerdings auch die Möglichkeit, mit einer anderen Software, dies Daten auch über LAN auszugeben. Es gibt zu dieser Hardware, auch ein Programm, womit man diese Daten empfangen kann. Allerdings nicht in dem Still wie ich es will, sondern dort werden die Daten zum Steuern einer weiteren Hardware verwendet.

Jetzt ist meine Frage eigendlich erstmal, kann man diese Daten die gesendet werden irgendwie mitschreiben, um mal zu lauschen was überhaubt gesendet wird.

Mein Problem wäre nämlich, das ich gerne wüßte wie schwer es würde eine LAN Anbindung zu realisieren. Wenn ich den Inhalt der Hardware richtig interpretiere, werden sogenannte Meldepunkte versendet, welche dann gewisse Bedeutungen haben, wie z.B...

Code:

9867 //Bedeutung "Alarm"
9866 //Bedeutung "Störung"

Vieleicht kann mir ja jemand sagen, ob es da einen Weg gibt, und wenn welchen.

Gruß Jens

[s.h.a.r.k]

Hm, das dürfte eher schwierig sein, außer du hast das Protokoll in den Händen. Du kannst dich ja mal mit Wireshark probieren, aber davon muss man Ahnung haben.

Das einfache Mitlauschen bei LAN kenne ich nicht wirklich, da die Pakete ja nicht für dich bestimmt sind, die über das LAN gehen. Vielleicht steht in der Doku was dazu, ob man einen Client bei dieser Hardware anmelden, oder wie man eine Verbindung dazu aufbauen kann. Nichts dazu gefunden?

[Jens Hartmann]

Das ist leider mein Problem, ich weiß nicht wie der ShakeHand ablaufen soll. Das Problem ist, du gibst in der Firmware der Hardware,

die IP auf welchem die vorhandene Software läuft an und in der Hardware sowie in der Software werden dann Passwort und Benutzername vereinbart, fertig.

Das heißt, ich stelle in der Hardware alle 3 par. ein, gebe diese in der vorhanden Software ein und die Daten kommen. Das wäre natürlich für uns das beste. Allerdings, vermute ich das mir der Hersteller der Software niemals das Protokoll geben wird.
Irgendeine Art der Anmeldung muss ja dahinter stecken. Allerdings denke ich, das die Hardware sich ja auch irgendwie melden muss, das Sie da ist.

Gruß Jens

[s.h.a.r.k]

Hm... Es kann sein, dass da ein Login ist, muss aber nicht. Eine TCP/IP-Verbindung machst du ja via IP und Port auf. Wenn du in der Kommandozeile netstat -a eingibts, so kannst du alle offnen Verbindungen sehen. So wäre es auch möglich, festzustellen, ob es sich um eine UPD oder TCP-Verbindung handelt.

Frag halt einfach mal lieb beim Hersteller nach ;) Ich weiß halt nicht wirklich, um was genau für Hardware es sich handelt.

[Jens Hartmann]

Also,

eine direkte Verbindung zur Hardware(Novar Einbruchmeldeanlage MB Serie) kann ich nicht feststellen (netstat -a)
(siehe Screenshot 1).

Allerdings, kann ich in einem Protokollfenster folgende Informationen sehen, wenn ich z.B. Tasten an einem Virtuellen Bedienteil betätige, sieht man die im Screenshot 2 kommenden Sende und Empfang Daten.

[taveuni]

Du könntest mit dem Process Explorer die aktive Verbindung sehen.
Es muss ja eine geben. Aber grundsätzlich schlag Dir das aus dem Kopf.
Es gibt 2 Möglichkeiten:
1.
Es gibt eine TCP/IP Schnittstelle des Herstellers und damit auch ein Protokoll.
So kannst Du Programme entwickeln welche über diese definierte Schnittstelle
mit dem Subsystem kommuniziert. Der Hersteller ändert dann normalerweise diese
nicht und Du bist einigermassen abgesichert.

2.
Es gibt kein offizielles Protokoll. Du mühst Dich mit Wireshark und unendlichen
Versuchen ab. Du investierst den 10-fachen Aufwand bis die Kommunikation einigermassen
steht. 2 Wochen später gibt es einen neuen Release der Firmware deines Systems
und das Protokoll hat komplett geändert...

Suchs Dir aus

Ein frohes neues Jahr

[Jens Hartmann]

Zitat:

Zitat von taveuni

2.
Es gibt kein offizielles Protokoll. Du mühst Dich mit Wireshark und unendlichen
Versuchen ab. Du investierst den 10-fachen Aufwand bis die Kommunikation einigermassen
steht. 2 Wochen später gibt es einen neuen Release der Firmware deines Systems
und das Protokoll hat komplett geändert...

Deine Bedenken versteh ich, allerdings denke ich, das es so gut wie unmöglich ist, das sich das Protokoll ändert, da ja dann die Gesamte Hardware, die dahinter hängen würde nicht mehr funktionieren würde. Soll heißen, bei jedem SoftwareUpdate der Zentrale, wäre ja auch eine Anpassung der Software Notwendig.

Da sich aber, z.B. die Software Version 1 einer alten Softwarevariante noch genau so nutzen lässt wie die aktuelle, und es mittlerweile sogar eine komplett neue Software gibt, kann sich das Protokoll eigendlich noch nie geändert haben.

Ich werde zwar mal beim Hersteller anfragen, aber ich vermute das ich da schlechte Karten haben werde.

Gruß jens

[Astat]

Zitat:

Zitat von Jens Hartmann

..., allerdings denke ich, das es so gut wie unmöglich ist, das sich das Protokoll ändert,..

Hallo Jens Hartmann, wenn das verwendeten Protokoll nicht sehr raffiniert verschlüsselt ist, sollte die Analyse
mit einem Netzwersniffer (Promiscuous mode) die gewünschten Informationen bringen.
Normalerweise sind solche Protokolle leicht nachzubauen.

Besorg dir Packetyzer

https://sourceforge.net/projects/packetyzer/

Lade dann den "Follow TCP-IP Flow" hoch, dann können wir Dir womöglich gleich weiterhelfen.

lg. Astat

[Jens Hartmann]

Hallo Astat,

schön das Du mir Hoffnung machst, also ich habe mir das Programm jetzt geladen, allerdings kommt nach dem Programmstart immer folgende Fehlermeldung.

NPPTool.dll not found

und naschließend

Wincap isnot loaded

Außerdem, was meinst Du mit

Zitat:

Zitat von Astat

Lade dann den "Follow TCP-IP Flow" hoch, dann können wir Dir womöglich gleich weiterhelfen.

Danke schon mal Gruß Jens

[s.h.a.r.k]

Dann lade dir die DLL halt schnell runter?

http://www.dll-files.com/dllindex/dl...shtml?npptools

[Astat]

Zitat:

Zitat von Jens Hartmann

..Wincap isnot loaded

Hallo Jens Hartmann.

Du musst Wincap auch installieren, sollte bei der Programminstallation mitinstalliert werden.
Meines wissens, erscheint da ein separater Dialog wenn der Wincap Treiber zu installieren ist.
Schau nochmals auf Sourceforge ob Du auch die Vollinstall gesaugt hast.
Du kannst natürlich auch einen anderen Networksniffer verwenden, Packetyzer ist aber mein Favorit.

Zitat:

Zitat von Jens Hartmann

..
Außerdem, was meinst Du mit
Lade dann den "Follow TCP-IP Flow" hoch, dann können wir Dir womöglich gleich weiterhelfen.

Nachdem Du den Netzwerkverkehr aufgezeichnet hast, unter

Reiter Connections, die betreffende Verbindung auswählen, und mit Show Packets und oder mit
Analyze TCP Flow, die Ergebnisse uns mitteilen.

Anbei gleich mal ein Server, an dem Du die zu empfangenden Pakete schon mal im Debuger ansehen kannst.
Du musst nur den Listening Port anpassen, und wenn die Kommunikation von Deiner Hardware TCP ist, dann siehst Du schon mal
was bei einem Verbindungsaufbau passiert. Sourcen musst Du natürlich an die Gegebenheiten eventuell leicht anpassen.

lg. Astat

[Jens Hartmann]

So,

hat bis jetzt wunderbar geklappt. Hier mal das Ergebniss.

Ich habe die Datei Decode.Cap in die Decode.Cap umbenannt.

Gruß Jens

[Astat]

Ja, sollte kein Problem sein.

Der Header ist so aufgebaut:

4Byte Längenangabe + 13 Byte Daten:

Delphi-Quellcode:

(** Request - Response (6 x Requests + Response)

00 00 00 0D C1 92 BD 73 2A BE 2E 47 24 F3 03 01
00 00 00 0D 2E 47 24 F3 2A BD C1 92 BD 74 03 01

00 00 00 0D C1 92 BD 74 2A BC 2E 47 24 F4 03 01
00 00 00 0D 2E 47 24 F4 2A BB C1 92 BD 75 03 01

00 00 00 0D C1 92 BD 75 2A BA 2E 47 24 F5 03 01
00 00 00 0D 2E 47 24 F5 2A B9 C1 92 BD 76 03 01


00 00 00 0D C1 92 BD 76 2A B8 2E 47 24 F6 03 01
00 00 00 0D 2E 47 24 F6 2A B7 C1 92 BD 77 03 01

00 00 00 0D C1 92 BD 77 2A B6 2E 47 24 F7 03 01
00 00 00 0D 2E 47 24 F7 2A B5 C1 92 BD 78 03 01

00 00 00 0D C1 92 BD 78 2A B4 2E 47 24 F8 03 01
00 00 00 0D 2E 47 24 F8 2A B3 C1 92 BD 79 03 01


Alle Requests sortiert

00 00 00 0D  C1 92 BD 73 2A BE 2E 47 24 F3 03 01
00 00 00 0D  C1 92 BD 74 2A BC 2E 47 24 F4 03 01
00 00 00 0D  C1 92 BD 75 2A BA 2E 47 24 F5 03 01
00 00 00 0D  C1 92 BD 76 2A B8 2E 47 24 F6 03 01
00 00 00 0D  C1 92 BD 77 2A B6 2E 47 24 F7 03 01
00 00 00 0D  C1 92 BD 78 2A B4 2E 47 24 F8 03 01

Alle Responses sortiert

00 00 00 0D  2E 47 24 F3 2A BD C1 92 BD 74 03 01
00 00 00 0D  2E 47 24 F4 2A BB C1 92 BD 75 03 01
00 00 00 0D  2E 47 24 F5 2A B9 C1 92 BD 76 03 01
00 00 00 0D  2E 47 24 F6 2A B7 C1 92 BD 77 03 01
00 00 00 0D  2E 47 24 F7 2A B5 C1 92 BD 78 03 01
00 00 00 0D  2E 47 24 F8 2A B3 C1 92 BD 79 03 01
**)

//--Headeraufbau
type
  TDataRec = packed record
    cbData : integer;
    Data1  : DWORD;
    Data2  : DWORD;
    Data3  : DWORD;
  end;

//-- Beispiel für Datenaufbereitung (Serverapplikation verwenden)
var
  DataRec: TDataRec;
  Buffer: array of Byte;
  ....
  //-- Im Socket Empfangsbuffer werden die 17 Bytes abgelegt.
  cbRcv := Recv(ClientSocket, Buffer[cb], 32768, 0);
  //-- Daten in die record struct schreiben
  move(Buffer, DataRec, SizeOf(TDataRec));
  
  //-- NetworkByteOrder
  DataRec.cbData := ntohl(DataRec.cbData);
  DataRec.Data1 := ntohl(DataRec.Data1);
  DataRec.Data2 := ntohl(DataRec.Data2);
  DataRec.Data3 := ntohl(DataRec.Data3);

Also starte den Testserver (Port kann als Start-Parameter übergeben werden), und
Debug alles durch ob der Header so passt, und du die erwarteten Daten bekommst.

Eventuell musst du noch ein Paar Bytes offsetten, aber Du kennst ja am ehesten die Daten, die du erwartest.
Einfach mal durchprobieren wenns nicht gleich geht, gibt ja nicht viele Möglichkeiten, bei so konstanter flacher
Headerstruktur.

Guten Rutsch, ich geh jetzt FEIERN!!

lg. Astat

[Jens Hartmann]

Danke erstmal für die Hilfe,

ich denke ich gehe jetzt auch erstmal feiern um einen klaren Kopf zu bekommen.

Irgendwie versteh ich das noch nicht so ganz. Aber vieleicht ist morgen ja besser.

Also, erst nochmal danke und auch einen guten Rutsch.

Gruß Jens

[Jens Hartmann]

Also,

ich habe mich jetzt den ganzen Nachmittag damit versucht zu beschäftigen. Leider ohne Erfolg. Ich weiß echt nicht wie ich das machen soll.

Ich finde noch nicht mal einen Anfang.

Vieleicht ist das doch noch eine Nummer zu Groß für mich.

Trotzallem, würde ich mich freuen, wenn Du mir das eventuell nochmal erklären könntest.

Gruß Jens

[Astat]

Zitat:

Zitat von Jens Hartmann

..erklären könntest.

Hallo Jens Hartmann, ich fasse mal alles zusammen, um sicherzustellen das wir vom selben reden.

1. Du hast eine Hardware, die mit einer Server-Software eine TCP/IP Socket Verbindung, zwecks Messdatenübermittlung unterhält.
2. Du möchtest herausfinden, wie das Protokoll zwischen Hardware und Server-Software aussieht, um im Endeffekt einen eigenen Software Server nachzubauen.

Was ist bisher bekannt?

1. Das Protokoll und der Datentransport über Socket

Das Protokoll besteht aus: 4 Byte Längenangabe + 13 Byte Daten
Das ist einfach so zu verstehen, dass 17 Byte Daten von deiner Hardware, in den Empfangsbuffer des Socket geschrieben werden.

Delphi-Quellcode:

cbRcv := Recv(ClientSocket, Buffer[cb], 32768, 0);

Weitere Vorgehensweise.

1. Du brauchst erstmals einen Server
2. Wie kann man nun auf die Längeninformationen die in den ersten 4 Byte des Header enthalten sind zugreifen.
3. Wie sind die restlichen 13 Byte Daten im Header aufgebaut, und wie kann man darauf zugreifen?


Also gehen wir dies mal der Reihe nach durch.
Punkt 1. Du brauchst erstmals einen Server. Wenn du gut in Socket API Programmierung eingearbeitet bist, kein Problem für Dich.
Wenn nicht, verwende den Server den ich Dir upgeloaded habe, dort sind nur recv und send für Dich interessant (Debug Breakpont).
Grundzüge der Socket API Programmierung sollten vorhanden sein, send, recv, select und Network Byte Order.
Socket API desshalb, weil für die Datenanalyse (13 Byte und Handshake = send) die API geeigneter ist, als eine Komponente.
Wenn Du genau die Internas einer Server-Komponente kennst, kannst Du natürlich auch diese verwenden.

Punkt 2. Wie kann man nun auf die Längeninformationen die in den ersten 4 Byte des Header enthalten sind zugreifen.
Da die Längeninformation in den ersten 4 Byte des Empfangsbuffers "Buffer" enthalten sind, einfach die ersten 4 Byte in eine
4 Byte Variable (integer) kopieren.

Delphi-Quellcode:

move(Buffer, IntegerVariable, SizeOf(Integer));

danach mit ntohl (TCP/IP network order to host byte order) in die Längeninfo umwandeln.

Auf Punkt 3. Wie sind die restlichen 13 Byte Daten im Header aufgebaut, und wie kann man darauf zugreifen?
möchte ich erst dann genauer eingehen, wenn du Punkt 1 + 2 (Server + Längeninformationen) hast.

lg. Astat

[Jens Hartmann]

Hallo Astat,

erstmal ganz großes Danke für die Erklärung. Ich glaube sogar, das ich das soweit verstanden habe. Ich habe mich jetzt mal mit den API Befehlen und mit deinem Server Programm versucht zu beschäftigen. Alles soweit verständlich. Allerdings habe ich noch zwei fragen.

1. Wenn ich dein Server Programm starte und die Breakpoints an den entsprechenden Stellen setzte, passiert erstmal gar nichts. Dann habe ich mir mal die Sachen im Form.Create angesehen.

Delphi-Quellcode:

  InitializeCriticalSection(_SocketLock);
  _wnd := handle;

  _bOnlyAccept := Pos('ONLYACCEPT', cmdline) <> 0;
  _Port := 8016;

  if ParamCount > 0 then begin
    {$R+}{$Q+}
    try
      _Port := 8016;//StrToInt(ParamStr(1)); Habe ich wegen Fehlermeldung raus Kommentiert. Und den Port hier auch auf 8016
                    //gesetzt.
                    //Wenn ich es richtig verstanden habe, muss hier der PORT für die Verbindung zur Hardware rein,der normal
                    // über einen Parameter der EXE gesetzt werden kann Programm.exe 8016 oder so
                    //Im Anhang habe ich mal einen Screenshot der Eigenschaften der Hardware
    except
      _Port := 8016;
    end;
    {$R-}{$Q-}
  end;

Jetzt meine Frage, muss ich jetzt irgendwie Daten senden, um welche empfange zu können. Oder muss eine Verbindung des Original Programms bestehen und ich lausch sozusagenmit.

Ist es relevant, wie ich im Netzwerk hänge. Mein Heimnetzwerk, ist über einen W-LAN Router aufgebaut. Und zwar in folgender Art & Weise...

Laptop mit Windows Vista über W-LAN -> Fritz-WLAN-Router -> Einbruchmeldeanlage über LAN-Anschluss direkt am Router

Danke nochmal, macht echt trotz schwierigkeiten voll Spass das hier zu tüfteln.

[EDIT] Anhang eingefügt. Sorry.

Gruß Jens

[Astat]

Zitat:

Zitat von Jens Hartmann

Delphi-Quellcode:

                    
  // Wenn ich es richtig verstanden habe, muss hier der PORT für die Verbindung zur Hardware rein,der normal
  // über einen Parameter der EXE gesetzt werden kann Programm.exe 8016 oder so
  // Im Anhang habe ich mal einen Screenshot der Eigenschaften der Hardware

Hm, ich dachte die Hardware verbindet sich zu Dir und nicht umgekehrt?

Zitat:

Zitat von Jens Hartmann

... Es gibt zu dieser Hardware, auch ein Programm, womit man diese Daten empfangen kann...

Ok, das finden wir auch noch raus "g".

Zitat:

Zitat von Jens Hartmann

Jetzt meine Frage, muss ich jetzt irgendwie Daten senden, um welche empfange zu können. Oder muss eine Verbindung des Original Programms bestehen und ich lausch sozusagenmit.

Nein, der Server horcht nun auf Port 8016. Deine Hardware musst du jetzt so einstellen, dass sich diese zum Port 8016
verbindet.

Teste das mal durch, und finde bitte heraus, wer nun wirklich der Client und der Server ist?

lg. Astat

[Jens Hartmann]

Also

die Hardware ist eine Einbruchmeldeanlage, auf die ich mich einloggen muss. Und zwar gibt es dafür zwei Varianten.

Die 1. Ist die Konfigurationssoftware der Zentrale. In dieser sage ich Verbindung herstellen, wie im Screenshot von meinem letzten Beitrag.

Die 2. Ist ein Managmentsystem, über welches ich mir an einem PC die Zuständen der Zentrale ansehen kann. Auch hier, wird beim Start der Software eine Verbindung zur Zentrale aufgebaut. Steht diese Verbindung, wird von der Zentrale kontinuierlich gesendet, und von der Software empfangen. Screenshot hier Einstellung Port 8015 (Bedarfsgesteuert)

Bedarfsgesteuert bedeutet in diesem Fall, das wenn eine Ereigniss auftritt, diese über TCP/IP versendet wird.

Also, müsste ja meine Software der Server und meine Hardware der Client sein.

Gruß Jens

[Astat]

Zitat:

Zitat von Jens Hartmann

Also, müsste ja meine Software der Server und meine Hardware der Client sein.

Naja, wenn ich das so lese, vermute ich mal Du bist der Client.

Anbei ein Client, zum testen.

Versuch mal damit eine Verbindung und ein Logon zu bekommen.

lg. Astat

[Jens Hartmann]

Das funktioniert nicht,

erst dauert es ein wenig und dann kommt folgende Fehlermeldung.

[Astat]

Zitat:

Zitat von Jens Hartmann

Das funktioniert nicht,

erst dauert es ein wenig und dann kommt folgende Fehlermeldung.

Nö, funkt anscheinend perfekt, ist eine WSAETIMEDOUT!

Also, btnConnect + warten bis im Memo1 connected + dann schnell btn SendDrücken!

Testen!

[Jens Hartmann]

Eben leider nicht.

Im Memo erscheint dieses Connect gar nicht. Ich habe auch mal in dem eintrag Memo1.Text einen Breakpoint gesetzt. Die Fehlermeldung kommt leider vorher.

[Astat]

Zitat:

Zitat von Jens Hartmann

Eben leider nicht.

Im Memo erscheint dieses Connect gar nicht. Ich habe auch mal in dem eintrag Memo1.Text einen Breakpoint gesetzt. Die Fehlermeldung kommt leider vorher.

Port und IP überprüfen, versuchen mit Telnet eine Verbindung aufzubauen!

[Jens Hartmann]

Die Einstellungen stimmen.

Mit Telnet bekomme ich allerdings scheinbar eine Verbindung. Da ich Windows Vista nutze, musste ich mir allerdings folgende Telnetvariante laden.

Telenet

[Astat]

Zitat:

Zitat von Jens Hartmann

Die Einstellungen stimmen.

Mit Telnet bekomme ich allerdings scheinbar eine Verbindung. Da ich Windows Vista nutze, musste ich mir allerdings folgende Telnetvariante laden.

Telenet

Naja, der Telnet Client funktioniert genauso wie der Demo Client.

Hab somit keine weiteren Tips mehr, leider!

lg. Astat

[Jens Hartmann]

So,ich habe das ganze jetzt nochmal in Delphi neu geschrieben, und es funktioniert. Irgendwie stimmt was nicht mit dem Projekt. Seltsamerweise, würde an keiner Stelle ein Breakpoint genommen. Noch nichtmal bei einem ShowMessage im Btn.Click.

Zusätzlich habe ich jedem Ereignis der TClientSocket eine Eintrag ins TMemo verpasst und bekomme nach dem Programmstart die folgenden 4 Einträge...

Code:

OnLookup
OnConnecting
OnConnect
OnWrite

in genau dieser Reihenfolge.

Hier mal der aktuelle Code.

Delphi-Quellcode:

var
  _Buffer : array [0..16] of Byte = (
    $00, $00, $00, $0D,
    $C1, $92, $BD, $73,
    $2A, $BE, $2E, $47,
    $24, $F3, $03, $01,
    $00);

function Write(ptrData: Pointer; cbData: integer): Boolean;
var
  ret, cbRcv, cb, cbRead: integer;
  sockaddr: TSockAddr;
  WSData: TWSAData;
  szBuf: array of char;
  ClientSocket: TSocket;
begin
  result := false;
  if (ptrData = nil) or (cbData <= 0) then EXIT;
  ClientSocket := 0;
  try
    ret := WSAStartup($0020, WSData);
    if (ret <> S_OK) then EXIT;

    ClientSocket := Socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
    if (ClientSocket = INVALID_SOCKET) then EXIT;

    FillChar(sockaddr, SizeOf(TSockAddr), #0);

    with sockaddr do begin
      sin_Family := AF_INET;
      sin_Port   := htons(8016);
      sin_Addr   := TInAddr(Inet_Addr(PChar('192.168.178.75')));
    end;

    ret := Connect(ClientSocket, sockaddr, SizeOf(sockaddr));
    if (Ret = Socket_Error) then EXIT;

    ret := Send(ClientSocket, ptrData^, cbData, 0);
    if (ret = SOCKET_ERROR) then EXIT;

    setlength(szBuf, 32768 * 2);

    cb := 0;
    szBuf[0] := #0;

    while true do begin
      ret := ioctlsocket(ClientSocket, FIONREAD, cbRead);
      if (ret = SOCKET_ERROR) then EXIT;
      if cbRead = 0 then break;

      cbRcv := Recv(ClientSocket, szBuf[cb], 32768, 0);
      if cbRcv = 0 then EXIT;

      if (cbRcv = WSAECONNRESET) or (cbRcv = SOCKET_ERROR) then EXIT;

      cb := cb + cbRcv;
      if cb + 32768 > Length(szBuf) then SetLength(szBuf, Length(szBuf) * 2);
    end;

    result := true;
  finally
    if ClientSocket > 0 then begin
      ShutDown(ClientSocket, SD_BOTH);
      Closesocket(ClientSocket);
    end;
    WSACleanup;
  end;
end;

procedure TForm1.ClientSocket1Connect(Sender: TObject;
  Socket: TCustomWinSocket);
begin
  Memo1.Lines.Add('OnConnect');
end;

procedure TForm1.ClientSocket1Connecting(Sender: TObject;
  Socket: TCustomWinSocket);
begin
  Memo1.Lines.Add('OnConnecting');
end;

procedure TForm1.ClientSocket1Disconnect(Sender: TObject;
  Socket: TCustomWinSocket);
begin
  Memo1.Lines.Add('OnDisConnect');
end;

procedure TForm1.ClientSocket1Error(Sender: TObject; Socket: TCustomWinSocket;
  ErrorEvent: TErrorEvent; var ErrorCode: Integer);
begin
  Memo1.Lines.Add('OnError');
end;

procedure TForm1.ClientSocket1Lookup(Sender: TObject; Socket: TCustomWinSocket);
begin
  Memo1.Lines.Add('OnLookup');
end;

procedure TForm1.ClientSocket1Read(Sender: TObject; Socket: TCustomWinSocket);
begin
  Memo1.Lines.Add('OnRead');
end;

procedure TForm1.ClientSocket1Write(Sender: TObject; Socket: TCustomWinSocket);
begin
  ClientSocket1.Socket.SendBuf(_Buffer, Length(_Buffer));
  Memo1.Lines.Add('OnWrite');
end;

procedure TForm1.btnLogonClick(Sender: TObject);
begin
  ClientSocket1.Socket.SendBuf(_Buffer, Length(_Buffer));
end;

Ich denke das, das so ganz gut aussieht. Allerdings weis ich nicht, ob meine Hardware mich als USER akzeptiert.

[EDIT]Astat, ich habe gerade gelesen, das Du mit Lazarus arbeitest. Kann es sein, das ich dadurch den Client nicht sauber geöffnet bekommen habe.

Gruß Jens

[Astat]

Zitat:

Zitat von Jens Hartmann

So,ich habe das ganze jetzt nochmal in Delphi neu geschrieben, und es funktioniert.

Jup, damit kann man nun arbeiten.

Zitat:

Zitat von Jens Hartmann

..ich habe gerade gelesen, das Du mit Lazarus arbeitest. Kann es sein, das ich dadurch den Client nicht sauber geöffnet bekommen habe.

Nein, sollte die client.dof und die Client.dcu im lib Verzeichnis, dran schuld sein, einfach löschen, und projekt danach mit Delphi öffnen.

Nun, wenn das Programm jetzt eine Verbindung zum Server hat, versuch mal den nächsten Buffer mit diesen Daten zu senden.
00 00 00 0D C1 92 BD 74 2A BC 2E 47 24 F4 03 01 00

und lese die Daten die du vom Server bekommst in das Memo ein.
Es sind Binärdaten, diese eventuell in Hex umwandeln.

Wenn du den richtigen Port hast, sollten nun permanent Daten gesendet werden.

Wichtig ist, dass alles genauso abläuft, wie bei deiner Netzweraufzeichnung.
D.h. User + Passwort + Port, also alles mit identischen Parametern.
Denn in den 13 Byte Daten sind user und Pwrd drinnen, eventuell noch ein Identifier mit 1 Byte.
Da du die Daten für das Logon kennst, User + Pwrd, kannst Du nun Rückschlüsse auf die 13 Byte Daten ziehen.
Dies musst Du Checken.

Zieh Dir nochmals Tread #13 rein.

Lass auch den Packetizer nebenbei laufen, dann siehst Du gleich welche Daten zurückkommen, und ob auch der richtige
Kanal der Hardware verwendet wird (Messaging Port) und nicht der Konfigurationsport.


lg. Astat

[Jens Hartmann]

Hab das jetzt gemacht und mal aufgezeichnet. Datei und Screenshot liegt im Anhang.
Es scheint aufjedenfall schon so zu sein, das meine Hardware erkennt, das da jemand was will.
Was ich jetzt nicht so ganz verstanden habe, ist das mit den Zugangsdaten.

Ich brauche ja folgende Zugangsdaten.

Code:

Passwort: 12345678
IdentNr.: 12345678
Code: 12345678

Wie kann ich die jetzt senden, und vorallem wann muss ich diese senden. Ist das ansonsten schon so wie ich mir das vorstellen muss.

Gruß Jens

[Astat]

Zitat:

Zitat von Jens Hartmann

Ich brauche ja folgende Zugangsdaten.

Code:

Passwort: 12345678
IdentNr.: 12345678
Code: 12345678

Wie kann ich die jetzt senden, und vorallem wann muss ich diese senden. Ist das ansonsten schon so wie ich mir das vorstellen muss.

Gruß Jens

OK, der _Buffer ist falsch, mit untenstehender Anmeldung versuchen, (Jeder 2. Hexwert lt. Thread #13 ist das was der Client sendet.)

1.
00 00 00 0D 2E 47 24 F3 2A BD C1 92 BD 74 03 01 00

2.
00 00 00 0D 2E 47 24 F4 2A BB C1 92 BD 75 03 01 00

Frage, die Zugangsdaten, sind die alle numerisch, weisst du die max länge der einzelnen Daten?
ISt wichtig, da diese ja in den 13 Byte stecken?

Astat

[Jens Hartmann]

Zitat:

Zitat von Astat

Frage, die Zugangsdaten, sind die alle numerisch, weisst du die max länge der einzelnen Daten?
ISt wichtig, da diese ja in den 13 Byte stecken?

Identnummer max. Länge 12 Zeichen numerisch. Länge flexibel. Kann also auch nur die 1 sein

Passwort wie Identnummer

Code max. Länge 8 Zeichen numerisch. Länge immer 8 Zeichen. Sonst muss man in der Hardware 00000001 eingeben. Die vorstehenden
Nullen aind aber Pflicht, werden sonst durch die Hardware aufgefüllt.


[EDIT] Und noch die aktuellen Anhänge der Datenverbindung.

[Jens Hartmann]

So, habe bis jetzt noch gebastelt.

Ich bin zwar noch nicht wirklich weiter, habe aber über den "Packetyzer" mal noch ein bißchen was heraus gefunden.

Und zwar, wenn ich eine Verbindung mit der Konfigurationssoftware zur Hardware aufbaue, Anhang "Aufzeichnung2" kann ich das mit den 17Byte erkenne. Außerdem, wird diese Meldung scheinbar ständig wiederholt. So eine Art polling.

Schaue ich mir mal die "Aufzeichnung1" an, kann man im unteren Teil sogar ein wenig Text erkennen, welchen ich eigendlich auch ausgeführt habe.

Und zwar, habe ich über ein Virtuelles Bedienteil die Hardware Bedient und eine Meldegruppe extern gesperrt. Genau diesen Text, kann man gestückelt im Anhang zwei auch erkennen.

Das müsste eigendlich ein gesendetes Ereigniss von meinem PC zur Hardware sein.

Vieleicht hilft Euch (Dir Astat) das ja weiter, mir zu Helfen.

Gruß und danke nochmal

Jens

[Astat]

Hallo Jens, es ist jetzt wieder Zeit für eine Bestandsaufnahme.

Mitlerweile sind einige Zusätzliche Programme aufgetaucht, wie "Konfigurationssoftware für Hardware", "Virtuelles Bedienteil".
Der Header mit den 17 Byte gehört, wie ich erst jetzt herausgefunden habe nicht zum Programm für die Anmeldung??
Da ging die Analyse vollkommen in die falsche Richtung.

Anmeldeinfos:

Identnummer: max. 12 Zeichen numerisch.
Passwort : max. 12 Zeichen numerisch.
Code : const 8 Zeichen numerisch Fixe Länge, Format 00000001, Nullen sind Pflicht.

Zitat:

..Es gibt zu dieser Hardware, auch ein Programm, womit man diese Daten empfangen kann.

Anscheinend gibt es zwei, eins für die Anmeldung und eins um Daten, wenn angemeldet, zu empfangen??

Also folgendes ist notwendig:

1. Grafik mit allen beteiligten Komponemten auf Verbindungsebene.
2. Wer kommuniziert mit wem, auf welchem Port, IP und mit welcher Identnummer + Passwort + Code
3. Sequenzdiagramm der Verwendung und des Verbindungsaufbaus (A connectet sich nach B und gibt Logoninfos ein, C Connectet sich und empfängt von D Daten etc.)
4. Wer spielt Server und wer den Client.
5. Welches Programm soll ersetzt werden.
6. Detailierte lückenlose Aufzeichnungen desjenigen Programms, das ersetzt werden soll (beginnend mit Connect + Logon + Date + Ende)
7. Einen Eigenbau Client oder Server der Daten empfangen und ausgeben Kann (ASCII + HEX), ohne einen solchen, und ohne sich mit
der Materie genauer zu beschäftigen wirds nicht gehen. Als Vorlage kannst Du die Upgeloadeten Client und Server Sourcen verwenden.

8. Detailierte lückenlose Aufzeichnungen des eigenbau Client oder Servers, (beginnend mit Connect + Date + Ende)

ACHTUNG: alle Aufzeichnungen müssen immer unter gleichen Bedingungen erfolgen (Identische Logondaten, und Aktionen auf oder mit dem Server)

Wenn Du das alles hast, sag bescheid.

lg. Astat

[Jens Hartmann]

Hallo Astat,

Zeit das ganze nochmal anzupacken.
Ich versuche das ganze jetzt mal komplett und genau zu Beschreiben und zusammen zu fassen und hoffe das der Text nicht zu trocken ist und ihn somit keiner mehr ließt. Aber kürzer geht einfach nicht. Ich denke bald es ist ein "Mammutprojekt"... OhJe :gruebel:

Zitat:

Zitat von Astat

Mitlerweile sind einige Zusätzliche Programme aufgetaucht, wie "Konfigurationssoftware für Hardware", "Virtuelles Bedienteil".

1. Die Hardware ist eine Einbruchmeldeanlage vom Hersteller Honeywell/Novar Typ MB256plus

2. Es gibt eine Konfigurationssoftware, in der man die gesamte Hardware die an diese Zentrale angeschlossen ist konfigurieren kann.
Das wiederum bedeutet, dass ich mit dieser Software konfigurieren kann, wann und wie, welcher Einbruchmeldekontakt(Bewegungsmelder, Fensterkontakte etc.) was macht(z.B. Alarmauslösen Einbruch, Alarmauslösen Überfall etc).

3. Des weiteren kann man mit dieser Software ein sogenanntes virtuelles Bedienteil
aufrufen, mit welchem man die Einbruchmeldeanlage auch Bedienen kann. Einen
Screenshot von dem Bedienteil findest Du in Anhang 1.
Bedienvorgängen wären z.B. das ansehen des aktuellen Zustands nach einem Alarm
oder das Abschalten eines Einbruchmeldekontaktes etc.

4. Dann gibt es da nach eine Software, mit der man so eine Art Gebäudemanagment realisieren kann. An diese Software kann man verschieden Hardware anbinden, und in
dessen Oberfläche dann z.B. Grundrisse, Gebäudeteile etc. anzeigen und auswerten.
In diese Grundrisse werden die Einbruchmeldekontakte graphisch integriert und
können ausgewertet werden. Für diese Auswertung, wird auch eine Verbindung zur Hardware aufgebaut. Bei Zustandsänderung (Fenster offen oder Fenster zu) wird dieses von der Zentrale an die Software weitergeleitet, damit diese z.B. ein graphisches Viereck einmal Grün und einmal Rot darstellen kann.

Die Funktion von dieser Software benötige ich eigentlich. Ich möchte nicht diese riesig aufgepeppte Software nutzen, sondern ich möchte lediglich die Betriebsereignisse und Zustände der Einbruchmeldeanlage wissen, um später folgende Verarbeitung damit durchzuführen.

1.Nachnildung von einem Ereignisspeicher in beliebiger Form. z.B.

Code:

  Fenster Wohnzimmer AUF
  Fenster Wohnzimmer ZU  etc.

Diese Ereignisse, bekomme ich momentan über die serielle Schnittstelle der Hardware. Allerdings bin ich damit örtlich gebunden und das möchte ich nicht. Ich will halt die Möglichkeit nutzen, da die Hardware diese Daten über das Netzwerk eh weitergibt, um diese dann an einem beliebigen Arbeitsplatz auswerten zu können.

Zitat:

Zitat von Astat

Anmeldeinfos:

Identnummer: max. 12 Zeichen numerisch.
Passwort : max. 12 Zeichen numerisch.
Code : const 8 Zeichen numerisch Fixe Länge, Format 00000001, Nullen sind Pflicht.

Ja genau..

Zitat:

Zitat von Astat

Anscheinend gibt es zwei, eins für die Anmeldung und eins um Daten, wenn angemeldet, zu empfangen??

Falsch, es gibt zwar 2 Programme, allerdings benötigen beide die selbe Anmeldung und sin unabhängig von einander.

Zitat:

Zitat von Astat

1. Grafik mit allen beteiligten Komponemten auf Verbindungsebene.

siehe Anhang 2

Zitat:

Zitat von Astat

2. Wer kommuniziert mit wem, auf welchem Port, IP und mit welcher Identnummer + Passwort + Code

Einbruchmeldeanlage mit Konfigurationssoftware Winfem über Port 8016 mit Identnummer:12345678,Passwort:12345678,Code:123456 78
oder, und das weiß ich halt nicht genau...
Konfigurationssoftware Winfem mit Einbruchmeldeanlage über Port 8016 mit Identnummer:12345678,Passwort:12345678,Code:123456 78

Einbruchmeldeanlage mit Gebäudemanagmentsoftware über Port 8015 mit Identnummer:12345678,Passwort:12345678,Code:123456 78
oder, und das weiß ich halt nicht genau...
Gebäudemanagmentsoftware mit Einbruchmeldeanlage über Port 8015 mit Identnummer:12345678,Passwort:123456,Code:12345678

Passwort, darf nur einmal vergeben sein, deshalb Gebäudemanagmentsoftware bei mir anders eingestellt wie Konfigurationssoftware.

Zitat:

Zitat von Astat

3. Sequenzdiagramm der Verwendung und des Verbindungsaufbaus (A connectet sich nach B und gibt Logoninfos ein, C Connectet sich und empfängt von D Daten etc.)

Ich denke zu wissen, das es bei beiden eigendlich identisch sein muss. Soll heißen....
Software logt sich auf Einbruchmeldeanlage an, kann jeweils Daten empfangen und auch senden.Ich kann aus beiden Programme auch die oben gannten Steuerungen ausführen. Daher LOGIN der Software und anschließender Duplexdatenverkehr.

Notwendig für meine Anwendung wäre zunächst allerdings nur der LOGIN mit anschließendem Datenemfang. Die Absicht zu Bedienen etc. habe ich momentan nicht.

Zitat:

Zitat von Astat

4. Wer spielt Server und wer den Client.

Das kann ich dir momentan leider nicht beantworten. Nur da ich mich ja zuerste einloggen muss, vermute ich, das ich als PC der Client bin. Ich kann ja auch mehrer Zentrale gleichzeitig Verwalten.

Zitat:

Zitat von Astat

5. Welches Programm soll ersetzt werden.

Eigendlich das zweite, allerdings halt wie oben schon mal erwähnt in völlig abgespeckter Version. Ich will lediglich Ereignisse als Tabelle speichern und eventuell eine Zustandsanzeige der aktuellen Meldungen realisieren. Das mit der Zustandsanzeige ist auch der Hauptgrund, warum ich diesen Aufwand betreiben möchte. Ich will mir eine graphische Oberfäche bauen, in der ich über folgende INFO´S mit die Zustände der Meldegruppen ansehen kann. (Anhang 3)

Zitat:

Zitat von Astat

6. Detailierte lückenlose Aufzeichnungen desjenigen Programms, das ersetzt werden soll (beginnend mit Connect + Logon + Date + Ende)

Werde das jetzt mal aufbauen und die Daten mitschreiben. Kommen später, ist etwas aufwendiger. Bislang habe ich dir Daten von der Konfigurationssoftware gesendet, die allerdings so denke ich identisch sein müssten. Aber um sichwer zu gehen, bekommst Du die die wirklich benötigt werden.

Zitat:

Zitat von Astat

7. Einen Eigenbau Client oder Server der Daten empfangen und ausgeben Kann (ASCII + HEX), ohne einen solchen, und ohne sich mit
der Materie genauer zu beschäftigen wirds nicht gehen. Als Vorlage kannst Du die Upgeloadeten Client und Server Sourcen verwenden.

Das wird wohl noch etwas schierig für mich. Aber ich werde kämpfen.

So, ich hoffe ich konnte das jetzt alles mal so einigermaßen zusammenstellen. Ich finde es total faszinierend mich damit zu beschäftigen, allerdings fällt es mir halt wegen den Kentnissen über die Materie etwas schwerer. Eigendlich wäre ich jetzt an einem Punkt diesen Punkt in meinem Programm zu verschieben, da ich mich selber noch sehr schwer damit tue. Andereseits, ist es jetzt wie immer, einmal angefangen wird es schwer bist zur Lösung aufzuhören.

Danke nochmal für die großartige Unterstützung. :thumb:

[EDIT]Übrigens die Gebäudemangmentsoftware wird über Event-Protokoll angebunden[/EDIT]
Gruß Jens

[Klaus01]

Hallo Jens,

was spricht jeden ein Gerät das
eine Umsetzung von seriell auf Ethernet macht?
Da wird dich die Hardware etwas kosten - aber
Du müsstest Dein Programm nicht ganz so viel umbauen.

Grüße
Klaus

[Jens Hartmann]

Zitat:

Zitat von Klaus01

was spricht jeden ein Gerät das
eine Umsetzung von seriell auf Ethernet macht?

Hallo Klaus, von der Sache her spricht da nichts gegen. Ich habe allerdings zwei sachen, die ich so nicht realisiert bekomme.

1. Würde ich gerne Zentral einen Rechner mit meinem Programm laufen habe, der aber von mehreren Zentralen die Daten bekommen soll.
Dabei hätte ich schon das Problem mit den Anzahl der seriellen Schnittsstellen am PC. Gut, könnte man eventuell auch noch lösen.

2. Und das ist das größere Problem, auf der vorhanden seriellen Schnittstelle werden Daten, wann immer diese entstehen ausgegeben. Sollte jetzt mal die Verbindung nicht vorhanden sein, weiß meine Software die Zustände nicht mehr.

Das ist zwei beim Netzwerk auch so, aber über die Netzwerkschnittstelle, wird nach aufbau einer Verbindung Syncronisiert. was mir die Möglichkeit gibt, nach jedem Programmstart und Verbindung zur Anlage den Status zu 100% aktuell zu sehen.

Bei serielle, bekomme ich niemals eine Syncronisation hin. Die Daten die ich nicht empfangen habe, sind einfach weg. Die Hardware ballert diese einfach nur ohne jegliche Kontrolle auf der Schnittelle raus.

Das ist leider mein Problem, oder besser gesagt mein Wunsch dem abhilfe zu schaffen. Und da ich die Standard-Software viel zu aufgeblustert finde, bin ich auf diesen Gedanken gekommen.

Trotzdem Danke

Gruß Jens

[Jens Hartmann]

So, jetzt auch die Daten mal komplett,

Logon -> Verbindung Beendet

Gruß Jens

[Astat]

Zitat:

Zitat von Jens Hartmann

So, jetzt auch die Daten mal komplett,

Logon -> Verbindung Beendet


.....

4. Dann gibt es da nach eine Software, mit der man so eine Art Gebäudemanagment realisieren kann. An diese Software kann man verschieden Hardware anbinden, und in
dessen Oberfläche dann z.B. Grundrisse, Gebäudeteile etc. anzeigen und auswerten.
In diese Grundrisse werden die Einbruchmeldekontakte graphisch integriert und
können ausgewertet werden. Für diese Auswertung, wird auch eine Verbindung zur Hardware aufgebaut. Bei Zustandsänderung (Fenster offen oder Fenster zu) wird dieses von der Zentrale an die Software weitergeleitet, damit diese z.B. ein graphisches Viereck einmal Grün und einmal Rot darstellen kann.

Die Funktion von dieser Software benötige ich eigentlich. Ich möchte nicht diese riesig aufgepeppte Software nutzen, sondern ich möchte lediglich die Betriebsereignisse und Zustände der Einbruchmeldeanlage wissen, um später folgende Verarbeitung damit durchzuführen.

......

Einbruchmeldeanlage mit Gebäudemanagmentsoftware über Port 8015 mit Identnummer:12345678,Passwort:12345678,Code:123456 78
oder, und das weiß ich halt nicht genau...
Gebäudemanagmentsoftware mit Einbruchmeldeanlage über Port 8015 mit Identnummer:12345678,Passwort:123456,Code:12345678

Hallo Jens, die Aufzeichnung ist mit Port 8016 und nicht wie von Dir angegeben von Port 8015 (Gebäudemanagment, das Du ja anzapfen willst)

stimmt da was nicht?

lg. Astat

[Jens Hartmann]

Zitat:

Zitat von Astat

Hallo Jens, die Aufzeichnung ist mit Port 8016 und nicht wie von Dir angegeben von Port 8015 (Gebäudemanagment, das Du ja anzapfen willst)

stimmt da was nicht?

Hallo Astat,

doch das ist schon OK. Ich habe an meiner Testanlage nur Port 8016 eingerichtet und greife mit beiden System darauf zu. Den Port kann man frei wählen.

Im Standardfall, werden wenn ein Kunde beide System betreibt die Port´s so eingestellt.

Da es aber bei mir eine Testanlage ist, ist das so OK. Ich gehe ja immer nur mit einem System an die Zentrale und nie Gleichzeitig mit beiden.

Ich kann die aber einen Mitschnitt mit dem anderen Port machen, wenn wir das brauchen.

Gruß Jens

[Astat]

Hallo, Jens jetzt noch folgendes.

TCP-IP View downloaden, um zu sehen ob die Software der Client oder der Server ist?
http://technet.microsoft.com/de-de/s.../bb897437.aspx

Stimmt das, dass User, Pwrd, Ident 12345678 ist?, und keine Verschlüsselung verwendet wird?

lg. Astat