Hallo,
Ich bin dabei einen kleinen IP Stack für Mikrocontroller zu schreiben.
Zum einfacheren debuggen habe ich das erst einmal auf dem PC unter Linux
implementiert. Dazu wird ein tap Device erstellt, das als virtuelle
Netzwerkkarte funktioniert. ARP Funktioniert soweit, bei einem Ping
allerdings zeigt die Konsole keine Antwort obwohl im Wireshark alles wie
gewünscht aussieht.
Zum kompilieren einfach make ausführen. Das Programm braucht wegen
TUN/TAP und setzen der IPs leider root Rechte und hört auf die IP
172.16.1.2. Die TAP Schnittstelle hat den Namen "ethdummy" und wird auf
die IP 172.16.1.1/24 gesetzt.
Falls jemand den Grund findet, warum das Ping Kommando keine Antwort
sieht wäre ich sehr dankbar.
Grüße
Stefan A. schrieb:> Ich bin dabei einen kleinen IP Stack für Mikrocontroller zu schreiben.
Was glaubst du besser machen zu können, als es die existierenden
Implementierungen tun?
Diese Frage muss man doch vor allen anderen stellen, meinst du nicht?
c-hater schrieb:> Diese Frage muss man doch vor allen anderen stellen, meinst du nicht?
Ich bin zwar nicht gefragt, ich meine aber nicht dass man sich diese
Frage stellen müsste. Weder vor allen anderen noch generell.
Man kann auch einfach etwas aus Spaß an der Freude oder zu Lernzwecken
entwickeln.
Ansonsten sähe es in diesem Forum sehr leer aus.
Nebenbei: ein eigener embedded IP-Stack steht bei mir auch schon lange
auf der Wunsch-Liste.
Da meine Zeit mit anderen Projekten und Hobbies schon zu mehr als 100%
ausgelastet ist werde ich das aber vermutlich nie anfangen, wie so
vieles anderes.
> Scheint, die Prüfsumme im ICMP-Reply stimmt nicht ...
Danke, es war die IP Prüfsumme. Wireshark markiert diese nicht, wenn die
Option dazu nicht extra angegeben ist. Andere fehlerhafte Prüfsummen
werden allerdings farblich markiert, daher war mir das nicht
aufgefallen.
Vielen Dank!
Le X. schrieb:> Ich bin zwar nicht gefragt, ich meine aber nicht dass man sich diese> Frage stellen müsste. Weder vor allen anderen noch generell.
Ähem... Doch.
> Man kann auch einfach etwas aus Spaß an der Freude oder zu Lernzwecken> entwickeln.
Natürlich. Ich habe auch schon oft Sachen von Grund auf selber
entwickelt, einfach weil es mir Spaß gemacht hat, das zu tun
(witzigerweise u.a. einen TP/IP-Stack ;o).
Dagegen ist absolut nichts einzuwenden. Allerdings sollte man dann auch
in der Lage sein, die Fehler in den eigenen Werken alleine suchen zu
können.
Das ist eigentlich der basic skill.
c-hater schrieb:> Le X. schrieb:>> Ich bin zwar nicht gefragt, ich meine aber nicht dass man sich diese>> Frage stellen müsste. Weder vor allen anderen noch generell.>> Ähem... Doch.>> Man kann auch einfach etwas aus Spaß an der Freude oder zu Lernzwecken>> entwickeln.>> Natürlich. Ich habe auch schon oft Sachen von Grund auf selber> entwickelt, einfach weil es mir Spaß gemacht hat, das zu tun> (witzigerweise u.a. einen TP/IP-Stack ;o).> Dagegen ist absolut nichts einzuwenden. Allerdings sollte man dann auch> in der Lage sein, die Fehler in den eigenen Werken alleine suchen zu> können.
Richtig, und lauflichter darf auch nur noch basteln wer das ohne
Hilfestellung hin kriegt, ist doch klar.
Alter, hast du einen an der Waffel.
c-hater schrieb:> Allerdings sollte man dann auch> in der Lage sein, die Fehler in den eigenen Werken alleine suchen zu> können.> Das ist eigentlich der basic skill.
Prinzipiell natürlich ja. Es gibt aber eigene Fehler, über die schaut
man 20mal und sieht sie nicht. Dann kommt ein Anderer, zeigt drauf und
sagt "Das sieht man doch auf den ersten Blick...".
Dann greift man sich ans Hirn und beklagt die eigene Dummheit.
Been there, survived that :-)
Just my 2 cents
P.S. Natürlich gibts auch Leute, denen das noch nie passiert ist ;-)
Klaus S. schrieb:> Es gibt aber eigene Fehler, über die schaut> man 20mal und sieht sie nicht.
Ohne jeden Zweifel gibt es solche Fehler. Kennt wohl jeder, der
tatsächlich selber entwickelt.
> Dann kommt ein Anderer, zeigt drauf und> sagt "Das sieht man doch auf den ersten Blick...".
Das allerdings ist dann doch schon sehr viel seltener. Das klappt
nichtmal in der kommerziellen Entwicklung mit regulären
Vier-Augen-Reviews so richtig. Ja, mehr oder weniger zufällig kann das
durchaus mal klappen, aber gerade diese ganz kleinen, aber eigentlich
"offensichtlichen" Fehler entziehen sich dem oft. Der ursprüngliche
Entwickler hat die bei weitem größte Chance, sie zu finden.
Es hilft einfach nur Disziplin. Wenn man erstmal sicher weiss, dass da
ein Bug sein muss, dann muss man halt suchen, bis man ihn findet. Das
kann sehr aufwendig sein. Vor allem, wenn man erstmal in die falsche
Richtung sucht.
Aber genau das ist eben da Knowhow erfahrener Entwickler: Wenigstens
ungefähr zu ahnen, wo dieser Scheiß-Bug in etwa sein könnte. Oder
zumindest eine Strategie zur Fehlersuche zu haben, die letztlich in die
richtige Richtung pendelt.
Der Bau so eine Strategie fällt natürlich dem am leichtesten, der den
Code am Besten kennt: also dem ursprünglichen Entwickler.
c-hater schrieb:> Der Bau so eine Strategie fällt natürlich dem am leichtesten, der den> Code am Besten kennt: also dem ursprünglichen Entwickler.
Großartige Fehleinschätzung. Tatsächlich gelingt es dem ursprünglichen
Entwickler bei vielen realen Fehlern kaum, diese zu finden, weil sie in
den von ihm erdachten Testszenarien einfach gar nicht vorkommen können.
Da ist dann der Blick eines anderen erfahrenen Entwicklers, oder auch
einfach nur eine "dumme Frage" oft hilfreicher.
Wer das abstreitet, streitet auch ab, daß es Selbstüberschätzung gibt.
DerEinzigeBernd schrieb:> Tatsächlich gelingt es dem ursprünglichen> Entwickler bei vielen realen Fehlern kaum, diese zu finden, weil sie in> den von ihm erdachten Testszenarien einfach gar nicht vorkommen können.
Dann taugt er nix. Wenn erstmal klar ist, dass da ein Bug sein muss, ist
natürlich der erste Schritt bei der Fehlersuche: Diesen reproduzierbar
zum Vorschein zu bringen. Sprich: die Entwicklung eines geeigneten
Testszenarios, was genau dies leistet.
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