Hallo, ich habe ein kleines Board mit ENC28J60 und einem ATmega32, welches an ein Messgerät angeschlossen ist. Das Board soll Messwerte auslesen und als einfache UDP-Pakete an einen PC senden, wo die Auswertung durch ein in Delphi geschriebenes Programm erfolgt. In diesem Programm nutze ich die beiden Komponenten TIdUdpClient und TIdUdpServer aus der Indy-Komponentensammlung. IP auf PC-Seite: 192.168.99.3 IP des ENC-Boards: 192.168.99.99 Port: 5042 Mein Problem ist, dass die vom µC erzeugten UDP-Pakete zwar korrekt übertragen werden (siehe Anhang), der UDP-Client meiner Delphi-Software diese aber nicht erkennt und ich verstehe nicht warum das so ist. Im Anhang mal ein aufgezeichneter Frame, wie ich ihn erzeuge und versende. Müsste doch eigentlich alles stimmen? Checksumme des UDP-Teils ist optional, ebenso der Quellport. Generell erfolgt die Übertragung als Broadcast, das heißt die Ziel-IP ist 255.255.255.255. Eine Sache ist seltsam: wenn ich mit meiner Delphisoftware ein UDP-Paket an meinen ENC sende, dieses dann dort wieder zurückschicke (mit Anpassung der IPs usw.), dann erkennt die Delphisoftware das UDP. Evtl. ein Problem mit den Indy-Komponenten? Ich denke nicht, denn kein einziger frei erhältlicher UDP-Client erkennt die von mir erzeugten UDP-Pakete. Ich denke daher, ich habe etwas grundsätzliches übersehen. Vielleicht kann hier ja jemand helfen. Danke! Jan
Angehängte Dateien:
-
udp.png
11 KB
Nunja wenn ich die Ausgabe im Screenshot (btw. - is das das neue Wireshark-Interface??) richtig interpretiere ist dein UDP-Paket nicht vollständig und korrekt. Es fehlen ein Quellport und viel wichtiger noch, die Checksumme. Wenn der UDP-Client (egal welcher) richtig arbeitet, wird er alle Pakete, egal wie gut sie sonst aussehen, verwerfen, wenn die Checksummme nicht vorhanden ist oder nicht stimmt... Ergo: Sorge erstmal dafür dass eine gültige Checksumme und ein Quellport (ist eigentlich egal welcher) mitgesendet werden, ich würde fast wetten dass es dann funktioniert. Zur Lektüre: http://www.faqs.org/rfcs/rfc768.html Grüße, F. Geiselhart
Danke für deine Antwort. Ich habe aber gelesen, dass die Angabe des Quellports und der UDP-Checksumme optional ist. Sieht man ja auch im Screenshot, bei der Checksumme wird "none" angezeigt, also kein Fehler. Aber du hast schon recht, vermutlich erwarten alle Clients hier eine Angabe. Ich probier das mal aus...doof, muss mal gucken, wie das mit dem Pseudo-Header funktioniert.
Angehängte Dateien:
-
udp.png
11 KB
So, habe mal Quellport angegeben und die Checksumme hardcodiert, daran liegt es nicht :(
Nunja, in der offiziellen RFC ist soweit ich sehe mal nirgends die Rede von optional...wäre mir jetzt auch neu...der einzige relevante Ausschnitt aus der RFC lautet wie folgt: "An all zero transmitted checksum value means that the transmitter generated no checksum (for debugging or for higher level protocols that don't care)." Und das wiederum ist hier vermutlich nicht der Fall, da die Higher-Level-Protocols deine UDP-Clients miteinschließen und ich denke dass die alle auf jeden Fall eine Checksumme und einen Quellport sehen möchten... Probiers einfach mal und berichte wie es gelaufen ist ;-) Grüße, F. Geiselhart
Okay, schade, zweite Idee: Probiers erstmal als normalen Punkt-zu-Punkt-Paketversand anstatt als Broadcast...vielleicht unterstützen das die Clients nicht... Grüße, F. Geiselhart
>Probiers erstmal als normalen Punkt-zu-Punkt-Paketversand
Funktioniert leider nicht.
BTW: Zonealarm und die Windows-Firewall sind beide deaktiviert.
Hi Jan, also Du hast jetzt kein Event in Delphi ? Hier ist ein Link: http://www.delphipraxis.net/post551474.html Firewall aus ? Nicht das man sich da ein Ei legt..... Man hat ja jetzt keinen Delphi Code Ausschnitt gesehen ... Wie inititalisiert Du ? Auf Adresse 0.0.0.0 zum Listen ? Gruß Sven
>also Du hast jetzt kein Event in Delphi ? Genau. Und wie gesagt, andere UDP-CLients empfangen auch nichts. Firewall ist aus. >Wie inititalisiert Du ? Auf Adresse 0.0.0.0 zum Listen ? Ja.
So, habe jetzt das ganze mal mit dem Beispiel Programm
im Anhang getestet.
Server und Client Programm
Mit Button1 wird der Server auf Port 5000 gestartet.
Mit Button2 wird einfach ein "hello" mit der Broadcast Funktion an Port
5000 gesendet.
Test: Funktion zwischen 2 Pcs -> OK
Funktion zwischen 1 Pc und 1 VMware -> OK
Funktion auf ein und demselben Pc -> OK
Wenn ein Event vom Server empfangen wird wird einfach ein "hello" in
die Titelzeile des Fensters geschrieben.
Versuche doch mal mit der exe dies zu schaffen.
Und dann schau Dir mal den Output in Wireshark an. Ist der genauso
wie das Datagramm von Deinem ENC28 ?
Poste bitte mal den Output von ipconfig /all ....
Welches System benutzt Du ?
Gruß Sven
>Poste bitte mal den Output von ipconfig /all ....
=> Anhang
Vielen Dank für dein Programm, werde das jetzt mal testen.
Ok, das sieht ja schon mal ganz normal aus. Was mir schon mal den Schweiss ins Gesicht getrieben hat, ist die Programmierung mit 2 Netzwerkinterfaces. Durch Bugs wurde das Listening nur auf einem Netzwerkdevice durchgeführt; und zwar auf dem ersten..... Um dieses Problem erst mal auszugrenzen würde ich das NVIDIA Device erstmal deaktivieren und schauen was passiert. Weiterhin hast Du etwas von ZoneAlarm geschrieben. Ich hatte da vor ca. 4 Jahren auch ein Problem mit der Firewall. Das deaktivieren reichte nicht aus, da die Filter Treiber noch geladen waren. (Fehler bei der Verarbeitung mit 2 Netzwerkkarten) Mein Vorschlag: ZoneAlarm ganz runter vom Rechner; plus NVIDIA mal deaktivieren..... Achso und versuche doch mal das ganze jetzt auf Port 5000, ich hatte in Delphi diesen Port genommen.... Gruß Sven
Leider nicht so gut denn aus welchen Gründen auch immer erhalte ich jetzt zwischen "User Data Protocol" und "Data" einen "Cross Point Frame Injector". Aber davor war es so: ein UDP von deinem Programm an den ENC28J60 geschickt und von dem wieder zurück (quasi als Echo) hat funktioniert bzw. funktioniert jetzt auch noch. Was nicht geht: vom ENC28J60 aus ein UDP zu schicken eben ohne, das vorher eines vom PC kam.
Kannst Du mal von beiden Fällen einen Screenshot machen ? Also Wireshark ? Wie in Posting #1 ? Gruß Sven
Angehängte Dateien:
-
capture_echo.png
34 KB
Hier ein Screenshot. Benutzt habe ich dein Programm, erst auf Button 1 dann auf Button 2 geklickt. Wie du siehst, wurde aus dem "hello" ein "+hello"...das habe ich aber so gemacht um sicher zu sein, dass das UDP vom ENC kommt. Wo allerdings die restlichen Zeichen herkommen, ist mir schleierhaft. Aber offenbar ist bereits bei dem auf PC-Seite erzeugten UDP-Paket was faul (Malformed Packet). Frage: welche Version der Indy-Komponenten benutzt du? Die derzeit aktuelle?
Ok, dass mit dem "cross point frame injector" hängt mit Port 5000 zusammen, bin jetzt mal auf port 44444 gegangen.
Hmm, das gibts doch nicht. Compiler war jetzt: D7 Komponente: Indy normal mit Auslieferung bzw. gePatched mit Service Packs. unter Info finde ich: V9.00.10 Seltsam. Werde jetzt auch Wireshark auf einer Testmaschine installieren. Werde dann ein kleines Testprogramm für ICS schreiben. Tz, das gibts doch einfach nicht. Gruß Sven
Aha, und wie ist der Output mit Port 44444 und dann in Wireshark. 1. PC sendet und dann ENC wieder zurück 2. ENC sendet alleine ein Paket an PC Port 44444 Gruß Sven
Dein Packetyzer versucht das Paket als ein "Cross point frame injector" Paket zu parsen, was ihm aber nicht gelingt (da es keins ist). Kannst du nicht einfach mal HEX Dumps anhängen? So findet man den Unterschied zwischen den Frames leichter, als in dem grafischen Gebimsel.
Angehängte Dateien:
-
capture_1.png
40 KB
Ok, bin noch auf folgendes Problem gestossen: Ein Ethernet-Frame muss mindestens 64 Byte umfassen, mit "hello" kommt das nicht hin. Ich habe daher ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 als Zeichenfolge verschickt. Dein Programm konnte ich nicht kompilieren, da wir offenbar unterschiedliche Versionen von Indy benutzen. Habe deins daher schnell neu zusammengeklickt. Also hier der Screenshot von 1. PC sendet und dann ENC wieder zurück
Angehängte Dateien:
-
capture_2.png
39 KB
Und noch von 2. ENC sendet alleine ein Paket an PC Port 44444 Sieht doch eigentlich gut aus. Nur ich bekomme halt kein Event, weder in meinem Delphiprog noch in einem beliebigen anderen Client. Und so wären wir wieder am Anfang.
Also, das Identification Feld ist beim Senden mit ENC nicht gesetzt. Kannst Du das mal testweise setzen ? vom ENC aus... Gruß Sven
So, habe noch mal simuliert und Deine IP Adressen eingesetzt.
Bitte teste noch mal folgende Schritte:
1. ENC sendet an Port 5000 die Msg "hello".
2. Auf dem PC startest Du das Programm von mir aber direkt die exe
(von der wissen wir, das sie definitiv reagiert)
(also nicht neu compilieren sonst ist möglicherweise wieder
ein Fehler drin)
3. Du baust für 1. die Msg nach dem Screenshot nach,
den ich angehangen habe.
Das ist eine Nachricht die definitiv funktioniert.
4. Jetzt schaun ob es geht. Wenn nicht: Dann Firewall
deinstallieren und WinPCap mit dem Paketyzer
runterschmeissen.
Dann werden die Pakete nicht gescheit durch die Filter-Treiber
gereicht.....
So und jetzt noch mal die Infos wie ich es getestet habe:
PC WXP SP2 -> VMware W2k
192.168.99.99 -> 192.168.99.3
Screenshot im Anhang...
Ich habe mal versucht noch ein paar Informationen
zu diesem Paketyzer herauszufinden.
Wenn ich das richtig gesehen habe, verwendet dieser eine ältere
Version von WinPCap. Dieser Treiber ist ja für das horchen auf
dem Netzwerkdevice zuständig.
Meine Version: Wireshark von SF mit Version 1.0 vom 28.03.2008
mit WinPCap 4.0.2 oder so...
Wie ist es mit der Firewall ?
Hast Du mal die Zonealarm deinstalliert ?
Kannst ja für die Zeit mal die Internet Verbindung
ziehen und dann die ZoneAlarm herunterschmeissen.
Danach unbedingt überprüfen das die Windows
Firewall deaktiviert ist.
icq7586746
Bitte berichte mal.
Hinter die Nummer muss noch der Monat der
Wireshark Version. Dann können wir per icq weiterquatschen.
Gruß Sven
Hex Output der MSG: ffffffffffff001b7704f3780800450000213c2700008011da99c0a86363ffffffff1343 1388000d712b68656c6c6f00000000000000000000000000
Ich könnte gerade ausrasten... Mir ist aufgefallen, dass bei deinem Screenshot die Total Length 33 ist, und meine Total Length immer genau um 14 größer war. Warum? Weil ich Depp die Länge des Ethernet2-Frames mit dazugezählt habe, was natürlich völliger Blödsinn ist!! Ich danke dir für deinen Einsatz, jetzt kann ich beruhigt schlafen gehen :) Viele Grüße, Jan
> Ich könnte gerade ausrasten... Ich auch, das gibt es doch nicht ! Nee, Spass. Hoffe Du hast gut geschlafen. > Mir ist aufgefallen, dass bei deinem Screenshot die Total Length 33 ist, > und meine Total Length immer genau um 14 größer war. Warum? Weil ich > Depp die Länge des Ethernet2-Frames mit dazugezählt habe, was natürlich > völliger Blödsinn ist!! Das hat mich jetzt auch gefuchst. Das Schlimme ist, das ich das gesehen habe und mir gedacht habe, ohh wieso hat er 14 bytes mehr. Wo kommen die her ? Habe schön noch mal die 14bytes nachgerechnet.... und irgendwie dann den Gedanken wieder verworfen. > Ich danke dir für deinen Einsatz, > jetzt kann ich beruhigt schlafen gehen :) Sehr gut. Kannst Dich ja trotzdem per icq melden, vielleicht geht man mal ein Bierchen trinken..... und quatscht über gute Ideen..... Gruß Sven
Der Witz ist ja, dass ich den ganzen Kram auch mal unter Linux mit tcpdump getestet habe und dieses Tool hat als einziges was von "truncated IP" und "14 bytes missing" :)) gemeldet. Naja...Google meinte dazu, dass das ein Bug oder so ist...jedenfalls habe ich da nicht mehr weiter gedacht, ein klarer Fehler! Bierchen? Coole Idee, meld mich mal.
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.