L-322agn Komplettausfall nach Ausfall einer Ethernet-Schnittstelle

Forum zu den aktuellen LANCOM Wireless Accesspoint Serien

Moderator: Lancom-Systems Moderatoren

Antworten
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

L-322agn Komplettausfall nach Ausfall einer Ethernet-Schnittstelle

Beitrag von Jirka »

Hallo,

ich kann mich daran erinnern, dass der L-322agn seinerzeit damit beworben wurde, dass er zwei Ethernet-Schnittstellen hat, die auch beide PoE haben und so ein zuverlässiger Betrieb sichergestellt werden kann, auch wenn ein Ethernet ausfällt. Ich musste allerdings mehrfach feststellen, dass das nur funktioniert, wenn es einen Ausfall vor dem LANCOM gibt. Fällt im LANCOM selber eine Ethernetschnittstelle aus, funktioniert das Ganze nicht mehr. Das Gerät landet in einer Dauerbootschleife und man kann über seriell sehr schön sehen, dass es ein Problem mit der Ethernet-Schnittstelle (MPC85xxEth) gibt, die ein sachunkundiger Mitarbeiter zuvor mit einem 15 Jahre alten, nicht nach PoE-Standard realisiertem Spezial-PoE beim wilden Umherstecken zerschossen hat. Wieso bootet ein LANCOM nicht hoch, wenn er eine Schnittstelle nicht mehr erkennt und verweigert so den kompletten Dienst? Das Problem tritt auch an Blitzschäden oder dergleichen mitunter auf, geht z. B. an einem 1781 die Ethernet-Schnittstelle nicht mehr, so kann man so nicht mal mehr die Konfig sichern. In meinen Augen würde ein perfektes Gerät auch mit defekten Schnittstellen hochfahren und dann würde z. B. die Ethernet-LED rot leuchten und ein Syslog-Eintrag/Status-Eintrag/Tab-Gerätestatus-Eintrag erzeugt werden und alles ist gut oder eben so gut wie möglich. Dass ein Gerät, was mehrere Schnittstellen hat (Ethernet/seriell/WLAN/ISDN) bei Ausfall einer Schnittstelle gleich ganz seinen Dienst quittiert, das leuchtet mir nicht so ganz ein.

Vielen Dank und viele Grüße,
Jirka
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6205
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Re: L-322agn Komplettausfall nach Ausfall einer Ethernet-Schnittstelle

Beitrag von alf29 »

Moin,
ich kann mich daran erinnern, dass der L-322agn seinerzeit damit beworben wurde, dass er zwei Ethernet-Schnittstellen hat, die auch beide PoE haben und so ein zuverlässiger Betrieb sichergestellt werden kann, auch wenn ein Ethernet ausfällt.
"Ausfallen" im Sinne von "kein Link mehr" oder über einen der beiden Ports wird kein (normkonformes) PoE gespeist...daß ein Gerät noch weiterlaufen soll, wenn seine Kern-Hardware selber erkannt hat, daß sie nicht mehr richtig läuft, das würde ich für einen Wunsch halten, dem mindestens ebensoviele Kunden widersprechen werden. In dem Sinne, daß teildefekte Hardware nicht so einfach weiterlaufen soll und dann Probleme unerkannt bleiben bzw. schwerer zu finden sind. Rote LEDs haben viele moderne LANCOMs gar nicht mehr, und die Geräte im quadratischen Gehäuse haben gar keine Ethernet-LEDs mehr. Wenn wir uns jetzt noch irgendein Blinkmuster für die beiden verbliebenen LEDs ausdenken, dann garantiere ich Dir, daß das 9 von 10 Kunden nicht verstehen.
Das Gerät landet in einer Dauerbootschleife und man kann über seriell sehr schön sehen, dass es ein Problem mit der Ethernet-Schnittstelle (MPC85xxEth) gibt, die ein sachunkundiger Mitarbeiter zuvor mit einem 15 Jahre alten, nicht nach PoE-Standard realisiertem Spezial-PoE beim wilden Umherstecken zerschossen hat.
Naja, wer mit solchen Basteleien arbeitet...der sollte schon wissen, was er tut...
Wieso bootet ein LANCOM nicht hoch, wenn er eine Schnittstelle nicht mehr erkennt und verweigert so den kompletten Dienst? Das Problem tritt auch an Blitzschäden oder dergleichen mitunter auf, geht z. B. an einem 1781 die Ethernet-Schnittstelle nicht mehr, so kann man so nicht mal mehr die Konfig sichern.
Unter anderem weil es je nach betroffener Hardware sehr schwierig und aufwendig sein kann, die Firmware so zu bauen, daß sie zur Laufzeit dann wirklich nirgendwo mehr auf diese defekte oder nicht mehr vorhandene Hardware zugreift. Beim WLAN ist das noch vergleichsweise einfach, weil der WLAN-Stack - historisch bedingt, Stichwort PCMCIA und Hotplug - so gebaut ist, daß er mit nicht vorhandener Hardware klarkommen kann. Beim Ethernet sieht das anders aus, das ist fest eingebaut und da geht der ganze Code einfach davon aus, daß die Hardware da ist - den Extraaufwand, um halb kaputte Geräte irgendwie am Laufen zu halten, wird niemand treiben wollen. Ganz im Gegenteil will man z.B. in der Produktion ein Gerät, das eben nicht hochläuft, wenn auch nur eine Schnittstelle nicht tut - sonst rutschen solche Fälle zu leicht durch.

