DHCP Probleme beim Elmeg IP290

Anti-T

Mitglied
Mitglied seit
2 Okt 2005
Beiträge
294
Punkte für Reaktionen
0
Punkte
0
ahasver schrieb:
Damit ist nun bewiesen, daß alle Snom-SW nach 3.60i eine Prüfung auf MAC-Adressen hat und http://www.ip-phone-forum.de/showthread.php?t=86994 erklärt.

Es ist etwas komplizierter und leider etwas unschöner.

Es gibt nach meinen Erkenntnissen 3 verschiedene Arten von diesen Telefonen:

1. das Snom 190 mit MAC-Adressen 000431...
2. das Elmeg IP290 der ersten Generation mit MAC-Adressen 000431...
3. das Elmeg IP290 der aktuellen Generation mit MAC-Adressen 00094F...

1. und 2. wurden zusammen produziert und haben keinen Unterschied, nur das Gehäuse ist anders bedruckt. http://www.ip-phone-forum.de/showthread.php?t=86994 enhält also nur bedingt wahre Aussagen und die Unterscheidung in zwei Produktklassen unter http://wiki.ip-phone-forum.de/telefone:funkwerk:firmware ist ebenfalls falsch. Richtig ist, dass die Firmware zwischen den unter 1. und 2. genannten Geräten einfachst ausgetauscht werden kann, man also auch die 3.60x auf einem IP290 (2.) installieren kann.

Die 3.61er Firmware läuft aber nur auf Geräten wie unter 3. beschrieben (wegen der MAC-Adresse). Hier scheinen nun tatsächlich Unterschiede zu existieren. Die Unterschiede werden aber nur auf Software-Ebene zu finden sein.

Wer also ein IP290 der ersten Generation (2.) hat kann die Firmare 3.61 nicht verwenden. Ich zähle auch zu den Nutzern der älteren Elmeg-Geräte (nein, kein Snom) mit einer 000431er MAC-Adresse (aus dem Sommer 2005). Wenn ich die 3.61er Elmeg-Firmware auf diesem meinen Elmeg-IP290 installieren will kommt "wrong image" oder so ähnlich. Ich finde es sehr kundenunfreundlich was sich Funkwerk da mit den Bestandkunden erlaubt!

Für mich ist Snom nach wie vor ein Elektronikschrott-Produzent der nur deshalb überlebt, weil die Leute zur Zeit jeden Scheiß kaufen auf dem VoIP draufsteht. Elmeg hat die Plunder-Hardware übernommen (da sind bei Snom bestimmt viele Sektkorken geflogen) und bekommt damit auch nicht so recht was auf die Reihe. Das IP-S290 ist mehr als nur kastriert und wann das IP-S400 kommen wird steht noch in den Sternen. Mal schauen was sie da dann alles weggelassen haben.
 
1) Wenn du eh ein Elmeg-Gerät hast, warum regst du dich dann darüber auf, dass SNOM die Firmwareentwicklung für das SNOM 190 eingestellt hat - du bist doch davon gar nicht betroffen, sondern dein Ansprechpartner ist Elmeg / Funkwerk?!

2) Wenn Du ein Elmeg der ersten Serie hast auf dem sich das Firmwareupdate nicht aufspielen lässt, warum wendest du dich nicht an Elmeg und fragst mal nach einem Austausch des Geräts?
 
@Anti-T
Danke für die Info zu den unterschiedlichen HW-Versionen.

Ich würde allerdings nicht Snom vorwerfen, daß sie Elektroschrott produzieren, sondern daß deren Produkt-Supportzyklen seeehr kurz sind. Mit FW 3.60x sind die meisten kritisierten Bugs im Netzwerkbereich (bis auf die Nicht-Unterstützung bestimmter DHCP-Funktionen) weg. Immerhin hatte mir der Snom-Support mir diesen DHCP-Bug über sein Support-Ticket-System fachlich präzise bestätigt. Bei Elmeg gibt es so ein Ticketsystem nicht mal. Deshalb glaub ich auch kaum, daß da irgendjemand ernsthaft die FW weiterpflegt. Für mich stellt sich die Sache so dar, daß die Kooperation Elmeg-Snom an unterschiedlichen geschäftlichen Interessen gescheitert ist und Snom keine Lust mehr hatte, weiterhin kostenlosen Support für Elmeg zu machen... Daß ich dann aber als Original-Snom-190-Käufer auch an Elmeg abgeschoben werde, find ich doch sehr ärgerlich. Einige beim 190 an den Support gemeldete Bugs oder Änderungswünsche sind jetzt in der 3xyer Reihe drin, während beim 190 nix mehr passieren wird (indem man einen Bug in ein nicht vorhandenes Feature umdeklariert...). Und auch beim Snom 200 wurde der Support ja frühzeitig eingestellt.

Für mich ist Snom da weiterhin der Ansprechpartner, das zum DHCP-Bug angelegte Ticket ist immernoch offen, und Snom hat mir noch nichts mitgeteilt, daß sich darum jetzt Elmeg kümmern täte...
 
ahasver schrieb:
@Anti-T
Danke für die Info zu den unterschiedlichen HW-Versionen.

Ich würde allerdings nicht Snom vorwerfen, daß sie Elektroschrott produzieren, sondern daß deren Produkt-Supportzyklen seeehr kurz sind.

Das eine bedeutet für mich das andere. Wer dauernd neue Geräte rausbringt sorgt dafür, dass die "älteren" Gernationen ganz schnell unbrauchbar werden. Stell dir vor du kaufst ein Auto und ein halbes Jahr später bekommst du keine Winterreifen mehr dafür.

ahasver schrieb:
Mit FW 3.60x sind die meisten kritisierten Bugs im Netzwerkbereich (bis auf die Nicht-Unterstützung bestimmter DHCP-Funktionen) weg. Immerhin hatte mir der Snom-Support mir diesen DHCP-Bug über sein Support-Ticket-System fachlich präzise bestätigt. Bei Elmeg gibt es so ein Ticketsystem nicht mal.

Doch, gibt es.

ahasver schrieb:
Deshalb glaub ich auch kaum, daß da irgendjemand ernsthaft die FW weiterpflegt.

Ich bin mir da auch nicht sicher. Ich sehe das so, dass das IP290 nur eine Erfahrungssammelei für die IP-Systemtelefonie (IP-S290, IP-S400) gewesen ist.

ahasver schrieb:
Für mich stellt sich die Sache so dar, daß die Kooperation Elmeg-Snom an unterschiedlichen geschäftlichen Interessen gescheitert ist und Snom keine Lust mehr hatte, weiterhin kostenlosen Support für Elmeg zu machen...

Ich denke eher, dass das Snom 190 seinen Produklebenszyklus erreicht hat und deshalb bei Snom rausgeflogen ist. Deshalb für mich ein Elektronikschrottproduzent. Der Support für Elmeg war sicher genauso kostenlos wie die von Elemg kostenlos produzierten Gehäuse. Verstehen?

ahasver schrieb:
Daß ich dann aber als Original-Snom-190-Käufer auch an Elmeg abgeschoben werde, find ich doch sehr ärgerlich. Einige beim 190 an den Support gemeldete Bugs oder Änderungswünsche sind jetzt in der 3xyer Reihe drin, während beim 190 nix mehr passieren wird (indem man einen Bug in ein nicht vorhandenes Feature umdeklariert...).

Genau deshalb die Bezeichnung Elektronikschrottproduzent.

ahasver schrieb:
Und auch beim Snom 200 wurde der Support ja frühzeitig eingestellt.

Genau deshalb die Bezeichnung Elektronikschrottproduzent.

ahasver schrieb:
Für mich ist Snom da weiterhin der Ansprechpartner, das zum DHCP-Bug angelegte Ticket ist immernoch offen, und Snom hat mir noch nichts mitgeteilt, daß sich darum jetzt Elmeg kümmern täte...

Welche DHCP-Funktionen werden eigentlich nicht unterstützt? Gib mal nen Link wo ich dazu was nachlesen kann.
 
Anti-T schrieb:
Gib mal nen Link wo ich dazu was nachlesen kann.
Darum bitte ich auch für das Ticket-System von Elmeg / Funkwerk, von dem Du ja behauptest, dass es existiert.
 
Tickets bekommt man, indem man die Hotline 00800 7333 7333 anruft. Bei Funkwerk werden die Tickets aber auch oft Calls genannt.
 
Anti-T schrieb:
Ich sehe das so, dass das IP290 nur eine Erfahrungssammelei für die IP-Systemtelefonie (IP-S290, IP-S400) gewesen ist.
Wenn ich die Ergebnisse vergleiche ist das Erfahrungssammeln eher ein KnowHow-Abkupfern.
Der Support für Elmeg war sicher genauso kostenlos wie die von Elemg kostenlos produzierten Gehäuse. Verstehen?
Ach so, das war der innovative Beitrag von Elmeg. Und deshalb sieht der Nachfolger bei Snom (Snom300) deutlich anders aus...
Anti-T schrieb:
Welche DHCP-Funktionen werden eigentlich nicht unterstützt? Gib mal nen Link wo ich dazu was nachlesen kann.
Siehe dazu mein Posting #6 in http://www.ip-phone-forum.de/showthread.php?t=81712
Daraufhin hatte ich einen Trace gemacht und die Prüfung durch den Snom-Support ergab die fehlende Unterstützung für "DHCP Option ?? und ??" [*] als Ursache, die jetzt vermutlich immernoch auf der nicht mehr beachteten "ToDo"-Liste steht... (vermute mal, daß das bei neuerer Snom-Firmware korrigiert wurde)
Hab mir damit beholfen, daß ich den DHCP-Server im Kabelmodem deaktiviere, so daß der erste erhaltene DHCP-Server der richtige ist... Und das dort geschilderte Problem beim Provider gehört auch der Vergangenheit an.

Achso, auch wenn ich die Beschimpfung als "Elektronikschrottproduzent" nicht sonderlich hilfreich finde, deswegen hier eine Verwarnung in Hauswartmanier zu erteilen, finde ich doch etwas arg übertrieben! (ich hoffe, ich fange mir wegen dem Gebrauch dieses Begriffes nicht auch eine ein...)


[*] Nachdem ich mal nach Deinen sonstigen Postings gesucht habe, wo Du gelegentlich auf (effektiv kostenpflichtige) Beratungsleistungen von Elmeg hinweist, statt die Fragen zu beantworten, hab ich die mir im Snom-Ticket nicht öffentlich genannten Optionen hier unkenntlich gemacht...
---
Edit: 1) Link korrigiert. 2) verwarnten Begriff "gemildert".
 
Zuletzt bearbeitet:
ahasver schrieb:
Wenn ich die Ergebnisse vergleiche ist das Erfahrungssammeln eher ein KnowHow-Abkupfern.

Ansichtssache. Anstatt selber bei 0 beginnend zu entwickeln hat man eingekauft. Auch der SIP-Serv ist ebenso wie das Snom 190 ein zugekauften Produkt und es diente schlicht und ergreifend der Know How Erlangung für SIP.

ahasver schrieb:
Ach so, das war der innovative Beitrag von Elmeg.

Der Elmeg-Beitrag am Snom 190 war das Gehäuse (ursprünglich das steinalte Elmeg CS290/CS290U). Mehr nicht.

ahasver schrieb:

"Dein" Posting No. 6 in dem Thread ist aber vom Gersthofer.

ahasver schrieb:
Daraufhin hatte ich einen Trace gemacht und die Prüfung durch den Snom-Support ergab die fehlende Unterstützung für "DHCP Option ?? und ??"
[*] als Ursache, die jetzt vermutlich immernoch auf der nicht mehr beachteten "ToDo"-Liste steht... (vermute mal, daß das bei neuerer Snom-Firmware korrigiert wurde)
Hab mir damit beholfen, daß ich den DHCP-Server im Kabelmodem deaktiviere, so daß der erste erhaltene DHCP-Server der richtige ist...

Häh? Welcher erste DHCP-Server?

Beim Lesen der weiteren Beiträge in dem Thread, insbesondere 8 (snomy) und 14 (Gersthofer), verstehe ich dein Problem sowieso nicht, wenn es denn schon behoben wurde.

ahasver schrieb:
[*] Nachdem ich mal nach Deinen sonstigen Postings gesucht habe, wo Du gelegentlich auf (effektiv kostenpflichtige) Beratungsleistungen von Elmeg hinweist,

Umsonst ist der Tod. Anstatt aber rumzujammern sollten die Leute einfach mal die o.g. KOSTENLOSE Hotline bei Funkwerk anrufen und das Problem ihres IP 290 schildern. Alternativ, und das ist der bessere Weg, kann man auch eine E-Mail an hotline[ät]funkwerk-ec.com mit einer sinnvollen Beschreibung schicken.

BTW: Mir wäre neu, dass man SNOMs (190er) bei Elmeg/Funkwerk supporten lassen kann.

ahasver schrieb:
statt die Fragen zu beantworten,

Ich arbeite nicht bei Funkwerk, ich bekomme kein Geld für den geleisteten Support, ich weiß nicht alles und kann deshalb auch nicht alles beantworten.
 
@ahasver
In diesem Forumsbereich geht es um ELMEG / FUNKWERK Enterprises Geräte. Fragen und Probleme zu SNOM-Geräten gehören in den betreffenden SNOM-Forumsbereich - wo du dieses ja schon geschildert hast; man muss deshalb nicht zwei Threads am Laufen halten.

@Anti-T
Bleibe beim jetzigen Threadthema; deine Ansichten zur Produktpolitik der Firma ElMEG / FUNKWERK ENTERPRISES gehört in einen eigenen Thread. Und wenn du deine Ansichten zur Produktpolitik der Firma SNOM kund tun willst, gab bzw. gibt es dazu einen Thread im SNOM-Bereich, zu dem du ja schon ausführlich Stellung genommen hast.

Überdies haben wir keine Lust, wegen dir und deinen Aussagen eine Abmahnung zu bekommen, nur weil du deine Ausdrucksweise nicht kanalisieren kannst.

Hier geht es allein um DHCP-Probleme mit dem Elmeg IP290
 
DHCP-Bug bei ElmegIP290/Snom190

Anti-T schrieb:
"Dein" Posting No. 6 in dem Thread ist aber vom Gersthofer.[...]Beim Lesen [...] verstehe ich dein Problem sowieso nicht, [....]
Kein Wunder, ich hatte mich leider vertan mit dem Link. Hab's oben geändert

Anti-T schrieb:
BTW: Mir wäre neu, dass man SNOMs (190er) bei Elmeg/Funkwerk supporten lassen kann.
Mir auch, aber die seinerzeitige Snom-Presseerklärung, lässt genau das vermuten.
 
Snom190 und ELMEG IP290

@der_Gersthofer
Zunächst mal danke, daß Du den umstrittenen Teil nochmal zur Fortsetzung der Diskussion aufgemacht und in einen eigenen Thread verlagert hast.
der_Gersthofer schrieb:
@ahasver In diesem Forumsbereich geht es um ELMEG / FUNKWERK Enterprises Geräte. Fragen und Probleme zu SNOM-Geräten gehören in den betreffenden SNOM-Forumsbereich
Beim Snom190/ElmegIP290 ist genau das nicht zu trennen, da ja baugleich. Und genau das ist IMHO hier das Thema und ja auch mit Stein des Anstoßes der Erhitzung der Diskussion. Das DHCP-Problem ist nur ein Detail zur Illustration des Problems.
der_Gersthofer schrieb:
@Anti-T Überdies haben wir keine Lust, wegen dir und deinen Aussagen eine Abmahnung zu bekommen,
Falls im konkreten Fall bei Snom die Nerven derart blank liegen sollten, dann wäre eh alles zu spät. Ich schätze die aber etwas souveräner ein...
 
Es ist deswegen zu trennen, weil für diejenigen, die ein SNOM 190 (mit der zuletzt verfügbaren Firmware 3.60x) haben, alleiniger Ansprechpartner die Firma SNOM ist -> und hierfür hast du ja bereits einen Thread im SNOM Bereich aufgemacht wo auch entsprechende Neuigkeiten / neue Infos etc. hingehören.

Für diejenigen, die ein Telefon der Firma Elmeg / Funkwerk (mit der zuletzt verfügbaren Firmware 3.60m war es glaube ich) haben, ist alleiniger Ansprechpartner die Firma Elmeg / Funkwerk -> und dafür ist dieser Thread hier im Elmeg Bereich.

Wenn man die Firmware des anderen Herstellers auf sein Gerät flasht, erlischt damit natürlich der Garantieanspruch und ist, wie immer, das alleinige Problem des Flashers.


Das hat mit "Nerven blank liegen" nichts zu tun, sondern
a) ist die Umgangssprache in diesem Forum eine andere (vgl. auch Forenregeln)
b) haben wir keine Lust, ggf. dafür einstehen zu müssen, nur weil manche Nutzer glauben, das Internet sei ein rechtsfreier Raum (vgl. auch dazu die Forenregeln)
 
der_Gersthofer schrieb:
Wenn man die Firmware des anderen Herstellers auf sein Gerät flasht, erlischt damit natürlich der Garantieanspruch und ist, wie immer, das alleinige Problem des Flashers.

Naja, für die Elmeg-Geräte mit den snom-Macadressen (00:04:...) ist die Firmware nicht nur in der Funktion identisch mit der snom-Firmware, es steht sogar snom190 überall als Modellname. Da bleibt einem also sozusagen als altes-elmeg-Besitzer nichts übrig als die Firmware des anderen Herstellers zu flashen.
 
ahasver schrieb:
Mir auch, aber die seinerzeitige Snom-Presseerklärung, lässt genau das vermuten.

VW schreibt eine Pressemeldung "Sharan-Kunden, wendet euch mit der Karre zukünftig bitte an Ford, die bauen das Ding unter dem Namen Ford Galaxy weiter und wir streichen jeglichen Support zum Sharan. Wir freuen uns, wenn sie ein anderes Auto von VW kaufen, für das wir kurze Zeit später den Support einstellen. Vielen Dank für ihre grenzenlose ********!"

ahasver schrieb:
Das DHCP-Problem ist nur ein Detail zur Illustration des Problems.

Ich denke es gibt keinen DHCP-Bug im Telefon. Stichwort Leasetime bei DCHCP. Wenn der Router (oder das Kabelmodem) dem Telefon eine private IP-Adresse gibt und der Router diese mit einer Leasetime von 30 Tagen versieht, dann wird das Telefon erst nach 15 Tagen auf die Idee kommen mal nach einer neuen Adresse zu fragen. So funktioniert nun mal ein DHCP-Client!

Lösung: Entweder der Router vergibt gar keine privaten IP-Adressen oder er sollte die Leasetime bei privaten vergebenen Adressen auf ganz kurz (wenige Minuten).

Einen DHCP-Fehler im Telefon sehe ich so nicht, schon eher einen im Kabelmodem/Router. Wie lang ist denn die Leastime?

der_Gersthofer schrieb:
Es ist deswegen zu trennen, weil für diejenigen, die ein SNOM 190 (mit der zuletzt verfügbaren Firmware 3.60x) haben, alleiniger Ansprechpartner die Firma SNOM ist

Nun, da liegst du aber falsch. Ansprechpartner bei Problemen ist der Verkäufer! Ansprüche gegen Snom exisiteren nach den deutschen Gesetzen nicht, es sei denn du hast das Telefon bei Snom gekauft (Snom=Verkäufer).

der_Gersthofer schrieb:
Für diejenigen, die ein Telefon der Firma Elmeg / Funkwerk (mit der zuletzt verfügbaren Firmware 3.60m war es glaube ich) haben, ist alleiniger Ansprechpartner die Firma Elmeg / Funkwerk

Schon wieder falsch, Ansprechpartner ist der Verkäufer des Elmeg/Funkwerk-Gerätes!

der_Gersthofer schrieb:
Wenn man die Firmware des anderen Herstellers auf sein Gerät flasht, erlischt damit natürlich der Garantieanspruch ...

Ansprüche zu welchen Garantien bitte?

Mit Verlaub, aber ich denke du kennst den Unterschied zwischen (gesetzlicher) Gewährleistung und (freiwilliger) Garantie nicht!

der_Gersthofer schrieb:
Das hat mit "Nerven blank liegen" nichts zu tun, sondern
a) ist die Umgangssprache in diesem Forum eine andere (vgl. auch Forenregeln)
b) haben wir keine Lust, ggf. dafür einstehen zu müssen, nur weil manche Nutzer glauben, das Internet sei ein rechtsfreier Raum (vgl. auch dazu die Forenregeln)

Nur zur Info: In Deutschland herrscht Meinungsfreiheit. Wenn ich Hersteller A Scheiße finde dann kann ich das auch äußern, hierfür gibt es keine rechtlichen Grundlagen das zu verbieten. Übrigens kann man ein Unternehmen auch nicht beleidigen.

Vielleicht liest du dich mal ein wenig ins StGB ein, bevor du hier als Moderator falsche Weisheiten aufstellst!
 
