Hallo im Rahmen eines studentischen Projekts wollen wir Messwerte von einem Mikrocontroller an einen PC schicken. Die Anbindung erfolgt über entsprechende Netzwerkcontroller und ein örtliches Netzwerk, aktuell aber aus Entwicklungsgründen mit Crosslinkkabel direkt am Laptop. Wir haben uns für einen Versand über UDP entschieden, da weder wichtige, noch viele Daten verschickt werden (pro Gerät ca 200Bytes alle 3s), später aber von vielen Teilnehmern. Um die Kommunikation zu überwachen setzen wir Wireshark ein. Die Programmierung von der PC Software die später die Auswertung übernehmen soll erfolgt in C++. Wir sind in der Lage, UDP Frames vom µC im Netzwerk zu verschicken, diese können wir wunderbar in Wireshark betrachten. Die Frames entstehen nicht automatisch sondern sind im Moment noch von Hand eingegeben, Byteweise. Das gibt uns den besten Zugriff auf den Frame. Nun haben wir ein Programm am PC laufen, welches alle 500ms zufällige Datenpakete via UDP übers Netzwerk schickt. Verbinden wir zwei PCs miteinander, so funktioniert diese Kommunikation einwandfrei. Tauschen wir nun einen der PCs (den Sender) mit unserem µC, kopieren den UDP Frame 1 zu 1 in den µC und lassen diesen Senden, sehen wir zwar in Wireshark den Frame, 100% identisch zu dem vom PC geschickten, aber die Software registriert diesen nicht mehr. Wir haben bereits mehrere Varianten ausprobiert: C++(VS2010), C++(QT4.7), C#, VB2010, Java(Processing) jeweils bezogen auf die PC Software die bisher ganz einfach nur emfpangene Pakete in einer Textbox ausgibt. Kommunikation von PC zu PC geht immer, aber von µC zu PC nicht. Da wir nun ratlos sind, hier die Frage ob sich eventuell jemand mit dieser Thematik auskennt und ebenfalls vor einem solchen Problem stand. Wir verstehen nicht so ganz, weshalb 2 identische Pakete einmal verarbeitet werden, und einmal nicht. Im Bild sichtbar der Frameaufbau. In diesem Falle als Broadcast, ein Beispiel von QT arbeitete mit Broadcasts. Gruß
Zeig doch mal den Sourcecode der empfangenden PC-Software. Alle Stellen, die irgendwas mit UDP machen.
Der o.a. Ethernet-Frame beinhaltet eine MAC-Adresse von MSI. Ich nehme an, dass diese (ursprünglich) von dem betreffenden PC stammt. Wurde die MAC-Adresse nicht verändert, sondern 1:1 übernommen, kann der PC entsprechende Ethernet-Pakete verwerfen, da er annehmen muss, dass er seine eigenen Pakete auf Grund irgendwelcher Netzwerkschleifen empfangen hätte. Es spricht in der Tat wenig dagegen, sich für einen eigenen Testaufbau MAC-Adressen auszudenken statt gleich einen Block zu kaufen. Notfalls kann man ja auch die Adresse einer alten, nicht mehr verwendeten Ethernetkarte wiederverwenden. Man sollte bei frei definierten Adresse jedoch unbedingt darauf achten, dass einige Bits im höchsten Oktett korrekt gesetzt sind, um nicht irgendwelche Sonderadressen zu verwenden, z.B. dedizierte Multicast-Adressen.
Hallo, Was den Quellcode angeht, dieser ist aktuell ein Beispiel von QT4.7 in C++, verwendet QT eigene Bibliotheken etc (Broadcast Receiver http://doc.qt.nokia.com/latest/network-broadcastreceiver.html). Die MAC Adresse ist von MSI, von dem Laptop der vorher der Sender war. Um den Frame 1 zu 1 zu kopieren haben wir diese einfach übernommen. Natürlich befindet sich der Laptop mit dieser Adresse nicht mehr im Netz, wir tauschen ihn gegen den µC aus. Darum sollte das kein Problem darstellen. IP und MAC stimmen also bei beiden Geräten überein, und da UDP verbindungslos arbeitet sehen die Pakete für den empfangenden PC identisch aus. Die Checksumme ist vom Originalframe übernommen, wie auch der ganze Rest dieses Frames. Es geht ja darum, den 100% selben Frame von zwei Quellen zu senden. Von einer wird er erkannt, von der anderen nicht, was auch unser Problem darstellt. In Wireshark sind beide ohne Unterschied erkennbar.
Denkt daran, dass Ethernet-Pakete eine Mindestlänge von 64 Bytes haben müssen. Das wird im Wireshark eventuell nicht so angezeigt. Sind die Pakete kürzer, müsst entweder Ihr oder der Ethernet-MAC die auffüllen. Außerdem hat jedes Ethernet-Paket zusätzlich noch eine FCS (Frame Checksum), die der Wireshark auch nicht anzeigt. Der Ethernet-Controller muss die jedoch erzeugen und senden. fchk
Stimmt, es sind laut Wireshark nur "61 Bytes on wire"! Neben der minimalen Länge von 64 Byte sollte man auch darauf achten, dass die Pakete eine gerade Anzahl von Bytes haben, da manche Netzwerkkomponenten Prüfsummen bei ungeraden Paketlängen falsch berechnen.
Hallo, die Mindestlänge ist durchaus bekannt, wenn allerdings Wireshark die FCS nicht anzeigt, sind es 65 Bytes (jedenfalls bei dem PC generierten Paket). Wie schon gesagt, das Paket ist 1 zu 1 aus einer funktionierenden Kommunikation kopiert jedoch ohne die FCS da sie nicht angezeigt wird. Gemeine Falle :( Der Hinweis auf die fehlende FCS ist super, die senden wir nämlich nicht mit. Mal sehen ob es mit klappt. Vielen Dank erstmal.
Guten Morgen, wir sind der Sache mit der FCS heute früh mal auf den Grund gegangen. Wir haben über die Ferien hinweg eine längere Pause im Projekt eingelegt, daher war mir entfallen, dass unser Controller (ENC28J60) die CRC bereits berechnet. Insofern entsprechen wir mit dem 61Byte Paket den Anforderungen an die Mindestlänge da hier die FCS einberechnet wird. Da diese Möglichkeit nun ausgeschlossen scheint, stehen wir wieder auf dem Schlauch, sprich wir sind für weitere Vorschläge offen.
Sunday schrieb: > wir sind der Sache mit der FCS heute früh mal auf den Grund gegangen. > Wir haben über die Ferien hinweg eine längere Pause im Projekt > eingelegt, daher war mir entfallen, dass unser Controller (ENC28J60) die > CRC bereits berechnet. Sicher? Schaut Euch mal MACON3.TXCRCEN und MACON3.PADCFG an, nachdem Ihr ein Paket gesendet habt. fchk
Hallo Frank, Diese werden bei uns in der Initialisierung gesetzt. Wir werden dennoch morgen mal einen Blick darauf werfen.
Hallo Frank, ich bin zusammen mit Sunday an dem Projekt beschäftigt. Ich habe gerade das MACON3-Register ausgelesen. Nachdem Powerup ist das Register leer, so wie es sein soll. Nach der Initialisierung ist der Hex-Wert 32, was heißt, dass die beiden Bits TXCRCEN und PADCFG0 gesetzt sind. Dieser Wert wird auch nach mehreren Paketen beibehalten. Sebastian
Sebastian schrieb: > Hallo Frank, > > ich bin zusammen mit Sunday an dem Projekt beschäftigt. > Ich habe gerade das MACON3-Register ausgelesen. Nachdem Powerup ist das > Register leer, so wie es sein soll. > > Nach der Initialisierung ist der Hex-Wert 32, was heißt, dass die beiden > Bits TXCRCEN und PADCFG0 gesetzt sind. > Dieser Wert wird auch nach mehreren Paketen beibehalten. OK, dann kann es daran auch nicht liegen. Jetzt mal ein anderer Test: Besorgt Euch einen 10 MBit Hub (es ist wichtig, dass es ein Hub und kein Switch ist), hängt Sender und Empfänger da dran, und probiert noch einmal. Dieser Test soll verhindern, dass irgendwer sonst das gesendete Paket anfasst. Ein Hub ist nur ein Koppelverstärker, der das an einem Port ankommende Signal an alle Ports durchreicht. Switches hingegen haben Intelligenz und Speicher eingebaut, und das wollen wir jetzt nicht. 100 MBit Hubs waren extrem selten (und die konnten dann auch wirklich nur 100 MBit) Wenn die Kiste noch einen BNC- und/oder einen 15-poligen SUB-D-Anschluss hat, umso besser - dann ist es mit ziemlicher Sicherheit ein Hub. Habt Ihr keinen, dann sollte es auf ébay sowas für 1€ geben. Ich hatte schon einige Male das Problem, dass mein HP Switch zu viel Intelligenz hatte und Pakete gefiltert hat (zu Recht, wie ich später immer wieder herausgefunden hatte, aber erst einmal war es verwirrend). Notfalls nehmt Ihr ein gekreuztes Ethernet-Kabel. Ggf. müsst Ihr dann auf beiden Enden 10BaseT full-duplex fest einstellen (anschließend wieder auf auto stellen nicht vergessen) Ansonsten fällt mir auch nichts mehr ein. fchk
Hallo Frank, vielen Dank für deinen ausführlichen Hinweis. Unser "Netzwerk" bestand bisher zu Testzwecken nur aus einem Crosslinkkabel, daher ist auch diese Möglichkeit ausgeschlossen. Gestern Abend allerdings ist es uns gelungen ein Paket (und weitere tausende) zu empfangen. Im Grunde war alles gleich aufgebaut, wir haben nur mal ein Paket eines ganz einfachen UDP Chat in C# ausprobiert. Heute werden wir anfangen dies auszubauen und (hoffentlich) auf C++ umsteigen können. Gruß
Bitte 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.