Ethernet-Karte Hänger
-
Topic author - Rank 5
- Beiträge: 422
- Registriert: Sa 27. Okt 2018, 17:51
- Hauptanschluß: 898906 laeng d
Re: Ethernet-Karte Hänger
Interessante Beobachtung am Rande: Ist die Eth-Karte "blockiert", zeigt also das rote Lämpchen, so wird die Karte *NICHT* mehr durch fragmentierte ICMP-Echo-Requests abgeschossen. Das verstehe ich nicht ganz, denn die Eth-Behandlung (inklusive Verwurf zu langer oder fragmentierter Frames) ist ja im Interrupt und sollte daher nicht von der Threadblockade betroffen sein. Die Blockade habe ich durch Blockieren des I2C-Busses provoziert.
Frage an Fred am Rande: Läuft bei Dir die Eth-Karte mit angeschlossener serieller Debugschnittstelle? Komischerweise blockiert die Karte bei mir reproduzierbar, wenn ich seriell etwas angeschlossen habe um dort mitzulesen und dann einne HTTPS-Request sende. Ich sehe dann die HTTP-Abfragen im Debug, aber sie laufen dann aufs rote Lämpchen und auf Timeout im Browser. Das passiert lustigerweise nicht wenn die Schnittstelle unbeschaltet ist, ggf. Blockade über Hardwarehandshakesignale?
Frage an Fred am Rande: Läuft bei Dir die Eth-Karte mit angeschlossener serieller Debugschnittstelle? Komischerweise blockiert die Karte bei mir reproduzierbar, wenn ich seriell etwas angeschlossen habe um dort mitzulesen und dann einne HTTPS-Request sende. Ich sehe dann die HTTP-Abfragen im Debug, aber sie laufen dann aufs rote Lämpchen und auf Timeout im Browser. Das passiert lustigerweise nicht wenn die Schnittstelle unbeschaltet ist, ggf. Blockade über Hardwarehandshakesignale?
- Folgende Benutzer bedankten sich beim Autor ProgBernie für den Beitrag:
- BjoernS
Gruß Bernd
--
Fernschreibstelle Labenz
898906 laeng d
--
Fernschreibstelle Labenz
898906 laeng d
-
- Founder
- Beiträge: 2320
- Registriert: Fr 3. Jun 2016, 13:49
- Wohnort: Braunschweig
- Hauptanschluß: 8579924 hawe d
Re: Ethernet-Karte Hänger
So komplett habe ich die bestehende Struktur des Basisprojekts "OpenMCP" noch nicht durchschaut, ich vermute aber, dass in der Interrupt-Behandlung nur "zeitkritische" Aktionen laufen (Vermutung: Daten abholen und in einen Puffer schreiben).ProgBernie hat geschrieben: ↑Di 14. Jul 2020, 11:51 Interessante Beobachtung am Rande: Ist die Eth-Karte "blockiert", zeigt also das rote Lämpchen, so wird die Karte *NICHT* mehr durch fragmentierte ICMP-Echo-Requests abgeschossen. Das verstehe ich nicht ganz, denn die Eth-Behandlung (inklusive Verwurf zu langer oder fragmentierter Frames) ist ja im Interrupt und sollte daher nicht von der Threadblockade betroffen sein. Die Blockade habe ich durch Blockieren des I2C-Busses provoziert.
Alles andere läuft in "kooperativen" Threads. Von diesen Threads ist die i-Telex-Kernfunktion nur einer, der HTTP-Server z.B. ein anderer.
Das zeitkritische Generieren des 50 Baud-Taktes ist in einer Interrupt-Funktion realisiert. Diese prüft, ob auch der "normale" i-Telex-Thread mindestens alle 2 Sekunden aufgerufen wird, wenn nicht, wird die rote Lampe angemacht.
Wenn also die rote Lampe an ist, werden vermutlich alle nicht-interrupt-gesteuerten Funktionen aufgerufen, wahrscheinlich auch nicht die, die den "Absturz" verursacht.
Das ist sehr merkwürdig. Das RTS und CTS sind zwar an den Atmel geführt, werden aber nicht ausgewertet.Frage an Fred am Rande: Läuft bei Dir die Eth-Karte mit angeschlossener serieller Debugschnittstelle? Komischerweise blockiert die Karte bei mir reproduzierbar, wenn ich seriell etwas angeschlossen habe um dort mitzulesen und dann einne HTTPS-Request sende. Ich sehe dann die HTTP-Abfragen im Debug, aber sie laufen dann aufs rote Lämpchen und auf Timeout im Browser. Das passiert lustigerweise nicht wenn die Schnittstelle unbeschaltet ist, ggf. Blockade über Hardwarehandshakesignale?
Ich sinniere gerade, ob irgendwelche an die Serielle Schnittstelle gesendeten Daten irgendwas anrichten können.
Aber das ist nicht der Fall, wenn der Empfangspuffer voll ist, dann werden Daten von dem UART verworfen.
Ich habe schon häufig über Stunden die serielle Debug-Ausgabe aufgezeichnet, nie hatte ich dort ein anderes Verhalten als sonst.
HTTPS-Request an Port 80 oder wie?
- Folgende Benutzer bedankten sich beim Autor FredSonnenrein für den Beitrag:
- BjoernS
Grüße,
Fred Sonnenrein, Braunschweig
i-Telex 952741 (Lo133), 8579924 (T100s), 781272 (T100), 792911 (T68d) oder 531072 (T.typ.72)
Bei besetzt oder gestört bitte 531002 versuchen.
Fred Sonnenrein, Braunschweig
i-Telex 952741 (Lo133), 8579924 (T100s), 781272 (T100), 792911 (T68d) oder 531072 (T.typ.72)
Bei besetzt oder gestört bitte 531002 versuchen.
-
Topic author - Rank 5
- Beiträge: 422
- Registriert: Sa 27. Okt 2018, 17:51
- Hauptanschluß: 898906 laeng d
Re: Ethernet-Karte Hänger
Hallo Fred,
vielleicht sollten wir die Diskussionen in die Entwickler-Ecke verschieben?
icmp() behandelt den EchoRequest direkt und ruft sogleich wieder sendEthernetFrame auf.
udp() und tcp() kopieren die Daten in die entsprechende socket-Struktur.
Noch eine Frage. Du sagtest das Blinken der grünen wäre ein erfolgloser RAM-Test. Ich habe das im code und experimentell nicht bestätigen können. Ein fehlschlagender RAM-Test lässt rot-gelb an und grün dauerhaft aus, habe ich mit einer Manipulation am 573 provoziert. Auch xram.c sagt da: LED aus, WDT aus und Endlosschleife.
BTW: Ich habe jetzt den Code komplett ohne die als DEPRECATED markierten prog_char am laufen.
vielleicht sollten wir die Diskussionen in die Entwickler-Ecke verschieben?
Das ist leider nicht ganz so, zumindest die gesamten ICMP-Sachen laufen alle komplett innerhalb des Interrupts, sogar das Senden der Antwort. Ich hätte auch erwartet daß die empfangenen Frames in eine Queue gepackt werden und dann später verabreitet. Aber die Methode ethernet() in system/net/ethernet.c is direkt die ISR und ruft arp() bzw. ip() auf. In ip() wird dann nach icmp(), udp() und tcp() verzweigt.FredSonnenrein hat geschrieben: ↑Di 14. Jul 2020, 13:07 So komplett habe ich die bestehende Struktur des Basisprojekts "OpenMCP" noch nicht durchschaut, ich vermute aber, dass in der Interrupt-Behandlung nur "zeitkritische" Aktionen laufen (Vermutung: Daten abholen und in einen Puffer schreiben).
icmp() behandelt den EchoRequest direkt und ruft sogleich wieder sendEthernetFrame auf.
udp() und tcp() kopieren die Daten in die entsprechende socket-Struktur.
Ja, nur komischerweise müsste der Absturz eigentlich ja im ISR passieren, wenn es um ICMP geht. Und dort hatte ich ja eingebaut, fragmentierte Frames zu verwerfen. da hatte ich fest mit einem Erfolg gerechnet.FredSonnenrein hat geschrieben: ↑Di 14. Jul 2020, 13:07 Alles andere läuft in "kooperativen" Threads. Von diesen Threads ist die i-Telex-Kernfunktion nur einer, der HTTP-Server z.B. ein anderer.
Das zeitkritische Generieren des 50 Baud-Taktes ist in einer Interrupt-Funktion realisiert. Diese prüft, ob auch der "normale" i-Telex-Thread mindestens alle 2 Sekunden aufgerufen wird, wenn nicht, wird die rote Lampe angemacht.
Wenn also die rote Lampe an ist, werden vermutlich alle nicht-interrupt-gesteuerten Funktionen aufgerufen, wahrscheinlich auch nicht die, die den "Absturz" verursacht.
Normaler Aufruf der 80er-Webseite. Ich kann es mir auch nicht so recht erklären. Ich dachte es liegt an meinen eingebauten Debugs, aber auch ein flashen der "offiziellen" 867 änderte da nichts.FredSonnenrein hat geschrieben: ↑Di 14. Jul 2020, 13:07 Das ist sehr merkwürdig. Das RTS und CTS sind zwar an den Atmel geführt, werden aber nicht ausgewertet.
Ich sinniere gerade, ob irgendwelche an die Serielle Schnittstelle gesendeten Daten irgendwas anrichten können.
Aber das ist nicht der Fall, wenn der Empfangspuffer voll ist, dann werden Daten von dem UART verworfen.
Ich habe schon häufig über Stunden die serielle Debug-Ausgabe aufgezeichnet, nie hatte ich dort ein anderes Verhalten als sonst.
HTTPS-Request an Port 80 oder wie?
Noch eine Frage. Du sagtest das Blinken der grünen wäre ein erfolgloser RAM-Test. Ich habe das im code und experimentell nicht bestätigen können. Ein fehlschlagender RAM-Test lässt rot-gelb an und grün dauerhaft aus, habe ich mit einer Manipulation am 573 provoziert. Auch xram.c sagt da: LED aus, WDT aus und Endlosschleife.
BTW: Ich habe jetzt den Code komplett ohne die als DEPRECATED markierten prog_char am laufen.
- Folgende Benutzer bedankten sich beim Autor ProgBernie für den Beitrag:
- BjoernS
Gruß Bernd
--
Fernschreibstelle Labenz
898906 laeng d
--
Fernschreibstelle Labenz
898906 laeng d
-
Topic author - Rank 5
- Beiträge: 422
- Registriert: Sa 27. Okt 2018, 17:51
- Hauptanschluß: 898906 laeng d
Re: Ethernet-Karte Hänger
Debugausgabe bei angeschlossenem Sellerie-Kabel:
Aufgerufen wurde zunächst die Startseite, dann i-Telex (Deutsch), dann Debug-Infos. Beim Abruf der Debug-Infos geht dann die rote LED an und bleibt es bis zum Watchdog, der die Karte erneut startet. Die Webseite zeigt die Debug-infos bis:
Nehme ich das Kabel ab, so kommen alle Zeilen der Debug-Infos im Browser. Aber nun kommts: Nehme ich den MAX232ACPE aus der Platine, bleibt die Ausgabe auch hängen! Ich nehme an das Aufleuchten von rot bei Abruf der Webseiten ist normal, das passiert nämlich immer.
Code: Alles auswählen
iTelex...
UART Initialisiert
STDOUT Initialisiert
CLOCK Initialisiert
LED_core Initialisiert
Config Initialisiert
EXTINT Initialisiert
MMC/SD Error
SHELL Initialisiert
THREAD Initialisiert
itelex_init1:
...SendePuffer, EmpfPuffer ok
...Config ok
...Timer-Callback-Funktion ok
ENC28j60 (Rev.: 6) initialisiert ( HW-Add: 02:03:6f:55:1c:c8 ) Fullduplex: Link ready
-+-> ARP initialisiert
|-> UDP (Tornado-engine) initialisiert
|-> TCP (Hurrican-engine) initialisiert
|-> Versuche DHCP-Config zu holen. DHCP-Config geholt
| IP : 192.168.178.90
| Netmask: 255.255.255.0
| Gateway: 192.168.178.1
| DNS : 192.168.178.1
|-> NTP-Server Zeit aktualisieren:Oeffne neues Socket.
UDP-Socket aufgemacht zur 130.133.1.10.
UDP-Packet gesendet.
Warte auf Antwort.Antwort erhalten.
UDP-Socket geschlossen.
Zeit: 18:56:57.84
HTTP-Server Port 80.
Telnet-Server Port 23.
itelex_init2:
...Cgi ok
iTelex Port 134.
...Email ok
...TlnBuch ok
http-server: index.html ( 470 Byte uebertragen (FLASH)
http-server: headline.html ( 217 Byte uebertragen (FLASH)
http-server: mainmenu.html ( 448 Byte uebertragen (FLASH)
http-server: info.html ( 910 Byte uebertragen (FLASH)
http-server: lochstreifen-hg.png ( 777 Byte uebertragen (FLASH)
http-server: style.css ( 448 Byte uebertragen (FLASH)
http-server: favicon.ico ( 0 Byte uebertragen (SD)
http-server: itelex-menu-de.html ( 542 Byte uebertragen (FLASH)
Code: Alles auswählen
TCP_socket[0]: ConnectionState=16, SendState=0, SourcePort=47156, DestinationPort=80, SourceIP=2EB2A8C0, Timeoutcounter=30
TCP_socket[1]: closed
TCP_socket[2]: closed
TCP_socket[3]: closed
TCP_socket[4]: closed
TCP_socket[5]: closed
NetzPort = 134
NetzEigeneIP = 00
LangTimerVal(&ZeitServerAbfrageTimer) = 4
- Folgende Benutzer bedankten sich beim Autor ProgBernie für den Beitrag:
- BjoernS
Gruß Bernd
--
Fernschreibstelle Labenz
898906 laeng d
--
Fernschreibstelle Labenz
898906 laeng d
-
Topic author - Rank 5
- Beiträge: 422
- Registriert: Sa 27. Okt 2018, 17:51
- Hauptanschluß: 898906 laeng d
Re: Ethernet-Karte Hänger
Und noch was interessantes: Die 825 protokolliert seriell und hängt sich dabei auch nicht weg. Viel weniger "ROT" bei Zugriffen über HTTP und alles wird seriell ohne Hänger geloggt.
Die Zeilen
fehlen mir in den neueren Versionen stets.
Die Zeilen
Code: Alles auswählen
iTelex TlnServer Port 11811.
...Teilnehmer-Server ok
00:00:00,20: Neustart 825 Reset-Flags 05
23:33:08,09: iTelex: Teilnehmer-Verzeichnis aus EEPROM geladen.
- Folgende Benutzer bedankten sich beim Autor ProgBernie für den Beitrag:
- BjoernS
Gruß Bernd
--
Fernschreibstelle Labenz
898906 laeng d
--
Fernschreibstelle Labenz
898906 laeng d
-
- Founder
- Beiträge: 2320
- Registriert: Fr 3. Jun 2016, 13:49
- Wohnort: Braunschweig
- Hauptanschluß: 8579924 hawe d
Re: Ethernet-Karte Hänger
Dann werde ich mal den Unterschied zwischen der 825 und der aktuellen Version genau überprüfen.
Fakt ist: Die Teilnehmer-Server-Funktion ist entfernt (da nicht mehr benötigt), dass auch das Auslesen des EEPROM dabei auf der Strecke geblieben ist, ist nicht beabsichtigt gewesen.
Fakt ist: Die Teilnehmer-Server-Funktion ist entfernt (da nicht mehr benötigt), dass auch das Auslesen des EEPROM dabei auf der Strecke geblieben ist, ist nicht beabsichtigt gewesen.
- Folgende Benutzer bedankten sich beim Autor FredSonnenrein für den Beitrag:
- BjoernS
Grüße,
Fred Sonnenrein, Braunschweig
i-Telex 952741 (Lo133), 8579924 (T100s), 781272 (T100), 792911 (T68d) oder 531072 (T.typ.72)
Bei besetzt oder gestört bitte 531002 versuchen.
Fred Sonnenrein, Braunschweig
i-Telex 952741 (Lo133), 8579924 (T100s), 781272 (T100), 792911 (T68d) oder 531072 (T.typ.72)
Bei besetzt oder gestört bitte 531002 versuchen.
-
Topic author - Rank 5
- Beiträge: 422
- Registriert: Sa 27. Okt 2018, 17:51
- Hauptanschluß: 898906 laeng d
Re: Ethernet-Karte Hänger
So, ich habe vermutlich die Probleme gefunden, ein bufferoverflow in einer Blockread-Methode über SPI. Mit den Änderungen bekomme ich erstmal meine Karte nicht mehr ohne weiteres abgeschossen, mal sehen was die Truppe von außen erreichen kann. Auch die Serielle funktioniert wieder besser.
Ich hänge hier mal die patches an:
Zusätzlich halte ich die folgenden Änderungen für sehr sinnvoll, da sie prinzipiell die Stabilität verbessern sollten:
1. Verwerfen aller fragmentierter Frames, sie werden ohnehin nicht korrekt assembliert:
2. Korrektur von ICMP-EchoReplies, diese haben eine um 4 Byte zu große Länge (Checksum)
Ich hänge hier mal die patches an:
Code: Alles auswählen
diff --git a/hardware/spi/spi_1.c b/hardware/spi/spi_1.c
index 71104f8..ec6419b 100644
--- a/hardware/spi/spi_1.c
+++ b/hardware/spi/spi_1.c
@@ -130,7 +130,7 @@ void SPI1_FastRead2Mem( char * buffer, int Datalenght )
int Counter = 0;
char data;
- while( Counter <= Datalenght )
+ while( Counter < Datalenght )
{
// warten auf fertig
while ( !( UCSR0A & (1<<UDRE0)) );
@@ -153,7 +153,7 @@ void SPI1_FastRead2Mem( char * buffer, int Datalenght )
int Counter = 0;
char data;
- while( Counter <= Datalenght )
+ while( Counter < Datalenght )
{
// warten auf fertig
while ( !( UCSR1A & (1<<UDRE1)) );
1. Verwerfen aller fragmentierter Frames, sie werden ohnehin nicht korrekt assembliert:
Code: Alles auswählen
diff --git a/system/net/ip.c b/system/net/ip.c
index 79cc4c5..0a94d94 100644
--- a/system/net/ip.c
+++ b/system/net/ip.c
@@ -78,8 +78,8 @@ void ip( int packet_lenght , char *buffer )
// checke mal ob dat überhaupt für uns ist
// if ( IP_packet->IP_DestinationIP != myIP || IP_packet->IP_DestinationIP != 0xffffffff ) return;
-// if ( ( IP_packet->IP_Flags_Fragmentoffset & htons( FRAGMENTOFFSET_bm ) ) == 0 )
-// {
+ if ( ( IP_packet->IP_Flags_Fragmentoffset & htons( FRAGMENTOFFSET_bm ) ) == 0 )
+ {
switch ( IP_packet->IP_Protocol )
{
case 0x01: if ( IP_packet->IP_DestinationIP != myIP ) return;
@@ -96,7 +96,7 @@ void ip( int packet_lenght , char *buffer )
#endif
default: break;
}
-// }
+ }
}
/* -----------------------------------------------------------------------------------------------------------*/
Code: Alles auswählen
diff --git a/system/net/icmp.c b/system/net/icmp.c
index e56a4b6..2b95930 100644
--- a/system/net/icmp.c
+++ b/system/net/icmp.c
@@ -75,7 +75,7 @@ void icmp( int packet_lenght, char *buffer)
ETH_packet->ETH_sourceMac[i] = mymac[i];
}
// und ab die post
- sendEthernetframe( packet_lenght, buffer); // packet_lenght - 4 weil der Controller die checksumme selber berechnet
+ sendEthernetframe( packet_lenght - 4, buffer); // packet_lenght - 4 weil der Controller die checksumme selber berechnet
break;
case ICMP_EchoReplay: if ( ICMP_packet->ICMP_Identifierer == 0xac1d && ICMP_Replaystate == ICMP_WaitForReplay )
ICMP_Replaystate = ICMP_ReplayOkay;
- Folgende Benutzer bedankten sich beim Autor ProgBernie für den Beitrag (Insgesamt 2):
- BjoernS • FredSonnenrein
Gruß Bernd
--
Fernschreibstelle Labenz
898906 laeng d
--
Fernschreibstelle Labenz
898906 laeng d
-
- Rank 3
- Beiträge: 199
- Registriert: Mi 6. Mai 2020, 21:25
- Wohnort: Darmstadt
- Hauptanschluß: 844767 twtr d
Re: Ethernet-Karte Hänger
Moin,
tolle Detektivarbeit, finde es jeden Tag spannend die Neuigkeiten zu lesen. Eine ausrollbare Abhilfe rückt in greifbare Nähe.
(Ich sehe auch, du hast schon geforkt, habe gleich meinen Stern gesetzt.)
Grüße
Björn
tolle Detektivarbeit, finde es jeden Tag spannend die Neuigkeiten zu lesen. Eine ausrollbare Abhilfe rückt in greifbare Nähe.
(Ich sehe auch, du hast schon geforkt, habe gleich meinen Stern gesetzt.)
Grüße
Björn
844767 twtr d
-
Topic author - Rank 5
- Beiträge: 422
- Registriert: Sa 27. Okt 2018, 17:51
- Hauptanschluß: 898906 laeng d
Re: Ethernet-Karte Hänger
Um dem ganzen einen gewissen Abschluß zu geben:
Seit der Korrektur (siehe auch im Entwickler-Thread) arbeitet die Eth-Karte bei mir wieder absolut zuverlässig und stabil. Aktueller Stand:
Seit der Korrektur (siehe auch im Entwickler-Thread) arbeitet die Eth-Karte bei mir wieder absolut zuverlässig und stabil. Aktueller Stand:
Code: Alles auswählen
SystemStartZeit = 16.07.2020 16:15:45, ResetFlag = 05
- Folgende Benutzer bedankten sich beim Autor ProgBernie für den Beitrag (Insgesamt 2):
- BjoernS • ulbrichf
Gruß Bernd
--
Fernschreibstelle Labenz
898906 laeng d
--
Fernschreibstelle Labenz
898906 laeng d