Frank K. schrieb:> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500> ether 76:77:ca:dd:2f:ad txqueuelen 1000 (Ethernet)
Ist es gewollt, dass das Interface nur eine lokale MAC-Adresse hat? Wenn
ja, ist die in Deinem Netz eindeutig?
Frank K. schrieb:> RX packets 382 bytes 76806 (75.0 KiB)> TX packets 17 bytes 2759 (2.6 KiB)
Auf jeden Fall gingen schonmal Pakete rein und raus.
Frank K. schrieb:> PING 192.168.235.2 (192.168.235.2) 56(84) bytes of data.> From 192.168.235.242 icmp_seq=1 Destination Host Unreachable
Klingt danach, dass der ARP-Request schiefgeht. Wie sieht die ARP-Table
aus, und was siehst Du mit tcpdump?
Hmmm schrieb:> Frank K. schrieb:>> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500>> ether 76:77:ca:dd:2f:ad txqueuelen 1000 (Ethernet)>> Ist es gewollt, dass das Interface nur eine lokale MAC-Adresse hat? Wenn> ja, ist die in Deinem Netz eindeutig?
Keine Ahnung, wo die herkommt. Im Uboot steht eine andere. Die hab ich
auch mal übernommen (mit hwaddress ether ....), hat aber nichts
geändert.
> Klingt danach, dass der ARP-Request schiefgeht. Wie sieht die ARP-Table> aus, und was siehst Du mit tcpdump?
root@a20-olinuxino:/etc# arp -an
? (192.168.235.2) at <incomplete> on eth0
? (192.168.235.1) at <incomplete> on eth0
tcpdump ist auf dem System nicht vorhanden, und ohne Netz tu ich mich
auch etwas schwer, da was nachzuinstallieren.
fchk
Frank K. schrieb:> root@a20-olinuxino:/etc# arp -an> ? (192.168.235.2) at <incomplete> on eth0> ? (192.168.235.1) at <incomplete> on eth0
Ja, es klemmt also ganz klar an arp. Allerdings: so ein Fehlerbild habe
ich noch niemals gesehen. Das wird vermutlich schwierig.
> tcpdump ist auf dem System nicht vorhanden, und ohne Netz tu ich mich> auch etwas schwer, da was nachzuinstallieren.
Dann hast du noch zwei Chancen (die allerdings beide einen weiteren
Rechner benötigen):
1) Monitorport am Switch einrichten und Rechner als Sniffer für den
ausgeleiteten Traffic.
2) Rechner mit zwei NICs als Bridge zwischen diesem Olimex-Teil und dem
Switch als Sniffer.
BTW: Vor allem anderen würde ich erstmal ein anderes Patchkabel
probieren. Nicht dass ein beschädigtes Kabel die Ursache des Spuks ist.
oszi40 schrieb:> würde ich auch mal ICMP prüfen ob> ein.
ICMP prüfen ergibt keinen Sinn, wenn schon ARP nachweislich nicht geht.
ICMP ist schließlich zwingend auf ARP angewiesen, um funktionieren zu
können.
Das Kabel ist nachweislich in Ordnung. Ich hatte noch einen 100M
USB-Ethernet-Adapter, und damit konnte ich erstmal Pakete
nachinstallieren. Das scheint mir irgendeine Treibersache zu sein. Keine
Ahnung. Ich muss mal Olimex fragen.
fchk
Frank K. schrieb:> tcpdump ist auf dem System nicht vorhanden, und ohne Netz tu ich mich> auch etwas schwer, da was nachzuinstallieren.
Dann lass tcpdump auf dem angepingten System laufen.
Der ARP-Request geht sowieso als Broadcast raus, wäre also für jedes
System im gleichen Netz sichtbar, und wenn tcpdump auf dem angepingten
System läuft, siehst Du auch noch den Rest.
c-hater schrieb:> BTW: Vor allem anderen würde ich erstmal ein anderes Patchkabel> probieren. Nicht dass ein beschädigtes Kabel die Ursache des Spuks ist.
Wäre einen Versuch wert. Passt zwar nur teilweise zu den Symptomen, weil
DHCP funktioniert, aber sporadische Ausfälle und Murphy's Law machen es
durchaus denkbar.
Frank K. schrieb:> Das Kabel ist nachweislich in Ordnung.
Gut, wenn man das erstmal sicher weiß ;o)
> Das scheint mir irgendeine Treibersache zu sein.
Nun ja, der Netzwerk-Stack funktioniert ja nachweislich in vielen
Millionen Geräten. Da bleiben dann eigentlich nur die Treiber oder
defekte Hardware.
Oder die 192.168.235.2 ist (warum auch immer) verkehrt. Ist das
tatsächlich die IP des Ethernetports der Fritzbox? Mal nen Ping auf die
Broadcastadresse gemacht (ping -b 192.168.235.255)?
Du kannst Dich mal bei mir ans Gastenetz klemmen: Du bekommst per DHCP
eine IP samt Gateway zugewiesen und kannst gerne auf p0rnoslon.ru nackte
xxx angucken, aber bekommst auf Ping weder vom Router noch von anderen
lokalen Maschinen eine Antwort.
Im vertrauenswürdig lokalen Netz sind die natürlich erlaubt.
Guckst Du mal ptbtime3.ptb.de, der liefert zuverlässig die Uhrzeit, aber
Ping versickert im Timeout.
Es kann also gewollt sein, Ping nicht zu beantworten, ohne dass ein
Fehler vorliegt.
Wenn das nicht vorsätzlich so eingerichtet ist, kommt immer noch eine
fehlende Route in Frage, das Ziel kennt den Rückweg nicht.
Manfred schrieb:> aber bekommst auf Ping weder vom Router noch von anderen> lokalen Maschinen eine Antwort.
Es ist eine Sache, auf Ping keine Antwort zu erhalten (timeout). Eine
andere aber, den Frame überhaupt nicht in Netz zu kriegen (unreachable).
(prx) A. K. schrieb:> Es ist eine Sache, auf Ping keine Antwort zu erhalten (timeout). Eine> andere aber, den Frame überhaupt nicht in Netz zu kriegen (unreachable).
"unreachable" würde ich interpretieren, dass das Ziel in einem anderen
Netz liegt und das Gateway fehlt.
Manfred schrieb:> (prx) A. K. schrieb:>> Es ist eine Sache, auf Ping keine Antwort zu erhalten (timeout). Eine>> andere aber, den Frame überhaupt nicht in Netz zu kriegen (unreachable).>> "unreachable" würde ich interpretieren, dass das Ziel in einem anderen> Netz liegt und das Gateway fehlt.
Ja, oder eben im gleichen Subnetz und arp funktioniert nicht. Genau das
ist hier der Fall (siehe oben, arp incomplete). Das hat nichts mit
geblocktem ICMP echo-request o.ä. zu tun.
Manfred schrieb:> "unreachable" würde ich interpretieren, dass das Ziel in einem anderen> Netz liegt und das Gateway fehlt.
Dann gibts nicht "destination host unreachable" wie hier, sondern
"network is unreachable".
Probier es aus: Pinge ein existierendes Gerät an, und während das läuft,
schalte es aus oder zieh es aus dem Netz. Das läuft auf 2 Varianten
raus, gleich oder mit der Zeit:
ARP Eintrag existiert => timeout
ARP Eintrag incomplete => host unreachable
Deshalb haben hier schon einige Leute zurecht auf ARP Problem erkannt.
> Ja, oder eben im gleichen Subnetz und arp funktioniert nicht.
Oder halt eben auch, wenn es den Rechner/die IP einfach nicht gibt.
Genau die gleiche Meldung, die gleichen ARP-Einträge gibt es, wenn er
z.B. den (nicht existierenden) 192.168.235.66 anpingen würde.
Deshalb die Frage: ist 192.168.235.2 die korrekte Adresse des
Ethernetports der Fritzbox? Kannst du die von einer anderen Kiste aus
mit der Adresse anpingen?
foobar schrieb:> Deshalb die Frage: ist 192.168.235.2 die korrekte Adresse des> Ethernetports der Fritzbox?
Er arbeitet mit DHCP und im Startbeitrag steht die daraus abgeleitete
Default-Route auf .2. Um das falsch zu machen muss man schon mit Absicht
Mist bauen.
Hmmm schrieb:> Ist es gewollt, dass das Interface nur eine lokale MAC-Adresse hat? Wenn> ja, ist die in Deinem Netz eindeutig?
Yep, hier wird es interessant. Lokale Adresse heisst, die ist selbst
vergeben, nicht offiziell definiert. Bei Bastelkram mit µC ist das nicht
ungewöhnlich. Aber wehe man verwendet die gleiche mehrfach.
c-hater schrieb:> Monitorport am Switch einrichten
Wird bei den Fritzbox-Ports schwierig. Und wer hat privat schon Switches
mit Mirrorport? Vielleicht hat man aber im Karton mit Hardware-Schrott
noch einen 10- oder 100-Mbit Hub liegen.
Versuche mal sämtliches checksum offloading auszuschalten: "ethtool -K
eth0 tx off rx off"
https://linux.die.net/man/8/ethtool
Vielleicht ist das in der Karte ja kaputt.
foobar schrieb:> Oder halt eben auch, wenn es den Rechner/die IP einfach nicht gibt.
Das stimmt, das Ergebnis bei arp -a sieht dann genauso aus.
> Deshalb die Frage: ist 192.168.235.2 die korrekte Adresse des> Ethernetports der Fritzbox? Kannst du die von einer anderen Kiste aus> mit der Adresse anpingen?
Das sollte man auf jeden Fall probieren/überprüfen. Es gibt nämlich ein
Szenario, bei dem das Gezeigte passieren könnte ganz ohne Hardware- oder
Treiberprobleme. Das wäre ein "parasitärer" DHCP-Server im Netz,
zusätzlich zu dem der Fritzbox, z.B. einer, der auf der Olimex-Kiste
selber läuft...
Da der DHCP-Offer ein Broadcast ist, könnte man das auf jedem Rechner im
Netz problemlos mit tcpdump sehen, also ohne jede Bastelmaßnahme.
Manfred schrieb:> Es kann also gewollt sein, Ping nicht zu beantworten, ohne dass ein> Fehler vorliegt.
Das schimpft sich dann 'stealth modus'. Und kann man einstellen im
Router.
Ist hier aber nicht anwendbar. Ein (IP-) Router, der auf ARP nicht
reagiert, der ist derart stealthy, dass er ohne manuellem ARP auch nicht
routet, sondern nur unnütz Strom verbraucht.
Ein Gerät, das auf ARP reagiert, aber nicht auf PING, ergibt kein "host
not reachable", sondern timeouts.
NB: Mindestens in Linux gibts auch ein "arping", eine Version von
"ping", die nicht nur über ICMP, sondern auch über ARP arbeiten kann.
Auf der Fritzbox kann man unter der Adresse
ip-Adresse-der-Fritzbox/html/capture.html Packetmitschnitte machen.
Vielleicht hilfts ja bei der Fehlersuche.
Viel Erfolg
Es muß ja nicht immer eine Fritzbox sein.
Er könnte auch über ein Crosskabel zu einem 2.PC mit fester Nachbar-IP
gehen um herauszubekommen ob das Übel evtl. an der Treiber-SW liegt und
ob diese Karte grundsätzlich noch gesund ist?
Thread beobachten
Seitenaufteilung abschalten