mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ENC28J60, ATmega32, UDP-Pakete


Autor: Jan (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Flo G. (phlo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, habe mal Quellport angegeben und die Checksumme hardcodiert, daran 
liegt es nicht :(

Autor: Flo G. (phlo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Flo G. (phlo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Probiers erstmal als normalen Punkt-zu-Punkt-Paketversand

Funktioniert leider nicht.

BTW: Zonealarm und die Windows-Firewall sind beide deaktiviert.

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Sven (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>Poste bitte mal den Output von ipconfig /all ....

=> Anhang

Vielen Dank für dein Programm, werde das jetzt mal testen.

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wie siehts aus ?

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst Du mal von beiden Fällen einen Screenshot machen ?
Also Wireshark ? Wie in Posting #1 ?

Gruß Sven

Autor: Jan (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, dass mit dem "cross point frame injector" hängt mit Port 5000 
zusammen, bin jetzt mal auf port 44444 gegangen.

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jan (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, das Identification Feld ist beim Senden mit ENC nicht gesetzt.

Kannst Du das mal testweise setzen ? vom ENC aus...

Gruß Sven

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat nix gebracht.

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
der Anhang ;-)

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hex Output der MSG:

ffffffffffff001b7704f3780800450000213c2700008011da99c0a86363ffffffff1343 
1388000d712b68656c6c6f00000000000000000000000000

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.