Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
das ist nicht verwunderlich. Denn innerhalb eines IP Segments wird über ARP adressiert und basiert auf MAC Adressen. Jedes Interface hält dazu eine Liste von Mapping-tabellen. Alle Interfaces fragen sich im Segment immer wieder welche MAC hat IP:... Erzähl es IP:....
Mit Wireshark kann man das nett mitlesen, kann ich nur empfehlen
Sag ich doch - hat mit seriöser Netzwerktechnik nix zu tun - das ist gepfusche vom Feinsten! Lass da mal jemanden nach dem Fehler suchen, wenn die Pakete plötzlich nicht mehr ankommen - welcher normal denkende Netzwerker vermutet "absichtlich" eingerichtete PC's mit identischer IP /MAC im Netz
Normalerweise sollte sich einer der PCs, zumindest wenn sie unter Windows laufen, mit einem Adresskonflikt abschalten. Ich hatte da da mal einen lustigen Fall. Wir hatten einen Server aus Altersgründen abgeschaltet und durch eine virtuelle Maschine ersetzt. Die IP-Adresse war die selbe. Aufgrund eines Unfalls bei Arbeiten am Notstromdiesel ist es im gesamten RZ zu einem Stromausfall gekommen. Nach und nach wurden alle Maschinen wieder eingeschaltet. Auch die stillgelegte. Die Anwendung hat dann nicht mehr richtig funktioniert. Zeitweise konnte ich mich mit RDP auf der Maschine verbinden und habe sie durchgestartet. Ich konnte mich von diesem Zeitpunkt an gar nicht mehr verbinden. Ich hab es dann mit VNC probiert, obwohl ich wusste, dass das auf der virtuellen Maschine gar nicht installiert ist. Ergebnis war, dass ich auf der alten Kiste gelandet bin. Seit dem ist die alte Maschine physisch vom Netz getrennt.
Lass da mal jemanden nach dem Fehler suchen, wenn die Pakete plötzlich nicht mehr ankommen - welcher normal denkende Netzwerker vermutet "absichtlich" eingerichtete PC's mit identischer IP /MAC im Netz
Du musst dich nur reinversetzen...
Genau wie ein SSO Login (vor Kurzem gesehen). Da war wohl "Kostenoptimierung" im Spiel. Nur der Laptop des Managers sollte Zugriff haben. Die "Software" war extern eingekauft worden.
Die Lösung ist denkbar einfach. Man nehme "Ich bin BWLer, hab 0 Plan, aber Kostenoptimierung" und "Ich bin Inder, hab ne Kurzschulung gemacht, und erstells für 100€".
Ähnlich sind im Übrigen auch "Verschlüsselungen" diverser Netzwerkprotokolle aufgebaut.
Zertifikate findest du meistens hartcodiert irgendwo im Sourcecode.
Bei .NET hast du es in wenigen Minuten...
So und das wird man im NORMALFALL natürlich so nicht machen.
Sag ich doch - hat mit seriöser Netzwerktechnik nix zu tun - das ist gepfusche vom Feinsten! Lass da mal jemanden nach dem Fehler suchen, wenn die Pakete plötzlich nicht mehr ankommen - welcher normal denkende Netzwerker vermutet "absichtlich" eingerichtete PC's mit identischer IP /MAC im Netz
Wie willst du Daten von PC1 mit IP 192.168.1.2 und MAC 08-00-27-00-44-6C auf den PC2 mit IP 192.168.1.2 und MAC 08-00-27-00-44-6C schicken - das erklär mir mal!
Nein, die Situation ist Anders!
Du hast 2 Clients (beide 192.168.1.2) und einen Server (192.168.1.3).
Der Client soll ein UDP Paket an den Server schicken, um sich "anzumelden" und eines um sich "abzumelden". Im angemeldeten Zustand sendet der Server UDP-Pakete an den Client.
(vereinfacht dargestellt).
Client A sendet nun von IP Adresse 192.168.1.2 das Anmeldepaket an den Server, der Server sendet ab diesem Zeitpunkt einen permanenten Stream an 192.168.1.2.
Client B sendet wiederum von IP Adresse 192.168.1.2 (also die Gleiche) ein Anmeldepaket. Der Server trägt B nicht in die Clientliste ein, da er Client A und B nicht unterscheiden kann und "denkt" er haben den Client bereits in seiner Liste.
So und je nach Netzwerkhardware funktioniert das jetzt tatsächlich, auf "IP Ebene" sogar sicher!
So und das wird man im NORMALFALL natürlich so nicht machen. Nehmen wir jetzt aber an, jemand erstellt für die Clientseite eine virtuelle Maschine mit hardcodierter Mac und IP.
Diese verteilt er nun, und so eine Situation kann real entstehen!
So, und das bitte mal in "der Natur" debuggen!
Falls jetzt kommt: "Gibts nicht!", da habe ich noch die Story einer "betriebswirtschaftlichen Standardsoftware" in VBA geschrieben auf Lager, welche auf eine Access-Datenbank (hardcodiert) mit hardcodiertem Passwort auf einem Windows-Server (Freigabe auf XP Rechner) zugreift.
@rb84
Sorry - aber das hat mit seriöser Netzwerktechnik nichts zu tun!
"Um eine Kommunikation zwischen zwei technischen Geräten aufzubauen, muss jedes der Geräte in der Lage sein, dem anderen Gerät Daten zu senden. Damit diese Daten bei der richtigen Gegenstelle ankommen, muss diese eindeutig benannt (adressiert) werden."
Wie willst du Daten von PC1 mit IP 192.168.1.2 und MAC 08-00-27-00-44-6C auf den PC2 mit IP 192.168.1.2 und MAC 08-00-27-00-44-6C schicken - das erklär mir mal!
Mal ne bescheiden Frage: wie hast du denn das an's laufen bekommen - zwei PC's mit identischer IP-Konfiguration (MAC UND IP) zu gleichen Zeit im gleichen Netz?
Das mit dem "nicht filtern" war falsch von mir ausgedrückt: Wenn ICH Netzwerkprotokolle entschlüssel, dann nehme ich 2 Systeme, mehr nicht!
Nur darauf war es gemeint.
Zum Thema: Mehrere Systeme mit gleicher IP/MAC: Klar geht das, es wird nur nicht wirklich richtig funktionieren, was ja auch der Grund fürs Debugging war
So ähnlich kann man das ja auch beim Spoofing machen: Das Switch "denkt" dann beispielsweise, an Steckplatz 1 UND Steckplatz 2 sei das gleiche Gerät. Teilweise wird dann das Paket eben an beide Steckplätze gesendet.
Nehmen wir jetzt mal an, es wird beim Protokoll normalerweise Broadcast genutzt, und die Clients "lauschen" nur, dann kann das tatsächlich funktionieren, 2 Systeme mit identischer Mac/IP im Netz. Zumindest so ein bischen...
Derartige Späße schafft man immer wieder. Ohne hoffentlich zuuu arg OT zu gehen: Um Router zu "verstecken" wurden die Router so konfiguriert, dass TTL nicht reduziert wurde. Gleichzeitig wurde eine bestimmte Trafficart "umgeleitet". Das waren nur wenige Byte/Stunde. Ok, trotzdem im Ring geroutet unschön :P
Vielen, vielen Dank für eure Hilfe aber ich hab soeben das Problem gelöst.
Fehlerursache: In der Wasseraufbereitungsanlage, die das Protokoll an den Moxa sendet, war das Protokoll nicht aktiviert. Dies wurde mir gerade vom Hersteller mitgeteilt und die haben dass dann gleich geändert.
Und schon bekomm ich meine Daten sauber auf der Visu angezeigt.
Danke nochmal an alle.
Gruß Helmut
du solltest vorne anfangen zu testen, an der Quelle, hier dem Moxa.
Um ganz sicher zu sein was am Moxa ankommt, bzw. raus geht, kannst du ja auf dem PC einen virtuellen COM Port einrichten und eine einfaches Terminal Program ranhängen.
Eine besonderheit bei RSR232 => IP ist das Auslösen der Übertragung des IP Packets. Hier kann man im Moxa einstellen, wodurch das Losschicken als IP Packets ausgelöst wird. Also wenn ein Zeichen oder Hex empfangen wird oder der Buffer eine max. Größe erreicht hat.
Dies must Du zuerst lösen bzw. prüfen. Wenn Du also schon eine andere Anlage damit hast, schau dir genau die Parameter im Moxa an.
Denn damit wird ja festgelegt was am ANFANG des Packetes drin steht.
Wenn das also in kontrollierter Form raus geht, kannst Du dich damit beschäftigen wie Du es in kontrollierte Form empfängst (im HS).
Dazu must Du es dann wieder vom virtuellen COM-Port weg nehmen und auf den UDP port senden lassen. ...
Du kannst es auch gleich mit Wireshark auf dem UDP port lesen, ist aber etwas anspruchsvoller. Würde ich am Anfang nicht empfehlen.
Wenn Du hier nach Moxa suchst, wirst Du noch viel dazu finden.
Folgender Hintergrund:
Ich bekomm von einem Moxa die Daten (ph-Wert, Temp. etc.) von einem Pool.
Diese Daten möchte ich im HS umwandeln und auf die Visu bringen.
Das ganze, mit genau den gleichen Systemen, funktioniert bei einem anderen Bauvorhaben ohne Probleme.
Keine Ahnung warum, jedoch funktioniert es bei dem aktuellen Projekt nicht.
Lt. Hersteller beginnt das Protokoll mit STX SAPHIR usw. Wenn ich nun auf im HS eine IP-Auswertung mache, dann findet er die Zeichenfolge SAPHIR schon gar nicht. Deswegen wollte ich mir die Daten irgendwie anschauen, was genau von dem Moxa gesendet wird.
Ich hab jetzt mal zu Testzwecken das ganze Protokoll ich ein 14byte KO schreiben lassen, siehe Anhang. Das beginnt mit AA 77 ... usw.
Leider kann ich damit nichts anfangen, deswegen war meine Frage nach einem Prog. mit welchem ich den Netzwerkverkehr genau mitlesen kann.
Oder gibt es eine Möglichkeit diesen genannten Wert (AA 77 etc.) zu entschlüsseln?
Ich kenn mich auf dem Gebiet einfach zu wenig aus aber ich denke mal dass das ein Hex-Wert ist, oder?
2 Systeme, auf denen eine virtuelle Maschine gestartet wurde, die die SELBE Mac und die SELBE IP verwendete und ein Broadcast-Protokoll nutzte...
Mal ne bescheiden Frage: wie hast du denn das an's laufen bekommen - zwei PC's mit identischer IP-Konfiguration (MAC UND IP) zu gleichen Zeit im gleichen Netz? Ohne Filterfunktion wirst du in einem normalen Netz mit mehr als 2 PC's nichts ausrichten.
Du brauchst zusätzlich einen Hub (KEIN Switch!!) oder ein Switch mit Monitoring-Port (mittlerweile ab 150€), wenn du einen ganz speziellen Rechner abhören willst.
Wenn man noch eine Netzwerkkarte rumliegen hat, kann man die zusätzlich in einen PC bauen und beide Netzwerkkarten im Bridge-Modus betreiben. Dann das abzuhörende Gerät in die eine Karte stecken und die andere wie gewöhnlich mit dem Switch verbinden.
ich denke Helmut hat ein normales Netz und nicht virtuelle Systeme. Die Filtermöglichkeiten im Wireshark sollten da ausreichen um den Traffic einer IP zu sehen.
PS: Multicast ist dann UDP-Traffic, kann man auch raus filtern. Habe es intensive bei der Fritzbox gemacht für IP-Routing. Die Korrektur ist übrigens nun offiziell bei AVM released worden .
oder man kennt einfach die Möglichkeiten in Wireshark zu filtern.
Hmm dann debugge mal mit den Filterfunktionen das hier:
2 Systeme, auf denen eine virtuelle Maschine gestartet wurde, die die SELBE Mac und die SELBE IP verwendete und ein Broadcast-Protokoll nutzte...
-> Ich halte von den Filterfunktionen zur Unterscheidung der Sender nicht allzu viel. Ich nutze das, um eben den Traffic EINES Systems übersichtlicher darzustellen.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Einen Kommentar schreiben: