Alle Dataien von denen geredet wird befinden sich in der Zip-Datai. Außerdem lege ich noch infos zu meiner Bastellösung bei. Nicht erschreken die Main.pas ist Quick and very Dirty Was bisher gescha: Autor: Christof Rieger Datum: 17.04.2006 00:25 Dateianhang: Ping.jpg (30.3kB, 89 Downloads) ------------------------------------------------------------------------ -------- Ich bin verwirrt. Ich habe auf einen Standart initialisierten ENC von Windows XP aus einen Ping gesendet. In der Anlage ist zu erkennen was im ENC Speicher angekommen ist. Die MAC Adressen und die IP-Adressen sind wunderbar zu erkennen. Nur die Strucktur hat nichts mit dem zu tun, was ich hier über den Ping gelesen habe. http://www.it-infothek.de/fhtw/semester_2/re_od_10.html Im Header kann ich auch keine dem Standart entsprechende IP-Strucktur erkennen. Hat da jemand eine Idee ????? Autor: André Kronfeldt (Freakazoid) Datum: 17.04.2006 07:56 ------------------------------------------------------------------------ -------- Da ist der Ethernet-Frame vor. Zudem scheint es der ARP-Request von windows zu sein (Broadcast). Ist Deine WinMac = 00:0a:e6:1a:72:42 (Elitegroup Mainboard g)? Du weißt aber, daß vor jedem empfangenen Ethernet-Paket ein 6Byte Status-Vektor kommt? Autor: Christof Rieger Datum: 17.04.2006 10:04 ------------------------------------------------------------------------ -------- @André Kronfeldt, Danke André das Passt ja alles auch wunderbar, Ether-Frame ist erkennbar und OK, MAC ist OK, Win XP ist OK, Elitegroup ist OK. Aber was nicht OK ist, die MAC des Senders Taucht 2 mal auf, zwischen Quell-IP und Ziehl-IP liegen 6 x 00. Das hat alles nichts mit einem Standart IPv4-Ping-Paket zu tuen wie ich es nach http://www.it-infothek.de/fhtw/semester_2/re_od_10.html erwartet hätte. Wo kann ich nachlesen wie der "Universal" Ping struckturiert ist und welche Antwort er erwartet. Autor: André Kronfeldt (Freakazoid) Datum: 17.04.2006 10:51 ------------------------------------------------------------------------ -------- Es ist ein ARP-Request: HardwareType: 0x0001 Protocol-Type: IP 0x0800 HardwareSize: 6 Protocol Size: 4 Opcode: Request (0x0001) SenderMAC: 00:0a:e6:1a:72:42 SenderIP: 192.168.173.11 TargetMAC: 00:00:00:00:00:00 TargetIP: 192.168.173.250 => Who has 192.168.173.250 tell 192.168.173.11 In Dein Reply kommt an die 6x 0x00 Deine MAC. => 192.168.173.250 is at xx:xx:xx:xx:xx:xx Natürlich taucht die MAC des Senders im ARP-Header UND im ETHERNET-Header auf. Wie kommst Du immer auf IPv4? Dein Bild ist NICHT der Ping (ICMP über IPv4), sondern ein aRP den Windows absetzt um das Ping auszuführen. Eine MAC bleibt nicht sonderlich lange im ARP-Cache ;-) Grüße, Freakazoid Dateianhang: Arp-Request.jpg (38.5kB, 120 Downloads) Hier mal Dein Paket in einem vernünftigen Editor ;-) Autor: Christof Rieger Datum: 17.04.2006 11:12 ------------------------------------------------------------------------ -------- Vielen Dank für das Licht im Dunkel. Das sind meine ersten Versuche. Ich wuste nicht, das vor dem eigentlichen Ping erst ein ARP kommt. Wenn ich das nun Richtig verstanden habe, muss ich nun den APR mit eingesetzert MAC und natürlich mit getauschtem Ziel und Quelle zurücksenden. Daruf hin sendet XP erst den eigentliche Ping ? Autor: André Kronfeldt (Freakazoid) Datum: 17.04.2006 11:20 ------------------------------------------------------------------------ -------- Jo. Das sieht ungefähr so aus: XP: Ey Karte, mach mal Ping an 192.168.173.250 Karte: Okay. Wenn Du mir sagst welche MAC der hat? Ich kann nur Ethernet. Bin halt Billigkarte ;-( XP: Oki. ARP: Who has 192.168.173.250 tell 192.168.173.11 Rieger: 192.168.173.250 is at xx:xx:xx:xx:xx:xx XP: Ey Karte. Mach mal Ping an 192.168.173.250 MAC xx:xx:xx:xx:xx:xx Karte: Ping! Rieger: Pong g Dir fehlt erstmal der erste 'Rieger', also der ARP-Reply ;-) Grüße & viel Erfolg, Freakazoid BTW: ein ARP kommt nur, wenn Du an eine IP was schicken willst und Windows die MAC braucht. NICHT vor jedem Ping. Der ARP-Cache behält die MAC einige Sekunden lang bei. Um zu testen ob Dein Arp-Reply funktioniert schick ein Ping. Bei "No route to host" funktionert Dein ARP-Reply nicht. Bei "Timeout sonstwas" kommt kein Ping-Reply (ICMP). Ein 'arp -a' Zeigt Die auch den Arp-Cache an. Da sollte nach einem Deiner Ping-Versuche sowas wie '192.168.173.250 <incomplete>' stehen. D.h. Windows hat ARP-Request für 192.168.173.250 gesendet, aber noch keine Antwort erhalten. Grüße, Freakazoid Autor: Christof Rieger Datum: 19.04.2006 09:49 ------------------------------------------------------------------------ -------- Noch mal Danke, ich habe auch etwas brauchbares im Internet gefunden. http://www.geocities.com/SiliconValley/Vista/8672/network/arp.html#A22 Autor: Christof Rieger Datum: 20.04.2006 16:21 Dateianhang: arp.jpg (76.8kB, 43 Downloads) ------------------------------------------------------------------------ -------- Windows ignoriert mein ARP-Replay. Lt. ENC Statusvektor (ist auch mit ausgegeben) hat er das Paket sauber übertragen können. Der ENC läuft auf half duplex. Oben steht der WindowsARPrequest unten meine Antwort. Danach hätte ich ein Ping von Windows erwartet, der schickt aber weiter nur Requests. Autor: André Kronfeldt (Freakazoid) Datum: 20.04.2006 20:03 ------------------------------------------------------------------------ -------- Was von dem 2. Paket sendest Du? Alles? Auch das '0f' Anfang? Autor: Christof Rieger Datum: 20.04.2006 20:17 ------------------------------------------------------------------------ -------- Ne 0F ist das INI-Byte für den ENC, so stehts zumindest im Datenblatt. Darauf soll ich ja auch den ETXST zeigen lassen und der ETXND soll auf das letze zu übertragende Byte zeigen! Oder ? Schön von dir zu hören Gruß Christof Autor: André Kronfeldt (Freakazoid) Datum: 20.04.2006 20:23 ------------------------------------------------------------------------ -------- öh? Woher kommt der Datenblock? Geht der so über's Netz, oder ist das nur eine Vermutung von Dir? Am Besten Du schneidest den Datenblock am Hub mit, oder unter Windows. Das 0x0f darf nicht mit übertragen werden. Ansonsten scheint der Reply okay zu sein (grob überflogen). Wo im Datenblatt steht das mit dem INI-Byte? Grüße, Freakazoid Gefunden. Du meinst das 'PACKET CONTROL BYTE'. ja das stimmt. ETXST und ETXND sollten damit korrekt sein. Wird das Paket denn gesendet?
Wenn der ENC im halb Duplex läuft dürfte er mir das Paket nur als gut gesendet anzeigen wenn er es selbst auch wieder empfangen konnte. Oder?. Gib mir mal ein Tip mit welchem Programm ich unter Windows XP den Ethernet Traffic mit verfolgen kann. Wenn Freeware wo Download. Ob das Paket wirklich gesendet wurde [mit den Achsel zuck]. Gruß Christof
Danke! Gefunden. Mich erschrecke die Paketgrößen immer wieder aufs neu 12MB für Tracing. Das muß aber Konfortabel sein.
Das ist nicht nur Tracing, da sind auch die Decoder für dutzende von Protokollen mit drin.
Ich Sehe, Geiles Teil. Der ARP kommt bei XP an und XP erzeugt auch ICMP Echo(ping). Die kommen aber nicht an meinem ENC an. Kann das damit zusammenhängen, dass mein Switch damit Probleme hat, dass das erste Byte meiner gewählten MAC zwar gerade ist aber ungleich null. Ich probiers mal aus.
ethereal: ja das ding ist echt gold wert. ich nutze das jetzt schon einige Jahre... Ist echt supermächtig. Ich kann die Filter immer noch nicht ganz richtig bedienen g Wegen der mac mal nen ausschnitt aus meinem code (bzw kommentar): //nic ethernet address. i picked an address that is free for //experimental/private use (really?) //see the last line: http://standards.ieee.org/regauth/oui/oui.txt //-> AC-DE-48-xx-xx-xx die letzten drei bytes hab ich beliebig gewählt. Bye, Simon
Vielen Dank. Ich Glaube mein ENC empfängt einfach nichts mehr nach dem er den AMR gesendet hat. Die Gelbe LED Blinkt mit jedem Ping -> Switch schaltet durch. Wird in Halb Duplex der Empfänger gesperrt und ich muss den wieder freischalten ?
evtl versuch mal den errate workaround zum tx logic resetten:
1 | //ganz normal paket basteln und zum enc kopieren...
|
2 | |
3 | //bad silicon workaround:
|
4 | //reset tx logic:
|
5 | enc28j60_spi_write_word(ENC28J60_OP_BFS | ENC28J60_REG_ECON1, |
6 | (1<<ENC28J60_BIT_TXRST)); |
7 | enc28j60_spi_write_word(ENC28J60_OP_BFC | ENC28J60_REG_ECON1, |
8 | (1<<ENC28J60_BIT_TXRST)); |
9 | |
10 | //activate transmission
|
11 | enc28j60_spi_write_word(ENC28J60_OP_BFS | ENC28J60_REG_ECON1, |
12 | (1<<ENC28J60_BIT_TXRTS)|(1<<ENC28J60_BIT_RXEN)); |
13 | //return
|
Bye, Simon
Der ENC empfängt nur Broadcasts !?! Wenn ich langenug warte geisten da welche im Netz rum. Die Empfängt er. Ich habe nun aus Verzweiflung UCEN in ERXFCON gelöscht. Geht aber Trotzdem nicht ???
@Christof: Versuch mal 'Packetyzer' von www.networkchemistry.com. Basiert auf Etherreal, ist aber um einiges bunter und übersichtlicher. Grüße, Freakazoid
setzt du die mac adresse beim enc ? ENC28J60_REG_MAADR5 = NIC_MAC0, ENC28J60_REG_MAADR4 = NIC_MAC1, ENC28J60_REG_MAADR3 = NIC_MAC2, ENC28J60_REG_MAADR2 = NIC_MAC3, ENC28J60_REG_MAADR1 = NIC_MAC4, ENC28J60_REG_MAADR0 = NIC_MAC5 aufpassen, ist gedreht! Evtl sendest du mit der falschen mac an ihn ? BYe, Simon
Danke Simon, probier ich dann mal aus, kann es sein, das es Schwachsinn ist UCEN zu löschen wenn ANDOR auch gelöscht ist und BCEN gesetzt ist. Dann reagirt er wirklich nurnoch auf Broadcasts ?!? Logik auf Seite 49.
Simon it was it !!!!!!!!!!!!!!!!!!!!!!!!!! Tausend Dank Bis zu den Problemen mit dem PONG ;-)
Über den gesamten Ethernetframe wird ja eine CRC-Checksumme gebildet. Solange diese OK ist, kann man doch auf die Überprüfung der IP und TCP/UTP/ICMP Checksummen verzichten. Die wären doch nur interesant, wenn man einen Frame mit fehlerhaften CRC verarbeiten möchte um den Fehler einzugrenzen. Die Warscheilichkeit, dass ein Frame mit korrektem CRC trotzdem fehlerhaft ist geht doch gegen 0. Oder !?!
nein! Stell dir folgende Situation vor: [enc28j60]------[router A]-------[router B]------[PC] Wenn jetzt zwischen A und B ein Protokoll gefahren wird dass keine eigene checksum hat oder zb router A ein defektes TCP Paket baut dann kommt beim enc zwar das ethernetpaket richtig an (baut ja router A zusammen) aber das TCP paket könnte trotzdem defekt sein. Du hast ja nicht überall Ethernet bzw zb router bauen ja die ethernetpakete neu zusammen etc. Da könnte schon was schiefgehen ;) Wobei die Router vermutlich auch die TCP Pakete bzw zumindest die IP Pakete checken sollten (oder ?) Zumindest wenn ein Paket übers inet geht weisst du ja nicht wie es transferiert wird. zb wenn ein paket über eine verbindung nach rfc 2549 wandert: http://www.faqs.org/rfcs/rfc2549.html ggg Bye, Simon
OK. Sollte man also in der endgültigen Version berücksichtigen. Ich lasse es beim "Spielen" aber ersteinmal weg. ;) Gruß und Gute Nacht Christof
Erster Erfolg: C:\Dokumente und Einstellungen\Christof>ping 192.168.173.250 Ping wird ausgeführt für 192.168.173.250 mit 32 Bytes Daten: Antwort von 192.168.173.250: Bytes=18 (gesendet 32) Zeit=30ms TTL=128 Antwort von 192.168.173.250: Bytes=18 (gesendet 32) Zeit=19ms TTL=128 Antwort von 192.168.173.250: Bytes=18 (gesendet 32) Zeit=23ms TTL=128 Antwort von 192.168.173.250: Bytes=18 (gesendet 32) Zeit=25ms TTL=128 Ping-Statistik für 192.168.173.250: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 19ms, Maximum = 30ms, Mittelwert = 24ms Ohne Ethereal wär das debuging sehr Aufwendig.
Guten Morgen ;) ich hoffe hier sind auch Hardware Fragen erlaubt... Ich grübel gerade darüber warum einige einen 100k Pull-up an die CS Leitung des ENC gelegt haben. Ich habe auch in einem Schaltplan folgendes gefunden:
1 | |
2 | /|\ 3,3v |
3 | |
|
4 | | | |
5 | |_| 100k |
6 | |
|
7 | __ | |
8 | CS ------ µC, normaler pin (@5V/0V) |
Sehe ich das richtig, das der Pull-Up nur den Strom begrenzen soll? Muss dieser Widerstand verwendet werden? Ich würde mich freuen, wenn mich jemand aufklären könnte. Vielen Dank im Voraus. Peter
Also ich hab den Enc schon an einem uc mit 5V und 3.3V laufen und bei beiden habe ich keinen solchen Widerstand verwendet. So funktioniert das nun seit 2 Wochen. Obs optimal ist kann ich nicht sagen, aber da nach ENC Datenblatt ja kein Levelshifting nötig ist, wüsste ich auch nicht warums schaden sollte, keinen zu verwenden. Evt wird der Widerstand ja verwendet, um /CS möglichst schnell auf high zu legen (deaktiviert). Fände ich jedenfalls auch merkwürdig, das programmieren des uC funzt auch so ohne Probleme. Evt kann uns noch jemand anders aufklären (?) :-)
Wenn es sehr kritisch wäre, würde der Chip in 2 Wochen sicher schon mal gemeckert haben ;) Ich habe noch einen Schaltplan gefunden (vom "Pictail Daught Board")er, aus dem Microchip Stack Zip (MCHPStackENC8722). In diesem ist auch ein 100k Widerstand nach 3,3V gezogen. Wenn ich man drüber nachdenke, verwirrt mich jetzt, das der Pin (wie in der Zeichnung von meinem letzten Post, ja im High Zustand auf 5 Volt liegt, aber der Pull-Up nach 3,3V zieht?! Mag auch daran liegen das es fast 3 Uhr ist, aber irgendwie ist mir das jetzt völlig unverständlich.
Laut Datenblatt hat der /CS-Pin einen (schwachen) internen pull-up an 3,3V, daher habe ich ihn bei meinem Design weggelassen. Wenn man schon einen extern verbauen möchte, dann sollte der eher im Bereich von 10k liegen, damit dieser auch dominiert.
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.