Ich weiß jetzt nicht, was Dein Kollege gemacht hat, und was da für eine Meldung kommt, aber wenn er den Port so weit gegrillt hat, daß der Ethernet-PHY nicht mehr gefunden wird (ich vermute mal, so eine Meldung wird das sein), dann hat man eine gute Chance, daß es bis in das Ethernet-Interface des Prozessors selber durchgeschlagen ist und der auch etwas mitbekommen hat. Dann wäre noch die Frage, ob der dauerhaft laufen würde, würde man den fehlenden PHY ignorieren.

Und wegen Konfig sichern: das klingt jetzt gemein, aber es ist nun einmal so: kein Backup, kein Mitleid...

Viele Grüße

Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: L-322agn Komplettausfall nach Ausfall einer Ethernet-Schnittstelle

Beitrag von Jirka »

Hallo Alfred,
alf29 hat geschrieben: 25 Mär 2019, 20:16daß ein Gerät noch weiterlaufen soll, wenn seine Kern-Hardware selber erkannt hat, daß sie nicht mehr richtig läuft, das würde ich für einen Wunsch halten, dem mindestens ebensoviele Kunden widersprechen werden.
ich bin da anderer Auffassung, aber da hat halt jeder so seine Erfahrungen oder Meinungen. Ein Gerät eines Qualitätsherstellers sollte meiner Meinung nach hochbooten, und wenigstens das noch zur Verfügung stellen, was noch geht. Im obigen Beispiel war es ein L-322, dem eine Ethernet-Schnittstelle abhanden gekommen war. Ja, was würde mich das stören, mind. 60 % der der L-322 nutzen nur eine Ethernet-Schnittstelle bei mir, das Gerät könnte also noch wunderbar weiter laufen, ja es gibt sogar einige Geräte, die nutzen gleich mal gar keine Ethernetschnittstelle (Relaisstationen).
Und wenn es bei LANCOM Themen mit unterschiedlichen Meinungen gibt, dann macht man das Ganze bei LANCOM üblicherweise konfigurierbar, und wo man der Meinung ist, dass die meisten das Verhalten so am besten finden oder wo man der Meinung ist, so müsse oder sollte sich ein Gerät verhalten, da macht man dann halt den Defaultwert draus. Fertig. (Aber das soll jetzt keineswegs eine Arbeitsaufforderung für Dich sein, nicht annähernd ist das bitte so zu verstehen. Es ist jetzt so wie es ist, ich bin halt anderer Meinung, aber ich habe es aufgegeben hier Feature-Wünsche zu äußern. Das ist also nur eine Diskussion zwischen uns, wie man sie bei einem kühlen Bier in gemütlicher Atmosphäre führen würde an einem schönen Sonntagabend (na ja, das Wetter könnte zugegebenermaßen etwas besser sein, aber die Sonne scheint).)
alf29 hat geschrieben: 25 Mär 2019, 20:16In dem Sinne, daß teildefekte Hardware nicht so einfach weiterlaufen soll und dann Probleme unerkannt bleiben bzw. schwerer zu finden sind.
Das ist doch nur, weil das LCOS das alles nicht bietet. Was ich alles schon erleben durfte, das zeigt, dass es hier Schwächen gibt.
Beispiele:
1) WLAN-Modul hängt: Passiert zugegebenermaßen selten, aber es kommt halt vor, vermutlich gibt es eine große Dunkelziffer von nicht entdeckten Fällen. Gerät funktioniert weiter und tut so, als sei alles ok. Ja selbst der WLC merkt nichts. Aber ich (bzw. das von mir eingerichtete PRTG)...
2) Jemand aus dem Forum schrieb mir hier auf dieses Posting, dass dem eben nicht so sei, wie Du geschrieben hast. Er habe einen 1811 gehabt, bei dem die WAN-(Ethernet-)Schnittstelle nicht mehr ging und das Gerät bootete trotzdem noch hoch.
3) ISDN-Schnittstelle defekt. Den Fall habe ich heute gerade auf dem Tisch. Die ISDN-Schnittstelle hat es komplett entschärft, trotzdem bootet das Gerät noch hoch (also ich finde es ja gut, aber Deiner Meinung nach sollte das ja nicht sein). Was ich auch nicht gut finde, wieso löscht das Gerät bei einem derartigen Defekt das ganze restliche Bootlog?! Sonst wird immer hinten rangehangen und was vom Anfang nicht mehr passt, fällt halt weg, aber bei derartigen Defekten ist es so schwierig nachzuvollziehen, was vorgefallen ist. Und Bootlog abspeichern war eingestellt.
Das Bootlog sieht so aus:

