ETH_M32 auf Net-IO

[Tobias S. (Gast)]

Hallo zusammen,

ich weiß es ist nicht der erste Beitrag zu dem Thema in diesem Forum, 
jedoch kann ich mein Problem in keiner Weise in einem Thema wieder 
finden.

Möchte einen Einstieg zum ENC28J60 bekommen. Daher hab ich mir ein 
Net-IO als Fertigmodul besorgt.

Nun hab ich erst einmal die angepasste Software von Ulrich Radig, von 
dieser Quelle auf den Net-IO gespielt: 
http://gm.stream-center.de/webserver/
Dazu dann erstmal die ganzen Fehler mit const und static bei den chars 
beseitigt. Lässt sich danach ohne Fehler kompilieren.

Hab anschließend die Config und ein paar Einstellungen geändert, passend 
die Fuses.
Das Net-IO meldet sich über DHCP auch kurz am Router an, ist jedoch 
sofort wieder weg. Beim anpingen kommt genau eine Antwort zurück. Danach 
ist Ende.


Kennt jemand dieses Phänomen oder kann mir einen Tipp geben, wo ich 
schauen kann?

Wäre für ein paar Tipps sehr dankbar.

Freundliche Grüße
Tobias

[leluno (Gast)]

mit wireshark schauen, wo sich das Teil aufhängt

[Georg G. (df2au)]

Tobias S. schrieb:
> Das Net-IO meldet sich über DHCP auch kurz am Router an

Bitte etwas präziser. Wird die DHCP Lease bezogen? Wenn ja, für welche 
Zeit?
Ist das Net-IO nach dieser Zeit komplett tot? ARP Cache im PC löschen, 
neuen Ping starten, mit Wireshark kontrollieren, was noch geht.

Die Radig Soft hat ein paar Problemchen, die grundlegenden Funktionen 
sind aber brauchbar.

[Tobias (Gast)]

Hallo zusammen,

habe Wireshark installiert und ein neuen Ping durchgeführt.
Anschließend dann den ARP Cache gelöscht.

Danach habe ich wieder ein Ping durchgeführt, mit eingeschaltetem 
Wireshark.
Es kamen folgendes Zeilen, die den Ping beschreiben sollten.


Zur Lease-Zeit. Kann ich außerhalb des Net-IO sehen ob Sie bezogen wird.
Den Datenverkehr zwischen Net-IO und Router kann ich ja leider nicht so 
ohne weiteres prüfen oder?

Gruß Tobias

[Tobias (Gast)]

Hallo,

hab jetzt mal folgendes gemacht:
ARP Eintrag nur für Net-IO auf dem PC gelöscht. Dort steht komischer 
weise immer der Verweis auf den Router drin. Warum auch immer.

Eintrag mit richtiger Mac erstellt. Funktioniert einwandfrei. Allerdings 
kann ich das ja nun kaum an jedem Gerät machen, von dem ich auf das Ding 
zugreife.

Könnte das ein Problem des Net-Io Code sein?

Gruß Tobias

[Stefan F. (Gast)]

> Den Datenverkehr zwischen Net-IO und Router kann ich ja leider
> nicht so ohne weiteres prüfen oder?

Bei meinen beiden Internet Routern geht das einfach so ohne besondere 
Konfiguration - ich hatte ebenfalls gedacht, es würde nicht gehen. Ich 
vermute mal, dass Wireshark irgendein Signal an den Router sendet, um 
ihn transparent zu machen, so dass man den Traffic der "anderen" Rechner 
mitschnüffeln kann.

Es geht (zumindest in meinem Fall) sogar, wenn der Laptop über WLAN 
angebunden ist, der Mikrocontroller jedoch über Kabel.

> Zur Lease-Zeit. Kann ich außerhalb des Net-IO sehen ob Sie bezogen wird.

Mein neuer Router zeigt unter "DHCP CLient List" die Mac-Adressen, 
Hostnamen und auch die Lease-Zeit an. Der alte Router zigte die 
Lease-Zeit nur im Logfile an.

> ARP Eintrag nur für Net-IO auf dem PC gelöscht.
> Dort steht komischer weise immer der Verweis auf den Router drin.

Möglicherweise, weil dein PC in einem anderen Subnetz (WLAN) als der 
Mikrocontroller (Kabel) hängt. Dann läuft jede Kommunikation über das 
Gateway.

