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ß
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,
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ß
wireshark___C_pc_udpframe.PNG
(71 KB)