Code: Alles auswählen

> show boot
Boot log (1006 Bytes):


XHFC: Invalid Chip-ID:0x00
XHFC: not busy after soft reset
XHFC: missing PCM-INIT flag after soft reset
XHFC: DPLL Error
XHFC: not busy after selecting a FIFO
XHFC: invalid FIFO counters after soft reset F1:0 F2:0 Z1:0 Z2:0
HFC-S F0IO pulse count error (Cnt1:0 Cnt2:0 i:201 IoBase:e4000000
XHFC: F0IO pulse count error (Cnt1:0 Cnt:0 Cnt2:0 i:16002 IoBase:e4000000
XHFC: PCM-Tx Error: F_USAGE: 0?=9  EndOfFrame: 0?=1
XHFC: PCM-Rx Error: rx_len: 0?=11  EndOfFrame: 0?=1  (F1:0 F2:0 Z1:0 Z2:0)
XHFC:   1/ 12: rx_error: 00 != ff
XHFC: 3 PCM errors detected, Tx:e4000000  Rx:e4000000 over STIO1
XHFC: PCM-Tx Error: F_USAGE: 0?=9  EndOfFrame: 0?=1
XHFC: PCM-Rx Error: rx_len: 0?=11  EndOfFrame: 0?=1  (F1:0 F2:0 Z1:0 Z2:0)
XHFC:   1/ 12: rx_error: 00 != ff
XHFC: 3 PCM errors detected, Tx:e4000000  Rx:e4000000 over STIO2
****

07/07/2019 15:47:28  System boot after power on

DEVICE:                LANCOM 1781A
HW-RELEASE:            0
VERSION:               10.12.0671 / 06.06.2019
Und der Chip so:
20190707_163112.jpg
Da fehlt vom Kölner Dom echt eine ganze Ecke... Hitzeschaden?! Dafür spricht eine leicht bräunliche Patina des Kölner Doms...
Aktiv war die ISDN-Schnittstelle übrigens (Verbindung zur Telefonanlage), jedenfalls vor Eintritt des Schadens.
alf29 hat geschrieben: 25 Mär 2019, 20:16Rote LEDs haben viele moderne LANCOMs gar nicht mehr, und die Geräte im quadratischen Gehäuse haben gar keine Ethernet-LEDs mehr. Wenn wir uns jetzt noch irgendein Blinkmuster für die beiden verbliebenen LEDs ausdenken, dann garantiere ich Dir, daß das 9 von 10 Kunden nicht verstehen.
Sicher, weil ja auch nicht alles dokumentiert werden würde. Ist ja jetzt auch schon so, was bedeutet es, wenn nur die Deckel-LEDs orange leuchten? Was, wenn ziemlich viele, aber nicht alle LEDs in etwas weniger als einer Sekunde regelmäßig orange aufblinken? Klar, das sind alles Hardwaredefekte, aber was das bedeutet, weiß auch ich in allen Fällen nicht genau.
alf29 hat geschrieben: 25 Mär 2019, 20:16Unter anderem weil es je nach betroffener Hardware sehr schwierig und aufwendig sein kann, die Firmware so zu bauen, daß sie zur Laufzeit dann wirklich nirgendwo mehr auf diese defekte oder nicht mehr vorhandene Hardware zugreift.
Ok, das ist ein Argument. Das stellt man sich vermutlich leichter vor. Gerade wenn zwei Ethernet-Chips auf dem Gerät sind, und man ja Ethernet-Schnittstellen auch deaktivieren kann und man dann ja auch davon ausgeht, dass die wirklich deaktiv sind.

Bei dem defekten ISDN-LANCOM hier verschwindet sogar der Menübaum Status/ISDN. Das finde ich schon krass.
alf29 hat geschrieben: 25 Mär 2019, 20:16den Extraaufwand, um halb kaputte Geräte irgendwie am Laufen zu halten, wird niemand treiben wollen.
Bei einem Billiggerät erwarte ich das so. Da geht irgendwas kaputt und es ist Schrott. Teure Geräte sind reparaturfreundlich und funktionieren auch noch, soweit es eben möglich ist. Ein 1906VA-4G mit 2 x VDSL, 1 x Glasfaser, 1 X LTE wird so zum Single Point of Failure.
alf29 hat geschrieben: 25 Mär 2019, 20:16Ganz im Gegenteil will man z.B. in der Produktion ein Gerät, das eben nicht hochläuft, wenn auch nur eine Schnittstelle nicht tut - sonst rutschen solche Fälle zu leicht durch.
Na ja, perfekt funktionieren tut das aber nicht...
alf29 hat geschrieben: 25 Mär 2019, 20:16Und wegen Konfig sichern: das klingt jetzt gemein, aber es ist nun einmal so: kein Backup, kein Mitleid...
Sicher, da gebe ich Dir Recht. Aber das betrifft ja Kunden/Geräte, die man bisher nicht hatte. Die haben halt eine Havarie und fragen, ob man weiter helfen kann. Kann man aber nicht, weil LANCOM so ein Gerät nicht so weit hochbooten lässt, dass man wenigstens über seriell noch raufkommt und sichern kann.
Ein zweites Argument wäre LANconfig. Dieses Programm hat leider eine kleine Designschwäche. Es sichert grundsätzlich nur die Konfigs aus dem Gerät, aber nicht das, was ich als letztes ins Gerät geschrieben habe. Wenn man das begriffen hat, macht man schon mal hier und da eine Sicherung, wenn man eine halbe Stunde an der Konfig rumgefummelt hat. Alles darunter zu sichern lohnt der Aufwand wiederum nicht, weil so ein Gerätedefekt/-diebstahl ja schon sehr selten vorkommt und LANconfig keine 1-Klick-Sicherung kann (ich markiere dann immer noch ein anderes Gerät mit, dann funktioniert die 1-Klick-Sicherung mit automatischer Auswahl des richtigen Ordners). Dabei wäre auch das alles kein Thema mehr, die Geräte haben einen Config-Status, den man nur mit LANconfig auswerten bräuchte, um nicht doppelt zu sichern (d. h. wenn die ausgelesene Konfig der zuletzt ins Gerät gespeicherten entspricht).

So Bier ist alle, Abendbrot gab es zwischenzeitlich auch schon und die Sonne geht jetzt auch gerade unter. Das heißt ich habe jetzt genug geschrieben. Nicht alles gleich als Kritik auffassen, ist nur eine Meinungsäußerung.

Viele Grüße,
Jirka
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Benutzeravatar
alf29
Moderator
Moderator
Beiträge: 6205
Registriert: 07 Nov 2004, 19:33
Wohnort: Aachen
Kontaktdaten:

Re: L-322agn Komplettausfall nach Ausfall einer Ethernet-Schnittstelle

Beitrag von alf29 »

Moin,
1) WLAN-Modul hängt: Passiert zugegebenermaßen selten, aber es kommt halt vor, vermutlich gibt es eine große Dunkelziffer von nicht entdeckten Fällen. Gerät funktioniert weiter und tut so, als sei alles ok. Ja selbst der WLC merkt nichts. Aber ich (bzw. das von mir eingerichtete PRTG)...
Das ist in 99% der Fälle kein Hardwareproblem, sondern ein softwaremäßiger Workaround, um eine irgendwie "abgestürzte" Hardware wieder zum Funktionieren zu bringen. Nicht schön, aber manchmal hat man im Treiber keine andere Wahl, als diesen Holzhammer auszupacken, weil der Hersteller der Hardware einem keine bessere Methode nennen kann oder will, den Chip wieder auf die Beine zu stellen. So ein Modul-Reset dauert üblicherweise unter einer Sekunde, die allermeisten Benutzer haben diese Resets gar nicht bemerkt, bis irgendein Schlauberger meinte, die müßten geloggt werden - ohne eine Antwort darauf zu haben, was man dem Kunden denn nun sagt, wenn er diese Meldungen im Log hat und sie abstellen möchte...
2) Jemand aus dem Forum schrieb mir hier auf dieses Posting, dass dem eben nicht so sei, wie Du geschrieben hast. Er habe einen 1811 gehabt, bei dem die WAN-(Ethernet-)Schnittstelle nicht mehr ging und das Gerät bootete trotzdem noch hoch.
Die Fälle müssen nicht vergleichbar sein. Bei Dir hat's den Ethernet-PHY komplett zerbrezelt, und zwar so, daß die Software ihn nicht mehr "sieht" - es ist so, als hättest Du den Baustein von der Platine abgelötet. Bei dem 1811 mag es so sein, daß nur das Line-Interface eines einzelnen PHYs in dem Switch-Baustein abgeraucht ist, und die Software die Register dieses PHYs nach wie vor "sieht". Dann ist der Defekt aus Sicht der Software nicht festzustellen, es kommt einfach nie ein Link zustande.
3) ISDN-Schnittstelle defekt. Den Fall habe ich heute gerade auf dem Tisch. Die ISDN-Schnittstelle hat es komplett entschärft, trotzdem bootet das Gerät noch hoch (also ich finde es ja gut, aber Deiner Meinung nach sollte das ja nicht sein).
Ja, finde ich nicht in Ordnung. Aber da haben auch einzelne Entwickler zum Teil unterschiedliche Meinungen.
Was ich auch nicht gut finde, wieso löscht das Gerät bei einem derartigen Defekt das ganze restliche Bootlog?! Sonst wird immer hinten rangehangen und was vom Anfang nicht mehr passt, fällt halt weg, aber bei derartigen Defekten ist es so schwierig nachzuvollziehen, was vorgefallen ist. Und Bootlog abspeichern war eingestellt.
Wenn es Teile aus dem Chip-Gehäuse herausgesprengt hat, dann ist der Chip Opfer eines massiven Überspannungsschadens geworden. Wie das bei einem ISDN passiert, das an einem internen Port einer TK-Anlage hängt, weiß ich nicht, üblicherweise hat man das nach Gewittern bei ISDN/xDSL-Schnittstellen, die an der "von draußen" kommenden Leitung hängen. Was in dem Moment passiert, wenn so eine Menge an Energie in das Gerät hineinfährt (ein Teil davon wird auch durch den ISDN-Chip durchgegangen sein), das ist mehr oder weniger undefiniert. Wenn das Gerät dabei nur einen Kaltstart hinlegt und nicht mehr dazu kommt, sein Bootlog persistent im Flash zu spreichern, dann hast Du Glück gehabt. Schrott ist das Gerät so oder so. Bei Überspannungsschäden weiß man nie, welche Bauteile noch geschädigt wurden und früher oder später auch noch ausfallen werden. Wenn solche Geräte bei uns im Service ankommen, dann werden sie nicht repariert und der Kunde bekommt stattdessen eine Bescheinigung, daß das ein Überspannungsschaden war. Die kann er dann bei der (hoffentlich vorhandenen) Versicherung einreichen.
Sicher, weil ja auch nicht alles dokumentiert werden würde. Ist ja jetzt auch schon so, was bedeutet es, wenn nur die Deckel-LEDs orange leuchten?
Also zumindest eine dauerhaft orange leuchtende Power-LED kann eine unzureichende Stromversorgung per PoE bedeuten, z.B. das Gerät braucht 802.3at für vollen Betrieb und bekommt nur 802.3af. Der Code ist irgendwann nachträglich eingabut worden, wahrscheinlich steht's in irgendwelchen Release-Notes oder einem Addendum zum Addendum des Addendums zum Referenz-Handbuch. Geschlossende und konsistente Dokumentation ist in der Tat ein Thema, das auch mich stören würde, aber irgendwie schluckt's die Mehrzahl der Kunden...