> Könnte das ein Problem des Net-Io Code sein?


Ja könnte sein. Ich habe gerade erst ein ähnliche Problem bei meinem 
Mini-Webserver gelöst, der ebenfalls auf µIP basiert, wie der von Herrn 
Radig.

Ich hatte den DHCP Client v1.0 von Adamp Dunkels verwendet. Der hat zwei 
zwei Fehler:

1) PT_WAIT_UNTIL muss in PT_YIELD_UNTIL geändert werden.
2) Zwei auskommentierte Code-Zeilen bezüglich Abfrage der DNS Adresse 
müssen einkommentiert werden (auch wenn man DNS nicht benötigt). 
Ansonsten fehlt im DHCP Request ein Byte, worauf manche Router 
empfindlich reagieren.

Weiterhin ist in pt.h (in v1.0) ein Fehler, der bewirkt, dass PT_YIELD 
in Sub-Threads nicht funktioniert. Ich hänge die korrigierte Version mal 
an.

Außerdem ignoriert der DHCP Client v1.0 die Lease time. Er sollte so 
geändert werden, dass das Modul die DHCP-Adresse vor Ablauf der Lease 
Time erneuert. Ich hänge meine Änderung ebenfalls mal an. Du kannst 
meine Datei aber sicher nicht 1:1 übernehmen. Muss schon manuell mergen.

[Martin K. (maart)]

Eigenartig finde ich es, dass sich innerhalb kurzer Zeit bei dir die 
MAC-Adresse des Net-IO verändert hat.

[Stefan F. (Gast)]

Das könnte durch einen Buffer-Overflow ausgelöst werden.

In meinem Werserver hatte war in Zusammenhang mit DHCP auf einen 
gemeinen Buffer-Overflow gestoßen: Mein Ethernet Puffer ist 1400 Bytes 
groß. Mein Router beantwortet DHCP Requests jedoch immer mit 1600 Bytes 
- obwohl nichtmal 400 Bytes davon verwendet werden. Wireshark zeigt 
leider nur die Anzahl der verwendeten Bytes an. Der Ethernet 
Controllermeldet jedoch die tatsächliche Anzahl von Bytes. In einer 
for-Schleife kopiert der Treiber alle 1600 Bytes ins RAM und 
überschreibt damit eine Menge Variablen (weil das Array ja nur 1400 
Bytes groß ist). Ich musste in den Treiber also einen zusätzlichen Check 
einbauen:

u16_t CP2200_ReadPacket(void)
{
        u16_t packetlen;
        u16_t i;
        packetlen = read_CP2200(CPLENH);
        packetlen = packetlen << 8;
        packetlen |= read_CP2200(CPLENL);

        if (packetlen>UIP_BUFSIZE) {
          packetlen=UIP_BUFSIZE;
        }

        for (i=0;i<packetlen;i++)
        {
                *(uip_buf+i) = read_CP2200(RXAUTORD);
        }
        return(packetlen);
}

Möglicherweise hat dein Treiber für den EN28J60 den selben Fehler.

[Stefan F. (Gast)]

Ich habe gerade mal in Herrn Radigs Code reingeschaut. SIeht so aus, als 
ob er den Check gegen Pufferüberlauf schon drin hat:

unsigned int enc_receive_packet( unsigned int bufsize, unsigned char *buf )
{
...

  // if the application buffer is to small, we just truncate
  if( len > bufsize ) len = bufsize;

[Stefan F. (Gast)]

Vergiss meine Sourcen von µIP, der code vom Radig baut ja gar nicht 
darauf auf. Das hatte ich wohl falsch in Erinnerung.

[Tobias S. (Gast)]

Stefan us schrieb:
> Ich habe gerade mal in Herrn Radigs Code reingeschaut. SIeht so
> aus, als
> ob er den Check gegen Pufferüberlauf schon drin hat:unsigned int
> enc_receive_packet( unsigned int bufsize, unsigned char *buf )
> {
> ...
>
>   // if the application buffer is to small, we just truncate
>   if( len > bufsize ) len = bufsize;


Ja, genau das habe ich auch gesehen. Das Netzwerk ist schon das 
richtige. Ich arbeite nur in den Standart Ip-Adresse also 
192.168.178....

Im Router wird komischer weise auch alles Grün angezeigt. Also das Gerät 
wäre verbunden. Ist es ja auch, nur erhält kein Rechner, kein Tables 
oder sonst was den Verweis zur Mac-Adresse.

Habe jetzt die MAC mal geändert und über DHCP zuweisen lassen. Klappt 
auch soweit aber leider fehlt wie vorher auch der Eintrag im ARP-Cache.

Gruß Tobias

[leluno (Gast)]

Die Änderung der MAc-Adresse kann eigentlich nicht vom netIO ausgehen. 
Das ist ausgereifte Software, die fehlerfrei funktioniert. Irgendwo ein 
Firewall?
Falls du ein cross-Kabel hast, probier den Anschluss mal ohne Gateway.

[c-hater (Gast)]

Tobias schrieb:

> hab jetzt mal folgendes gemacht:
> ARP Eintrag nur für Net-IO auf dem PC gelöscht. Dort steht komischer
> weise immer der Verweis auf den Router drin. Warum auch immer.
>
> Eintrag mit richtiger Mac erstellt. Funktioniert einwandfrei. Allerdings
> kann ich das ja nun kaum an jedem Gerät machen, von dem ich auf das Ding
> zugreife.

Ich würde darauf tippen, daß du auf deinem PC Windows laufen hast, von 
dem aus du auch gepingt hast und daß unter diesem Windows auch entweder 
eine VirtualBox-VM installiert ist und/oder ein Cisco-VPN-Client.

Kannst du das ganz oder teilweise bestätigen?

[Nosnibor (Gast)]

Also wenn ich das Wireshark-Orakel richtig deute, ist in dem Netz die 
192.168.178.210 doppelt vergeben. Sollte man nicht machen, sowas, denn 
das hat jede Menge verwirrender Effekte zur Folge.

Wireshark zeigt:
 1. ARP-Broadcast: 192.168.178.100 fragt nach 192.168.178.210
 2. ARP-Antwort: 192.168.178.210 ist 00:20:18:b1:15:6f
 3. Ping-request 192.168.178.100 --> 192.168.178.210
 4. Ping-Antwort dazu
 5. zweite ARP-Antwort: 192.168.178.210 ist jetzt 00:24:fe:e6:5f:5b

Da sind also zwei Geräte im Netz (00:20:18:b1:15:6f und 
00:24:fe:e6:5f:5b), die sich beide einbilden, Inhaber der IP-Adresse 
192.168.178.210 zu sein. Eines davon (wohl der Router, wenn man von der 
Herstellerkennung in der Ethernetadresse ausgeht) hat für die 
ARP-Antwort 200ms gebraucht, deshalb hat das andere den Ping-request 
bekommen und inzwischen auch beantwortet. Aber man kann sich nicht 
darauf verlassen, daß der Router jedesmal so lahm ist.

Also: wer hat in dem Netz die IP-Adressen vergeben und warum hat er das 
falsch gemacht?

[Tobias (Gast)]

c-hater schrieb:
> Tobias schrieb:
>
>> hab jetzt mal folgendes gemacht:
>> ARP Eintrag nur für Net-IO auf dem PC gelöscht. Dort steht komischer
>> weise immer der Verweis auf den Router drin. Warum auch immer.
>>
>> Eintrag mit richtiger Mac erstellt. Funktioniert einwandfrei. Allerdings
>> kann ich das ja nun kaum an jedem Gerät machen, von dem ich auf das Ding
>> zugreife.
>
> Ich würde darauf tippen, daß du auf deinem PC Windows laufen hast, von
> dem aus du auch gepingt hast und daß unter diesem Windows auch entweder
> eine VirtualBox-VM installiert ist und/oder ein Cisco-VPN-Client.
>
> Kannst du das ganz oder teilweise bestätigen?

Ja, das ist korrekt. Ich arbeite mit der Virtual Box.
Nur ist es so, dass ich von einem Apple oder Adrioid Gerät auch keinen 
Zugriff auf das Net-IO habe. Kann also eigentlich nicht am Client 
liegen, von dem ich auf das Net-IO zugreife.

[Tobias S. (tobias-s)]

Ich habe es nach langem probieren endlich hin bekommen.

Der Router hat ordentliche Probleme gemacht.
Habe alle Einträge des Net-IO gelöscht und dann nochmal die Mac-Adresse 
geändert. Jetzt läuft alles einwandfrei.

Gruß Tobias