Hallo, ich selbst bin Elektroniker, ich schreibe auch etwas Quellecode, kann aber nicht behaupten wirklich programieren zu können. Ich verwende hier in mehreren Aufbauten einen Arduino Nano zusamen mit einem Wiznet W5500 in Form des Modules WIZ850IO. https://docs.wiznet.io/Product/ioModule/WIZ850io Ich mache eine einfache Kommunikation via TCP um vom PC aus den Nano zu steuern, hier konkret die Relais zu schalten und die Rückmeldungen einzulesen. Das geht auch meistens aber manchmal auch nicht. Um den Fehler einzukreisen und meinen Qullecode auszuschließen habe ich das Ethernet Beispiel aus der IDE aufgespielt und nur die IP-Adresse angepasst. Nun zum konkreten Problem. Ich habe teilweise den Fall, das ein Ping nicht geht, ich aber zeitgleich über TCP Daten zu dem Nano schicken kann. Das verstehe ich nicht?! Der Ping wird ja direkt im W5500 verarbeitet und der antwortet nicht. Aber die Kommunikation durch den W5500 bis zum Nano geht gleichzeitig? Maßnahmen/Hinweise - originaler Nano von Arduino.cc (gekauft bei Mouser) - mit mehreren Nanos getestet - WIZ850IO Nachbau "aus dem Internet" - nachgekaufter originaler WIZ850IO (gekauft bei Mouser) - Schaltplan im Anhang - Quellcode im Anhang (Beispiel aus der IDE, minimale Anpassung (IP-Adresse) - verschiedene PCs (Win10) - Verschiedene Netzwerkkabel - direkte Netzwerkverbindung zum Windows PC, kein DHCP, kein DNS... - Spannungsversorgung oszillografiert, ist sehr unauffällig - Pegel und Verlauf des SPI sehen unauffällig aus - weitere Details hab ich jetzt weggelassen, ist jetzt eh schon ein Textwand Hat da jemand schon ähnliche Erfahrungen gesammelt, bzw. ein paar Stichworte das ich das besser verstehen kann. Ich erhoffe mir dadurch zu finden, weshalb ich manchmal Kommunikationsaussetzer habe. Danke ---- Benjamin
Benjamin K. schrieb: > Schaltplan im Anhang Wo bitte? Erster Gedanke: - Relais machen Störungen - wenn der W5500 über den Nano versorgt wird, muss man "schon" aufpassen ob das von der Stromaufnahme her passt. Daher: Schaltplan bitte.
Angehängte Dateien:
-
WIZ850IO_SCH.png
75 KB
Ach Mist, der Anhang fehlt ja doch. Da hab ich wohl mit der zweiten Datei die erste wieder rausgeschmissen. Die Versorgung ist von eigenem externem Netzteil, ca. 20cm Zuleitung, es hängt sonst nichts anderes dran. Ich habe den Schaltplan etwas zusammengeschoben damit das ein wenig kompakter ist. Und auch etwas weggelassen, z.B. wo die Relais hingehen. Das kann ich hier nicht alles zeigen, das ist auch irrelevant, weil da im Moment noch gar nichts dran hängt, außer 3cm Leitung bis zum Stecker. Ich habe das exakt gleiche Phänomen auch auf einer anderen Platine. Dort habe ich eine komplett andere Versorgung mit 5V aus einem Schaltregler, von 24V kommend. Ab dem Längsregler NCV1117 ist es dann identisch. Daher nehme ich an, das die Versorgung nicht ursächlich ist. Aber Danke für den Hinweis, Spannungsversorgung ist immer kritsch zu hinterfragen. ---- Benjamin
:
Bearbeitet durch User
Gibt es einen Grund, warum du das unbedingt mit dem Wiznet machen willst? Als der rauskam gab es noch keine ESPxx basierten netzwerkfähigen Controller. Bzw. ein Raspi... Die Wiznet Chips waren ziemliche Krücken. Was man auch machen kann, eine alte PCI Netzwerkkarte nehmen und per WOL da ein Relais mit Ausgangstreiber dranklöppeln :-) Kostet nix, wenn man die LAN-Karte als quasi Schrott hat. Hab ich mal vor 20 Jahren gamacht. Eine 100 MHz RTLirgendwas. Braucht kein Mainboard, sondern am WOL nur ein 5V Netzteil, Netzwerkkabel dran, und Magic Packet mit der MAC ID schicken.
Gerald B. schrieb: > Gibt es einen Grund, warum du das unbedingt mit dem Wiznet machen > willst? Als der rauskam gab es noch keine ESPxx basierten > netzwerkfähigen Controller. Bzw. ein Raspi... Die Wiznet Chips waren > ziemliche Krücken. Der Grund ist, den Nano kenne ich ziemlich gut. Und mit Raspi, also Linux und Micropyton oder so, will ich nicht anfangen. Da habe ich so viele neue Baustellen. Das schöne an dem Nano ist ja, das der so klein und einfach ist. ESP basiert schaue ich mit an. ---- Benjamin
Benjamin K. schrieb: > Ich habe das exakt gleiche Phänomen auch auf einer anderen Platine. Wenn man mit "W5500 ping fails" googelt, gibt es einige Hinweise die vom Muster her auch auf dein Problem hin passen. Aber weder hab ich Erfahrung mit dem W5500 noch mit Arduinos.
Benjamin K. schrieb: > Ich habe das exakt gleiche Phänomen auch auf einer anderen Platine Du könntest mal den UDP Tester versuchen ob sich dabei ähnliche Phänomene ergeben: Beitrag "Re: UDP-Netzwerke(l)n mit kleinen Mikrocontrollern und WizNet W5100/W5500" Damit kannst du zwar nicht die Datenübertragung für dein Protkoll überprüfen, aber der W5500 wird voll konfiguriert ud lässt sich damit auch pingen. Wenn du einen zweiten Arduino verwendest und ein UDP Beispiel drauf laufen lässt könntest du auch die UDP Kommunikation testen.
Benjamin K. schrieb: > Der Ping wird ja direkt im W5500 verarbeitet und der antwortet nicht. > Aber die Kommunikation durch den W5500 bis zum Nano geht gleichzeitig? Ping läuft über die ICMP-Protokollebene, nicht über TCP. Befinden sich beide Netzknoten (PC und W5500) im selben Netz, also am selben Ethernet-Switch? Oder ist da noch ein Router dazwischen? Hast du mal mit Wireshark auf dem PC geschaut, ob der Ping ein ICMP Echo Request Paket rausschickt? Hat dein Switch eine Möglichkeit, einen Port zu spiegeln, so dass du an einem dritten PC mit Wireshark sehen könntest, was beim W5500 ankommt? LG, Sebastian
Sebastian W. schrieb: > Ping läuft über die ICMP-Protokollebene Das ist ohne Bedeutung. Sobald der W5500 mit IP Daten und MAC Adresse initialisiert ist (und einige Dinge mehr) reagiert der W5500 grundsätzlich und automatisch im Hintergrund auf den ICMP Echo Request, egal ob und welches Protokoll man aktiviert hat oder nicht. Übrigens genau so wie LwIP per Default konfiguriert ist und reagiert.
:
Bearbeitet durch User
Überprüfe mal die "dicken" 220uF Kondensatoren. Im Datenblatt des Spannungsreglers gibt es Hinweise zur richtigen Dimensionierung. Ich glaube die sind viel zu groß.
Hans W. schrieb: > Ich glaube die sind viel zu groß. Das ist durchaus möglich. Grundsätzlich sind "grosse" Kondensatoren am Ausgang eines integrierten Analogreglers nicht angebracht da sie das Regelverhalten stark verschlechtern oder ausser Kraft setzen. Dagegen dürfen Kondensatoren am Eingang eines Reglers gross sein damit sich der Regler darauf "stützen" kann. Extrembeispiel ist ein Regler an einer weichen Batterie (Innenwiderstand gross) ohne starke C-Pufferung, da weiss oft ein Regler nicht was er tun soll ...
Sebastian W. schrieb: > Ping läuft über die ICMP-Protokollebene, nicht über TCP. Befinden sich > beide Netzknoten (PC und W5500) im selben Netz, also am selben > Ethernet-Switch? Oder ist da noch ein Router dazwischen? Hast du mal mit > Wireshark auf dem PC geschaut, ob der Ping ein ICMP Echo Request Paket > rausschickt? Hat dein Switch eine Möglichkeit, einen Port zu spiegeln, > so dass du an einem dritten PC mit Wireshark sehen könntest, was beim > W5500 ankommt? Tschuldigung, viel zu tun heute, ich kome erst jetzt dazu. Ja, hängt alles am selben unmanaged Switch. Oder auch direkt mit Kabel am Ethernet-Port des Rechners. Wireshark hab ich geschaut, das Ping geht raus, aber es kommt keine Antwort.
Wastl schrieb: > Sebastian W. schrieb: >> Ping läuft über die ICMP-Protokollebene > > Das ist ohne Bedeutung. Sobald der W5500 mit IP Daten und MAC > Adresse initialisiert ist (und einige Dinge mehr) reagiert der > W5500 grundsätzlich und automatisch im Hintergrund auf den ICMP > Echo Request, egal ob und welches Protokoll man aktiviert hat > oder nicht. EBEN, genau, exakt das ist mein Problem!!! Das verstehe ich nicht. Der W5500 ist nachweislich mit TCP ansprechbar. Das ICMP geht gleichzeitig aber nicht.
Wastl schrieb: > Hans W. schrieb: >> Ich glaube die sind viel zu groß. > > Das ist durchaus möglich. Grundsätzlich sind "grosse" Kondensatoren > am Ausgang eines integrierten Analogreglers nicht angebracht da sie > das Regelverhalten stark verschlechtern oder ausser Kraft setzen. > > Dagegen dürfen Kondensatoren am Eingang eines Reglers gross sein > damit sich der Regler darauf "stützen" kann. Extrembeispiel ist > ein Regler an einer weichen Batterie (Innenwiderstand gross) ohne > starke C-Pufferung, da weiss oft ein Regler nicht was er tun soll ... Das ist es aber nicht. Die Ausgangsspannung hab ich mir mit dem guten 1,5GHz Oszi angeschaut. Das ist ein gerader Strich, ohne signifikanten Ripple. Das war so schön gerade, das ich das als Ursache damit wieder bei Seite gelegt habe. Aus dem Datenblatt des NCV1117 Seite 9: https://www.onsemi.com/pdf/datasheet/ncp1117-d.pdf "A minimum capacitance value of 4.7 µF [..] is required.[..]Higher values of output capacitance can be used to enhance loop stability and transient response with the additional benefit of reducing output noise."
Benjamin K. schrieb: > Ja, hängt alles am selben unmanaged Switch. Oder auch direkt mit Kabel > am Ethernet-Port des Rechners. > Wireshark hab ich geschaut, das Ping geht raus, aber es kommt keine > Antwort. Keine Antwort an PC sichtbar bei PC und W5500 am selben Switch, oder auch keine Antwort am PC sichtbar bei direkter Kabelverbindung zwischen PC und W5500? Ach, und scheitert der Ping auch, wenn du nie eine TCP/HTTP-Verbindung aufmachst? Im Code fehlt wohl auch der Aufruf von maintain(), aber dabei geht es um DHCP und den Erhalt der IP-Adresse. LG, Sebastian
Benjamin K. schrieb: > Aus dem Datenblatt des NCV1117 Seite 9 ... Allerdings gibt es weiter unten ein Diagramm für den zulässigen ESR des Kondensators. Ich verstehe es so, dass der ESR bei größeren Kapazitäten kleiner sein soll. Allerdings deckt das Diagramm nur den Bereich bis maximal 100 uF ab. Sebastian W. schrieb: > scheitert der Ping auch, wenn du nie eine TCP/HTTP-Verbindung aufmachst? Sehr gute Frage.
:
Bearbeitet durch User
Benjamin K. schrieb: > Das ICMP geht gleichzeitig aber nicht. Das weisst du nicht! "ICMP stands for Internet Control Message Protocol." Das kann alles Mögliche sein. Das, was du weisst, ist dass auf den Ping von aussen, dem ICMP Echo Request von deinem W5500 nicht geantwortet wird. Oder habe ich da was falsch verstanden?
Benjamin K. schrieb: > Aus dem Datenblatt des NCV1117 Seite 9: .... ist zu entnehmen dass keines der Schaltungsbeispiele einen Kondensator grösser als 22uF verwendet. Warum das so ist (keine "grossen" Kondensatoren) habe ich ja begründet. Dennoch hängt es im Einzelfall von den spezifischen Eigen- schaften (die ich nicht kenne) eines Reglers ab.
Benjamin K. schrieb: > Ich habe teilweise den Fall, das ein Ping nicht geht, ich aber > zeitgleich über TCP Daten zu dem Nano schicken kann. Fummelst Du (evtl. ungewollt) am Mode Register herum? Wenn Bit 4 gesetzt ist, wird nicht mehr auf Pings (ICMP Echo) geantwortet.
Hmmm schrieb: > Fummelst Du (evtl. ungewollt) am Mode Register herum? Er benutzt ja die Ethernet-Klasse. Da wird nichts herumgefummelt. siehe: #include <Ethernet.h> Kann natürlich immer noch sein dass die Ethernet-Klasse selbst Mist macht ...
Sebastian W. schrieb: > Keine Antwort an PC sichtbar bei PC und W5500 am selben Switch, oder > auch keine Antwort am PC sichtbar bei direkter Kabelverbindung zwischen > PC und W5500? Beides, > Ach, und scheitert der Ping auch, wenn du nie eine TCP/HTTP-Verbindung > aufmachst? Ja,TCP mit PuTTY, geht. Ping geht nicht TCP mit PuTTY geht > Im Code fehlt wohl auch der Aufruf von maintain(), aber dabei geht es um > DHCP und den Erhalt der IP-Adresse. Nee, es gibt doch nur einen unmanaged Switch, kein DNS, kein DHCP Fest eingestellte IP Adressen.
Benjamin K. schrieb: > WiznetTester.ino (4,07 KB) Aus deinem Programm kann ich nicht erkennen welchen Chip Select du verwendet. Eigentlich gar keinen?
Gerald B. schrieb: >Die Wiznet Chips waren ziemliche Krücken. Das kann ich nicht bestätigen. Bei mir werkeln etliche W5500-Module mit ATMEGA und RP2040 kontrolliert seit Jahr und Tag. Ping, Udp, Tcp funktionieren wie im Datenblatt beschrieben. Ich verwende allerdings ein etwas anderes Modul mit eingebautem 3.3V Spannungsregler. Übrigens habe ich noch Probleme wegen zu hoher Abblockkondensatoren gehabt, sowohl vor oder hinter einem Spannungsregler. Harald
Benjamin K. schrieb: > EBEN, genau, exakt das ist mein Problem!!! Warum gehst du nicht auf meinen Vorschlag ein, das UDP Testprogramm einmal auszuprobieren? Du kannst ja sagen: "nein das macht für mich keinen Sinn", oder "nein ich kann das nicht, dafür bin ich zu blöd" oder was weiss ich. Aber einfach stehen lassen finde ich nicht so toll. Jedenfalls wäre die Aussage schon mal erleuchtend ob du mit dem laufenden UDP Tester immer deinen Arduino anpingen kannst.
Wastl schrieb: > Benjamin K. schrieb: >> EBEN, genau, exakt das ist mein Problem!!! > > Warum gehst du nicht auf meinen Vorschlag ein, das UDP > Testprogramm einmal auszuprobieren? Du kannst ja sagen: "nein > das macht für mich keinen Sinn", oder "nein ich kann das nicht, > dafür bin ich zu blöd" oder was weiss ich. Aber einfach stehen > lassen finde ich nicht so toll. Jedenfalls wäre die Aussage > schon mal erleuchtend ob du mit dem laufenden UDP Tester immer > deinen Arduino anpingen kannst. Ich hab das ja auch schon in Betracht gezogen. So einfach ist es dann aber nicht. Die Kommunikation funktioniert ja meistens. Mir ist jetzt nicht klar worin der Informationsgewinn liegt? Ich müsste das ja bei mir einbauen um dann sagen zu können dass es jetzt nicht mehr manchmal rumzickt. Wenn der UDP-Tester sagt,"alles Super" hilft mir das nicht soo viel. Ja, gut wenn das auch nicht geht weiß ich etwas mehr. Sehe ich das richtig, das ich dann zwei Arduinos mit W5500 brauchen würde?
Benjamin K. schrieb: > Sehe ich das richtig, das ich dann zwei Arduinos mit W5500 brauchen > würde? Nein, du kannst Ping von deinem Rechner aus machen. Ausserdem hast du ja mehrere Arduinos .... Der UDP Tester von mir kann keinen Ping auslösen da der Speicherplatz auf den kleinen Mega328 zu klein ist.
Benjamin K. schrieb: > Ich müsste das ja bei mir einbauen Du musst da gar nichts "einbauen". Einfach nur den Code flashen. Und mit einem Terminal steuern. Einfach mal die Bildchen anschauen und daraus lernen was zu tun ist.
Ist denn am PC, von dem aus das Ping getestet wird, die Firewall komplett abgedreht und das Netzwerk ein "privates"? Windows (und ich gehe davon aus, daß der Threadstarter das verwendet) entwickelt sonst ein ausgesprochen lästiges Eigenleben, insbesondere bei Netzwerkverbindungen.
Benjamin K. schrieb: > Wenn der UDP-Tester sagt,"alles Super" hilft mir das nicht soo viel. Das hilft sehr wohl, denn damit bekämst du die Aussage dass in deinem Setup etwas schief läuft. Benjamin K. schrieb: > Ich mache eine einfache Kommunikation via TCP um vom PC aus den Nano zu > steuern, hier konkret die Relais zu schalten und die Rückmeldungen > einzulesen. Das geht auch meistens aber manchmal auch nicht. Dir ist schon klar dass TCP für "einfache Steuerungen" ungeeignet ist? Warum? Weil TCP einen Datenstrom darstellt, den es gilt zu analysieren, zu parsen. Denn TCP garantiert dir nicht ganze (also vollständige) Pakete in einem Schwung zu bekommen. Pakete können fragmentiert sein, das hast du nicht in der Hand. Daher vielleicht deine Aussage "meistens aber manchmal auch nicht". Um Pakete vollständig in einem Schwung und eindeutig zu übertragen benutzt man UDP und behandelt die Fehlerüberprüfung (Acknowledgement) selbst. UDP sendet - soweit die MTU das erlaubt - immer ganze Pakete ohne Fragmentierung. Nochmal in aller Kürze: TCP ist ein Datenstrom, kein Paket-Handler für den Benutzer.
:
Bearbeitet durch User
Wastl schrieb: > Benjamin K. schrieb: >> Sehe ich das richtig, das ich dann zwei Arduinos mit W5500 brauchen >> würde? > > Nein, du kannst Ping von deinem Rechner aus machen. Ausserdem hast > du ja mehrere Arduinos .... Der UDP Tester von mir kann keinen > Ping auslösen da der Speicherplatz auf den kleinen Mega328 zu > klein ist. Ist ein W5500 richtig initialisiert, antwortet er auf Pings. Zusätzliche SW ist dazu nicht notwendig. Ich weiß nicht, wie du deinen Udp-Tester programmiert hat. Bei mir brauchen die W5500-Routinen (Initialisierung, Udp senden und empfangen, dito mit Tcp) nur wenige kB. Sie passsen bequem in einen ATMEGA328. Auch der RAM-Verbrauch ist niedrig. W5500 hat genug eingebauten RAM.
Harald P. schrieb: > Sie passsen bequem in einen ATMEGA328. Auch > der RAM-Verbrauch ist niedrig. Lies nochmal und verstehe meine Aussage: Wastl schrieb: > Der UDP Tester von mir kann keinen > Ping auslösen da der Speicherplatz auf den kleinen Mega328 zu > klein ist. Wenn du anderer Meinung bist dann programmiere einen ICMP Echo Request auf einen Mega328 und zeige ihn mir. Das wäre ein Beweis dafür dass ich falsch liege.
Harald P. schrieb: > Zusätzliche SW ist dazu nicht notwendig. Das hat auch niemand behauptet. Harald P. schrieb: > Ich weiß nicht, wie du deinen Udp-Tester programmiert hat. Wenn du dir den Funktionsumfang mal genauer anschaust wirst du vielleicht schlauer. Vielleicht aber auch nicht.
:
Bearbeitet durch User
Wastl schrieb: > Das hilft sehr wohl, denn damit bekämst du die Aussage dass in > deinem Setup etwas schief läuft. Hab das HEX aufgespielt. Nichts eingestellt, nur den Ping ausgeführt, das geht. Viel kann ich jetzt nicht ableiten, bei mir geht es ja auch meistens. Was ich heiute noch gemacht habe: - Update "Ethernet" Library von V2.0.0 auf V2.0.2 hat nicht geholfen - Umbau auf Adafruit "Ethernet2" Library Auch dort verhält sich das Beispielprogramm identisch. TCP geht, PING geht nicht und manchmal geht es dann doch. Da geht es auch nach einem Reset immer noch. Hab auch intensiver ins Wireshark geschaut. Was mir gerade eben aufgefallen ist: die TCP Frames (aus Putty) haben als Dest MAC den Broadcast ff:ff:ff:ff:ff:ff und das funktioniert. damit geht aber der Ping nicht. Und auf einmal schaltet der um auf Dest de:ad:be:ef:fe:ed Dann geht auch das Ping. Ich vermut jetzt einfach mal, das die MAC Adresse nicht stimmt, der ARP falsch beantwortet wird, .... und der PC zwar ein TCP absetzen kann, aber das ICMP mit der Broadcast Adresse nicht geht. Muu sich jetzt weiter untersuchen, zumindest klingt das erstmal halbwegs plausibel und ich habe einen Ansatzpunkt.
Benjamin K. schrieb: > die TCP Frames (aus Putty) haben als Dest MAC den Broadcast > ff:ff:ff:ff:ff:ff und das funktioniert. damit geht aber der Ping nicht. > Und auf einmal schaltet der um auf Dest de:ad:be:ef:fe:ed > Dann geht auch das Ping. Der PC sendet TCP-Frames an ff:ff:ff:ff:ff:ff? Das ist sehr seltsam. Er sollte ja vorher per ARP die zur IP-Adresse gehörige MAC-Adresse erfragt haben. Hat da irgendwann der W5500 positiv mit ff:ff:ff:ff:ff:ff drauf geantwortet? Das würde darauf hindeuten, dass die Ethernet-Bibliothek den W5500 schon aktiviert, bevor die MAC-Adresse gesetzt wird, oder? LG, Sebastian
Sebastian W. schrieb: > Der PC sendet TCP-Frames an ff:ff:ff:ff:ff:ff? Das ist sehr seltsam. Er > sollte ja vorher per ARP die zur IP-Adresse gehörige MAC-Adresse erfragt > haben. Hat da irgendwann der W5500 positiv mit ff:ff:ff:ff:ff:ff drauf > geantwortet? Das würde darauf hindeuten, dass die Ethernet-Bibliothek > den W5500 schon aktiviert, bevor die MAC-Adresse gesetzt wird, oder? Ich vermute das ist meiner Arbeitsweise geschuldet. Ich starte mein Programm (an dem ich ja auch noch weiter dran schreibe) und das setzt als MAC die ff:ff:ff:ff:ff:ff. Damit kommt die Verbindung das erste mal hoch. Windows löst das ARP also mit 192.168.0.48 zu ff:ff:ff:ff:ff:ff auf. Hat zur Konsequenz das TCP geht, aber Ping nicht. Dann spiele ich über USB eine neue Software auf den Arduino. Währendessen ist die Ethernetverbindung ja noch aktiv, der Rechner merkt das gar nicht. Die Arduino kommt jetzt mit einer anderen MAC hoch. Und hier vermute ich, das der Windowsrechner das jetzt gar nicht bemerkt hat. Und ich stelle dann fest, das z.B. die "Ethernet2" Bibliothek auch nicht geht. Ich müsste jedes mal nach dem Programmaufspielen alles abstecken, ausschalten und neu anstecken. Deshalb ging es auch mit Wastls UDP-Tester. Dafür musste ich den ISP Programmer anstecken. Dafür hab ich die Versorgung ausgeschaltet, und das USB-Kabel umgesteckt. Ich werde weiter berichten, falls hier noch Erkentnisse entstehen.
Benjamin K. schrieb: > Ich vermute das ist meiner Arbeitsweise geschuldet. > Ich starte mein Programm (an dem ich ja auch noch weiter dran schreibe) > und das setzt als MAC die ff:ff:ff:ff:ff:ff. Das ist völliger Murks. Benjamin K. schrieb: > Und hier vermute ich, das der Windowsrechner das jetzt gar nicht bemerkt > hat. Der Murks bleibt eine gewisse Zeit im ARP-Cache, bevor ein neuer Request geschickt wird.
Benjamin K. schrieb: > Ich starte mein Programm (an dem ich ja auch noch weiter dran schreibe) > und das setzt als MAC die ff:ff:ff:ff:ff:ff. Das ist eine sehr unschöne MAC-Adresse. Zum einen, weil es eine Gruppenadresse ist (Bit 0 der ersten Bytes ist 1), und zum anderen, weil es die Broadcastadresse ist. Mein W5500 (gerade getestet) reagiert nicht auf ICMP Echo Requests an die Broadcastadresse, und ich kann mir vorstellen, dass er das selbst dann nicht tut, wenn die Broadcastadresse seine eigene MAC-Adresse ist.
1 | 15:43:42.316602 30:b5:c2:08:30:fb (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 98: 192.168.6.1 > 192.168.6.255: ICMP echo request, id 31199, seq 5, length 64 |
Setze als MAC besser eine andere, legale lokale MAC-Adresse. Es muss ja nicht DEADBEEFFEED sein ... LG, Sebastian
:
Bearbeitet durch User
Hmmm schrieb: > Benjamin K. schrieb: >> und das setzt als MAC die ff:ff:ff:ff:ff:ff. > > Das ist völliger Murks. Ja, sag ich doch auch. Ich hab IP und MAC und noch weiteres in den Eeprom gepackt. (Hab ich doch weiter oben geschrieben, ach nee, hab ich ja doch nicht). Damit hat man auf mehreren Geräten dann das gleiche Programm und die Einstellungen bleiben auch bei einem Update erhalten. War halt blöd wenn man das dann einzustellen vergisst und das dann nur halb funktioniert. Und er Eeprom liest halt 0xff wenn noch nicht benutzt. Ja, das Beispielprogramm von ganz oben hab ich genau aufgespielt, das ging dann eben wegen Arp cache auch nicht. Mein Fehler war, die MAC Adresse bei einem Programm falsch eingestellt zu haben und dann den Fehler über den ARP cache dann zu einem völlig funktionierenden Programm verschleppt zu haben.
Benjamin K. schrieb: > Hab das HEX aufgespielt. Nichts eingestellt, nur den Ping ausgeführt, > das geht. > Viel kann ich jetzt nicht ableiten, bei mir geht es ja auch meistens. Oh doch! Du kannst daraus Ableiten, dass es nicht am Hardwareaufbau liegt und auch nicht an der Firmware des Wiznet Chips. Denn der Funktioniert ja.
Benjamin K. schrieb: > de:ad:be:ef:fe:ed "deadbeef feed" ist bestimmt kein Zufall. Danach kann man googeln und findet es z.B. dort wieder: https://xod.io/docs/guide/w5500-advanced/ Das ist wohl der default Wert vom Wiznet Chip. Hast du mehrere davon im Netz?
:
Bearbeitet durch User
Benjamin K. schrieb: > Mein Fehler war, die MAC Adresse bei einem Programm falsch eingestellt > zu haben und dann den Fehler über den ARP cache dann zu einem völlig > funktionierenden Programm verschleppt zu haben. Schön, dass du alles nachvollziehen konntest! LG, Sebastian
Hans W. schrieb: > Benjamin K. schrieb: > "deadbeef feed" ist bestimmt kein Zufall. Natürlich ist das kein Zufall. Das ist die Mac Adresse vom Arduinos Beispiel (siehe ganz oben, WiznetTester.ino) > Das ist wohl der default Wert vom Wiznet Chip. Hast du mehrere davon im > Netz? Ähh, nein, welches Netz? Ein Rechner, ein Kabel und der Arduino.
Hans W. schrieb: > Oh doch! Du kannst daraus Ableiten, dass es nicht am Hardwareaufbau > liegt und auch nicht an der Firmware des Wiznet Chips. Denn der > Funktioniert ja. Nein, genau das kann ich eben nicht ableiten. Mein Aufbau funktionierte ja auch, zumindest zeitweise. Ist das jetzt nur zeitweise besser oder ist das Problem ganz weg?
Sebastian W. schrieb: > Benjamin K. schrieb: >> Mein Fehler war, die MAC Adresse bei einem Programm falsch eingestellt >> zu haben und dann den Fehler über den ARP cache dann zu einem völlig >> funktionierenden Programm verschleppt zu haben. > > Schön, dass du alles nachvollziehen konntest! > > LG, Sebastian Danke, ich hab immer noch einer Knoten im Hirn. ---- Benjamin
Hans W. schrieb: > Das ist wohl der default Wert vom Wiznet Chip. Hast du mehrere davon im > Netz? Vielleicht solltest Du vor dem Kommentieren den Thread komplett lesen. Dann wüsstest Du, dass die Fehlerursache längst gefunden wurde.
Benjamin K. schrieb: > Danke, ich hab immer noch einer Knoten im Hirn. Du könntest die störenden Einträge im ARP-Cache des PC ja auch rechtzeitig löschen. Anscheinend geht das mit "arp -d". Und nach dem Lesen der MAC-Adresse aus dem EEPROM zumindest Bit 0 des ersten Bytes auf 0 setzen. LG, Sebastian
:
Bearbeitet durch User
Sebastian W. schrieb: > Du könntest die störenden Einträge im ARP-Cache des PC ja auch > rechtzeitig löschen. Anscheinend geht das mit "arp -d" Genau das hab ich zum Testen dann ja gemacht. Und ja, das geht. > Und nach dem Lesen der MAC-Adresse aus dem EEPROM zumindest Bit 0 des > ersten Bytes auf 0 setzen. Nee, das ist ja auch gar nicht nötig. Ich prüfe die Mac die ich aus dem Eeprom lese. Wenn das ff:ff.. ist dann nimmt er fest das Deadbeef. Eigentlich ist das auch unnötig, die Mac einstellbar zu haben, es gibt (bis jetzt) nur einen einzigen wiznet im Netzwerk. Das ist für Selbstgebaute Prufstandsautomatisierung. Das muss nachher zuverlässig und ohne größere Eingriffe funktionieren. Aber danke, du hast mir schon geholfen. ---- Benjamin
Eine Idee wäre noch, einen Nano mit Atmega328PB zu nehmen und aus dessen Unique Id eine MAC-Adresse zu hashen. Dann kann man sich unter Umständen das Gedönse mit der erstmaligen EEPROM-Konfiguration sparen. LG, Sebastian
Benjamin K. schrieb: > Aber danke, du hast mir schon geholfen. > Benjamin Das sieht ja blöd aus, ich wollte doch nicht rumschreien. Ich hab doch nur meine Striche gemacht als Signatur. -- Benjamin So sollte das aussehen
:
Bearbeitet durch User
Benjamin K. schrieb: > Das sieht ja blöd aus Smartphone-Nutzer? In einem richtigen Webbrowser sieht das so aus, wie von Dir angestrebt. Eine Signatur ist hier allerdings komplett überflüssig und wird von den allerwenigsten genutzt.
Der Atmel-MC im Nano hat nicht allzu große Ressourcen (2k RAM), nur einen Kern und deshalb kein brauchbares Multitasking. Daher würde UDP deutlich besser passen als TCP, weil es drastisch weniger Ressourcen benötigt. Ich nutze für meine Projekte, bei denen es zugegeben nicht auf große Geschwindigkeit und Datenmengen ankommt, UDP quasi im "Ping-Pong-Mode". UDP selbst hat ja kein Handshaking wie TCP, aber was hindert mich, per UDP eine Bestätigung zurück zu senden? Ich spiele quasi mit UDP das Verhalten von TCP nach, klappt bisher immer, ist sehr zuverlässig und schont den Prozessor ... Man kann in den übertragenen Messages ja verschiedene Befehle codieren, u.a. auch ein "NOP" (no operation mit Antwort) und ersetzt damit das Ping (was wieder auf TCP basiert). Meine Befehle sehen immer so aus: <:COM:PAR:> COM=Kommando PAR=Parameter, Buchstaben (1..3) oder Ziffern mit dazu passenden Antworten. Ich habe eine gut erkennbares Start- und Endekennzeichen, kann den Payload einfach parsen und es ist in einem Monitor-Programm gut lesbar - im Gegensatz zu irgendwelchem binären Kauderwelsch. Manchmal sende ich auch eine ID mit (fortlaufende Zahl), um bei Mehrfachsendung eine mehrfache Ausführung zu verhindern ...
:
Bearbeitet durch User
Frank E. schrieb: > Daher würde UDP deutlich besser passen als TCP, weil es drastisch > weniger Ressourcen benötigt. Es geht um einen Wiznet-Chip, da hat der Controller mit dem TCP-Handling nichts zu tun.
Frank E. schrieb: > Der Atmel-MC im Nano hat nicht allzu große Ressourcen (2k RAM), nur > einen Kern und deshalb kein brauchbares Multitasking. Nun, es kommt darauf an, wie man MT definiert. Aber klar: echtes (wirklich paralleles) MT benötigt mehr als einen Rechenkern, ist also mit dem Nano nicht möglich. Mit der Kombi aus Nano und dem Wiznet-Teil hingegen schon, denn das Ding verfügt über einen eigenen Rechenkern und übernimmt große Teile der Funktionalität einen TCP/IP-Stacks und arbeitet den Kram vollständig selbstständig und parallel zum Nano ab. Dein weiteren Einlassungen betreffen also überhaupt nicht das Problem des TO.
Frank E. schrieb: > Daher würde UDP deutlich besser passen als TCP Wastl schrieb: > Dir ist schon klar dass ......
Frank E. schrieb: > Ich spiele quasi mit UDP das Verhalten von TCP nach, klappt bisher > immer, ist sehr zuverlässig und schont den Prozessor ... Zudem bekommt man garantiert ganze Pakete ...
Wastl schrieb: > Zudem bekommt man garantiert ganze Pakete ... Deren maximale Größe wird vom "schwächsten" Glied in der gesamten Netzwerk-Strecke begrenzt. Soweit ich mich erinnere beginnen die Einschränkungen bei knapp über 500 Bytes.
:
Bearbeitet durch User
Hans W. schrieb: > Soweit ich mich erinnere beginnen die > Einschränkungen bei knapp über 500 Bytes. Solange du nicht dazu sagst auf was du das beziehst, liegen die Einschränkungen bei der MTU und nicht bei 500 Bytes.
Wastl schrieb: > Frank E. schrieb: >> Ich spiele quasi mit UDP das Verhalten von TCP nach, klappt bisher >> immer, ist sehr zuverlässig und schont den Prozessor ... > > Zudem bekommt man garantiert ganze Pakete ... Das stimmt natürlich nicht! Auch UDP-Pakete können fragmentiert werden. Nur wenn der UDP-Traffic auf das LAN beschränkt ist und die Pakete passend zu MTU des LAN generiert werden, kann man davon ausgehen, dass sie nicht fragmentiert werden. Vollidioten, die sich darauf verlassen, sind dann schön angeschissen, wenn die hervorragend funktionierende Lösung dann mal z.B. per VPN benutzt werden soll und auf einmal "unerklärlicherweise" nix mehr geht...
Wastl schrieb: > Solange du nicht dazu sagst auf was du das beziehst, liegen > die Einschränkungen bei der MTU und nicht bei 500 Bytes. Worauf er das bezieht, schrieb er doch: Das schwächste Glied in der Kette, und im Worst Case kommt seine Zahl recht gut hin. Die Mindest-MTU beträgt 576 Bytes, nach Abzug von IP- und UDP-Header sind das maximal 548 Bytes UDP-Payload.
Hmmm schrieb: > Die Mindest-MTU beträgt 576 Bytes Wo hast du denn das her? Nein, das mag für Ethernet gelten, aber ganz sicher nicht global für IP. Und IP kann auch über andere Infrastrukturen transportiert werden als nur Ethernet.
Ob S. schrieb: > Wo hast du denn das her? RFC 791. Ob S. schrieb: > Nein, das mag für Ethernet gelten, aber ganz sicher nicht global für IP. Es gilt allgemein für IP. Faktisch gibt oder gab es zwar auch kleinere MTUs, da müssen sich dann aber die Link-Partner zwingend um die Fragmentierung und Reassembly kümmern - siehe z.B. ATM, wo es keine Mini-MTU gab, sondern die AAL5-Encapsulation dazwischen war. Und daraus folgt dann: "It is recommended that hosts only send datagrams larger than 576 octets if they have assurance that the destination is prepared to accept the larger datagrams."
:
Bearbeitet durch User
Fest steht weiterhin dass UDP für Datenpakete das geeignetere Mittel gegenüber TCP ist, da für den Stream bei TCP aufwendige Parse-Operationen durchgeführt werden müssen um einzelne Datenpakete sicher zu separieren. Nur weil ein Wiznet Chip zufällig kleine Pakete auch über TCP "ganzheitlich" überträgt, garantiert nicht dass das immer funktioniert. So genau kenne ich den RFC für TCP nicht, behaupte aber mal aus dem hohlen Bauch heraus das dafür nichts garantiert bzw. gefordert ist. Siehe auch: Benjamin K. schrieb: > Das geht auch meistens aber manchmal auch nicht.
:
Bearbeitet durch User
Hmmm schrieb: > RFC 791. Bitte genauer spezifizieren, wo das da stehen soll. > Es gilt allgemein für IP. Faktisch gibt oder gab es zwar auch kleinere > MTUs, da müssen sich dann aber die Link-Partner zwingend um die > Fragmentierung und Defragmentierung kümmern Der Punkt ist dann wohl eher, dass die das eben nicht immer tun. Ich bin konkret bei diversen VPNs auf dieses Problem gestoßen. Eigentlich bei ALLEN verbreiteten... Außen (also für den VPN-Tunnel selber) ist das praktisch immer sichergestellt. Aber nicht für den Traffic durch den Tunnel. > "It is recommended that hosts only send datagrams larger than 576 octets > if they have assurance that the destination is prepared to accept the > larger datagrams." Hmmm... Das hört sich dann aber auch schon wieder deutlich vorsichtiger an... Eher so: oberhalb von 576 Bytes MUSST du mit MTU-Problemen rechnen. Das schließt aber sicher nicht aus, dass es auch Probleme unterhalb dieser Grenze geben kann. Und die Praxis zeigt: Es gibt sie.
Wastl schrieb: > Fest steht weiterhin dass UDP für Datenpakete das geeignetere > Mittel gegenüber TCP ist, da für den Stream bei TCP aufwendige > Parse-Operationen durchgeführt werden müssen um einzelne > Datenpakete sicher zu separieren. Ich benutze gerne MQTT für Datenpakete ;) LG, Sebastian
:
Bearbeitet durch User
Ob S. schrieb: > Bitte genauer spezifizieren, wo das da stehen soll. Chapter 3.1 (Header Format), eher als Randnotiz: "All hosts must be prepared to accept datagrams of up to 576 octets (whether they arrive whole or in fragments)." Bis zu dieser Grösse ist also vorgeschrieben, dass selbst im Fall von Fragmentierung alles wieder zusammengebaut werden muss. Pakete bis 576 Bytes brutto (bei UDP 548 Bytes netto) gehen demnach (zumindest in der Theorie) nicht aus diesem Grund verloren. Deutlich eindeutiger ist es in RFC 8200 für IPv6 formuliert: "IPv6 requires that every link in the Internet have an MTU of 1280 octets or greater. This is known as the IPv6 minimum link MTU. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6." Ob S. schrieb: > Der Punkt ist dann wohl eher, dass die das eben nicht immer tun. Murks gibt es häufig. Da muss ich nur an den Ärger in der DSL-Anfangszeit denken, als plötzlich viele mit einer MTU von 1492 unterwegs waren. Das wäre theoretisch kein Problem gewesen, während in der Praxis "schlaue" Admins der Meinung waren, ICMP wäre gefährlich, und so die Path MTU Discovery kaputtgemacht haben. Ob S. schrieb: > Ich bin > konkret bei diversen VPNs auf dieses Problem gestoßen. Eigentlich bei > ALLEN verbreiteten... Wie hast Du es geschafft, die MTU des VPN-Tunnels unter 576 zu bekommen? Mehrere ineinander getunnelte VPNs? Aber wahrscheinlich hatte das nichts mit dieser Grenze zu tun, sondern war ein klassisches TCP-MSS-Problem, z.B. weil der VPN-Client dem OS eine zu grosse MTU vorspielt. Dazu ein kaputtes ICMP-Handling, und der Salat ist perfekt.
Hmmm schrieb: > Wie hast Du es geschafft, die MTU des VPN-Tunnels unter 576 zu bekommen? > Mehrere ineinander getunnelte VPNs? Nein. Der Tunnel selber lief teilweise über eine Transportstrecke mit nur 512 Byte MTU (war physikalisch nicht anders möglich, eben kein Ethernet). Wenn man annimmt, das die von dir zitierten RFC-Teile wirklich eine mandatory-Festlegung darstellen, dann war natürlich schon das spezifikationswidrig. Allerdings: normaler Traffic (ICMP und UDP) über diesen Transport war problemlos möglich. Die MTU-Größe wurde korrekt discovered und UDP-Pakete mit einer Gesamtgröße kleinergleich dieser MTU wurden auch korrekt transportiert. In den verschiedenen getesteten Tunnels passierte dann aber nur Müll. Nicht immer derselbe Müll, aber letztlich war keines der VPNs funktional. > Aber wahrscheinlich hatte das nichts mit dieser Grenze zu tun, sondern > war ein klassisches TCP-MSS-Problem Nein, das kann ich sicher ausschliessen. TCP war weder "außen" noch "innen" involviert. Es wurden immer nur packets (also UDP), niemals streams (also TCP) verwendet. Damit entfallen alle durch die höhere Komplexität von streams denkbaren zusätzlichen Fehlerursachen.
Es gibt im Mode Register ein Bit names Ping Block Mode. Wenn das gesetzt ist kommet kein Ping zurück (datasheet seite 32, v1.0) Vielleicht ist es ja das.
Günther S. schrieb: > Es gibt im Mode Register ein Bit names Ping Block Mode. Wenn das gesetzt > ist kommet kein Ping zurück (datasheet seite 32, v1.0) Vielleicht ist es > ja das. Hatten wir viele Postings vorher schon. Zwischenzeitlich hat sich auch die Ursache der Probleme geklärt: der TO hatte (wie üblich) wesentliche Fakten in seinem OT verschwiegen. Man nennt das: Salamitaktik. Immerhin hat er später noch mit der Wahrheit herausgerückt, so dass der Thread nicht völlig nutzlos ist. Er zeigt zwei Sachen auf: 1) Dass man bei der Beurteilung von Netzwerkfehlern immer auch die Caches der beteiligten Systeme berücksichtigen muss. 2) das man bei der Vergabe von irgendwelchen Default-Adressen zumindest für deren GÜLTIGKEIT sorgen sollte.
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.