Anti-T schrieb:
Ich denke es gibt keinen DHCP-Bug im Telefon. Stichwort Leasetime bei DCHCP. Wenn der Router (oder das Kabelmodem) dem Telefon eine private IP-Adresse gibt und der Router diese mit einer Leasetime von 30 Tagen versieht, dann wird das Telefon erst nach 15 Tagen auf die Idee kommen mal nach einer neuen Adresse zu fragen. So funktioniert nun mal ein DHCP-Client!

Lösung: Entweder der Router vergibt gar keine privaten IP-Adressen oder er sollte die Leasetime bei privaten vergebenen Adressen auf ganz kurz (wenige Minuten).

Das Problem ist ja nicht, daß das Telefon sich keine aktuelle IP-Adresse neu holt, weil die Lease noch läuft, sondern daß der/die per DHCP mitgeteilte(n) DNS-Server sich nachträglich ändert. Und den erfragt es nicht, sondern bekommt es mitgeteilt. Die dafür zuständigen Optionen sind im DHCP-Client des Snom nicht oder unvollständig implementiert.

Anti-T schrieb:
Einen DHCP-Fehler im Telefon sehe ich so nicht, schon eher einen im Kabelmodem/Router. Wie lang ist denn die Leastime?
Nanu, ist das Telefon doch kein E***S***? ;)
Die private vom Router und die öffentliche sind lang genug, die für die temporäre private IP vom Kabelmodem weiß ich nicht, spielt aber keine Rolle, da das Problem ja auch hinter dem Router auftritt und dort die IP sich nicht ändert. Und andere Geräte am Kabelmodem hatten das Problem ja auch nie. Und wie geschrieben, das Phänomen ist unabhängig davon, ob direkt hinter Kabelmodem oder hinter dem Router. Beide reichen den Provider-DNS durch, sobald er erreichbar ist und per DHCP mitgeteilt wird. Wenn per DHCP aber der DNS zusammen mit der IP mitgeteilt wird, geht alles gut. Ich weiß nicht, ob ich das in dem alten Thread so verquer beschrieben hatte, aber IMHO müßte das Scenario jeder mit der passenden Hardwarde und einem eigenen DHCP-Server nachstellen können.
 
Zuletzt bearbeitet:
Anti-T schrieb:
Lösung: Entweder der Router vergibt gar keine privaten IP-Adressen oder er sollte die Leasetime bei privaten vergebenen Adressen auf ganz kurz (wenige Minuten).
Beides keine "Lösung", sondern ein Work around. Einfluß auf die Leasetime hab ich nur am Router, und da macht das keinen Sinn. Und ersteres praktiziere ich nun seit ettlichen Monaten: Ich hab den DHCP-Server im Kabelmodem abgeschaltet, der mir temporär eine IP geben kann. Wenigstens wartet das Snom noch lange genug auf die IP (der DHCP-Request-Fortschrittsbalken ist noch nicht ganz am rechten Display-Rand), bis das Modem online ist. Modem offline schalten geht dann halt nicht, zumindest komm ich dann nicht auf's Telefon mangels erreichbarer IP. Und mit statischer IP hinter dem Router (was Snom auch empfiehlt) geht auch nicht, weil mein Router dann den Provider-DNS nicht durchlässt (oder ich zu doof bin, das dem Billigteil beizubringen...)
 
ahasver schrieb:
Das Problem ist ja nicht, daß das Telefon sich keine aktuelle IP-Adresse neu holt, weil die Lease noch läuft, sondern daß der/die per DHCP mitgeteilte(n) DNS-Server sich nachträglich ändert. Und den erfragt es nicht, sondern bekommt es mitgeteilt.

Ein DHCP-Server ist kein Push- sondern ein Pull-Dienst (ist zumindest mein Kenntnissstand). Er vergibt Daten auf Anfrage, aber nicht von allein. Wenn Aktualisierungen zu machen sind, dann muss der DHCP-Client den DHCP-Server in irgendeiner Form fragen, von allein erfährt der DHCP-Client aber keine Änderungen. Tut der DHCP-Client das doch, dann wäre der DHCP-Client im Telefon meiner Meinung nach buggy.

ahasver schrieb:
Die dafür zuständigen Optionen sind im DHCP-Client des Snom nicht oder unvollständig implementiert.

