SNOM Telefone: bei 40 Geräten gleichzeitig Netzwerkfehler

Guard-X

Aktives Mitglied
Mitglied seit
14 Mai 2005
Beiträge
2,497
Punkte für Reaktionen
0
Punkte
36
Hi,

hatte gerade einen ganz merkwürdigen Fehler. Bei 40 Telefonen, egal ob 190 oder 360, hat sich gleichzeitig der interne Hub "aufgehängt", d.h. Telefon und angeschlossenes PC's waren nicht mehr im Netz erreichbar. Das Telefon selbst funktionierte noch einwandfrei (Adreßbuch, verpasste Anrufe usw.), man konnte halt nur nicht telefonieren bzw. erreicht werden.
Auch alle anderen Telefone funktionierten weiterhin ganz normal.

Hat jemand schon mal sowas erlebt, was könnte die Ursache sein?

mfg Guard-X
 
Das hoert sich fuer mich so an, als haette da irgendwas den Netzwerk-Stack der Telefone zum Absturz gebracht. Das scheint aber auch eher unwahrscheinlich, da auf dem Telefon Linux laeuft und mir ist ein solcher Fehler im Netzwerk-Stack von Linux nicht bekannt. Koennte vielleicht sein, dass es am Treiber fuer die Netzwerkkarte liegt.

Evtl. kennt ja der snom-Support das Problem schon und kann helfen. Waere gut wenn du uns aber auf dem Laufenden halten koenntest.

@snomy: falls du das hier liest, kannst du ja vielleicht auch kurz was dazu sagen. Das ganze beunruhigt mich ein wenig, weil ich hier auch eine Installation mit ca. 50 Telefonen betreue. Wenn die alle auf einmal ausfallen... :(
 
Hi Maik,

merkwürdig ist nur, das die anderen 110 Telefone keine Probleme hatten. Alle Telefone sind auf mehreren Switchen verteilt gewesen.

Aber eins könnte ich mir noch vorstellen (Auszug aus Logfile)
Code:
[5]5/9/2005	19:32:04	SNMP:	Received	packet	from	non-trusted	source
[5]5/9/2005	19:32:32	SNMP:	Received	packet	from	non-trusted	source
[5]5/9/2005	19:32:34	SNMP:	Received	packet	from	non-trusted	source
[5]5/9/2005	19:33:03	SNMP:	Received	packet	from	non-trusted	source
[5]5/9/2005	19:33:04	SNMP:	Received	packet	from	non-trusted	source
[5]5/9/2005	19:33:33	SNMP:	Received	packet	from	non-trusted	source
[5]5/9/2005	19:33:34	SNMP:	Received	packet	from	non-trusted	source
[5]5/9/2005	19:34:03	SNMP:	Received	packet	from	non-trusted	source
[5]5/9/2005	19:34:05	SNMP:	Received	packet	from	non-trusted	source

Nach Source stehen noch diverse Server-IPs. Sieht nach einem Broadcast aus, der an alle Telefone gesendet wird. Vielleicht ein memory leak, so wie bei einigen alten Fw-Versionen?

Hoffentlich ist das kein generelles Problem mit der Anzahl, habe nämlich letzte Woche noch 60 Stück bestellt ... ;-)

mfg Guard-X
 
Sind die anderen 110 Telefon auch von snom? Haben die evtl. ne andere Firmware oder nen anderen kernel?
 
Hi Maik,

Sind die anderen 110 Telefon auch von snom? Haben die evtl. ne andere Firmware oder nen anderen kernel?

Ja! Es waren hautpsächlich Telefone mit den Apps. 4.1, Kernel 3.20 und Ram 3.31. Ein paar wenige noch mit 3.60k und alter Ramdisk und sogar 1 SNOM 190 war dabei.

Ich möchte mich halt nicht damit ab tun nach dem Motto: "Kann wohl mal passieren". Sowas darf in einem Produktivsystem natürlich nicht mehrmals vorkommen. Ich kann halt nicht quer durch Deutschland fahren und alle Telefone resetten. Ach ja, waren auch alle an verschiedenen Standorten, die intern über Festverbindungen vernetzt sind. Ich hatte kurz vorher ein Stottern in der Leitung als es passiert ist, jedoch war mein Telefon nicht direkt betroffen.

PS.: Endlich kann man alle Lizenzen auf einmal bekommen :)
IF YOU NEED MORE THAN 10 licenses please send you list of MAC adresses (preferable .csv) to [email protected]

mfg Guard-X
 
Guard-X schrieb:
Ja! Es waren hautpsächlich Telefone mit den Apps. 4.1, Kernel 3.20 und Ram 3.31. Ein paar wenige noch mit 3.60k und alter Ramdisk und sogar 1 SNOM 190 war dabei.

Scheint dann also wirklich ein Problem mit dem Kernel zu sein. :(

Ich möchte mich halt nicht damit ab tun nach dem Motto: "Kann wohl mal passieren". Sowas darf in einem Produktivsystem natürlich nicht mehrmals vorkommen. Ich kann halt nicht quer durch Deutschland fahren und alle Telefone resetten.

Da kann ich dir nur zustimmen. Deshalb wäre es auch nett, wenn du dem snom-Support auch gleich mal nen Link zu diesem Thread geben könntest.

Ach ja, waren auch alle an verschiedenen Standorten, die intern über Festverbindungen vernetzt sind. Ich hatte kurz vorher ein Stottern in der Leitung als es passiert ist, jedoch war mein Telefon nicht direkt betroffen.

Sind die Telefone eigentlich alle im gleichen Subnetz oder in verschiedenen? Das mit dem Stottern deutet ja schon irgendwie drauf hin, dass alle Telefone davon betroffen waren aber das zumindest einige 'überlebt' haben. Ich vermute immer noch, dass es ein Broadcast-Paket war, mit dem die Telefone ein Problem hatten.

PS.: Endlich kann man alle Lizenzen auf einmal bekommen :)

Ging das nicht schon beim Beta-Test? Ich frage mich allerdings warum man ein csv-File verwenden soll, wenn es eh nur 1 Spalte gibt?! :)
 
Hi Maik,

ist gerade beim SNOM-Support in Arbeit. Wenn ich dafür eine Lösung bekommen habe, melde ich mich hier noch mal zu dem Thema.

mfg Guard-X
 
hallo, ich gebe zu ich bin von snom...

das hört sich sehr seltsam an. wenn das telefon noch tastendrücke etc annimmt beudetet es dass die applikation selbst nicht betroffen ist.

wir haben auch schon in der zwischenzeit den hersteller der chips angefragt ob ihm bekannt ist dass es probleme mit dem eingebauten switch gibt (der nicht vom linux betrieben wird). sie meinen dass sie so ein problem bisher noch nicht hatten (wir ja auch noch nicht.-). Aber möglicherweise ist da irgendein seltsames paket durch das kabel gegangen welches den switch zu absturz bringt (multicase, broadcast). Vielleicht hat ja jemand mal lust, ein broadcast/multicast mit mehr als 1600 bytes zu verschicken).

Für uns wäre es wichtig das problem reproduzieren zu können. Wenn das möglich ist sind wir dem problem ganz nahe.
 
voipanfaenger schrieb:
hallo, ich gebe zu ich bin von snom...

Es sei dir verziehen. ;)

Nee mal im Ernst. Wir sind froh über jeden, der uns hier ein wenig weiterhelfen kann.

das hört sich sehr seltsam an. wenn das telefon noch tastendrücke etc annimmt beudetet es dass die applikation selbst nicht betroffen ist.

wir haben auch schon in der zwischenzeit den hersteller der chips angefragt ob ihm bekannt ist dass es probleme mit dem eingebauten switch gibt (der nicht vom linux betrieben wird).

Interessant. Ich bin bisher davon ausgegangen, dass einfach die beiden Netzwerkinterfaces der INCA nach aussen gefuehrt wurden und im bridging Modus betrieben werden. Aber ich nehme mal an, dass man so wenig CPU-Last hat und weniger Speicher braucht.

sie meinen dass sie so ein problem bisher noch nicht hatten (wir ja auch noch nicht.-). Aber möglicherweise ist da irgendein seltsames paket durch das kabel gegangen welches den switch zu absturz bringt (multicase, broadcast). Vielleicht hat ja jemand mal lust, ein broadcast/multicast mit mehr als 1600 bytes zu verschicken).

Wäre wohl die einzig sinnvolle Erklärung. Ich werd mal sehen, ob ich bei uns mal ein kleines Test-Setup machen kann. Ich hoffe mal, dass ich dazu in den nächsten Tagen ein wenig Zeit haben werde.

@Guard-X: Kannst du evtl. mal noch nen Rechner bei dir ans Netz hängen, der nicht aktiv ist und einfach nur alle Multicast- und Broadcast-Pakete mitloggt? Dann hätten wir zumindest mal nen Dump, wenn es wieder passiert und damit könnte man das ganze dann mal rekonstruieren.
 
Hallo.

Wir konnten den Fehler leider nicht reproduzieren und er ist auch nicht wieder vorgekommen. Ich denke mal, das war eine einmalige Sache...

mfg Guard-X
 

Statistik des Forums

Themen
244,696
Beiträge
2,216,704
Mitglieder
371,316
Neuestes Mitglied
realbluethunder
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.