Probleme beta LCOS 9.24.0113

[DirkK]

Hi,

habe gerade meinen 1784VA weggeschossen mit der Firmware LC-1784VA-9.24.0113.upx. Danach ging keine WAN-Verbindung mehr. Er bekommt zwar noch die Connection, aber aus dem LAN geht kein Traffic mehr raus oder rein. Fängt bei der DNS-Auflösung an, aber selbst wenn man die durch einen anderen DNS-Server "überbrückt" oder IP's direkt im Browser angibt fließen keine Daten.

Kann das damit zusammenhängen?

Zurück auf die 110 oder flashen der 113 mit 70Rel hat auch keine Lösung gebracht, die Leitungen sind nach wie vor zugeschnürt. Aktuell musste ich manuell auf die Backup-Backup-Leitung umstellen, was mit 3 statt 60MBit nicht lustig ist.

Gruß
Dirk

[DirkK]

Er bekommt zwar noch die Connection, aber aus dem LAN geht kein Traffic mehr raus oder rein. Fängt bei der DNS-Auflösung an, aber selbst wenn man die durch einen anderen DNS-Server "überbrückt" oder IP's direkt im Browser angibt fließen keine Daten.

Völlig kurios: ich habe noch bis fast 2 Uhr probiert das Problem zu fixen, aber nichts hat funktioniert. Jetzt über Nacht hat sich das Problem von selbst geheilt...
Alles wieder wie vorher. Aktuell sind die FW 110 und 70Rel drin, aber ich verstehe trotzdem nicht, warum stundenlang keine Daten ins WAN gegangen sind.

Gruß
Dirk

[LoUiS]

Hi,

ich habe Deine Beitraege abgetrennt, da ich nicht denke das es etwas mit dem anderen Thema zu tun hat.
Da Du eine beta Version eingespielt hast, ist Dein Feedback sicherlich hier im Bereich zum LCOS Betatest besser aufgehoben.
Da ich auch Probleme mit einer DHCPoE WAN Verbindung mit dieser Build festgestellt habe, habe ich diese Build erst mal vom FTP entfernt.


Ciao
LoUiS

[DirkK]

ich habe Deine Beitraege abgetrennt, da ich nicht denke das es etwas mit dem anderen Thema zu tun hat.
Da Du eine beta Version eingespielt hast, ist Dein Feedback sicherlich hier im Bereich zum LCOS Betatest besser aufgehoben.

OK, Danke!

Kurze Info zum Fehler:
Ein Trace auf DNS zeigt zwar eine Anfrage in Richtung DNS-Server des DSL-Anbieters, läuft aber trotz einer bestehenden DSL-Verbindung auf einen Timeout. Mein 1784 besitzt zwei WAN-DSL-Leitungen bei zwei verschiedenen Providern. Die DNS-Anfragen gehen im Loadbalancing raus. Auf beiden Leitungen kommen Timeouts.

Kann jemand erklären, warum aber das Problem weiter bestand, obwohl ich die FW 113 mit der 70Rel ersetzt habe, den Router neu gestartet und die Verbindungen neu aufgebaut wurden? Und warum hat sich das Problem über Nacht selbst geheilt?

Da ich auch Probleme mit einer DHCPoE WAN Verbindung mit dieser Build festgestellt habe, habe ich diese Build erst mal vom FTP entfernt.

Habe ich gesehen, jetzt liegt die 114 dort. Ist der Fehler dort raus?

beste Grüße
Dirk

[LoUiS]

Ich habe mit meinem LANCOM 1781EF+ mit der Build 0114 kein Problem mehr feststellen koennen, weshalb ich die Build auf den FTP geladen habe.

[DirkK]

Ich habe mit meinem LANCOM 1781EF+ mit der Build 0114 kein Problem mehr feststellen koennen,

Mein 1784VA funktioniert mit der 0114 auch wieder problemlos.

Gruß
Dirk

[DirkK]

Hi,

gerade noch mal ein Problem mit der Rel 0115 bemerkt:


In der Stationstabelle gibt es mehrere Clients mit Reservierungen:
Client1 IP1
Client2 IP2
usw.

Fehler:
nicht angemeldeter Client1. Client2 meldet sich an, bekommt aber IP1. Client1 kommt wieder in den WLAN-Bereich und versucht sich anzumelden. Dies schlägt natürlich fehl, da IP1 schon belegt.

Nach manueller Löschung der entsprechenden DHCP-Tabellen Einträge funktioniert wieder alles.

Gruß Dirk

[DirkK]

gerade noch mal ein Problem mit der Rel 0115 bemerkt:

Nach manueller Löschung der entsprechenden DHCP-Tabellen Einträge funktioniert wieder alles.

Gerade wieder das Problem gehabt...
Also die BOOTO-Stationstabelle wird nicht sauber verarbeitet. Ist definitiv ein Bug.
Der DHCP-Server vergibt hier Adressen falsch. Zu einer MAC existieren z.B. zwei IP-Adressen und die zweite MAC wird dadurch nicht ins Netz gelassen...

Beste Grüße
Dirk