Könnte auch ein vom Bootlader erkannter Hardware-Defekt sein, den sähe man auf der Outband.
Was, wenn ziemlich viele, aber nicht alle LEDs in etwas weniger als einer Sekunde regelmäßig orange aufblinken? Klar, das sind alles Hardwaredefekte, aber was das bedeutet, weiß auch ich in allen Fällen nicht genau.
Ich würde jetzt mal auf ein (Stecker-)Netzteil tippen, in dem Elkos das Ende ihrer Lebensdauer erreicht haben, und das immer wieder anläuft und dann zusammenbricht. Dokumentieren können wir nur die LED-Codes, die von der Software erzeugt werden. Was bei Hardware-Defekten passiert, wo weder LCOS noch Bootlader anlaufen, ist mehr oder weniger undefiniert. Da erwartest Du zuviel, das kann man nicht definieren/dokumentieren.
Ok, das ist ein Argument. Das stellt man sich vermutlich leichter vor. Gerade wenn zwei Ethernet-Chips auf dem Gerät sind, und man ja Ethernet-Schnittstellen auch deaktivieren kann und man dann ja auch davon ausgeht, dass die wirklich deaktiv sind.
Eine in Software abgeschaltete Schnittstelle ist ja immer noch "da". Und am Rande bemerkt: wenn ETH-1 kaputt ist und nicht gefunden wird, könnte es passieren, daß beim Enumerieren der Schnittstellen aus ETH-2 auf einmal ETH-1 wird. Gar nicht lustig, wenn auf einmal auf ETH-2 Traffic auftaucht, der eigentlich für ETH-1 vorgesehen ist.
Bei dem defekten ISDN-LANCOM hier verschwindet sogar der Menübaum Status/ISDN. Das finde ich schon krass.
Indeed. Aber wie schon oben gesagt, da variieren die Ansichten unter den Entwicklern.
Bei einem Billiggerät erwarte ich das so. Da geht irgendwas kaputt und es ist Schrott. Teure Geräte sind reparaturfreundlich und funktionieren auch noch, soweit es eben möglich ist.
Es steht Dir ja frei, das L-322 zur Reparatur einzuschicken. Wenn Dir das zu teuer ist, kannst Du ja versuchen, den Chip selber zu tauschen, aber Du solltest jemanden finden, der wirklich gut im Löten/Entlöten von SMD-Bauteilen ist. Vielleicht hast Du aber auch Pech und nach Tausch des Ethernet-PHYs geht es immer noch nicht, weil noch etwas in Richtung Prozessor "durchgeschlagen" ist. Der steckt im BGA-Gehäuse und das ist dann endgültig ein Totalschaden - unabhängig davon, ob der Rest des Gerätes noch zu funktionieren scheint (s.o.).
Ein 1906VA-4G mit 2 x VDSL, 1 x Glasfaser, 1 X LTE wird so zum Single Point of Failure.
Ein Gerät, an dem eine Schnittstelle durch Überspannung gestorben ist, ist Schrott - siehe oben. Jemand, der so ein Gerät an zentraler und wichtiger Stelle weiter betreibt, handelt m.E. unprofessionell.

Viele Grüße

Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

Re: L-322agn Komplettausfall nach Ausfall einer Ethernet-Schnittstelle

Beitrag von GrandDixence »

Interessant wäre zu erfahren, ob die Leiterplatine, im Bereich wo die ISDN-Leitung auf die Leiterplatine tritt, einen Überspannungsschutz mit Varistor (wahrscheinliches Platinen-Kennzeichen: V) oder einen Überspannungsschutz mit Suppressordiode (wahrscheinliches Platinen-Kennzeichen: D oder S) aufweist.

Ein eingangsseitiger Überspannungsschutz sollte bei einem guten Elektronikprodukt vorhanden sein.

https://de.wikipedia.org/wiki/Varistor

https://de.wikipedia.org/wiki/Suppressordiode

Und sehr gute Elektronikprodukte haben sogar eine eingangs- und ausgangsseitige galvanische Trennung in Form eines Optokopplers für Signalleitungen.

https://de.wikipedia.org/wiki/Optokoppler

Im Fall des "Kölner Doms" hat dieser Überspannungsschutz versagt und somit sollte diese Leiterplatine im Elektroschrott entsorgt werden.
Antworten