Schon erstaunlich. Genug bugs wären ja da...
Zitat von "Preussal"ja da bist du nicht allein.
aber das hat bei der 2.3er version auch ewig gedauertbin auch gespannt wann was neues kommt
Schon erstaunlich. Genug bugs wären ja da...
Zitat von "Preussal"ja da bist du nicht allein.
aber das hat bei der 2.3er version auch ewig gedauertbin auch gespannt wann was neues kommt
Hallo Allerseits,
Ist das nur bei mir so, oder gibts schon seit Monaten keine "interessanten Upgrades" mehr? Jedenfalls erzählt mir das efw-upgrade bei jeder Gelegenheit...
Gruß,
Alex
Hi Jochen,
Das ist ja interessant. Du konzentrierst dich hauptsächlich auf die Entstörung der Stromversorgung, richtig? Ich hab diese hier im Einsatz:
http://www.intellihome.be/deutsch/heim_a…eckbarer_filter
Allerdings zu einem komplett anderen Zweck...
Gruss,
Alex
Hi Jochen,
Sag mal, bist du oder warst du mal bei der Telekom? Ich frag das nicht um dich hinterher zu beschimpfen, keine Angst. Ich bin nur beeindruckt über die Insider-Kenntnisse und die Telekom-Lingo.
Und betreffs des eigentlichen Diskussionsthemas: Ich beschwere mich garantiert nicht. Ich bin happy mit dem was ich habe und freue mich auf die Zukunft, die üblicherweise alles besser macht. Wenn jetzt nur noch die EFW so arbeiten würde wie sie sollte
Gruss,
Alex
Hi Jochen,
versteh ich ja alles aus technischer Sicht. Warum die Telekom-Leute aber im Brustton der Überzeugung behaupten, dass selbst 2000 am äußersten Rand der technischen Möglichkeiten ist erschließt sich mir nicht. Aber wie auch immer: Ich bin erstmal happy. Bisher war ja ich nicht gerade verwöhnt
Gruß,
Alex
Hi Jochen,
Das Dingen oberhalb der Modem/Router ist nur ein Patchpanel. Da ist zwar die Blende 1HE hoch, aber direkt dahinter wird die ganze Angelegenheit schmaler. Über den Modems sind gut 2 cm Luft. Und direkt oberhalb des Panels sind 4 120er Lüfter die die Luft aus dem Schrank saugen. Ist ganz schön zugig wo die stehen
Die Frage nach dem DSL ist interessant. Ich wohne in einem Kaff wo die T-Com nur 2000er DLS Leitungen verkauft, und nicht mal die 2000 garantieren sie. 1500 wären wahrscheinlicher. Liegt an der Entfernung zum nächsten Verteiler. Naja, jedenfalls hatte ich jahrelang 2 Leitungen in 2 verschiedenen Häusern, verbunden per Richtfunk. Das andere Haus habe ich nun verkauft und mir noch einen Anschluss in mein Haus legen lassen. Diesmal von M-net. Die verkaufen DSL 6000, aber logischerweise hab ich mir keine drastischen Unterschiede erwartet, da M-net zwar eigene Infrastruktur hat, allerdings erst hinter dem Verteiler. Somit liegen also dieselben Beschränkungen vor wie bei T-Com. Der Telekom-Techniker, der im Auftrag von M-net die Leitung geschaltet hat meinte sogar, dass die beiden Leitungen wahrscheinlich übersprechen würden und ich mit permanenten SYNC Problemen zu rechnen hätte. Lange Rede, kurzer Sinn: Während bei der T-Com-Leitung bei ca. 200kB/sec Schluss ist, liefert die M-net-Leitung stabil zwischen 800 und 1000 kB/sec. Zu jeder Tageszeit und auch wenn ich beide Leitungen gleichzeitig glühen lasse. Versteh ich zwar nicht, aber ich werd mich mal nicht beschweren
Ums nochmal ganz kurz zu machen: Ich hab 1x DSL 2000- und einmal DSL 6000+.
Gruß,
Alex
Vorsicht Augenkrebs!
http://www.fotocommunity.de/pc/pc/mypics/1…isplay/21561387
So sieht mein Zylonen-System im Einsatz aus. Schön dass die Dinger fast genau 1HE haben. Passen wunderbar in eine Kabellücke im Schrank
Hast schon recht. Im betrieb sehen die echt ein bisschen Zylonen-mässig aus
Abgesehen vom VoIP hat bisher nichts gemuckt und mit eingetragenem STUN Server flutscht das auch wieder. Somit ist jetzt für mich erstmal alles grün. Im Bug-Tracker hab ich noch einen weiteren Kommentar geschrieben, aber interessieren tut's erstmal niemanden. Ist schade drum, ehrlich. Kann man halt nix machen. In der nächsten Zeit werden die Italiener eh erstmal mit Trauern beschäftigt sein, jetzt wo sie aus der WM geflogen sind
Gruß,
Alex
Übrigens: Ich hab mir diese Dinger geholt:
Schön billig, aber ein Interface zum davonlaufen
Hi Jochen,
natürlich hast du mit den Sicherheitsbedenken recht, trotzdem stört mich das alles ein wenig. Auch hab ich festgestellt, dass ich durch den zusätzlichen Hop massive Probleme mit VoIP bekommen habe. Hab ich mittlerweile aber auch behoben.
Sag mal, hast du bei deinen Routern NAT an? Ohne NAT bekomm ich keine Zugriffe von aussen geforwarded. Meine Config sieht nun so aus:
- NAT an
- EFW in der "DMZ" Zone des Routers
Scheint so weit zu funktionieren, aber noch ein NAT Device macht halt Probleme, siehe VoIP. Irgend eine Idee wie ich da ohne NAT weiterkommen könnte?
Gruß,
Alex
P.S.: Sorry, dass ich dich so auf Trapp halte mit meinen Problemen, aber du bist bisher der einzige Ansprechpartner / Leidensgenosse den ich habe.
Hallo Jochen,
Gut, dann lassen wir die Mühlen mal mahlen. Bis dahin hat mir dein Workaround schon einmal sehr weitergeholfen. Ich hab mit 2 kleine Modem/Router besorgt und deinem Vorschlag entsprechend aufgesetzt. Bisher (!) läuft alles so wie's soll. Wenn ein Link weg ist, ist er "DEAD" und die Backup-Leitung übernimmt. Auch der Proxy macht derzeit (!) keine Probleme. Natürlich werde ich das morgen nochmal testen. Und übermorgen. Und......
Jedenfalls vielen Dank für den Denkanstoss!
Zu deiner Frage: Ja, ich hab auch 5 von den PCI-e Realteks drin. Die liefen ja erstmal gar nicht, bis ich nen neuen Treiber eingebunden hatte. Anscheinend ein Fehler im Kernel. Aber nun mit dem neuen Treiber scheinen die Chips eigentlich problemlos zu laufen. Auch hohe Netz-zu-Netz Last können die problemlos ab. Ich denke der Fehler ist weniger in der Hardware zu suchen. Das Problem ist, dass die Büchse bei PPPoE Leitungsausfall erstmal Probleme hat überhaupt zu merken, dass sie offline ist. Danach gibts dann anscheinend beim setzen der Routen auf die Gateways trouble. Die DNS-Settings spielen wohl auch noch mit rein. Im großen und ganzen ist das Failover in Verbindung mit PPPoE gründlich im A*sch. Der ganze Workaround - selbst wenn er langfristig funktioniert - hinterlässt einen faden Beigeschmack. Die zwei Billigst-Router stehen nun an der ersten Linie zum Netz und sind der erste Angriffspunkt. Von da aus hab ich dann einen wunderbaren Vektor auf die Firewall selbst. Da darf ich gar nicht drüber nachdenken...
Na wie auch immer. Deutschland hat gewonnen und mein Failover geht auch. Da bin ich doch erstmal zufrieden
Gruß,
Alex
Noch was: Ich könnte beim Bug-Tracker etwas Unterstützung gebrauchen. Im Moment scheint das keinen zu interessieren. Wenn also jemand anderes ebenfalls mit diesem Problem zu kämpfen hat wär's nett wenn ihr mir eine kurze "Me Too" confirmation posten könntet. Das Ticket ist hier: http://bugs.endian.com/view.php?id=3015
Danke,
Alex
Hallo Jochen,
ja, einmal krieg ich's auch immer hin, dann ists wieder vorbei. Das Failover macht ganz schlicht was es will, aber garantiert nicht was es soll. Am Sonntag hatte ich meine EFW mal wieder so weit, dass sie einen Failover recht gut hinbekam. Ich hatte einen Ping auf http://www.google.com laufen und hab bei der Hauptleitung den Stecker gezogen. Gab ein paar Timeouts und dann gings weiter auf Leitung 2. Stecker wieder rein und zurück gings auf Leitung 1. Tolle Sache, wäre da nicht ein kleiner Haken: Ich hab meinen HTTP Proxy transparent auf GREEN laufen. das funktioniert grandios so lange Leitung 1 online ist. Passiert ein Failover lehnt der Proxy alle Requests von jedem Rechner im Netz ab. Im Log stehen dann haufenweise TCP_DENIED Ereignisse drin. Versteht sich von selbst, dass das mit den Regeln im Proxy absolut nix zu tun hat, da die ja auf Leitung 1 perfekt funktionieren. Ich hab trotzdem mal alle Block-Regeln ausgeschaltet und nur eine einzige ALLOW ANY/ANY drin gelassen. Funktioniert auf Leitung 1. Bei Failover wird wieder jede Anfrage von jeder IP geblockt. Sobald ich den Proxy ausschalte geht alles auch auf Leitung 2. Das soll mir mal einer plausibel erklären.
Das war, wie gesagt am Sonntag. Montag morgen bin ich weggefahren und erst vor einer halben Stunde wieder daheim angekommen. Geändert habe ich in der Zeit nichts (logisch, da ich ja nicht da war). Da ich ja absolut nichts anderes mit meiner Zeit anzufangen weiß, bin ich als ersten in den Keller gegangen und hab den Stecker von Leitung 1 gezogen. Ergebnis: Failover funktioniert wieder nicht.
Echt, schön langsam geht mir mit der EFW die Geduld aus. Die Tatsache, dass so viele offensichtliche Fehler in diesem Produkt derartig lange überleben bringt mich zum Nachdenken. Schließlich ist eine Firewall ein sicherheitsrelevanter Teil der Infrastruktur. Wie viele versteckte Mängel mag es da noch geben, die meine Umgebung eventuell gefährden? Ich denke ich werde mich nochmal auf die Suche nach Alternative machen. Die Vyatta FW hab ich mir mal angeschaut, aber Donnerwetter, die schaut villeicht kompliziert aus... Ich weiß, das hier ist wohl nicht unbedingt der richtige Platz um sowas zu fragen, aber gibts noch andere freie Alternativen die Failover beherrschen???
Betreffs des Wiederverbindungs-Timeouts: Das ist die Zeit, die die EFW wartet, bis sie nach einem Leitungsverlust einen neuen Einwahlversuch startet. Die Zeiteinheit sind Sekunden. Über den Standard-Intervall schweigt sich die Dokumentation ja leider aus...
Gruß,
Alex
Hallo Grenzwert,
Kannst du mir dein Setup nochmal erläutern, bitte? Du hast also einen extra Router vor der Endian und nutzt den sozusagen als Gateway, richtig?
Gefällt mir zwar nicht (ein vernünftiger Firewall/Router sollte das packen), aber ich würd's mal probieren.
BTW: Beide IPs sind statisch, also sollte es mit einer gewechselten IP nix zu tun haben. Ich bin grad unterwegs und hab nicht so viel Zeit, aber wenn ich wieder zuhause bin schreib ich noch was rein. Ich hab nämlich noch weitergetestet und teilweise haarsträubend unlogische Fehlerbilder entdeckt.
Gruß, Alex
Hallo Allerseits,
Ich bin mir nicht sicher ob ich bei der Konfiguration was vergessen habe (bin IPcop Umsteiger), aber ansich sieht ja so weit alles ganz logisch aus.
Ich habe 2 DSL Leitungen (T-Com & M-Net). Beide Uplinks sind eingerichtet und funktionieren. Der M-Net Account ist mein Hauptaccount und ist so konfiguriert, dass er bei Ausfall auf die T-Com-Leitung umschaltet. Die Konfiguration kann man sich im angehängten .jpg anschauen.
Das Problem, kurz dargestellt durch 2 Tests:
1.
- EFW rebootet. Beide Uplinks "UP"
- Hauptlink (M-Net) manuell abgeschaltet (/Network/Interfaces/Uplink Editor im Web-Interface)
- Hauptlink zeigt Status "INACTIVE"
- Der Backup-Link übernimmt. Alles paletti
2.
- EFW rebootet. Beide Uplinks "UP"
- DSL-Kabel aus dem Splitter rausgezogen
- Hauptlink zeigt Status "CONNECTING"
- Nichts passiert. Backup-Link übernimmt NICHT
Wenn ich alles so lasse wechselt der Status des Hauptlinks zwischen "CONNECTING" und "INACTIVE" hin und her. Der Backup-Link ist währenddessen "UP". Internet-Zugriff ist nicht möglich.
Hier kommt aber jetzt das schlimmste: Wenn ich den Stecker wieder reinstecke kommt der Hauptlink nicht wieder hoch. Angezeigt wird abwechselnd "CONNECTING" und "DEAD". Das hier taucht immer wieder im Log auf:
Jun 18 03:16:02 pppd[20281] Plugin rp-pppoe.so loaded.
Jun 18 03:16:02 pppd[20281] RP-PPPoE plugin version 3.3 compiled against pppd 2.4.4
Jun 18 03:16:02 pppd[20281] pppd 2.4.4 started by root, uid 0
Jun 18 03:16:02 pppd[20281] PPP session is 6613
Jun 18 03:16:02 pppd[20281] Using interface ppp1
Jun 18 03:16:02 pppd[20281] Connect: ppp1 <--> eth4
Jun 18 03:16:03 pppd[20281] CHAP authentication succeeded
Jun 18 03:16:03 pppd[20281] CHAP authentication succeeded
Jun 18 03:16:03 pppd[20281] peer from calling number 00:90:1A:42:8A:BE authorized
Jun 18 03:16:03 pppd[20281] local IP address xxx.xxx.xxx.xxx
Jun 18 03:16:03 pppd[20281] remote IP address xxx.xxx.xxx.xxx
Jun 18 03:16:03 pppd[20281] primary DNS address 212.18.3.5
Jun 18 03:16:03 pppd[20281] secondary DNS address 212.18.0.5
Jun 18 03:16:09 pppd[20288] Terminating on signal 15
Jun 18 03:16:09 pppd[20288] Connect time 0.1 minutes.
Jun 18 03:16:09 pppd[20288] Sent 120 bytes, received 40 bytes.
Jun 18 03:16:09 pppd[20288] Connection terminated.
Jun 18 03:16:09 pppd[20288] Exit.
Jun 18 03:16:10 pppd[20762] Plugin rp-pppoe.so loaded.
Jun 18 03:16:10 pppd[20762] RP-PPPoE plugin version 3.3 compiled against pppd 2.4.4
Jun 18 03:16:10 pppd[20762] pppd 2.4.4 started by root, uid 0
Jun 18 03:16:45 pppd[20762] Timeout waiting for PADO packets
Jun 18 03:16:45 pppd[20762] Unable to complete PPPoE Discovery
Jun 18 03:16:45 pppd[20762] Exit.
Alles anzeigen
An dieser Stelle hilft nur noch ein Reboot.
Mittlerweile hab ich es sogar einmal fertiggebracht, dass der Failover funktioniert. Ich habe die folgende Policy-Route aufgesetzt:
Source: GREEN, Destination: ANY, Service/Port: ANY/ANY, Route via: Main uplink, Use backup link if uplink fails: checked
- Hauptlink manuell abgeschaltet -> Failover funktioniert nach ca. 10 Sekunden
- Hauptlink wieder eingeschaltet -> Routing geht wieder auf Hauplink zurück
- DSL-Kabel rausgezogen -> Failover funktioniert nach ca. 30 Sekunden
- DSL-Label wieder reingesteckt -> Der Hauptlink komt wieder "UP" und die Pakete gehen wieder durch.
Alles perfekt. Nur als ich dasselbe eine Stunde später nochmal probiert habe gings wieder nicht. Geändert hab ich zwischendurch nichts.
Ich hab noch eine andere Policy-Route die allen Traffic aus "RED" durch den Backup-Link schickt. Irgendwann kam dann aber plötzlich "RED"-Traffic durch den Hauptlink. Nach einem Reboot war dann wieder alles normal.
Bei weiteren Tests habe ich noch festgestellt, dass immer wenn ich den Link automatisch überprüfen lasse ("Check if these hosts are reachable". Ausprobiert hab ich
http://www.google.com, http://www.google.com & http://www.yahoo.com, 8.8.8.8) auf jeden Fall der Link irgendwann "DEAD" ist. Google ist natürlich währenddessen erreichbar. Und ein Failover findet auch nicht statt.
Ich verzweifle hier langsam. Was mache ich verkehrt?? Ich hab die Endian FW eigentlich hauptsächlich wegen dem Failover aufgesetzt. Zu diesem Zeitpunkt hatte ich die 2. Leitung noch nicht geschaltet, hab mich aber darauf verlassen dass alles funktioniert wenn sie dann da ist. Seitdem ist mir die EFW irgendwie ans Herz gewachsen, so dass ich nicht schon wieder umkonfigurieren will...
Meine Hardware ist ein Intel ATOM Pine Trail D mit ICH8M Chipset und 4 Realtek Gigabit NICs, 2GB RAM und einer 120GB HD
Wens interessiert: Ich habe das ganze auch als Bug gemeldet: http://bugs.endian.com/view.php?id=3015