[LoUiS]

Hi,

betrifft das nur WLAN-Geräte?
Ist hier fuer den Client1 in der Zwischenzeit die Lease-Time abgelaufen? Dann darf der DHCP-Server die IP neu vergeben.
Btw. Wenn die Clients roamen, ist es besser einen zentralen DHCP-Server zu verwenden. Das hat IMHO nichts mit BOOTP zu tun.


Ciao
LoUiS

[DirkK]

betrifft das nur WLAN-Geräte?
Ist hier fuer den Client1 in der Zwischenzeit die Lease-Time abgelaufen? Dann darf der DHCP-Server die IP neu vergeben.
Btw. Wenn die Clients roamen, ist es besser einen zentralen DHCP-Server zu verwenden. Das hat IMHO nichts mit BOOTP zu tun.

Ja, aktuell sind das nur WLAN-Geräte.
Nein die Lease-Time war nicht abgelaufen.
Mein 1784 ist WLAN-Controller, zentraler DHCP-Server und die Geräte roamen zwischen den AP's
Mit BOOTP meinte ich die Vergabe von "festen" IP-Adressen über den DHCP-Server.
90% der Geräte haben "feste" über die Stations-Tabelle verteilte IP-Adressen
Und hier vergibt der DHCP-Server die Adressen falsch.

In der Liste steht z.B.:
Client1 MAC1 IP1
Client2 MAC2 IP2
und das hat bis dato auch immer funktioniert.

in der Rel. 0115 aber finde ich bei identischer Konfiguration folgende Adress-Verteilung
Client1 MAC1 IP1
Client1 MAC1 IP2
Client2 MAC2 IP nicht zugewiesen, auch nicht aus dem noch freien IP-Pool, da ja Reservierung auf IP2 konfiguriert und IP2 durch Client1 belegt.

Beste Grüße
Dirk

[Jirka]

Hallo Dirk,

Du schreibst nicht ganz konkret auf welche Tabellen sich Deine Aussagen beziehen. So kann man das schwer nachvollziehen. Wenn Du von den zwei IPs schreibst, dann bist Du vermutlich in der Status-DHCP-Tabelle, vorher aber in der Setup-DHCP-Hosts-Tabelle (BOOTP).
Mir sieht das erst mal mehr nach einem Konfigurationsfehler aus. DHCP-Weiterleitungen in den APs oder sowas hast Du nicht konfiguriert? Hmm, kann eigentlich nicht, weil Du hast ja von WLAN-Controller geschrieben.
Aber wenn Du von der DHCP-Status-Tabelle schreibst, dann müssten doch auch unterschiedliche Zeiten für die IP-Adresszuweisungen zu erkennen sein und an denen könnte man ein Troubleshooting ansetzen.
Wenn Du willst, kann ich gerne mal auf Deine Konfig draufschauen.

Viele Grüße,
Jirka

[DirkK]

Hallo Jirak,

Du schreibst nicht ganz konkret auf welche Tabellen sich Deine Aussagen beziehen. So kann man das schwer nachvollziehen. Wenn Du von den zwei IPs schreibst, dann bist Du vermutlich in der Status-DHCP-Tabelle, vorher aber in der Setup-DHCP-Hosts-Tabelle (BOOTP).

Naja ok, natürlich sind das zwei Tabellen:
1. die Konfiguration: Setup-DHCP-Hosts-Tabelle (BOOTP)
2. der Status, wo ich den Fehler dann sehe: Status-DHCP-Tabelle

Mir sieht das erst mal mehr nach einem Konfigurationsfehler aus. DHCP-Weiterleitungen in den APs oder sowas hast Du nicht konfiguriert? Hmm, kann eigentlich nicht, weil Du hast ja von WLAN-Controller geschrieben.

Konfigurationsfehler kann es definitiv nicht sein, denn in der Setup-DHCP-Hosts-Tabelle (BOOTP) lässt sich eine MAC-Adresse nicht zwei mal eintragen. Man kann zwar sehr wohl zwei MAC's eine IP zuordnen (mache ich nicht) aber nicht einer MAC zwei IP's. Aber genau das mach der DHCP-Server des 1784.
Zudem funktionierte diese Konfiguration seit mehreren Jahren tadellos.
Und ja DHCP-Weiterleitungen o.ä. ist auch nicht konfiguriert. Es gibt auch nur einen DHCP-Server im LAN. Vor einigen Monaten habe ich alle Netzservices auf einen 1724 konsolidiert, den ich dann durch den 1784+WLC-Option ersetzt habe.

Aber wenn Du von der DHCP-Status-Tabelle schreibst, dann müssten doch auch unterschiedliche Zeiten für die IP-Adresszuweisungen zu erkennen sein und an denen könnte man ein Troubleshooting ansetzen.

Das ist wohl wahr, habe ich auch gesehen, aber ändert ja nichts an der Tatsache, dass der DHCP im 1784 nicht einfach einer MAC zwei IPs zuweisen darf.
Anbei ein Auszug der Stationstabelle mit den betroffenen Clients. Hier sieht an ganz deutlich, dass die beiden MAC's keinerlei Ähnlichkeiten haben, auch die IP's sind im letzten Byte eigentlich nicht ähnlich. Trotzdem bekommt Client1 sowohl die .233, wie auch die .35.

Beste Grüße
Dirk

[Jirka]

Hallo Dirk,

Konfigurationsfehler kann es definitiv nicht sein

ok. Dann ist es eine spezielle Situation, die das Fehlverhalten auslöst. Dann muss man nur rausfinden, welche...

denn in der Setup-DHCP-Hosts-Tabelle (BOOTP) lässt sich eine MAC-Adresse nicht zwei mal eintragen.

Doch, schon. Aber in einem anderen Netz. Denn in einem anderen lokalen ARF-Netz kann die MAC ja eine andere IP zugewiesen bekommen.

Aber genau das mach der DHCP-Server des 1784.

Ja, dann wäre der nächste Schritt aber ein DHCP-Trace.

Zudem funktionierte diese Konfiguration seit mehreren Jahren tadellos.

Glaube ich Dir. Trotzdem muss das nichts heißen, Fehler können sich leider ja auch einschleichen.

Das ist wohl wahr, habe ich auch gesehen, aber ändert ja nichts an der Tatsache, dass der DHCP im 1784 nicht einfach einer MAC zwei IPs zuweisen darf.

So eine Situation kann bei Konfigurationsänderungen aber entstehen: Client-A bekommt eine IP zugewiesen. Anschließend erfasst Du in der BOOTP/Hosts-Tabelle für die MAC-Adresse eine andere IP. Dann hast Du anschließend in der Status-DHCP-Tabelle zwei Einträge (eine Zuweisung, eine Reservierung). Wenn der Client nun roamt, oder den Bereich kurz verlässt und damit ein erneuten DHCP-Request sendet, dann vergibt der DHCP-Server die reservierte IP. Bei der anderen Zuweisung ist aber die Lease-Time noch nicht abgelaufen. Folglich hast Du jetzt zwei Einträge. Und wenn der Client auch noch ein Apple-Gerät ist, dann hast Du auch lange was davon, denn die krallen sich gerne die maximal zulässige Lease-Time. Aber ich denke meine Beschreibung hier hat jetzt nichts mit Deinem Problem zu tun, sie war eher informativ.

Anbei ein Auszug der Stationstabelle mit den betroffenen Clients. Hier sieht an ganz deutlich, dass die beiden MAC's keinerlei Ähnlichkeiten haben, auch die IP's sind im letzten Byte eigentlich nicht ähnlich. Trotzdem bekommt Client1 sowohl die .233, wie auch die .35.

Ja, wie gesagt, DHCP-Trace. Oder mal eine Angabe zu den Zeiten, ob die Adresszuweisungen zum selben Zeitpunkt erfolgten.
Ich kann an Deinen MAC-Adressen jetzt auch nichts erkennen, ok, die eine fängt mit 64 an, das ist sicherlich schon eine besondere Zahl, aber ansonsten...

Viele Grüße,
Jirka

[stefanbunzel]

Hallo Jirka und Dirk,

mal eine kurze Empfehlung meinerseits zu dieser Problematik, die ich bei Lancom in den letzten Jahren immer wieder mal hatte (aber aus Zeitgründen nie weiter intensiv analysiert habe): Bei der Nutzung von BootP sollte es keine Überschneidungen mit DHCP-Adress-Bereichen geben! Wenn du also zum Beispiel DHCP im Bereich 192.168.1.1 bis ...128 nutzt, dann kannst du problemlos deine "festen" IP's mittels BootP im Bereich 192.168.1.129 bis ...254 reservieren.

Hierdurch konnte ich diese doppelten bzw. vermischten Zuweisungen von eigentlich reservierten IP-Adressen immer elegant umgehen.

Okay, das löst erst einmal nicht dein aktuelles Problem - verhindert aber elegant zukünftig vergleichbare Probleme.

Viele Grüße,
Stefan

[DirkK]

Hi,

ist ja nett, dass ihr hier mögliche Fehlerquellen und Lösungen vorbringt, aber wie gesagt, die DHCP-Konfiguration existiert seit FW Rel 9.10.???, seit März 16, also über ein halbes Jahr, ohne dass ich das Problem (bzgl. DHCP) hatte. Jetzt mit Rel. 9.24.0115 ist das Problem innerhalb von wenigen (4?) Tagen drei Mal aufgetreten.

Deswegen ist meine Intention v.a. hier den Lancom-MA das Fehlerbild zu beschreiben, einfach um auf potentielle (oder wie ich hier meine sichere) Bugs aufmerksam zu machen. In gewissem Rahmen bin ich auch gerne bereit mal ein Trace o.ä. zur genaueren Beschreibung zu liefern. Aber bei so einem sporadischen Problem ist das schon recht aufwändig.
Es ist nämlich nicht damit getan die DHCP-Status Einträge zu löschen, sondern das Problem tritt irgendwann einmal auf, ist also nicht provozierbar.

Beste Grüße
Dirk