Möglicherweise reden wir aber auch aneinander vorbei. Die automatische Adressvergabe mittels DHCP hat zum Beispiel nichts mit der automatischen Adressvergabe bei PPP zu tun. Gleiches könnte bei SIP der Fall sein, so dass sich das Telefon die (zusätzlichen) Daten nicht per DHCP sondern auf Applikationsebene (via SIP) holt. Das hat dann also nichts mit der Implementation des DHCP zu tun.

Es könnte aber auch sein, dass der DHCP-Prozess noch nicht zu Ende ist. So nach dem Prinzip "Hier hast du erst mal die angefragte IP-Adresse und die Subnetzmaske, die anderen Optionen (DNS-Server, Gateway) bekommst du gleich." So detailliert habe ich mich mit DHCP noch nicht auseinandergesetzt, bei den Microsoft-DHCP-Servern bin ich gewohnt, dass es in ein zwei Sekunden einfach funktioniert und danach ist Ruhe bis 50% der Leasetime vorbei sind.

ahasver schrieb:
Nanu, ist das Telefon doch kein E***S***? ;)

Doch, aber nicht (nur) deswegen.

ahasver schrieb:
Und wie geschrieben, das Phänomen ist unabhängig davon, ob direkt hinter Kabelmodem oder hinter dem Router. Beide reichen den Provider-DNS durch, sobald er erreichbar ist und per DHCP mitgeteilt wird.

Also ehrlich, dann taugen diese Geräte auch nichts, offensichtlich haben die keinen eigenen DNS-Proxy/DNS-Server in sich.
 
So, hab mir jetzt mal die Mühe gemacht, die RFC's zu DHCP und den DHCP Options im Hinblick auf das Problem zu durchzuforsten. Demnach hatte ich im technischen Detail einiges falsch verstanden und hier entsprechend falsch dargestellt.

Die Sache sieht, soweit ich das jetzt verstanden habe, folgendermaßen aus:

* bei DHCP drei relevante Zeitwerte gibt: Die Lease-Time, T1 und T2
* die Lease Time ist der maximale Gültigkeitszeitraum der IP-Adresse (Lease)
* T1 ist die Zeit, nach der der Client versuchen sollte, die Gültigkeit der Lease IP beim bisher genutzten DHCP-Server zu verlängern
* T2 ist die Zeit, nach der der Client, wenn keine Verlängerung geklappt hat, bei alle erreichbaren DHCP-Server nach einer neuen IP zu fragen
* für T1 ist standardmäßig 50% der Lease Time und für T2 irgendwas um die 83 oder 87 % der Lease Time empfohlen.
* Das Snom beachtet die vom Server mitgeteilten T1 und T2 nicht, sondern verwendet nur aus der Lease Time abgeleiteten Standardwerte (wobei ich nicht weiß, ob da die per RFC vorgeschlagenen Werte oder andere genommen werden, vielleicht gar 99oder 100% Lease-Time?), das ist das von mir als Bug bezeichnete Problem, Snom nennt es "Feature Request"
* Der DHCP-Server im Kabelmodem vergibt nun im Offline-Zustand eine lokale IP mit langer Lease Time, aber sehr kurzer T1/T2, damit man lange offline arbeiten kann, aber trotzem öfter mal nachgefragt wird, ob ein neuer DHCP-Server verfügbar ist (weil das Modem inzwischen online ist).
* Wenn das Kabelmodem nun online gegangen ist, fragt das Snom nicht nach, weil die errechneten/angenommenen T1/T2 noch lange nicht abgelaufen sind.
* Hinter dem Router wird da etwas verfälscht, weil der die lokalen IP's ebenfalls per DHCP vergibt und dann als DNS-Proxy fungiert (alles andere ist bei dem Teil ein Krampf), da könnte ich tatsächlich was mit extrem kurzer Lease-Time schrauben.

Das Abschalten des DHCP-Servers im Kabelmodem ist also der folgerichtige Work around.

Jetzt können wir weiter streiten, ob die Ignoranz gegenüber T1/T2 ein Bug oder ein nicht unterstütztes Feature ist...
 

Neueste Beiträge

Statistik des Forums

Themen
244,857
Beiträge
2,219,606
Mitglieder
371,571
Neuestes Mitglied
FritzFunk
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.

IPPF im Überblick

Neueste Beiträge