From Harry.News at gmx.de Mon Dec 1 20:45:51 2014 From: Harry.News at gmx.de (=?ISO-8859-1?Q?Harald_M=FCller?=) Date: Mon, 01 Dec 2014 20:45:51 +0100 Subject: [fli4l] =?iso-8859-1?q?Zugriff_auf_bestimmte_Ger=E4te_im_LAN_mit_?= =?iso-8859-1?q?FLI4L_beschr=E4nken?= In-Reply-To: References: Message-ID: Ich benutze für so etwas einen Switch der Port basierende VLANs kann. Die Endgeräte müssen kein VLAN kennen, die VLANs werden über die Ports zugewiesen. Netgear FS526T: Sehr empfehlenswert aber nur 100Mbit + 2x1000Mbit Netgear GS724T: 1000MBit, schaltet bei mehreren VLAN auf einem Port leider in den Hub-Modus. Die beiden habe ich noch ins Auge gefasst: TP-Link TL-SG3424 TP-Link TL-SG5428 WLAN entweder über mehrere AP (einfach) oder eine AP mit Multi-SSD in Vernindung mit VLAN (etwas komplizierter). Harry From Hans at Bachner.priv.at Mon Dec 1 23:48:24 2014 From: Hans at Bachner.priv.at (Hans Bachner) Date: Mon, 01 Dec 2014 23:48:24 +0100 Subject: [fli4l] =?utf-8?q?IPs/Netze_vone=3F=3D=3D=3Futf-8=3FQ=3Finander_t?= =?utf-8?q?rennen___Fragen_=C3=BCb=3F=3D=3D=3Futf-8=3FQ=3Fer_Fragen?= References: Message-ID: Hallo Christoph, danke für deine ausführliche Antwort. Christoph Schulz schrieb: >>> Zweitens: An vielen Stellen im Code wird (zu recht!) angenommen, >>> dass >>> die Inhalte von /etc/rc.cfg und /boot/rc.cfg identisch sind. >> >> Warum wird hier doppelt gemoppelt? Warum wird die Konfiguration noch ein >> zweites Mal in das rootfs verpackt? Wenn man sie dort haben will kann >> man sie ja auch während des Bootens aus dem /boot Verzeichnis dorthin >> kopieren. Welcher Code schaut sich die /etc/rc.cfg an? > > Nun, die Archive wurden auf Basis der Konfiguration in /etc/rc.cfg > gebaut. Nun, ob der Build-Prozess seine Infos in der einen oder anderen Datei sammelt und sie am Ende in die andere kopiert, ist wohl nicht von strategischer Bedeutung und auch nicht in Stein gemeißelt. > Insofern hast du Recht, dass die Redundanz (die vermutlich > historisch > bedingt ist) natürlich nicht schön ist. Jedoch würde ich deshalb > irgendwann > den anderen Weg gehen, nämlich die /boot/rc.cfg wegzulassen und > die > Konfiguration nur noch aus /etc/rc.cfg auszulesen. Ich würde es genau umgekehrt machen, wenn aus historischen Gründen eine /etc/rc.cfg erforderlich ist. > Mal ehrlich: Das nachträgliche Ändern der Konfiguration in /boot > ist doch > Hackaround ohnegleichen. Nein - das ist ein Workaround für die (noch) fehlenden Konfigurationsmöglichkeiten auf dem Router selbst. > Das eine Argument ist bislang "ich mach's, weil > ich es kann (und weil es geht, wenn ich aufpasse)" (das andere > Argument mit > der Zeitersparnis greife ich weiter unten auf). Das ist sicherlich > kein > tragfähiges Konzept und sollte nicht künstlich am Leben gehalten > werden. Vor > allem kann man nur dann überblicken, was geht und was nicht geht, > wenn man > im Detail verstanden hat, wie Pakete aufgebaut sind und was für > Prüfungen > und Aktionen mkfli4l so macht, um die Installationsarchive zu bauen. > Dieses > Wissen ist sicherlich "advanced" und nicht einem "normalen" Nutzer > zuzumuten. Ich halte es absolut nicht für die Lösung, die man einem neuen fli4l-Nutzer ans Herz legen sollte. Aber es ist für erfahrenere Nutzer eine Möglichkeit, (noch) fehlende Funktionalität auf einfache Weise zu ersetzen. Ich verwende fli4l seit der Version 2.0.4 (ca. 2002) - mit ein Grund dafür ist, dass der Router eben *keine* Black Box ist und ich bei Problemen oder Wünschen auf Gedeih und Verderb auf den Router-Hersteller angewiesen bin. Und selbst bei den "Black Box" Routern, die zumindest einen telnet/ssh/ftp-Zugang bieten, kann ich Konfigurationsdateien ändern, ohne gleich ein Firmware-Update machen zu müssen. Natürlich kann auch bei diesen Routern nicht alles übers Web-Interface konfiguriert werden. > Allerdings gebe ich dir hiermit Recht: > [schnipp] > > Eine Verknüpfung von WebGUI und Persistenz (und ein Rückkanal zu > der > Konfiguration auf dem Build-Host) wäre eine feine Sache. Leider > sind hier > viele Fragen zu klären, viele Probleme zu wälzen und natürlich > geeignete > technische Lösungen zu entwickeln. Nicht unmöglich, aber sicher > nichts für > "so mal nebenbei". Erst einmal danke für die Zustimmung in der Sache. Dass so ein Teil-Projekt nicht in drei Abenden erledigt ist, ist mir (vor allem als auch-Software-Entwickler) völlig klar. Worum es mir in diesem Beitrag geht: der - wenn auch wacklige - Steg sollte nicht abgerissen werden, bevor die neue Brücke steht. > Mein ursprünglicher Beitrag sollte eigentlich auch nur darauf > hinweisen, > dass es _nicht_ ratsam ist, die /boot/rc.cfg nachträglich zu > verändern. Ja, eh. > Und > bei diesem Standpunkt bleibe ich ;-) Jegliche unerwünschte > Konsequenzen, die > aus einem solchen Handeln resultieren, sind hausgemacht. Ist klar. > Es gibt keinen "offiziellen Support" dafür. Den verlang ich auch gar nicht. Wenn sich aus einer (direkten) Änderung der boot.cfg ein Problem ergibt, werde ich hier sicher nicht motzen - sondern (wenn ich den Grund nicht selbst ermitteln kann) halt einmal nach den Gründen fragen. Ich erwarte sicher nicht, dass ein geändertes Verhalten automatisch sofort als Bug eingestuft wird. Wenn es aber gute Gründe für das alte Verhalten gibt, erwarte ich schon, dass diese in die Überlegungen des Teams mit einfließen. Mutwilliges Abdrehen von Möglichkeiten ohne echten Mehrwert sollte imho nicht vorkommen, das wäre eine Missachtung der Anwender, denen ja das ganze Projekt letztlich zugute kommen soll. > Was ich bei der ganzen Diskussion nicht verstehe: Wenn man (z.B.) > zusätzliche Hosts in der /boot/rc.cfg eintragen will, dann muss man > den > Router doch ohnehin booten. Wenn man die Änderung *nur* in der /boot/rc.cfg einträgt, dann ja. Wenn man aber die von dnsmasq verwendeten Konfigurations-Dateien kennt, ist das Hinzufügen eines Hosts mit dem Editieren einer, maximal zwei weiterer Datei(en) und einem anschließenden # killall dnsmasq # dnsmasq --min-port=4096 erledigt. (Bitte nicht in die Doku aufnehmen - das war jetzt aus dem Gedächtnis.) Mit ein paar Befehlen mehr werden sogar die dnsmasq-Konfigurationsdateien automatisch neu gebaut. Bei den aktuellen Tarball-Versionen geht es auch einfacher, da kann zumindest die laufende Konfiguration schon über das Web-GUI modifiziert werden; es braucht dann wirklich nur noch für Persistenz gesorgt werden (/boot/rc.cfg). > Warum dann nicht einfach den normalen Weg gehen > (Konfiguration auf Build-Host ändern, Archive bauen, Router > aktualisieren, > booten)? Das kostet vielleicht zwei Minuten mehr, ist aber sauber > (es kann > nichts kaputt gemacht werden, weil mkfli4l alles überprüft) und > unterstützt. - weil der Router, um den es geht, nicht immer neben mir steht, und bei der Upload-Geschwindigkeit meines DSL Anschlusses zu Hause ein mehrfaches von den genannten zwei Minuten für ein Update zur Folge hätte - weil ich bei einem Reboot nicht nur für mich selbst den Internet-Zugang unterbreche. Im günstigsten Fall hab ich "nur" die Familie am Hals, mittleres Szenario ist ein Büro mit einem halben Dutzend Mitarbeitern. Ich hab fli4l aber auch schon auf Jugendlagern mit vier- oder fünftausend Teilnehmern eingesetzt, der Internetzugang war sowohl für die Administration als auch für die Programmgestaltung essenziell. Um es auf den Punkt zu bringen: um die Funktionalität zu erweitern, ist (in der Regel) tatsächlich ein neuer Build, Upload und Reboot nötig. Wenn es aber nur um - sagen wir einmal: Konfigurations*daten* geht, ist das doch Overkill und bringt ernsthafte Einschränkungen beim Zeitpunkt, an dem eine Änderung durchgeführt und/oder zur Geschwindigkeit, mit dem sie wirksam werden kann, mit sich. Außerdem: wegen eines zusätzlichen Host-Eintrags neu zu booten, ist nicht einmal mehr unter Windows notwendig. Und hier ist Linux. Wo bleibt da meine schöne Uptime? ====== fli4l läuft seit: 378 Tagen, 14 Stunden und 10 Minuten ====== Ich meine, die Möglichkeit so eines Eingreifens über die offiziellen Schnittstellen hinaus ist eine der großen Stärken des fli4l-Projektes. Ich hab halt nicht die Zeit, für alles, was ich mir wünsche, eine Lösung zu produzieren und bin daher für diese Flexibilität sehr dankbar. Mein bisher einziger Beitrag (zum opt cpmvrmlog) ist schon einige Jahre her - will sagen, wenn ich wirklich die Zeit aufbringen kann, behalt ich das Ergebnis auch nicht für mich. Danke fürs bis hierher Mitlesen. Schöne Grüße, Hans. From kay at martinen.de Tue Dec 2 00:51:15 2014 From: kay at martinen.de (Kay Martinen) Date: Tue, 02 Dec 2014 00:51:15 +0100 Subject: [fli4l] =?utf-8?q?IPs/Netze_voneinander_trennen___Fragen_=C3=BCbe?= =?utf-8?q?r_Fragen?= In-Reply-To: References: Message-ID: Am 01.12.2014 um 23:48 schrieb Hans Bachner an Christoph Schulz: > Nun, ob der Build-Prozess seine Infos in der einen oder anderen Datei > sammelt und sie am Ende in die andere kopiert, ist wohl nicht von > strategischer Bedeutung und auch nicht in Stein gemeißelt. Ich weiß jetzt nicht welche, wo liegt, würde als FLI user aber vorziehen eine cfg zu belassen die nicht irgendwo verpackt ist. So das man ggf. bei Problemen von außen ran kommt, z.b. mit einem Live-System. >> Mal ehrlich: Das nachträgliche Ändern der Konfiguration in /boot >> ist doch >> Hackaround ohnegleichen. > > Nein - das ist ein Workaround für die (noch) fehlenden > Konfigurationsmöglichkeiten auf dem Router selbst. Auch sus eben dem Grund mein Obiger Einwurf. Allerdings sehe ich auch die Möglichkeit das die fehlende Konfigurierbarkeit als "Security by Design" gedacht ist. Kann das sein? Wenn die nicht einfach zugänglich ist kann sie bei einem Hack-versuch auch nicht manipuliert werden. Andererseits kann ein Hacker der schon auf der router-shell ist vermutlich eh alles erreichen. Nicht nur /etc Aber: Ich wünsche mir eine Möglichkeit das man auf dem Build-PC eine Konfiguration ändert, auf den FLI schiebt (z.b. per imonc) und dieser statt eines Reboot nur ein schnelles neu starten aller (oder betroffener) Dienste macht. Also z.b. grob geschnitzt copy cfg dialmode=manual, hangup restart all dialmode=auto sollte auf jedem Router-PC schneller gehen als ein komplett Reboot aber genau so gut sein. Ich meine jetzt nur bei Änderungen an der konfig die keine Module de-aktivieren, sondern reine parameter-änderungen sind. Z.b. die hosts liste, firewall-einstellungen u.a. >> Argument mit >> der Zeitersparnis greife ich weiter unten auf). Das ist sicherlich >> kein >> tragfähiges Konzept und sollte nicht künstlich am Leben gehalten >> werden. Vor Wenn mein FLI 3 min. und mehr braucht für einen Neustart, aber vielleicht nur wenige sekunden um alle Dienste neu zu starten (serverdienste gehören ja eh per Design nicht auf den router) dann finde ich das alles andere als irrelevant. Da nun auch der Trend zu VOIP geht wären das immer noch fast 3min der nicht -Erreichbarkeit gegenüber X sekunden als Beispiel. Und es hört ja nicht auf, Internet scheint immer wichtiger zu werden, man denke nur an IPTV u. was noch alles kommt. Dinge die man eben nicht gern unterbrechen will.... ohne gleich von Sucht zu reden. Nicht an jedem FLI hängt nur ein Nutzer! Wäre es so, bräuchte man keinen Router, nur ein DSL-Modem! >> Prüfungen >> und Aktionen mkfli4l so macht, um die Installationsarchive zu bauen. Installations-archive klingt hochtrabend wenn es nur eine winzige Änderung z.b. an der hostliste gibt. Warum muss deshalb gleich das ganze Archiv neu übertragen und auf dem FLI ausgepackt werden (was dann eben den Reboot nach sich zieht)? Ich sehe da keinen wirklichen technischen Grund. >> Dieses >> Wissen ist sicherlich "advanced" und nicht einem "normalen" Nutzer >> zuzumuten. Eben, ich bin ja nur ein normaler. Kann man das einfacher vermitteln warum obiges nicht gehen sollte? > fli4l-Nutzer ans Herz legen sollte. Aber es ist für erfahrenere Nutzer > eine Möglichkeit, (noch) fehlende Funktionalität auf einfache Weise zu > ersetzen. Ich verwende fli4l seit der Version 2.0.4 (ca. 2002) - mit ein Und ich verwendete ihn seit 1.6.x. DA gab es sogar mal ein Windows-GUI Programm das die parameter-eingabe und Erstellung der routerdisks bot. Eine eingebaute Hilfe zu den Optionen war M.W. zumindest "angedacht". Jedenfalls gab es IMHO direkt bei Änderung eine Warnung das sich diese auf anderes auswirkt und beim deaktivieren verschwand dann auch der zugehörige Block an werten. Das war praktisch.Eindeutig für den Normalen User leichter verständlich und einfacher. Aber: Gibt es nicht mehr! Stattdessen blafft mir mkfli seine Fehlermeldungen vor, und wenn ich das Fenster schließe sind die infos weg. Also darf ich es nicht zu machen, sondern muss gleich nach den monierten werten in den config-dateien suchen und es erneut probieren. Bestenfalls unpraktisch, meine ich. Oder schreibt der die irgendwo in ein log? >> Eine Verknüpfung von WebGUI und Persistenz (und ein Rückkanal zu >> der >> Konfiguration auf dem Build-Host) wäre eine feine Sache. Leider >> sind hier >> viele Fragen zu klären, viele Probleme zu wälzen und natürlich >> geeignete >> technische Lösungen zu entwickeln. Nicht unmöglich, aber sicher >> nichts für >> "so mal nebenbei". Sicher nicht einfach. Ich stelle mir das mal so vor: imonc kommuniziert eh mit dem FLI. Und dort hab ich den pfad zu den configs eingetragen. Wenn jetzt eine datei auf dem router geändert würde (bietet das dateisystem dafür nicht einen event-support an?) dann braucht imond die config nur an imonc zurück übertragen. Klingt für mich "relativ" einfach, aber ich könnte es nat. nicht. Ich finde auch nicht das so was Priorität bräuchte. Mir wäre lieber ein schnelles übertragen der konfig-dateien und eine übernahme ohne reboot. > Um es auf den Punkt zu bringen: um die Funktionalität zu erweitern, ist > (in der Regel) tatsächlich ein neuer Build, Upload und Reboot nötig. > Wenn es aber nur um - sagen wir einmal: Konfigurations*daten* geht, ist > das doch Overkill und bringt ernsthafte Einschränkungen beim Zeitpunkt, > an dem eine Änderung durchgeführt und/oder zur Geschwindigkeit, mit > dem sie wirksam werden kann, mit sich. > > Außerdem: wegen eines zusätzlichen Host-Eintrags neu zu booten, ist > nicht einmal mehr unter Windows notwendig. Und hier ist Linux. Wo bleibt > da meine schöne Uptime? Gute Erklärung. Das sehe ich genau so. Kay From fli4l at kristov.de Tue Dec 2 08:01:16 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Tue, 02 Dec 2014 08:01:16 +0100 Subject: [fli4l] =?utf-8?q?IPs/Netze_voneinander_trennen___Fragen_=C3=BCbe?= =?utf-8?q?r_Fragen?= References: Message-ID: Hallo! Kay Martinen schrieb: > Installations-archive klingt hochtrabend wenn es nur eine winzige > Änderung z.b. an der hostliste gibt. Warum muss deshalb gleich das ganze > Archiv neu übertragen und auf dem FLI ausgepackt werden (was dann eben > den Reboot nach sich zieht)? Ich sehe da keinen wirklichen technischen > Grund. Weil es keine Möglichkeit gibt herauszufinden, welche Skripte auf dem fli4l die Konfiguration an welcher Stelle auslesen. Woher "weißt" du denn, welche Änderungen sich auf welche Komponenten auswirken? Stell dir einfach vor, du änderst OPT_IPV6 von 'no' auf 'yes' (oder umgekehrt). Dies ist eine "winzige Änderung" in der rc.cfg, sie betrifft jedoch so ungefähr fünfzig verschiedene Skripte, hat das Einbinden diverser zusätzlicher Dateien zur Folge und bringt einen Haufen an zusätzlichen Anforderungen an die Konfiguration mit. > Und ich verwendete ihn seit 1.6.x. DA gab es sogar mal ein Windows-GUI > Programm das die parameter-eingabe und Erstellung der routerdisks bot. > Eine eingebaute Hilfe zu den Optionen war M.W. zumindest "angedacht". > Jedenfalls gab es IMHO direkt bei Änderung eine Warnung das sich diese > auf anderes auswirkt und beim deaktivieren verschwand dann auch der > zugehörige Block an werten. Das war praktisch.Eindeutig für den Normalen > User leichter verständlich und einfacher. Aber: Gibt es nicht mehr! Das ist sehr einfach zu beantworten: Vor der 2.0 war die Menge der Konfigurationsoptionen fest. Es gab keine Möglichkeit, den fli4l durch externe Pakete zu erweitern. Wenn man eine feste Menge von Konfigurationsoptionen hat, dann kann man auch sehr einfach eine Konfigurationsanwendung dafür schreiben und auf diese Einstellungen hin optimieren. Wenn man hingegen eine variable (und unterschiedlich getypte) Menge von Konfigurationsoptionen hat, wird das um einiges schwieriger, vor allem dann, wenn es nicht eine endlose Liste von Variablen und Eingabefeldern werden soll. > Stattdessen blafft mir mkfli seine Fehlermeldungen vor, und wenn ich das > Fenster schließe sind die infos weg. Also darf ich es nicht zu machen, > sondern muss gleich nach den monierten werten in den config-dateien > suchen und es erneut probieren. Bestenfalls unpraktisch, meine ich. Oder > schreibt der die irgendwo in ein log? Sicher. > Sicher nicht einfach. Ich stelle mir das mal so vor: imonc kommuniziert > eh mit dem FLI. Schon ein falscher Ansatz. Für dich mag das imonc/imond-Duo das Nonplusultra des fli4l sein, viele jedoch setzen diese Programme gar nicht ein, allein schon deshalb, weil sie gar kein Windows nutzen! Auch dafür muss es Lösungen geben. > Und dort hab ich den pfad zu den configs eingetragen. Zu welchen Konfigurationen? Anwender im semiprofessionellen Umfeld konfigurieren an die 10-50 fli4l-Installationen mit entsprechend vielen Konfigurationen. Wie willst du das mit imonc vernünftig in den Griff bekommen? > Wenn jetzt eine datei auf dem router geändert würde (bietet das > dateisystem dafür nicht einen event-support an?) dann braucht imond die > config nur an imonc zurück übertragen. Klingt für mich "relativ" > einfach, aber ich könnte es nat. nicht. Die Konfiguration ist eine Abstraktion der Situation auf dem Router. Während du in der Konfiguration DOMAIN_NAME='lan', HOST_1_NAME='test' und HOST_1_IP4='1.2.3.4' schreibst, steht auf dem Router 1.2.3.4 test.lan test in der /etc/hosts.d/hosts.dns drin. Das ist nicht automatisiert "zurückzuportieren", es müsste für jedes Paket, jedes OPT und jedes die Konfiguration auslesende Skript Code geben, der diese Rückwärtsumsetzung macht. Abgesehen davon ist nicht jede Änderung auf dem fli4l kompatibel mit der Ausgangskonfiguration, da ich auf dem fli4l alles mögliche machen kann, also auch Dinge wie - 1.2.3.4 test.lan test + 1.2.3.4 test2.lanx test3 was nicht mit Hilfe einer fli4l-Konfiguration erreicht werden kann (wenn die Domäne ".lan" bleibt und es noch andere Einträge mit ".lan" gibt). Gruß, -- Christoph Schulz [fli4l-Team] From fli4l at kristov.de Tue Dec 2 08:16:01 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Tue, 02 Dec 2014 08:16:01 +0100 Subject: [fli4l] =?utf-8?q?IPs/Netze_voneinander_trennen___Fragen_=C3=BCbe?= =?utf-8?q?r_Fragen?= References: Message-ID: Hallo! Hans Bachner schrieb: > Wenn man die Änderung *nur* in der /boot/rc.cfg einträgt, dann ja. > Wenn man aber die von dnsmasq verwendeten Konfigurations-Dateien kennt, > ist das Hinzufügen eines Hosts mit dem Editieren einer, maximal zwei > weiterer Datei(en) und einem anschließenden > > # killall dnsmasq > # dnsmasq --min-port=4096 > > erledigt. (Bitte nicht in die Doku aufnehmen - das war jetzt aus dem > Gedächtnis.) Genau darum geht es mir aber: Woher weißt du, auf welche Teile des Systems sich die Konfigurationsänderungen auswirken? Kannst du mir aus dem Kopf sagen, was alles angepasst werden muss, wenn man OPT_IPV6 von 'no' auf 'yes' setzt? Selbst _ich_, der in den letzten Jahren maßgeblich an der Entwicklung vom ipv6-Paket beteiligt war, könnte dir eine solche Aufzählung nicht liefern! > - weil ich bei einem Reboot nicht nur für mich selbst den > Internet-Zugang unterbreche. Ja, das ist ein valides Argument. Aber auch hier stellt sich dieselbe Frage: Welche Änderungen an der Konfiguration haben Auswirkungen auf die Internet- Anbindung? Das Hinzufügen von ACLs zur WebGUI sicher nicht. Das Ändern der MTU der Netzwerkkarte, über welche die Internet-Anbindung erfolgt, sicherlich. Wie will man diese Abhängigkeiten in den Griff bekommen? Ich habe hier zuhause eine FritzBox laufen. Auch diese bootet bei den meisten Konfigurationsänderungen. Und das in meinen Augen zu Recht -- die Entwickler haben sich entschieden, die funktionale Vorhersagbarkeit wichtiger zu nehmen als eine potentiell erhöhte Benutzerfreundlichkeit (potentiell nur deshalb, weil im Falle einer Fehleinschätzung die Dienste ohne den Reboot eben doch nicht 100%-ig arbeiten, was sich wieder negativ auf die Benutzerlaune auswirken kann). > Um es auf den Punkt zu bringen: um die Funktionalität zu erweitern, ist > (in der Regel) tatsächlich ein neuer Build, Upload und Reboot nötig. > Wenn es aber nur um - sagen wir einmal: Konfigurations*daten* geht, ist > das doch Overkill und bringt ernsthafte Einschränkungen beim Zeitpunkt, > an dem eine Änderung durchgeführt und/oder zur Geschwindigkeit, mit > dem sie wirksam werden kann, mit sich. Sicher. Ich habe das auch im Hinterkopf. Die Umsetzung ist aber immer schwieriger, als man denkt, insbesondere wenn man berücksichtigt, dass das fli4l-Projekt vor 14 Jahren nicht mit dieser Anforderung entworfen wurde. Mit anderen Worten: Die Code-Basis gibt das zur Zeit nicht her. Und es wird ein langer Weg werden, das zu ändern. > Ich meine, die Möglichkeit so eines Eingreifens über die offiziellen > Schnittstellen hinaus ist eine der großen Stärken des fli4l-Projektes. Sorry, da mache ich nicht mit. Ich bin Entwickler und weiß, was es heißt, wenn irgendjemand "über die offiziellen Schnittstellen hinaus" auf ein System zugreift. Wenn keine benötigten Schnittstellen da sind, müssen entsprechend welche geschaffen werden. Punkt. Dass es auch anders geht ist klar, es bleibt jedoch immer eine Frickel-Lösung. Und dass dies eine Stärke des fli4l-Projekts ist, spricht nicht gerade für die API, die von fli4l angeboten wird. Mich erinnert dies an DOS vs. Windows: DOS hat kaum API geboten (außer für den Zugriff aufs Dateisystem), und fast alle Programme haben sich dadrumgemogelt und direkt aufs BIOS oder die Hardware zugegriffen. Dadurch konnten tolle Programme geschrieben werden, die aber nicht vernünftig zusammengearbeitet haben. Dann kam Windows, schob dem direkten BIOS- und Hardware-Zugriff einen Riegel vor, und nun wurden die Programme zwar weniger individuell, dafür aber haben sie i.d.R. problemloser zusammengearbeitet, und Dinge wie Multitasking waren -- verglichen mit DOS- Lösungen -- wirklich zuverlässig. Viele Grüße, -- Christoph Schulz [fli4l-Team] From newsgroup at lan4me.de Tue Dec 2 18:05:15 2014 From: newsgroup at lan4me.de (Peter Schiefer) Date: Tue, 2 Dec 2014 18:05:15 +0100 Subject: [fli4l] =?iso-8859-1?q?Patch_1_f=FCr_fli4l_3=2E6=2E2_verf=FCgbar?= Message-ID: <1waq2mi5bs7ce.dlg@lan4me.de> Hallo, es steht der Patch 1 als Archiv für fli4l 3.6.2 bereit http://www.fli4l.de/download/archiv/stabile-version-36x/362/bugs-und-patches/ it diesem Archiv werden einige bekannt Fehler sowie Sicherheitskorrekturen von Programen die fli4l nutzt korrigiert. Details auf der obigen Webseite, auf der auch ein DIFF verlinkt ist mit den Änderungen im Detail. Gruß Peter [fli4l-Team] Ich bitte um Beachtung des Followup-To: spline.fli4l From f.stroeter at gmx.net Wed Dec 3 19:43:39 2014 From: f.stroeter at gmx.net (Frank Stroeter) Date: Wed, 03 Dec 2014 19:43:39 +0100 Subject: [fli4l] =?utf-8?q?IP_Bereich_f=C3=BCr_Inet_sperren_v3=2E6=2E2?= Message-ID: Hallo Freunde des Fli, ich stehe gerade ein wenig auf dem Schlauch. Ich möchte in der base.txt einem IP Adressbereich den Zugang zum Inet verwehren. Muss ich alle Adressen einzeln eintragen? Kann ich keinen Bereich von bis festlegen? Bisher habe ich nur diese Variante gefunden: PF_FORWARD_1=?192.168.6.12 DROP? Vielen Dank für Eure Antworten Frank From kay at martinen.de Wed Dec 3 19:57:43 2014 From: kay at martinen.de (Kay Martinen) Date: Wed, 03 Dec 2014 19:57:43 +0100 Subject: [fli4l] =?utf-8?q?IP_Bereich_f=C3=BCr_Inet_sperren_v3=2E6=2E2?= In-Reply-To: References: Message-ID: Am 03.12.2014 um 19:43 schrieb Frank Stroeter: > Ich möchte in der base.txt einem IP Adressbereich den Zugang zum Inet > verwehren. Da gibt es m.w. ein OPT für mit dem du solche Sperren auch machen kannst. Kay From volleskorn at vollbio.de Wed Dec 3 20:13:43 2014 From: volleskorn at vollbio.de (Harvey) Date: Wed, 03 Dec 2014 20:13:43 +0100 Subject: [fli4l] =?utf-8?q?IP_Bereich_f=C3=BCr_Inet_sperren_v3=2E6=2E2?= In-Reply-To: References: Message-ID: Frank, > ich stehe gerade ein wenig auf dem Schlauch. Ich möchte in der > base.txt einem IP Adressbereich den Zugang zum Inet verwehren. > Muss ich alle Adressen einzeln eintragen? Kann ich keinen Bereich > von bis festlegen? Sieh dir mal Opt_OAC aus dem Http-Paket an, das macht evtl. was Du willst. Harvey From news.uwe at section-9.de Wed Dec 3 20:18:58 2014 From: news.uwe at section-9.de (Uwe Zeppei) Date: Wed, 03 Dec 2014 20:18:58 +0100 Subject: [fli4l] =?utf-8?q?IP_Bereich_f=C3=BCr_Inet_sperren_v3=2E6=2E2?= In-Reply-To: References: Message-ID: Hallo! Am 03.12.2014 um 19:43 schrieb Frank Stroeter: > ich stehe gerade ein wenig auf dem Schlauch. > Ich möchte in der base.txt einem IP Adressbereich den Zugang zum Inet > verwehren. > Muss ich alle Adressen einzeln eintragen? Kann ich keinen Bereich von > bis festlegen? Was hast du denn für ein Netz und welcher Bereich wäre es denn? > Bisher habe ich nur diese Variante gefunden: > PF_FORWARD_1=?192.168.6.12 DROP? Das wäre eine, evtl. (wenn es sich um Hosts handelt) könnte OPT_OAC was für dich sein. -- Viele Grüße Uwe From fli4l at robert.reschpara.de Thu Dec 4 07:45:38 2014 From: fli4l at robert.reschpara.de (Robert Resch) Date: Thu, 04 Dec 2014 07:45:38 +0100 Subject: [fli4l] =?utf-8?q?IP_Bereich_f=C3=BCr_Inet_sperren_v3=2E6=2E2?= In-Reply-To: References: Message-ID: Am 03.12.2014 um 20:13 schrieb Harvey: > Frank, > >> ich stehe gerade ein wenig auf dem Schlauch. Ich möchte in der >> base.txt einem IP Adressbereich den Zugang zum Inet verwehren. >> Muss ich alle Adressen einzeln eintragen? Kann ich keinen Bereich >> von bis festlegen? > > Sieh dir mal Opt_OAC aus dem Http-Paket an, das macht evtl. was Du willst. das ist viel zu flexibel! *sfg* Erfordert allerdings dass die zu sperrenden Hosts in der host-liste eingepflegt wurden - idealerweise incl. MAC. Robert From fli4l at kristov.de Thu Dec 4 07:55:21 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Thu, 04 Dec 2014 07:55:21 +0100 Subject: [fli4l] =?utf-8?q?IP_Bereich_f=C3=BCr_Inet_sperren_v3=2E6=2E2?= References: Message-ID: X-Post & F'up2: s.f.dev Hallo! Robert Resch schrieb: > das ist viel zu flexibel! *sfg* Bis auf... > Erfordert allerdings dass die zu sperrenden Hosts in der host-liste > eingepflegt wurden - idealerweise incl. MAC. ...IPv6. Damit kann man sich leider immer noch an OAC "vorbeimogeln". Ticket für 4.0, anyone? Viele Grüße, -- Christoph Schulz [fli4l-Team] From marcus.hochhuth at web.de Thu Dec 4 17:36:24 2014 From: marcus.hochhuth at web.de (Marcus Hochhuth) Date: Thu, 04 Dec 2014 17:36:24 +0100 Subject: [fli4l] =?windows-1252?q?Patch_1_f=FCr_fli4l_3=2E6=2E2_verf=FCgba?= =?windows-1252?q?r?= In-Reply-To: <1waq2mi5bs7ce.dlg@lan4me.de> References: <1waq2mi5bs7ce.dlg@lan4me.de> Message-ID: <5fd2.54808d89.410a5@obiwan-news.my-fqdn.de> Am 02.12.2014 um 18:05 schrieb Peter Schiefer: > es steht der Patch 1 als Archiv für fli4l 3.6.2 bereit > > http://www.fli4l.de/download/archiv/stabile-version-36x/362/bugs-und-patches/ ich habe den Patch auf 3 fli4l eingesetzt, die über OpenVPN verbunden sind. Bisher keinerlei Probleme. Gruß und Danke Marcus From fli4l at kristov.de Thu Dec 4 20:28:54 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Thu, 04 Dec 2014 20:28:54 +0100 Subject: [fli4l] =?utf-8?q?Patch_1_f=C3=BCr_fli4l_3=2E6=2E2_verf=C3=BCgbar?= References: <1waq2mi5bs7ce.dlg@lan4me.de> <5fd2.54808d89.410a5@obiwan-news.my-fqdn.de> Message-ID: Hallo! Marcus Hochhuth schrieb: >> es steht der Patch 1 als Archiv für fli4l 3.6.2 bereit >> >> http://www.fli4l.de/download/archiv/stabile-version-36x/362/bugs-und-patches/ > > ich habe den Patch auf 3 fli4l eingesetzt, die über OpenVPN verbunden > sind. Bisher keinerlei Probleme. Danke für die Rückmeldung! Viele Grüße, -- Christoph Schulz [fli4l-Team] From artur at kawa.invalid Fri Dec 5 04:10:06 2014 From: artur at kawa.invalid (Artur Kawa) Date: Fri, 5 Dec 2014 04:10:06 +0100 Subject: [fli4l] =?iso-8859-1?q?Patch_1_f=FCr_fli4l_3=2E6=2E2_verf=FCgbar?= In-Reply-To: <1waq2mi5bs7ce.dlg@lan4me.de> References: <1waq2mi5bs7ce.dlg@lan4me.de> Message-ID: "Peter Schiefer" schrieb im Newsbeitrag news:1waq2mi5bs7ce.dlg at lan4me.de... > es steht der Patch 1 als Archiv für fli4l 3.6.2 bereit Hallo Peter, danke für die Info. Ich habe bei meinem Dad noch FLI 3.6.1 laufen. Wolle bei ihm an Weihnachten auf 3.10.0 updaten. Macht das Update auf 3.6.2 Patch 1 überhaupt jetzt noch Sinn, oder kann ich getrost das - auch von mir lange erhoffte - große Weihnachts Update abwarten? Freue mich schon richtig darauf. Habe dann an Weihnachten mal was sinnvolles zu tun, was auch Spaß macht ;-) Grüße Artur From newsgroup at lan4me.de Fri Dec 5 06:08:20 2014 From: newsgroup at lan4me.de (Peter Schiefer) Date: Fri, 5 Dec 2014 06:08:20 +0100 Subject: [fli4l] =?iso-8859-1?q?Patch_1_f=FCr_fli4l_3=2E6=2E2_verf=FCgbar?= References: <1waq2mi5bs7ce.dlg@lan4me.de> Message-ID: <14ss3ns3t4rfz$.dlg@lan4me.de> Hallo Artur, Am Fri, 5 Dec 2014 04:10:06 +0100 schrieb Artur Kawa: > Ich habe bei meinem Dad noch FLI 3.6.1 laufen. Wolle bei > ihm an Weihnachten auf 3.10.0 updaten. das ist eine gute Idee ;) > Macht das Update auf 3.6.2 Patch 1 überhaupt jetzt noch Sinn, > oder kann ich getrost das - auch von mir lange erhoffte - > große Weihnachts Update abwarten? es mach Sinn, wenn Du eines der gepatchten Programme dort einsetzt, als Openvpn, Dyndns oder Wget aus den Tools. > Freue mich schon richtig darauf. Habe dann an Weihnachten > mal was sinnvolles zu tun, was auch Spaß macht ;-) Du könntes auch jeztt schon den Weg 3.10-Wöchentliche-Entwicklerversion gehen - dann ist der Aufwand an Weihnachten nur noch minimal, da sich an den Konfigurationsdatei eigentlich nichts mehr ändern sollte. Gruß Peter From f.stroeter at gmx.net Fri Dec 5 08:11:15 2014 From: f.stroeter at gmx.net (Frank Stroeter) Date: Fri, 05 Dec 2014 08:11:15 +0100 Subject: [fli4l] =?utf-8?q?IP_Bereich_f=C3=BCr_Inet_sperren_v3=2E6=2E2?= In-Reply-To: References: Message-ID: Vielen Dank für Eure Antworten. > Bisher habe ich nur diese Variante gefunden: > PF_FORWARD_1=?192.168.6.12 DROP? Also gibt es in der base.txt keine Möglichkeit einen IP Adressbereich einzutragen? Muß ich dann PF_FORWARD_1=?192.168.6.12 DROP? PF_FORWARD_2=?192.168.6.13 DROP? PF_FORWARD_3=?192.168.6.14 DROP? PF_FORWARD_4=?192.168.6.15 DROP? usw. eintragen? Grüße Frank From fli4l at kristov.de Fri Dec 5 08:46:26 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Fri, 05 Dec 2014 08:46:26 +0100 Subject: [fli4l] =?utf-8?q?IP_Bereich_f=C3=BCr_Inet_sperren_v3=2E6=2E2?= References: Message-ID: Hallo! Frank Stroeter schrieb: > Also gibt es in der base.txt keine Möglichkeit einen IP Adressbereich > einzutragen? Doch, sofern dieser Bereich ein (Sub-)Netz darstellt. > Muß ich dann > PF_FORWARD_1=?192.168.6.12 DROP? > PF_FORWARD_2=?192.168.6.13 DROP? > PF_FORWARD_3=?192.168.6.14 DROP? > PF_FORWARD_4=?192.168.6.15 DROP? > usw. > eintragen? Ja, es sei denn, du platzierst alle betreffenden Rechner in ein eigenes Subnetz. Beispiel: PF_FORWARD_1='192.168.6.8/29 DROP' Dies wird alle Pakete verwerfen, die von Adressen kommen, die nach Löschen der untersten drei Adressbits (32 - 29 = 3) die Adresse 192.168.6.8 ergeben. Dies betrifft also die folgenden acht Adressen: 192.168.6.8, 192.168.6.9, 192.168.6.10, 192.168.6.11, 192.168.6.12, 192.168.6.13, 192.168.6.14, 192.168.6.15 /29 bildet immer Achtergruppen (die untersten drei Bits werden ignoriert und 2^3 = 8), /30 Vierergruppen (die untersten zwei Bits werden ignoriert, und 2^2=3) und /28 Sechzehnergruppen (32 - 28 = 4, 2^4 = 16). Wie du siehst, sind das aber nicht beliebige Bereiche, sondern sie müssen jeweils an einer Vierer-, Achter-, Sechzehnergrenze etc. beginnen. Du kannst also einen Bereich 192.168.6.128-135 gut mit Hilfe eines /29er Netzes erschlagen (Übungsaufgabe: welches Netz ist das?), einen Bereich 192.168.6.129-136 aber nicht, weil der Beginn nicht an einer durch acht teilbaren Adresse liegt. Wenn du eine überschaubare Anzahl von Hosts im Netz hast und diese Namen haben, würde ich eher empfehlen, die Regeln einzeln und mit Namen zu formulieren, also: PF_FORWARD_1='@tv DROP' PF_FORWARD_2='@iphone DROP' ... Alternativ erlaubst du den Rechnern, die "durch" dürfen, via ACCEPT die Paketweiterleitung und sperrst dann pauschal den Rest, also: PF_FORWARD_1='@pc ACCEPT' PF_FORWARD_2='@laptop ACCEPT' PF_FORWARD_3='DROP' Das hat den Vorteil, dass neue Geräte erstmal nicht in andere Netze dürfen, bis du sie explizit freigeschaltet hast. Die letzte Regel kannst du sogar weglassen, wenn du PF_FORWARD_POLICY='DROP' gesetzt hast. Viele Grüße, -- Christoph Schulz [fli4l-Team] From H.Schmitt at schmitt-it.eu Fri Dec 12 15:32:31 2014 From: H.Schmitt at schmitt-it.eu (Holger S.) Date: Fri, 12 Dec 2014 15:32:31 +0100 Subject: [fli4l] Routen Frage Message-ID: Hallo, ich habe einen Unitymedia Kabel Anschluss mit einer FB 6360 und dahinter der FLI4L als Ethernetrouter. Die FB und der FLI4L haben eine feste öffentliche IP. Auf dem FLI4L läuft ein OpenVpn. Von extern ist die Weboberfläche der FB nicht erreichbar. Jetzt möchte ich gerne von extern über die VPN Verbindung auf die Weboberfläche der FB zugreifen. Leider funktioniert das nicht. hier die Konfig aus der base: IP_NET_N='2' IP_NET_1='192.168.6.1/24' IP_NET_1_DEV='eth1' IP_NET_2='1.2.3.4/30' #öffentliche IP von FLI4L ... IP_ROUTE_N='1' IP_ROUTE_1='0.0.0.0/0 1.2.3.3' # Alles über die IP der FB Die OpenVpn Konfig auf dem Server sieht so aus: OPENVPN_1_NAME='NB' OPENVPN_1_LOCAL_PORT='12233' OPENVPN_1_SECRET='NB.secret' # Key-Datei des Clients OPENVPN_1_TYPE='tunnel' OPENVPN_1_REMOTE_VPN_IP='10.0.0.2' # Client-IP-Adresse OPENVPN_1_LOCAL_VPN_IP='10.0.0.1' # Server-IP-Adresse OPENVPN_1_ROUTE_N='0' OPENVPN_1_PF_INPUT_N='1' OPENVPN_1_PF_INPUT_1='ACCEPT' OPENVPN_1_PF_FORWARD_N='1' OPENVPN_1_PF_FORWARD_1='ACCEPT BIDIRECTIONAL' In meiner OpenVpn Konfig auf dem Roadwarrier habe ich folgende Route eingetragen: ... ifconfig 10.0.0.2 10.0.0.1 route 192.168.6.0 255.255.255.0 ... Wo muss ich die Route auf die 1.2.3.3 (FB) eintragen? Gruß Holger From martin.hans at directbox.com Fri Dec 12 16:38:27 2014 From: martin.hans at directbox.com (Martin Hans) Date: Fri, 12 Dec 2014 16:38:27 +0100 Subject: [fli4l] Routen Frage In-Reply-To: References: Message-ID: Servus Holger, > ich habe einen Unitymedia Kabel Anschluss mit einer FB 6360 und dahinter > der FLI4L als Ethernetrouter. Die FB und der FLI4L haben eine feste > öffentliche IP. Auf dem FLI4L läuft ein OpenVpn. Von extern ist die > Weboberfläche der FB nicht erreichbar. > Jetzt möchte ich gerne von extern über die VPN Verbindung auf die > Weboberfläche der FB zugreifen. > Leider funktioniert das nicht. > > ... > > Wo muss ich die Route auf die 1.2.3.3 (FB) eintragen? wenn ich dich richtig verstanden habe, dann musst du die Route auf FB gar nicht eintragen, weil du ei ja mit deinem Standardgateway eh schon eingetragen hast! Dein Problem ist vielmehr, dass die FB nicht weiß, wohin sie dir antworten soll, denn die kennt das 10er Netz nicht, in dem sich ja dein OVPN-Client befindet - du müsstest also auf der FB eine Route eintragen, die in etwa wie folgt aussehen könnte: IP_ROUTE_1='10.0.0.0/30 192.168.6.1' oder so... Dann könnte die FB deine Anfragen auf diesem Weg beantworten und der Fli4l kennt deinen Roadworrier ja :-) Gruß Martin From Gela_N at web.de Sat Dec 13 12:31:23 2014 From: Gela_N at web.de (Angela Neumann) Date: Sat, 13 Dec 2014 12:31:23 +0100 Subject: [fli4l] Banana Pi Router Message-ID: Es geht darum: https://www.reichelt.de/?ARTICLE=150228;SID=14Uc3Mi38AAAIAAB9b72c306b5b24cabf76ec8058ba8acbbba7bb Ist das als Plattform für einen Fli nutzbar? Danke! From kay at martinen.de Sat Dec 13 12:50:44 2014 From: kay at martinen.de (Kay Martinen) Date: Sat, 13 Dec 2014 12:50:44 +0100 Subject: [fli4l] Banana Pi Router In-Reply-To: References: Message-ID: Am 13.12.2014 um 12:31 schrieb Angela Neumann: > Es geht darum: > https://www.reichelt.de/?ARTICLE=150228;SID=14Uc3Mi38AAAIAAB9b72c306b5b24cabf76ec8058ba8acbbba7bb > Ist das als Plattform für einen Fli nutzbar? Da das keine x86 Hardware ist: Nein. Aber vielleicht mal bei anderen Router-Linuxen nach lesen. DD-WRT z.b. es gibt so viele... Kay From SK-Privat at gmx.net Sun Dec 14 00:49:21 2014 From: SK-Privat at gmx.net (Stefan Kuhne) Date: Sun, 14 Dec 2014 00:49:21 +0100 Subject: [fli4l] Banana Pi Router In-Reply-To: References: Message-ID: Am 13.12.2014 um 12:50 schrieb Kay Martinen: Hallo, > Da das keine x86 Hardware ist: Nein. Aber vielleicht mal bei anderen > Router-Linuxen nach lesen. DD-WRT z.b. es gibt so viele... > es gibt aber Versuche einer ARM Unterstützung. Grüße, Stefan Kuhne From lespocky at web.de Sun Dec 14 10:24:03 2014 From: lespocky at web.de (Alexander Dahl) Date: Sun, 14 Dec 2014 10:24:03 +0100 Subject: [fli4l] Banana Pi Router References: Message-ID: Hallo Angela, Angela Neumann schrieb: > Es geht darum: > https://www.reichelt.de/?ARTICLE=150228;SID=14Uc3Mi38AAAIAAB9b72c306b5b24cabf76ec8058ba8acbbba7bb Nice. :-) > Ist das als Plattform für einen Fli nutzbar? Derzeit leider nicht. fli4l unterstützt als Plattform im Moment nur x86 und x86-64. Die Unterstützung für weitere Plattformen wäre grundsätzlich machbar, viele Dinge, die dafür nötig sind, wurden in der Vergangenheit schon vorbereitet bzw. werden für die zwei verschiedenen Plattformen x86 und x86-64 schon genutzt. Allerdings hat sich noch niemand ernsthaft an die Portierung für arm gesetzt. Ich selbst hab ein zwei Mal versucht fli4l auf einem raspberry pi zum Laufen zu bekommen, aber ich werde immer wieder von anderen Projekten abgelenkt. Ich denke das fli4l Team würde sich freuen, wenn da jemand mal reinspringen würde, um das ganze etwas voran zu treiben. ;-) Grüße Alex -- ***** http://blog.antiblau.de/ ***************************** GnuPG-FP: 02C8 A590 7FE5 CA5F 3601 D1D5 8FBA 7744 CC87 10D0 From Ulrich.Hupe at t-online.de Sun Dec 14 15:56:20 2014 From: Ulrich.Hupe at t-online.de (Ulrich Hupe) Date: Sun, 14 Dec 2014 15:56:20 +0100 Subject: [fli4l] Banana Pi Router In-Reply-To: References: Message-ID: Das habe ich auch schon mal ins Auge gefaßt. Habe mich dann allerdings für das APU Board entschieden. Das ist auch ncht sooo vie teurer, aber erheblich leistungsfähiger! Als EIS käme das schon eher in Betracht. Ulrich >> Ist das als Plattform für einen Fli nutzbar? > > Ich selbst hab ein zwei Mal versucht fli4l auf einem raspberry pi zum > Laufen zu bekommen, aber ich werde immer wieder von anderen Projekten > abgelenkt. Ich denke das fli4l Team würde sich freuen, wenn da jemand > mal reinspringen würde, um das ganze etwas voran zu treiben. ;-) From delucks at freenet.de Sun Dec 14 18:26:46 2014 From: delucks at freenet.de (Frank Lucke) Date: Sun, 14 Dec 2014 18:26:46 +0100 Subject: [fli4l] =?utf-8?q?wenn_ich_nicht_geizig_w=C3=A4re_=2E=2E?= Message-ID: dann hätte ich schon einige Leute mit meinen Teilen erschlagen. "Ist doch nur Software"schöner Spruch.Auch mit 3.10 Versuchen ergeben sich ständig nichtnachvollziiehbare Fehlermeldungen. Fehlermeldung Buildprozess mkfli4l.bat mit fileonly opt/dsl.txt:56: cannot access 'files/lib/firmware/isdn/fdslbase.bin' of type 'local file system object' opt/isdn.txt:110: cannot access 'files/lib/firmware/isdn/fdslbase.bin' of type 'local file system object' fli4l 3.10.0-r35134-testing Pakete Komponenten base DSL ISDN AVM ADSL/ISDN Controller V4F dsl WLAN Conceptronic C54Ri hd NIC Realtek RTL8139 D httpd NIC Realtek RTL8139 C isdn wlan kernel 3_17 Konfigs OPT_FRITZDSL='yes' .... FRITZDSL_TYPE='fcdsl' .... OPT_ISDN='yes' .... ISDN_TYPE='104' Kann damit jemand etwas anfangen? From bernd.kuhls at t-online.de Sun Dec 14 18:34:32 2014 From: bernd.kuhls at t-online.de (Bernd Kuhls) Date: Sun, 14 Dec 2014 18:34:32 +0100 Subject: [fli4l] =?utf-8?q?wenn_ich_nicht_geizig_w=C3=A4re_=2E=2E?= References: Message-ID: Frank Lucke wrote in news:m6kh8n$bgu$1 at vm- news.spline.inf.fu-berlin.de: > Kann damit jemand etwas anfangen? Hi, bitte füge noch das Paket "non_gpl/firmware.tar.gz" zu Deiner Paketliste hinzu. Viele Grüße, Bernd From diese-ist at nurfuerspam.de Sun Dec 14 19:13:59 2014 From: diese-ist at nurfuerspam.de (Ralf Zilian) Date: Sun, 14 Dec 2014 19:13:59 +0100 Subject: [fli4l] Banana Pi Router In-Reply-To: References: Message-ID: Ulrich Hupe wrote: > Das habe ich auch schon mal ins Auge gefaßt. > Habe mich dann allerdings für das APU Board entschieden. > Das ist auch ncht sooo vie teurer, aber > erheblich leistungsfähiger! Welches APU-Board wäre das? und wech Ralf -- ERROR: Coffeepot not found - Operator halted. From Gela_N at web.de Sun Dec 14 19:27:15 2014 From: Gela_N at web.de (Angela Neumann) Date: Sun, 14 Dec 2014 19:27:15 +0100 Subject: [fli4l] Banana Pi Router In-Reply-To: References: Message-ID: Ich hab meinen auch seit Jahren auf einem Alix 2c3 laufen. Aber so als reiner Router hinterm Router für WLAN wär der sicher dicke ausreichend. Das war so die Idee, und Fli4l läuft hier seit version 2.x, will nix anderes ;) Am 14.12.2014 15:56, schrieb Ulrich Hupe: > Das habe ich auch schon mal ins Auge gefaßt. > Habe mich dann allerdings für das APU Board entschieden. From delucks at freenet.de Sun Dec 14 19:36:33 2014 From: delucks at freenet.de (Frank Lucke) Date: Sun, 14 Dec 2014 19:36:33 +0100 Subject: [fli4l] =?iso-8859-15?q?wenn_ich_nicht_geizig_w=E4re_=2E=2E?= In-Reply-To: References: Message-ID: > Hi, > > bitte füge noch das Paket "non_gpl/firmware.tar.gz" zu Deiner Paketliste > hinzu. > > Viele Grüße, Bernd erfreutes Hi zurück. Ich hab das Paket einge"flochten";mkfli4l läuft ohne Fehler durch. Perfekt. Noch nicht weiter getestet,aber bisher RiesenDanke. Ich werde berichten. Grüße von der Nordsee Frank From hsieckmann at t-online.de Mon Dec 15 12:38:35 2014 From: hsieckmann at t-online.de (Helmut Sieckmann) Date: Mon, 15 Dec 2014 12:38:35 +0100 Subject: [fli4l] Version 4.0.0-r35619-testing Message-ID: Hallo, ich versuche seit gestern diese Version auf ein APU_1C Board zu installieren. Eswill mir einfach nicht gelingen. Ich lasse die serielle Konsole mitlaufen und erhalte ständig folgende Meldungen: hdboot mounting boot device ... Unable to locate boot volume! Available partitions: major minor #blocks name Could not mount boot volume, check partitions and drivers! BusyBox v1.22.1 (fli4l) built-in shell (ash) Enter 'help' for a list of built-in commands. /bin/sh: can't access tty; job control turned off An dieser Stelle bricht der Bootprozess ab. Allerdings schreibt er vorher: init started: BusyBox v1.22.1 (fli4l) Das ganze läuft auf einer SD Karte, FAT Partition ist 150MB. Eine andere Installation mit Version 3.9.xx auf der selben Karte bootet einwandfrei. Da ich schon graue Haare habe, muß ich mal um Unterstützung bitten. Zusätzlich habe ich noch Fragen zum Netzwerkkartentreiber und Festplattentreiber. Version 3.9.xx läuft mit Realtek "r8169" und HD "pata-amd". Ist das bei der4.0.0 auch noch so? Da ich schon graue Haare habe, muß ich mal um Unterstützung bitten. P.S. Version 4 ist ja ganz schön schwierig... Gruß Helmut From fli4l at kristov.de Mon Dec 15 12:58:28 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Mon, 15 Dec 2014 12:58:28 +0100 Subject: [fli4l] Version 4.0.0-r35619-testing References: Message-ID: Hallo! Helmut Sieckmann schrieb: > Eine andere Installation mit Version 3.9.xx auf der selben Karte > bootet einwandfrei. Um dein Problem nachstellen zu können, brauchen wir die _genaue_ Version. "xx" hilft leider überhaupt nicht weiter. > P.S. Version 4 ist ja ganz schön schwierig... Inwiefern? Im hd-Paket hat sich nichts Fundamentales geändert (ja, wirklich nicht). Funktioniert denn der aktuelle 3.10-Tarball problemlos? Viele Grüße, -- Christoph Schulz [fli4l-Team] From hsieckmann at t-online.de Mon Dec 15 13:50:18 2014 From: hsieckmann at t-online.de (Helmut Sieckmann) Date: Mon, 15 Dec 2014 13:50:18 +0100 Subject: [fli4l] Version 4.0.0-r35619-testing In-Reply-To: References: Message-ID: Am 15.12.2014 um 12:58 schrieb Christoph Schulz: > Hallo! > > Helmut Sieckmann schrieb: > >> Eine andere Installation mit Version 3.9.xx auf der selben Karte >> bootet einwandfrei. > > Um dein Problem nachstellen zu können, brauchen wir die _genaue_ Version. > "xx" hilft leider überhaupt nicht weiter. Die genaue Version, die ich gerade probiere steht im Betreff: 4.0.0-r35619-testing die 3.9.xx ist z.Zt 3.9.0-r30602-testing...läuft seit April auf APU_1C > >> P.S. Version 4 ist ja ganz schön schwierig... > > Inwiefern? Im hd-Paket hat sich nichts Fundamentales geändert (ja, wirklich > nicht). Funktioniert denn der aktuelle 3.10-Tarball problemlos? > > nicht das Paket hd, sondern der ganze DSL, ppp, pppoe Kram... Da durchzublicken ist jetzt schwierig geworden... :-( Bisher war es meistens nicht unbedingt erforderlich die Manuals zu lesen, oder nur bestimmte Abschnitte. Das ist jetzt Vergangenheit, und klare ist es dann auch nicht sofort. Ich benutze fli4l seit Version 2.0.xx Gruß From fli4l at kristov.de Mon Dec 15 14:25:56 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Mon, 15 Dec 2014 14:25:56 +0100 Subject: [fli4l] Version 4.0.0-r35619-testing References: Message-ID: Hallo! Helmut Sieckmann schrieb: > Die genaue Version, die ich gerade probiere steht im Betreff: > 4.0.0-r35619-testing > > die 3.9.xx ist z.Zt 3.9.0-r30602-testing...läuft seit April auf APU_1C ^^^^^^^^^^^^^^^^^^^^ Die wollte ich wissen, danke. >> >>> P.S. Version 4 ist ja ganz schön schwierig... >> >> Inwiefern? Im hd-Paket hat sich nichts Fundamentales geändert (ja, >> wirklich nicht). Funktioniert denn der aktuelle 3.10-Tarball problemlos? >> >> > nicht das Paket hd, sondern der ganze DSL, ppp, pppoe Kram... > Da durchzublicken ist jetzt schwierig geworden... :-( Das ist allein der Tatsache geschuldet, dass wir weiterhin einen modularen Aufbau für gut befinden. Deshalb ist jetzt das Gemeinsame (PPP) in ein eigenes Paket gelandet. Ein DSL-/ISDN-/UMTS-/...-Nutzer braucht jetzt also zwei Pakete (ppp + pppoe/isdn/umts/...) statt vorher nur eines. Ansonsten hat es lediglich Umbenennungen und Verschiebungen gegeben, um der Tatsache gerecht zu werden, dass man PPPoE oder PPTP nicht allein am DSL-Anschluss nutzen kann -- das Paket also "dsl" zu nennen ist nicht sinnvoll. > Bisher war es meistens nicht unbedingt erforderlich die Manuals zu > lesen, oder nur bestimmte Abschnitte. > Das ist jetzt Vergangenheit, und klare ist es dann auch nicht sofort. Die Dokumentation ist bei der 4.0 an vielen Stellen noch nicht fertig (z.B. was IPv6 betrifft), das ist bekannt. Aber gerade der PPP-Kram ist eigentlich IMHO gut dokumentiert. Kannst du bitte den Finger auf die Stellen legen, an denen der Text noch nicht gut formuliert ist? Viele Grüße, -- Christoph Schulz [fli4l-Team] From delucks at freenet.de Mon Dec 15 19:23:22 2014 From: delucks at freenet.de (Frank Lucke) Date: Mon, 15 Dec 2014 19:23:22 +0100 Subject: [fli4l] =?utf-8?q?n=C3=A4chste_Frage___Zusammenhang_von_Netzname_?= =?utf-8?q?und_Variablenname?= Message-ID: Moin Moin Um meine WLan-Angelegenheit ( ich nenne das mal so )"greifbar" zu machen habe ich die MAC-Adresse der zugehörigen Steckkarte eingegben. Dafür habe ich die Vorgabe WLAN_1 benutzt.Das entsprechende IP_Netz ist auch benannt. WLAN_N='1' WLAN_1_MAC='00:11:22:33:44:55' andere gibts ja nicht IP_NET_3=192.168.77.1/24' IP_NET_3_DEV='wlan0' 0 weil das erste Device dieser Art Buildprozess und Übertragung auf den Router sind Okay. DassBooten erzeugt aber folgende Fehler : (/etc/rc/rc130.wlan) WARN: Unknown addrss 00:11:22:33:44:55, using WLAN_1 * as default configuration for device wlan0 (/etc/rc/rc130.wlan) WARN: Change your Config_x_MAC='00:11:22:33:44:55' for device wlan0 Damit weiß ich nichts anzufangen.Ich habe nur WLAN_1 oder soll da tatsächlich x hingeschrieben werden oder muss wlan0 zu wlan1 weerden? Wo klemmt die Sache? (Die Zahlen und Buchstaben der MAC sind Beispiele) From fli4l at kristov.de Mon Dec 15 19:51:49 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Mon, 15 Dec 2014 19:51:49 +0100 Subject: [fli4l] =?utf-8?q?n=C3=A4chste_Frage___Zusammenhang_von_Netzname_?= =?utf-8?q?und_Variablenname?= References: Message-ID: Hallo! Frank Lucke schrieb: > Moin Moin Bitte _immer_ (d.h. in jeder E-Mail, die einen neuen Thread startet) die jeweils getestete Version angeben, am besten bereits im Betreff. Wir haben keine Lust, anhand des Namens des Threaderstellers in vorigen Threads zu wühlen... > WLAN_1_MAC='00:11:22:33:44:55' andere gibts ja nicht Besitzt die eigentliche MAC-Adresse Buchstaben? > [...] > DassBooten erzeugt aber folgende Fehler : > > (/etc/rc/rc130.wlan) WARN: Unknown addrss 00:11:22:33:44:55, using > WLAN_1 * as default configuration for device wlan0 Bitte die Meldungen _genau_ angeben, am besten einfach via Copy&Paste. Die obige Meldung existiert nämlich in den Quellen nicht, vermutlich meinst du: Unknown mac address [...], using WLAN_1_* as default configuration for device wlan0 > (/etc/rc/rc130.wlan) WARN: Change your Config_x_MAC='00:11:22:33:44:55' > for device wlan0 > > Damit weiß ich nichts anzufangen.Ich habe nur WLAN_1 oder soll da > tatsächlich x hingeschrieben werden oder muss wlan0 zu wlan1 weerden? > Wo klemmt die Sache? > (Die Zahlen und Buchstaben der MAC sind Beispiele) Mach mal auf deinem fli4l: ls /var/run/wlan_*.conf Die Dateien, die dort liegen, sehen so aus: wlan_.conf Diese MAC-Adresse muss in WLAN_1_MAC eingetragen werden. Für mich sieht es so aus, als ob die MAC-Adresse nicht richtig ist. Das kann an einem einfachen Vertipper liegen, vielleicht aber auch an einem Bug im Code. Um das eine oder andere auszuschließen, brauchen wir die obige Information (also welche wlan_*.conf-Dateien in /var/run sind). Viele Grüße, -- Christoph Schulz [fli4l-Team] From hsieckmann at t-online.de Mon Dec 15 20:05:03 2014 From: hsieckmann at t-online.de (Helmut Sieckmann) Date: Mon, 15 Dec 2014 20:05:03 +0100 Subject: [fli4l] Version 4.0.0-r35619-testing In-Reply-To: References: Message-ID: Am 15.12.2014 um 14:25 schrieb Christoph Schulz: > Hallo! > > Helmut Sieckmann schrieb: > > > Das ist allein der Tatsache geschuldet, dass wir weiterhin einen modularen > Aufbau für gut befinden. Deshalb ist jetzt das Gemeinsame (PPP) in ein > eigenes Paket gelandet. Ein DSL-/ISDN-/UMTS-/...-Nutzer braucht jetzt also > zwei Pakete (ppp + pppoe/isdn/umts/...) statt vorher nur eines. Ansonsten > hat es lediglich Umbenennungen und Verschiebungen gegeben, um der Tatsache > gerecht zu werden, dass man PPPoE oder PPTP nicht allein am DSL-Anschluss > nutzen kann -- das Paket also "dsl" zu nennen ist nicht sinnvoll. > ok > > Die Dokumentation ist bei der 4.0 an vielen Stellen noch nicht fertig (z.B. > was IPv6 betrifft), das ist bekannt. Aber gerade der PPP-Kram ist eigentlich > IMHO gut dokumentiert. Kannst du bitte den Finger auf die Stellen legen, an > denen der Text noch nicht gut formuliert ist? > > Das werde ich mal die Tage machen; aber leider ist auf mein erstes posting nur zum Teil eingegangen worden. Warum bootet der fli4l nicht?; siehe Fehlermeldung im 1. Posting. Welche Treiber für das APU Board? Gruß Helmut From fli4l at kristov.de Mon Dec 15 20:39:26 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Mon, 15 Dec 2014 20:39:26 +0100 Subject: [fli4l] Version 4.0.0-r35619-testing References: Message-ID: Hallo! Helmut Sieckmann schrieb: > Das werde ich mal die Tage machen; aber leider ist auf mein erstes > posting nur zum Teil eingegangen worden. > Warum bootet der fli4l nicht?; siehe Fehlermeldung im 1. Posting. Ich kann nur auf die Dinge eingehen, bei denen ich mich auskenne... Ich weiß nicht, warum dein System nicht bootet, ich nutze kein APU oder sonst ein eingebettetes System. Wir haben allerdings hier einige APU-Nutzer in der NG; ich hoffe, dass jemand von ihnen dir noch antwortet. Viele Grüße, -- Christoph Schulz [fli4l-Team] From martin.hans at directbox.com Tue Dec 16 08:40:10 2014 From: martin.hans at directbox.com (Martin Hans) Date: Tue, 16 Dec 2014 08:40:10 +0100 Subject: [fli4l] Portabhaengiges Routing Message-ID: Servus zusammen, folgende Situation: Zwei Standorte - jeweils an jedem Standort zwei Fli4l 3.6.2 an einer eigenen A-DSL-, S-DSL- bzw, CompanyConnect-Leitung. Netze am einen Standort: 192.168.13.x sowie 16.x am anderen Standort: 192.168.2.x, 3.x sowie 4.x ...wobei die Fli4l die Netze nur über einen Windows-Server erreichen, sich gegenseitig allerdings sehen. Über zwei Router läuft via OpenVPN die Standortvernetzung. Über die anderen beiden Router ist zusätzlich eine OpenVPN-Verbdindung aufgebaut, über die im Moment aber keine Daten laufen. Aufgabe: Weil die eine VPN-Verbindung in bestimmten Situationen voll ausgelastet ist und damit RDP-Sitzungen sehr zäh werden, würde ich alle RDP-Sitzungen gerne über den zweiten Tunnel routen. Ansatz: Da der RDP-Dienst üblicherweise über dern Port 3389 bereitgestellt wird, würde ich den gesamten Traffic portabhängig auf den zweiten Router umleiten. Mein Denkansatz führt mich zu einem Eintrag, der in etwa wie folgt aussehen könnte: PF_FORWARD_x=?tmpl:rdp ... Aber egal ob DNAT oder anderes - irgendwie wird ja immer die Zieladresse geändert... Oder habe ich einen Denkfehler und sollte ganz anders vorgehen? Für jeden Hinweis dankbar :-) Gruß Martin From fli4l at kristov.de Tue Dec 16 08:47:45 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Tue, 16 Dec 2014 08:47:45 +0100 Subject: [fli4l] Portabhaengiges Routing References: Message-ID: Hallo! Martin Hans schrieb: > Aufgabe: > > Weil die eine VPN-Verbindung in bestimmten Situationen voll ausgelastet > ist und damit RDP-Sitzungen sehr zäh werden, würde ich alle > RDP-Sitzungen gerne über den zweiten Tunnel routen. > > Ansatz: > Da der RDP-Dienst üblicherweise über dern Port 3389 bereitgestellt wird, > würde ich den gesamten Traffic portabhängig auf den zweiten Router > umleiten. D.h. du änderst bei Paketen, die an den Port 3389 gehen, deren Zieladresse auf die Adresse des zweiten Routers, aber der Port bleibt derselbe. Richtig? > Aber egal ob DNAT oder anderes - irgendwie wird ja immer die Zieladresse > geändert... Das willst du doch auch?!? > > Oder habe ich einen Denkfehler und sollte ganz anders vorgehen? Ich weiß nicht, ob ein Denkfehler vorliegt, aber mir erschließt sich jedenfalls dein Problem nicht ;-) Viele Grüße, -- Christoph Schulz [fli4l-Team] From fli4l at kristov.de Tue Dec 16 09:52:53 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Tue, 16 Dec 2014 09:52:53 +0100 Subject: [fli4l] Fax Empfang fli4l-3.10.0-r34866-testing References: Message-ID: Hallo! Frank Stroeter schrieb: > Ich habe bei der Gelegenheit etwas anderes festgestellt. > > Wenn ich von einem Telefon das Fax auf dem Fli anrufe wird im > Faxverzeichnis eine Datei mit der Kennung und einer Größe von 0 Byte > erstellt. Diese findet sich aber nicht in der mfax.log wieder. > Kann also auch nicht gelöscht werden. > Hat das einen Sinn, oder füllt es nur das Faxverzeichnis? > (Dieses Verhalten kann ich auch bei der V3.6.1 feststellen). Kannst du bitte dafür in unserem Bugtracker auf http://bugs.fli4l.de/ ein Ticket anlegen? Komponente "faxrcv", Vorgangstyp "Bug", Priorität "unwesentlich" o.ä. Danke und Gruß, -- Christoph Schulz [fli4l-Team] From fli4l at kristov.de Tue Dec 16 09:57:23 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Tue, 16 Dec 2014 09:57:23 +0100 Subject: [fli4l] =?utf-8?q?IPs/Netze_voneinander_trennen___Fragen_?= =?utf-8?q?=EF=BF=BDber_Fragen?= References: <45e67ahqj9ebdhppljkh49h326rgikd956@4ax.com> Message-ID: Hallo! Michael Wieser schrieb: >>Vielleicht baue ich demnächst Code ein, der zur Bootzeit die Dateien gegen >>diese Prüfsummen vergleicht und bei Unstimmigkeiten den Boot-Vorgang >>anhält, damit es nicht zu größeren Problemen kommt. >> > > Bitte! Wenn`s einfach geht und nicht zuviel Aufwand bedeutet. Kannst du hierfür ein Ticket in unserem Bugtracker (http://bugs.fli4l.de/) anlegen? Zumindest als Option finde ich auch, dass eine solche Prüfung eine gute Idee ist. Komponente "base", Vorgangstyp "Neue Funktion", Priorität "unwesentlich" o.ä. Danke und Gruß, -- Christoph Schulz [fli4l-Team] From martin.hans at directbox.com Tue Dec 16 10:00:03 2014 From: martin.hans at directbox.com (Martin Hans) Date: Tue, 16 Dec 2014 10:00:03 +0100 Subject: [fli4l] Portabhaengiges Routing In-Reply-To: References: Message-ID: Servus Christoph, > > D.h. du änderst bei Paketen, die an den Port 3389 gehen, deren Zieladresse > auf die Adresse des zweiten Routers, aber der Port bleibt derselbe. Richtig? Richtig - wobei das ja ein Problem ist, denn Ziel sollte ja nach wie vor der Zilserver sein, also einer von mehreren Terminalserver am anderen Standort - und nicht der zweite Router - der soll ja nur als zusätzliches Gateway dienen. >> Aber egal ob DNAT oder anderes - irgendwie wird ja immer die Zieladresse >> geändert... > > Das willst du doch auch?!? Nein, wenn es anders geht, dann nicht :-) Bin noch dabei, mal eine Skizze zu "bauen" - wird aber erst später fertig. Martin From fli4l at kristov.de Tue Dec 16 10:59:50 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Tue, 16 Dec 2014 10:59:50 +0100 Subject: [fli4l] Portabhaengiges Routing References: Message-ID: Hallo! Martin Hans schrieb: >> D.h. du änderst bei Paketen, die an den Port 3389 gehen, deren >> Zieladresse auf die Adresse des zweiten Routers, aber der Port bleibt >> derselbe. Richtig? > > Richtig - wobei das ja ein Problem ist, denn Ziel sollte ja nach wie vor > der Zilserver sein, also einer von mehreren Terminalserver am anderen > Standort - und nicht der zweite Router - der soll ja nur als > zusätzliches Gateway dienen. Ah, jetzt verstehe ich dich erst. Der erste Router soll _zwei_ _verschiedene_ Routen zum _ein- und demselben_ Server kennen. Du solltest mal deine momentane Routing-Konfiguration hier publizieren. Also: Welcher Router routet welche Netze über welche Schnittstellen bzw. welche Gateways. Das würde immens weiterhelfen. Ansonsten kann der fli4l Policy-Based-Routing noch nicht out-of-the-box. Das muss man also manuell aktivieren, etwa über ein eigenes Skript und OPT_USERCMD. Viele Grüße, -- Christoph Schulz [fli4l-Team] From Ulrich.Hupe at t-online.de Tue Dec 16 12:46:34 2014 From: Ulrich.Hupe at t-online.de (Ulrich Hupe) Date: Tue, 16 Dec 2014 12:46:34 +0100 Subject: [fli4l] Banana Pi Router In-Reply-To: References: Message-ID: Hallo Ralf, Ich verwende 1D4 Ulrich Am 14.12.2014 19:13, schrieb Ralf Zilian: > > Welches APU-Board wäre das? > > und wech > Ralf > From delucks at freenet.de Tue Dec 16 14:01:18 2014 From: delucks at freenet.de (Frank Lucke) Date: Tue, 16 Dec 2014 14:01:18 +0100 Subject: [fli4l] Entwicklerversion 3.10.0-r35134-testing In-Reply-To: References: Message-ID: Am 15.12.2014 um 19:51 schrieb Christoph Schulz: > Bitte _immer_ (d.h. in jeder E-Mail, die einen neuen Thread startet) die > jeweils getestete Version angeben, am besten bereits im Betreff. Verstanden.Den Tadel nehme ich an. > Bitte die Meldungen _genau_ angeben, am besten einfach via Copy&Paste. Die > obige Meldung existiert nämlich in den Quellen nicht, vermutlich meinst du: > > Unknown mac address [...], using WLAN_1_* as default configuration for > device wlan0 mac ist richtig ; von mir falsch abgeschrieben Schonmal vorher die Info: Die MAC in /config/wlan.txt ist dieselbe welche auf der Karte aufgedruckt ist.Auch wird sie richtig in der Fehlermeldung benutzt Ich gebe mal die Echte an (ein Paar ist falsch) 00:79:5A:32:D2:C2 > Mach mal auf deinem fli4l: > > ls /var/run/wlan_*.conf > /var/run/wlan_00:79:5A:32:D2:C2_idx.conf /var/run/wlan_11:22:33:44:55:66.conf /var/run/wlan_11:22:33:44:55:66_idx.conf /var/run/wlan_default.conf /var/run/wlan0.conf /var/run/wlan0_idx.conf /var/run/wlan_00:79:5A:32:D2:C2.conf scheint zu fehlen. /var/run/wlan_00:79:5A:32:D2:C2_idx.conf > Diese MAC-Adresse muss in WLAN_1_MAC eingetragen werden. Das ist sie.Fehler noch vorhanden 2te Frage seit Übergang zu 3.10 ist die IMONC-Verbindung weg (mit httpd ist der Router ansprechbar),wahrscheinlich hab ich bei den Configs was Übersehen.Was ist dafür mindestens notwendig ? > > Viele Grüße, mal sehen Frank From fli4l at kristov.de Tue Dec 16 14:25:28 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Tue, 16 Dec 2014 14:25:28 +0100 Subject: [fli4l] Entwicklerversion 3.10.0-r35134-testing References: Message-ID: Hallo! Frank Lucke schrieb: > Schonmal vorher die Info: > Die MAC in /config/wlan.txt ist dieselbe welche auf der Karte > aufgedruckt ist.Auch wird sie richtig in der Fehlermeldung benutzt > Ich gebe mal die Echte an (ein Paar ist falsch) 00:79:5A:32:D2:C2 > >> Mach mal auf deinem fli4l: >> >> ls /var/run/wlan_*.conf >> > /var/run/wlan_00:79:5A:32:D2:C2_idx.conf > /var/run/wlan_11:22:33:44:55:66.conf > /var/run/wlan_11:22:33:44:55:66_idx.conf Ähm, woher kommt diese MAC-Adresse (11:22:33:44:55:66)?? Hast du _wirklich_ eine Karte mit dieser MAC-Adresse? >> Diese MAC-Adresse muss in WLAN_1_MAC eingetragen werden. > > Das ist sie.Fehler noch vorhanden Ich verstehe nicht, warum du eine wlan_11:22:33:44:55:66.conf hast. Bist du sicher, _nirgendwo_ in deiner Konfiguration diese MAC-Adresse benutzt zu haben? > > 2te Frage > seit Übergang zu 3.10 ist die IMONC-Verbindung weg (mit httpd ist der > Router ansprechbar),wahrscheinlich hab ich bei den Configs was > Übersehen.Was ist dafür mindestens notwendig ? START_IMOND='yes' Was heißt "die IMONC-Verbindung ist weg"? Dein Client ist ein Windows- System, du nutzt den grafischen winimonc-Client, und beim Starten des Programms kommt... was für eine Meldung? >> Viele Grüße, > mal sehen Dann kriegst du halt nur noch einen Gruß, -- Christoph Schulz [fli4l-Team] From martin.hans at directbox.com Tue Dec 16 15:29:11 2014 From: martin.hans at directbox.com (Martin Hans) Date: Tue, 16 Dec 2014 15:29:11 +0100 Subject: [fli4l] Portabhaengiges Routing In-Reply-To: References: Message-ID: Servus Christoph, > Ah, jetzt verstehe ich dich erst. Der erste Router soll _zwei_ > _verschiedene_ Routen zum _ein- und demselben_ Server kennen. > > Du solltest mal deine momentane Routing-Konfiguration hier publizieren. > Also: Welcher Router routet welche Netze über welche Schnittstellen bzw. > welche Gateways. Das würde immens weiterhelfen. OK - versuche mich als erstes mal mit ASCII-Art: (LAN 1) TS 2 (192.168.13.3) | (192.168.13.2) TS 1 | TS 3 (192.168.13.4) \ | / \ | / \ | / \ | / \ | / (192.168.13.1)\ | / ------- | | | WIN | | | ------- (192.168.16.1)/ \ / \ / \ / \ (192.168.16.2)/ \(192.168.16.3) ------- ------- | | | | | Fli4l |-----| Fli4l | | A | LAN | B | ------- ------- | | | | OpenVPN 1 | | OpenVPN 2 | | | | ------- ------- | | | | | Fli4l |-----| Fli4l | | C | LAN | D | ------- ------- (192.168.2.2)\ /(192.168.2.3) \ / \ / \ / \ / (192.168.2.1)\ / ------- | | | WIN | | | ------- / | \ / | \ / | \ / | \ / | \ (192.168.3.x) Client 1 | Client 3 (192.168.4.x) Client 2 (192.168.1.x) (LAN 2) Bei fester Laufweite der Schrift sollte man erkennen können, wie das Konstrukt aussieht. Routing Fli4l A (IP-Adresse: 192.168.16.2): IP_ROUTE_N='4' IP_ROUTE_1='0.0.0.0/0 62.X.X.X' IP_ROUTE_2='192.168.13.0/24 192.168.16.1' IP_ROUTE_3='192.168.14.0/24 192.168.16.1' IP_ROUTE_4='192.168.15.0/24 192.168.16.1' OPENVPN_1_NAME='01-X-Y' OPENVPN_1_REMOTE_HOST='217.X.X.X' OPENVPN_1_REMOTE_PORT='60003' OPENVPN_1_LOCAL_PORT='50003' OPENVPN_1_SECRET='X.secret' OPENVPN_1_TYPE='tunnel' OPENVPN_1_REMOTE_VPN_IP='10.1.0.3' OPENVPN_1_LOCAL_VPN_IP='10.1.0.1' OPENVPN_1_ROUTE_N='4' OPENVPN_1_ROUTE_1='192.168.2.0/24' OPENVPN_1_ROUTE_2='192.168.3.0/24' OPENVPN_1_ROUTE_3='192.168.4.0/24' OPENVPN_1_ROUTE_4='192.168.1.0/24' Routing Fli4l C (IP-Adresse: 192.168.2.2): IP_ROUTE_N='3' IP_ROUTE_1='192.168.3.0/24 192.168.2.1' IP_ROUTE_2='192.168.4.0/24 192.168.2.1' IP_ROUTE_3='192.168.1.0/24 192.168.2.1' OPENVPN_1_NAME='01-Y-X' OPENVPN_1_REMOTE_HOST='62.X.X.X' OPENVPN_1_REMOTE_PORT='50003' OPENVPN_1_LOCAL_PORT='60003' OPENVPN_1_SECRET='X.secret' OPENVPN_1_TYPE='tunnel' OPENVPN_1_REMOTE_VPN_IP='10.1.0.1' OPENVPN_1_LOCAL_VPN_IP='10.1.0.3' OPENVPN_1_ROUTE_N='3' OPENVPN_1_ROUTE_1='192.168.13.0/24' OPENVPN_1_ROUTE_2='192.168.15.0/24' OPENVPN_1_ROUTE_3='192.168.16.0/24' Fehlen noch Infos? Martin From fli4l at kristov.de Tue Dec 16 16:05:20 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Tue, 16 Dec 2014 16:05:20 +0100 Subject: [fli4l] Portabhaengiges Routing References: Message-ID: Hallo! Martin Hans schrieb: > [...] > Fehlen noch Infos? Theoretisch schon (Router B und D sowie das OpenVPN dazwischen), aber praktisch kann ich mir vorstellen, wie die Konfiguration da aussieht. Ich würde vorschlagen, vier ungenutzte /24er LANs für das Routing zu nutzen: Alle Verbindungen, die über Router A laufen mit Ziel 192.168.x.0/24 (x in (1,2,3,4)) und Zielport 3389 werden z.B. auf das Netz 192.168.110+x.0/24 gemappt; für alle 192.168.110+x.0/24 gibt es dann eine Route zu Router B. Router B macht die Umwandlung rückgängig. Etwa so: Router A: IP_ROUTE_N='8' IP_ROUTE_5='192.168.111.0/24 192.168.16.3' IP_ROUTE_6='192.168.112.0/24 192.168.16.3' IP_ROUTE_7='192.168.113.0/24 192.168.16.3' IP_ROUTE_8='192.168.114.0/24 192.168.16.3' PF_PREROUTING_N='4' PF_PREROUTING_1='tmpl:rdp any 192.168.1.0/24 NETMAP:192.168.111.0/24' PF_PREROUTING_2='tmpl:rdp any 192.168.2.0/24 NETMAP:192.168.112.0/24' PF_PREROUTING_3='tmpl:rdp any 192.168.3.0/24 NETMAP:192.168.113.0/24' PF_PREROUTING_4='tmpl:rdp any 192.168.4.0/24 NETMAP:192.168.114.0/24' Router B: PF_PREROUTING_N='4' PF_PREROUTING_1='tmpl:rdp any 192.168.111.0/24 NETMAP:192.168.1.0/24' PF_PREROUTING_2='tmpl:rdp any 192.168.112.0/24 NETMAP:192.168.2.0/24' PF_PREROUTING_3='tmpl:rdp any 192.168.113.0/24 NETMAP:192.168.3.0/24' PF_PREROUTING_4='tmpl:rdp any 192.168.114.0/24 NETMAP:192.168.4.0/24' Ist ungetestet, sollte aber funktionieren. Du könntest zusätzlich entsprechende if:...-Klauseln ergänzen, um sicherzustellen, dass das Umschreiben der Adressen auch wirklich nur für Pakete gilt, die an den richtigen Schnittstellen bei den Routern A und B ankommen. Theoretisch ist es möglich, ohne das doppelte Adressumschreiben so ein Routing aufzusetzen (mit Hilfe von Firewall-Flags, mehreren Routing-Tabellen und entsprechenden Routing-Regeln). Da fli4l dies aber momentan nicht kann (siehe https://ssl.nettworks.org/bugs/browse/FFL-546), deshalb mein Vorschlag mit einer doppelten Adressumschreibung. Viele Grüße, -- Christoph Schulz [fli4l-Team] From martin.hans at directbox.com Tue Dec 16 16:14:44 2014 From: martin.hans at directbox.com (Martin Hans) Date: Tue, 16 Dec 2014 16:14:44 +0100 Subject: [fli4l] Portabhaengiges Routing In-Reply-To: References: Message-ID: Servus Christoph, > >> [...] >> Fehlen noch Infos? > > Theoretisch schon (Router B und D sowie das OpenVPN dazwischen), aber > praktisch kann ich mir vorstellen, wie die Konfiguration da aussieht. davon ging ich aus und tatsächlich laufen die im Moment ja in der Standardkonfiguration ohne irgendwelche zusätzlichen Routen - sie tun ja noch nichts :-) - was sich aber ändern soll. > Ich würde vorschlagen, vier ungenutzte /24er LANs für das Routing zu nutzen: > Alle Verbindungen, die über Router A laufen mit Ziel 192.168.x.0/24 (x in > (1,2,3,4)) und Zielport 3389 werden z.B. auf das Netz 192.168.110+x.0/24 > gemappt; für alle 192.168.110+x.0/24 gibt es dann eine Route zu Router B. > Router B macht die Umwandlung rückgängig. Etwa so: >... Liest sich schlüssig, aber auch komliziert ;-) Das ist dann mal eine Beschäftigung für die Tage "zwischen den Jahren", wenn das Büro leer ist und ein Routerneustart nicht stört - dann spare ich mir das Aufsetzen einer kompletten Testumgebung, die ja nicht gerade klein wäre :-) Berichte dann, wenn es klappt, oder vermutlich viel eher, wenn ich noch Fragen dazu habe ;-) Danke! Martin From delucks at freenet.de Tue Dec 16 20:34:23 2014 From: delucks at freenet.de (Frank Lucke) Date: Tue, 16 Dec 2014 20:34:23 +0100 Subject: [fli4l] Entwicklerversion 3.10.0-r35134-testing In-Reply-To: References: Message-ID: Danke für die Geduld mit mir ! > Ähm, woher kommt diese MAC-Adresse (11:22:33:44:55:66)?? Hast du _wirklich_ > eine Karte mit dieser MAC-Adresse? > Nein habe ich nicht. Die Werte sind dieselben wie die Beispiele aus den unbearbeiteten Wlan-Paket.Warum die hier auftauchen weiss ich nicht. Kann man die überzähligen Dateien nicht einfach löschen.Andere MACs hab ich nie benutzt. >> 2te Frage > Was heißt "die IMONC-Verbindung ist weg"? Dein Client ist ein Windows- > System, du nutzt den grafischen winimonc-Client, und beim Starten des > Programms kommt... was für eine Meldung? Meine Versuche hatte ich mit 3.6.2 angefangen Da klappte die Verbindung WinRechner zu fli4l immer;seit den 3.10 Übungen gibts keine mehr. Die Meldung ist mir zu lang,sagt etwas von Kritischer Fehler und "Hostname fli4l kann nicht aufgelöst werden" Salve Frank From fli4l at kristov.de Tue Dec 16 20:39:19 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Tue, 16 Dec 2014 20:39:19 +0100 Subject: [fli4l] Entwicklerversion 3.10.0-r35134-testing References: Message-ID: Hallo! Frank Lucke schrieb: >> Ähm, woher kommt diese MAC-Adresse (11:22:33:44:55:66)?? Hast du >> _wirklich_ eine Karte mit dieser MAC-Adresse? >> > Nein habe ich nicht. Die Werte sind dieselben wie die Beispiele aus den > unbearbeiteten Wlan-Paket.Warum die hier auftauchen weiss ich nicht. > Kann man die überzähligen Dateien nicht einfach löschen.Andere MACs hab > ich nie benutzt. Bitte zeig uns die _komplette_ Konfiguration (abzüglich von Passwörtern) des wlan-Pakets. Hier ist eindeutig etwas faul. > >>> 2te Frage >> Was heißt "die IMONC-Verbindung ist weg"? Dein Client ist ein Windows- >> System, du nutzt den grafischen winimonc-Client, und beim Starten des >> Programms kommt... was für eine Meldung? > > Meine Versuche hatte ich mit 3.6.2 angefangen Da klappte die Verbindung > WinRechner zu fli4l immer;seit den 3.10 Übungen gibts keine mehr. > Die Meldung ist mir zu lang,sagt etwas von Kritischer Fehler und > "Hostname fli4l kann nicht aufgelöst werden" Dein fli4l-Router heißt auch wirklich "fli4l" (HOSTNAME='fli4l')? Wenn nein, ist das der Fehler. Wenn ja: Hast du einen DNS-Server installiert (Paket dns_dhcp; OPT_DNS='yes')? Auch hier würde die Komplett-Konfiguration des dns_dhcp-Pakets weiterhelfen. Gruß, -- Christoph Schulz [fli4l-Team] From redhead.kc85 at t-online.de Wed Dec 17 19:22:11 2014 From: redhead.kc85 at t-online.de (Enrico Grämer) Date: Wed, 17 Dec 2014 19:22:11 +0100 Subject: [fli4l] =?utf-8?q?nicht_routender_Ro=3F=3D=3D=3Futf-8=3FQ=3Futer?= Message-ID: Guten Abend, das wäre eigentlich mein Problem gewesen, weswegen ich mich hier im Forum angemeldet hatte. Aber seit ein paar Tagen funktioniert er nun endlich nach 2 wochen grübeln, Doku studieren und suchen. Ungefähr seit 10 Jahren habe ich den Fli4L Version 2.0.8 am Teledat 300 ohne Probleme in Betrieb. Da aber so langsam auf VDSL und dieses (fürchterliche) VoIP umgestellt werden muss, dachte ich, dass es Zeit für was Neuem wird. Die erste Woche habe ich mit Hardware, den Treibern dazu, und dem vorm Rechner vertrödelt. Doku zwar gelesen aber nicht zu 100% verhirnt. Die Netzwerkkarte vom Board (eepro100) geht nur mit dem alten Kernel, USB-Netwerk-Adapter sollen nur mit dem neuen Kernel funktionieren. Merkwürdig war, dass die "Bau-Saftware" beim alten Kernel nicht bei der RTL8150 nach Fehler schreit. Mir ist in den Untiefen des Filesystems aufgefallen, dass beim alten Kernel doch Treiber dafür vorhanden sind....? Nützte aber doch nichts, da RTL8150 doch nicht mit meiner vorhandenen NW-Karte mit RTL8152 kompatibel sind. Ich dachte es ging beim Treiber um "Familie". Ich habe dann also um weiter zu kommen den Futro S200 hergenommen. Der Router ging dann auf Anhieb, er wollte aber nichts routen. Ping vom internen Netz auf den Router ging, IMONC konnte auch alles, aber nichts ging ins Internet. Vom Router aus, konnte ich das interne Netz erreichen, Internet-Adressen (Namen) ebenso. Also geht DNS.... Später kam mir dann die Idee statt den Namen die Adresse selber anzupingen. Geht.... ???? Daraufhin habe ich mit den Filterregeln experimentert, nichts half, muss ja eigentlich gehen. :? Ich habe auch vom neuen auf das alte Verfahren umgestellt. Dazu dann in die config/base.txt die ganzen verlangten Werte eingetragen, bis da alles ohne Fehler durchlief. Allerdings wurde dann unter check/base.txt der Wert pf_input_policy angemeckert. Habs deswegen aufgegeben und weiter gegrübelt, und mich fürs Forum angemeldet ...... :evil: In der base.txt steht ja DNS_FORWARDERS drin. Die Doku sagt dazu: DNS_FORWARDERS Hier ist die DNS-Server-Adresse des Internet-Providers anzugeben, wenn ?i4l als Router in das Internet verwendet wird. Der ?i4l-Router gibt dann sämtliche DNS-Queries,die er nicht selbst beantworten kann,an diese Adresse weiter. Möchte man mehrere DNS-Forwarder angeben,trennt man die IP-Adressen durch Blanks. Es ist auch möglich, optional Port-Nummern an die IP-Adressen durch Doppelpunkt ge- trennt anzugeben. Allerdings muss dann OPT_DNS='yes' (Seite 103) sein (Paket dns_dhcp (Seite 101))und es darf nirgends die Option *_USEPEERDNS benutzt werden. ... heisst für mich, dass ich OPT_DNS nur anschalten muss, wenn mit Ports hantieren will. Sollte es also eigentlich nicht sein. Hab das deswegen auch nicht weiterverfolgt. Geht ja weder mit Win noch Linux. :evil: :evil: Weiter hinten in der Doku zu opt_DNS heisst ja ..... wenn man Zweifel hat.... Also hab ichs dann doch mal probiert. Na, endlich! :lol: From fli4l at kristov.de Wed Dec 17 20:58:21 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Wed, 17 Dec 2014 20:58:21 +0100 Subject: [fli4l] nicht routender Router References: Message-ID: Hallo! Enrico Grämer schrieb: > Die Netzwerkkarte vom Board (eepro100) geht nur mit dem alten Kernel, Wie meinst du das? In der aktuellen fli4l-Version gibt es doch den e100- Treiber. Aus der NIC-Liste (https://ssl.nettworks.org/wiki/display/f/Netzwerkkarten): "pci e100 Intel(R) PRO/100 Network" > USB-Netwerk-Adapter sollen > nur mit dem neuen Kernel funktionieren. Was meinst du mit "alt" und "neu"? 3.14 vs. 3.17? > Merkwürdig war, dass die > "Bau-Saftware" beim alten Kernel nicht > bei der RTL8150 nach Fehler schreit. Mir ist in den Untiefen des > Filesystems aufgefallen, dass beim alten > Kernel doch Treiber dafür vorhanden sind....? > Nützte aber doch nichts, da RTL8150 doch nicht mit meiner vorhandenen > NW-Karte mit RTL8152 kompatibel sind. > Ich dachte es ging beim Treiber um "Familie". Ich verstehe hier dein Problem nicht. Es gibt einen Treiber "rtl8150" sowohl im 3.14- als auch im 3.17-Kernel. Und dieser Treiber funktioniert mit deiner Karte nicht, weder mit 3.14 noch mit 3.17. Warum sollte nun mkfli4l beim Bauen eine Fehlermeldung produzieren? mkfli4l kennt doch nicht deine Hardware! > Vom Router aus, konnte ich das interne Netz erreichen, Internet-Adressen > (Namen) ebenso. > Also geht DNS.... Lokal auf dem Router ja. > Es ist auch möglich, optional Port-Nummern an die IP-Adressen durch > Doppelpunkt ge- > trennt anzugeben. Allerdings muss dann OPT_DNS='yes' (Seite 103) sein > (Paket dns_dhcp > (Seite 101))und es darf nirgends die Option *_USEPEERDNS benutzt > werden. > > > ... heisst für mich, dass ich OPT_DNS nur anschalten muss, wenn mit > Ports hantieren will. Nein. Du brauchst natürlich OPT_DNS='yes', wenn _irgendein Client_ in deinem LAN DNS braucht. Das war natürlich schon immer so (auch bei 2.0.8!), denn wie will dein Windows-Client die lokale /etc/hosts oder /etc/resolv.conf deines Routers kennen? Dazu muss er eine DNS-Abfrage an deinen fli4l schicken, und deshalb braucht es auf deinem fli4l eben einen Server, der diese Anfrage bearbeitet -- eben den DNS-Server. Ich gebe aber zu, dass die Dokumentation an dieser Stelle verbesserungswürdig ist. Viele Grüße, -- Christoph Schulz [fli4l-Team] From fli4l at kristov.de Wed Dec 17 21:56:57 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Wed, 17 Dec 2014 21:56:57 +0100 Subject: [fli4l] =?utf-8?q?/etc/rc=2Ecfg_und_/boot/rc=2Ecfg_=28was=3A_IPs/?= =?utf-8?q?Netze_voneinander_trennen___Fragen_=C3=BCber_Fragen=29?= References: Message-ID: Hallo! Hans Bachner schrieb: >> Insofern hast du Recht, dass die Redundanz (die vermutlich >> historisch >> bedingt ist) natürlich nicht schön ist. Jedoch würde ich deshalb >> irgendwann >> den anderen Weg gehen, nämlich die /boot/rc.cfg wegzulassen und >> die >> Konfiguration nur noch aus /etc/rc.cfg auszulesen. > > Ich würde es genau umgekehrt machen, wenn aus historischen Gründen > eine /etc/rc.cfg erforderlich ist. Es werden beide Dateien gebraucht. Die /boot/rc.cfg steht den Skripten in /etc/boot.d/ ja noch nicht zur Verfügung, weil zu diesem Zeitpunkt das Boot- Volume noch nicht eingehängt ist. Da aber für diesen Fall _irgendeine_ Konfiguration zur Verfügung stehen _muss_, damit die richtigen Treiber geladen werden können und das Boot-Volume eingehängt werden kann, gibt es die Konfiguration auch in /etc/rc.cfg (im RootFS). > >> Mal ehrlich: Das nachträgliche Ändern der Konfiguration in /boot >> ist doch >> Hackaround ohnegleichen. > > Nein - das ist ein Workaround für die (noch) fehlenden > Konfigurationsmöglichkeiten auf dem Router selbst. Mit FFL-1126 habe ich die Sache jetzt auf eine andere Art und Weise gelöst. Siehe Ticket-Beschreibung für Details. Kurze Zusammenfassung: Auf dem fli4l kann man immer auf die /etc/rc.cfg zugreifen, und wenn du die /boot/rc.cfg angepasst haben solltest, schlägt das jetzt auch auf die /etc/rc.cfg durch. Will heißen: Skripte bekommen immer die aktuelle Konfiguration zu sehen, egal ob das Boot-Volume nach dem Booten ausgehängt wird oder nicht. Feedback ist willkommen. Viele Grüße, -- Christoph Schulz [fli4l-Team] From delucks at freenet.de Thu Dec 18 19:26:20 2014 From: delucks at freenet.de (Frank Lucke) Date: Thu, 18 Dec 2014 19:26:20 +0100 Subject: [fli4l] kleines Hurra ! In-Reply-To: References: Message-ID: ein fröhliches Moin Moin Die Wlan-Karte wurde akzeptiert.Das Hauptproblem war die Übertragung vom Win-Rechner zum Router. Meine Arbeitsfestplatte ist eine CF-Karte;deshalb hab ich die Dateien aus dem Build-Ordner auf die CF Kopiert und neu gebootet.Keine Fehlermeldung und ein neues Wlan"feld" ist empfangbar. Soweit das. > Dein fli4l-Router heißt auch wirklich "fli4l" (HOSTNAME='fli4l')? Wenn nein, > ist das der Fehler. Wenn ja: Hast du einen DNS-Server installiert (Paket > dns_dhcp; OPT_DNS='yes')? Auch hier würde die Komplett-Konfiguration des > dns_dhcp-Pakets weiterhelfen. Ja er heißt "fli4l" ,das DNS-Paket ist installiert und eingeschaltett. Es arbeitet aber nicht;Als zusätzlichen Host hab ich eine Fritzbox konfiguriert die auch nicht auf gelöst wird. Ich zeige jetzt mal nur Auszüge. #------------------------------------------------------------------------------ # General settings: #------------------------------------------------------------------------------ HOSTNAME='fli4l' # name of fli4l router PASSWORD='password' # password for root login BOOT_TYPE='hd' # boot device: hd, cd, ls120, integrated, # attached, netboot, pxeboot LIBATA_DMA='disabled' # Use DMA on ATA Drives ('enabled') or no # ('disabled'). The default 'disabled' # allows ancient IDE CF cards to be boot # Use 'enabled' if you boot from a Virtua # virtual device. MOUNT_BOOT='rw' # mount boot device: ro, rw, no BOOTMENU_TIME='5' # waiting time of bootmenu in seconds # before activating normal boot TIME_INFO='MEZ-1MESZ,M3.5.0,M10.5.0/3' # description of local time zone, # don't touch without reading documentat KERNEL_VERSION='3.17.4-nonfree' # kernel version KERNEL_BOOT_OPTION='' # append option to kernel command line COMP_TYPE_OPT='xz' # compression algorithm if compression is # enabled for OPT archive; # NOTE that some boot types may disallow # some compression algorithms IP_CONNTRACK_MAX='' # override maximum limit of connection # tracking entries POWERMANAGEMENT='acpi' # select pm interface: none, acpi, apm, a # apm_rm switches to real mode before in # apm power off #------------------------------------------------------------------------------ # Localisation #------------------------------------------------------------------------------ LOCALE='de' # defines the default language for sever # components, such as httpd #------------------------------------------------------------------------------ # Console settings (serial console, blank time, beep): #------------------------------------------------------------------------------ CONSOLE_BLANK_TIME='' # time in minutes (1-60) to blank # console; '0' = never, '' = system defau BEEP='yes' # enable beep after boot and shutdown SER_CONSOLE='no' # use serial interface instead of or as # additional output device and main input SER_CONSOLE_IF='0' # serial interface to use, 0 for ttyS0 (C SER_CONSOLE_RATE='9600' # baudrate for serial console #------------------------------------------------------------------------------ # Debug Settings: #------------------------------------------------------------------------------ DEBUG_STARTUP='no' # write an execution trace of the boot #------------------------------------------------------------------------------ # Keyboard layout #------------------------------------------------------------------------------ KEYBOARD_LOCALE='auto' # auto: use most common keyboard layout f # the language specified in 'LOCALE' #OPT_MAKEKBL='yes' # set to 'yes' to make a new local keybo # layout map on the fli4l-router #------------------------------------------------------------------------------ # Ethernet card drivers: #------------------------------------------------------------------------------ # # please see file base_nic.list in your config-dir or read the document # # # If you need a dummy device, use 'dummy' as your NET_DRV # and IP_NET_%_DEV='dummy' as your device # #------------------------------------------------------------------------------ NET_DRV_N='2' # number of ethernet drivers to load, usu NET_DRV_1='8139too' # 1st driver: NIC Realtek RT 8129 NET_DRV_1_OPTION='' # 1st driver: 2x vorhanden NET_DRV_2='rt2500pci' # 2nd driver: Wlan Concepttronic C54Ri NET_DRV_2_OPTION='' # 2nd driver: NET_DRV_3='ne' # 3nd driver: name (e.g. NE2000 ISAclone) NET_DRV_3_OPTION='' # 3nd driver: additional optio #------------------------------------------------------------------------------ # Ether networks used with IP protocol: #------------------------------------------------------------------------------ IP_NET_N='3' # number of IP ethernet networks, usuall IP_NET_1='192.168.12.1/24' # IP address of your n'th ethernet card # and IP_NET_1_DEV='eth0' # netmask in CIDR (no. of set bits) # required: device name like ethX IP_NET_2='192.168.22.254/24' # 2. Netz DSL-Modem - Router IP_NET_2_DEV='eth1' # oder 2. wired Netz # IP_NET_3='192.168.32.1/24' # 3. Netz W-Lan!! IP_NET_3_DEV='wlan0' # #------------------------------------------------------------------------------ # Additional routes, optional #------------------------------------------------------------------------------ und #------------------------------------------------------------------------------ # HOSTS #------------------------------------------------------------------------------ # # Do not add an entry for the router! It's added automatically. # If you need an alias please add HOSTNAME_ALIAS_N in the base.txt # HOST_N='1' # number of hosts in your domain # 1st host: HOST_1_NAME='fritzwlan' # name #HOST_1_DOMAIN='foo.lan' # different domain (optional) # as declared in DOMAIN_NAME (base.txt) HOST_1_IP4='192.168.6.5' # IP-Adress #HOST_1_IP6='::ffff:192.168.6.10' # IPv6-Adress / optional HOST_1_ALIAS_N='1' # number of optional alias names HOST_1_ALIAS_1='fritzfon' # 1st optional alias name HOST_1_ALIAS_2='printserver.lan.fli4l' #HOST_1_DHCPTYP='hostname' # set static dhcp-lease via [hostname] # or [mac] #HOST_1_MAC='de:ad:be:ef:08:15' # MAC-Adress - needed for static DHCP or # host based PXE #HOST_1_PXE_FILENAME='pxelinux' # Filename of PXE Netboot-Image #HOST_1_PXE_SERVERNAME='tftp.lan.fli4l' # Name of Netboot-Server - see OPT_TFTP #HOST_1_PXE_SERVERIP='192.168.6.1' # IP-Adress of Netboot-Server #HOST_1_PXE_OPTIONS='' # extra options for PXE-Boot # 2nd host: HOST_2_NAME='client2' HOST_2_IP4='192.168.6.11' #HOST_2_MAC='de:ad:be:ef:08:15' # 3rd host: HOST_3_NAME='client3' HOST_3_IP4='192.168.6.12' #HOST_3_MAC='de:ad:be:ef:08:15' # 4th host: HOST_4_NAME='client4' HOST_4_IP4='192.168.6.13' #HOST_4_MAC='de:ad:be:ef:08:15' #------------------------------------------------------------------------------ # HOST entries (Extra-Host with full FQDN): #------------------------------------------------------------------------------ HOST_EXTRA_N='0' # number of extra hosts HOST_EXTRA_1_NAME='host.foo.bar' # name HOST_EXTRA_1_IP4='10.0.0.1' # IP-Adress (ipv4) HOST_EXTRA_1_IP6='::ffff:10.0.0.1' # IP-Adress (ipv6) / optional #------------------------------------------------------------------------------ # DNS configuration: #------------------------------------------------------------------------------ OPT_DNS='yes' # start dns server: yes or no DNS_BIND_INTERFACES='no' # DON'T bind to all interfaces with 'yes # and listen only to ip addreses listed # in DNS_LISTEN # set to 'no' to bind to ALL ip addresse DNS_LISTEN_N='0' # if 0 then listen on all interfaces DNS_LISTEN_1='IP_NET_1_IPADDR' # first IP to listen on DNS_VERBOSE='no' # log queries into syslog DNS_MX_SERVER='' # fqdn of the mx for your DOMAIN DNS_FORBIDDEN_N='0' # number of forbidden domains DNS_FORBIDDEN_1='foo.bar' # 1st forbidden domain DNS_FORBIDDEN_2='bar.foo' # 2nd forbidden domain DNS_REDIRECT_N='0' # number of redirected domains DNS_REDIRECT_1='foo.bar.foo' # 1st redirected domain DNS_REDIRECT_1_IP='192.168.6.100' # IP of redirected domain DNS_BOGUS_PRIV='yes' # fake reverse lookups for RFC1918 # private address ranges DNS_FILTERWIN2K='no' # filters useless windows-originated DNS # requests and blocks all SRV requests, # when enabled DNS_LOCAL_HOST_CACHE_TTL='60' # TTL for entries in /etc/hosts or DHCP #DNS_SUPPORT_IPV6='no' # enable/disable IPV6-support #------------------------------------------------------------------------------ # Special DNS configuration #--------------------------- # delegation of DNS-Request for Domains or/and reverse network lookup # zone delegation (domain and network) to upstream servers #------------------------------------------------------------------------------ DNS_ZONE_DELEGATION_N='0' # number of zone delegations #DNS_ZONE_DELEGATION_1_UPSTREAM_SERVER_N='3' # number of upstream servers #DNS_ZONE_DELEGATION_1_UPSTREAM_SERVER_1_IP='1.2.3.4:5353' # ip address or @hostname with optiona # number used to query upstream server #DNS_ZONE_DELEGATION_1_UPSTREAM_SERVER_1_QUERYSOURCEIP='111.222.33.123' # ip adress or IP_NET_x_IPADDR with opti # portnumber used as query source #DNS_ZONE_DELEGATION_1_UPSTREAM_SERVER_2_IP='@dns-upstream' #DNS_ZONE_DELEGATION_1_UPSTREAM_SERVER_2_QUERYSOURCEIP='IP_NET_1_IPADDR' #DNS_ZONE_DELEGATION_1_UPSTREAM_SERVER_3_IP='192.168.3.12' #DNS_ZONE_DELEGATION_1_UPSTREAM_SERVER_3_QUERYSOURCEIP='IP_NET_1_IPADDR:5678' #DNS_ZONE_DELEGATION_1_DOMAIN_N='2' # number of domains to delegate #DNS_ZONE_DELEGATION_1_DOMAIN_1='firma.de.example.com' #DNS_ZONE_DELEGATION_1_DOMAIN_2='firma.com.example.com' #DNS_ZONE_DELEGATION_1_NETWORK_N='3' # number of networks to delegate #DNS_ZONE_DELEGATION_1_NETWORK_1='192.168.1.0/24' #DNS_ZONE_DELEGATION_1_NETWORK_2='172.16.1.0/24' #DNS_ZONE_DELEGATION_1_NETWORK_3='10.1.2.0/24' # domains which are allowed to return private ip addresses from upstream # DNS Servers DNS_REBINDOK_N='0' # Number of Domains DNS_REBINDOK_1_DOMAIN='rfc-ignorant.de' #------------------------------------------------------------------------------ # DHCP-Server configuration: sconmal Danke fürs ansehen Frank From fli4l at kristov.de Thu Dec 18 20:14:22 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Thu, 18 Dec 2014 20:14:22 +0100 Subject: [fli4l] kleines Hurra ! References: Message-ID: Hallo! Frank Lucke schrieb: > ein fröhliches Moin Moin > > Die Wlan-Karte wurde akzeptiert.Das Hauptproblem war die Übertragung vom > Win-Rechner zum Router. Kannst du uns mitteilen, was das Problem war? Hast du vergessen, die angepasste Konfigurationsdatei zu übertragen? Oder was war das Problem? > Ja er heißt "fli4l" ,das DNS-Paket ist installiert und eingeschaltett. > Es arbeitet aber nicht; Wie testest du das? Mit einem PING zu einem Host von einem LAN-Client aus? Oder auf dem fli4l direkt? Zeig mal den Inhalt von /etc/resolv.conf und von /etc/resolv.dnsmasq. > Als zusätzlichen Host hab ich eine Fritzbox > konfiguriert die auch nicht auf gelöst wird. > Ich zeige jetzt mal nur Auszüge. > [...] Die Firewall-Konfiguration fehlt (alle Variablen mit PF_ am Anfang). Des Weiteren fehlt DNS_FORWARDERS in der Liste; auch diese Variable muss für eine ordnungsgemäße DNS-Konfiguration gesetzt sein. AUch der Inhalt von DOMAIN_NAME ist in diesem Zusammenhang interessant. Danke und Gruß, -- Christoph Schulz [fli4l-Team] From mein-fli4l-postfach at freenet.de Thu Dec 18 20:14:48 2014 From: mein-fli4l-postfach at freenet.de (Stefan Sauer) Date: Thu, 18 Dec 2014 20:14:48 +0100 Subject: [fli4l] =?utf-8?q?Web_Proxy_Auto-Dis=3F=3D=3D=3Futf-8=3FQ=3Fcover?= =?utf-8?q?y_Protocol?= Message-ID: Hallo zusammen, ich hab mal eine Frage an die Spezialisten: Ich möchte, dass mein fli eine sogenannte pac bzw. wpad.dat Datei an Webbrowser sendet, wenn diese danach fragen. Dabei handelt es sich um eine Javascript-Datei, die im Browser die Proxykonfiguration vornimmt. Dazu nutze ich die Option 252 des DHCP-Protokolls zusammen mit dem dnsmasq-Server des fli. Wie hier [ http://tools.ietf.org/html/draft-ietf-wrec-wpad-01 ] beschrieben, muss man eine URL in Form eines Strings angeben, was ich auch gemacht habe. IP_NET_3_NAME='wpad.mein.lan' sorgt dafür, dass der Name wpad auch aufgelöst werden kann. Nur wie bekomme ich den Webserver des fli dazu die Datei wpad.dat zur Verfügung zu stellen und dann auch noch ohne Anmeldung? Danke gandalf From fli4l at kristov.de Thu Dec 18 20:28:31 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Thu, 18 Dec 2014 20:28:31 +0100 Subject: [fli4l] Web Proxy Auto-Discovery Protocol References: Message-ID: Hallo! Stefan Sauer schrieb: > Nur wie bekomme ich den Webserver des fli dazu > die Datei wpad.dat zur Verfügung zu stellen und dann auch noch ohne > Anmeldung? Also wenn ich rc430.httpd richtig lese, ist eine Anmeldung erst ab /admin erforderlich. Wenn du deine Datei(en) also direkt unterhalb von / bereitstellst, sollte das klappen. Das würde heißen, du müsstest sie in /srv/www bereitstellen. Viele Grüße, -- Christoph Schulz [fli4l-Team] From mein-fli4l-postfach at freenet.de Thu Dec 18 20:40:31 2014 From: mein-fli4l-postfach at freenet.de (Stefan Sauer) Date: Thu, 18 Dec 2014 20:40:31 +0100 Subject: [fli4l] =?utf-8?q?Web_Proxy_=3F=3D=3D=3Futf-8=3FQ=3FAuto-Discover?= =?utf-8?q?y_Protocol?= References: Message-ID: Also wenn ich rc430.httpd richtig lese, ist eine Anmeldung erst ab /admin erforderlich. Wenn du deine Datei(en) also direkt unterhalb von / bereitstellst, sollte das klappen. Das würde heißen, du müsstest sie in /srv/www bereitstellen. Viele Grüße, -- Christoph Schulz Kann ich die Datei vor dem Remoteupdate einfach nach opt/files/srv/www/ kopieren und dann updaten, oder muss ich noch andere Dateien anpassen, damit meine wpad.dat den Weg auf den Router findet? Danke, gandalf From fli4l at kristov.de Thu Dec 18 20:59:44 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Thu, 18 Dec 2014 20:59:44 +0100 Subject: [fli4l] Web Proxy Auto-Discovery Protocol References: Message-ID: Hallo! Stefan Sauer schrieb: > Kann ich die Datei vor dem Remoteupdate einfach nach opt/files/srv/www/ > kopieren und dann updaten, Nein. Das würde nur bei Typ B-Installationen gehen, und auch nur ohne anschließendes Update. > oder muss ich noch andere Dateien anpassen, > damit meine wpad.dat den Weg auf den Router findet? Schau dir OPT_USERCMD aus dem Paket "usercmd" an, das bietet mit USERCMD_FILE_%_(SRC|DST) vermutlich genau das an, was du brauchst. Gruß, -- Christoph Schulz [fli4l-Team] From fli4l at kristov.de Thu Dec 18 21:01:38 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Thu, 18 Dec 2014 21:01:38 +0100 Subject: [fli4l] Web Proxy Auto-Discovery Protocol References: Message-ID: Hallo! Christoph Schulz schrieb: > Schau dir OPT_USERCMD aus dem Paket "usercmd" an, das bietet mit > USERCMD_FILE_%_(SRC|DST) vermutlich genau das an, was du brauchst. Das existiert allerdings nur in aktuellen Entwicklerversionen. Nutzt du den 3.10-Tarball? In 3.6.2 gibt es das so nicht... Viele Grüße, -- Christoph Schulz [fli4l-Team] From mein-fli4l-postfach at freenet.de Thu Dec 18 21:10:14 2014 From: mein-fli4l-postfach at freenet.de (Stefan Sauer) Date: Thu, 18 Dec 2014 21:10:14 +0100 Subject: [fli4l] =?utf-8?q?We=3F=3D=3D=3Futf-8=3FQ=3Fb_Proxy_Auto-Discover?= =?utf-8?b?eSBQcm8/PT0/dXRmLTg/UT90b2NvbA==?= References: Message-ID: Danke für den Tipp, und ja ich nutze die Version 3.10. Dann versuch ich's mal Bis dann gandalf From mein-fli4l-postfach at freenet.de Thu Dec 18 22:57:06 2014 From: mein-fli4l-postfach at freenet.de (Stefan Sauer) Date: Thu, 18 Dec 2014 22:57:06 +0100 Subject: [fli4l] =?utf-8?q?We=3F=3D=3D=3Futf-8=3FQ=3Fb_Proxy_Auto-Discover?= =?utf-8?b?eSBQcm8/PT0/dXRmLTg/UT90b2NvbA==?= References: Message-ID: Für alle, die mitlesen: Danke noch mal für die prompte Unterstützung, es geht jetzt. Gute Nacht gandalf From delucks at freenet.de Fri Dec 19 14:32:09 2014 From: delucks at freenet.de (Frank Lucke) Date: Fri, 19 Dec 2014 14:32:09 +0100 Subject: [fli4l] kleines Hurra ! In-Reply-To: References: Message-ID: Am 18.12.2014 um 20:14 schrieb Christoph Schulz: > Kannst du uns mitteilen, was das Problem war? Hast du vergessen, die > angepasste Konfigurationsdatei zu übertragen? Oder was war das Problem? > Leider nein (zum Mitteilen).Ich weiß es nicht,aber da die Übertragerei Schwierigkeiten hatte lag es wahrscheinlich da irgendwo. >AUch der Inhalt von DOMAIN_NAME ist in diesem Zusammenhang interessant. > Diese Variable hatte ich falsch verstanden.Windowsmässig mit Arbeitsgruppe übersetzt habe ich´s kapiert.Vor einigen Jahren wusste ich´s mal,aber die Zeit nagt an allem. Die nächsten Probs zeichnen sich schon ab,aber dann frage ich neu. herzlichsten und lieben Dank Frank From redhead.kc85 at t-online.de Fri Dec 19 15:55:25 2014 From: redhead.kc85 at t-online.de (Enrico Grämer) Date: Fri, 19 Dec 2014 15:55:25 +0100 Subject: [fli4l] =?utf-8?q?nicht_rout=3F=3D=3D=3Futf-8=3FQ=3Fender_Router?= References: Message-ID: Hallo, so, endlich wieder Zeit. Zitat: > Enrico Grämer schrieb: > > > Die Netzwerkkarte vom Board (eepro100) geht nur mit dem alten > > Kernel, > > Wie meinst du das? In der aktuellen fli4l-Version gibt es doch den > e100- > Treiber. Aus der NIC-Liste > (https://ssl.nettworks.org/wiki/display/f/Netzwerkkarten): > > "pci e100 Intel(R) PRO/100 Network" Nein, nicht diese. Ich meine damit den Treiber namens eepro100, für die Intel i82557/i82558/i82559 PCI EtherExpressPro. Der passt auch für Intel 82551. Der ist auf dem Kontron-Board MOPSLX800 drauf. Zitat: > > USB-Netwerk-Adapter sollen > > nur mit dem neuen Kernel funktionieren. > > > > Was meinst du mit "alt" und "neu"? 3.14 vs. 3.17? Der alte Kernel ist 2.6.16.62, der neue Kernel 2.6.32.59 Zitat: > > Merkwürdig war, dass die > > "Bau-Saftware" beim alten Kernel nicht > > bei der RTL8150 nach Fehler schreit. Mir ist in den Untiefen > > des > > Filesystems aufgefallen, dass beim alten > > Kernel doch Treiber dafür vorhanden sind....? > > Nützte aber doch nichts, da RTL8150 doch nicht mit meiner > > vorhandenen > > NW-Karte mit RTL8152 kompatibel sind. > > Ich dachte es ging beim Treiber um "Familie". > > Ich verstehe hier dein Problem nicht. Es gibt einen Treiber > "rtl8150" sowohl > im 3.14- als auch im 3.17-Kernel. Und dieser Treiber funktioniert > mit deiner > Karte nicht, weder mit 3.14 noch mit 3.17. Warum sollte nun mkfli4l > beim > Bauen eine Fehlermeldung produzieren? mkfli4l kennt doch nicht deine > > Hardware! Genau anders herum mein ich das, eigentlich kein Problem. Lt. Doku sollen alle USB-Netzkwerkkarten nur mit dem neueren Kernel 2.6.32.59 funktionieren. Steht so in der PDF und der NIC-Liste unter /config der Fli4l Version 3.6.2 drin. Mich hatte es nur gewundert, dass der Treiber dann doch ohne Fehlermeldung eingebunden wurde. Dass es dann nicht funktioniert, weil ich nicht die RTL8150 sondern RTL8152 ist ja klar, da die Hardware nicht kompatibel ist. Zitat: > > Vom Router aus, konnte ich das interne Netz erreichen, > > Internet-Adressen > > (Namen) ebenso. > > Also geht DNS.... > > Lokal auf dem Router ja. > > > Es ist auch möglich, optional Port-Nummern an die IP-Adressen > > durch > > Doppelpunkt ge- > > trennt anzugeben. Allerdings muss dann OPT_DNS='yes' (Seite > > 103) sein > > (Paket dns_dhcp > > (Seite 101))und es darf nirgends die Option *_USEPEERDNS > > benutzt > > werden. > > > > > > ... heisst für mich, dass ich OPT_DNS nur anschalten muss, > > wenn mit > > Ports hantieren will. > > Nein. Du brauchst natürlich OPT_DNS='yes', wenn _irgendein Client_ > in deinem > LAN DNS braucht. Das war natürlich schon immer so (auch bei > 2.0.8!), denn > wie will dein Windows-Client die lokale /etc/hosts oder > /etc/resolv.conf > deines Routers kennen? Dazu muss er eine DNS-Abfrage an deinen fli4l > > schicken, und deshalb braucht es auf deinem fli4l eben einen Server, > der > diese Anfrage bearbeitet -- eben den DNS-Server. > > Ich gebe aber zu, dass die Dokumentation an dieser Stelle > verbesserungswürdig ist. Stimmt, jetzt wo Du das sagst; bei Version 2.0.8 heisst es "START_DNS" Ich hatte ja auch keine Zweifel, es konnte ja nicht daran liegen, da es ja weder bei XP noch XUBUNTU funktionert. Da ich keine Zweifel hatte, hatte ich es aus gelassen. ;) Wenn ich drüber nachgedacht hätte, wäre mir auch klar gewesen, dass es ja nicht ohne DNS-Server funktionieren kann. -- MFG Enrico From f.stroeter at gmx.net Fri Dec 19 17:10:51 2014 From: f.stroeter at gmx.net (Frank Stroeter) Date: Fri, 19 Dec 2014 17:10:51 +0100 Subject: [fli4l] V3.6.2-UMTS geht nur mit "Warmstart" Message-ID: Hallo Fli Gemeinde, ich habe mich mal wieder mit UMTS beschäftigt. Mein Router V3.6.2 mit aktuellem Patch funktioniert mit div. UMTS Sticks einwandfrei ausser nach einem Stromausfall. - Router stromlos keine UMTS Hardware gefunden. - reboot über Imonc, HTTP oder Konsole und alles funktioniert. Getestet mit Huawei E173-u1 und ZTE MF190. In der USB.txt habe ich alle 3 Treiber geladen: USB_LOWLEVEL='ehci uhci ohci' Dieses Problem habe ich mit einer 3.10.0-r34866 schonmal beschrieben. Ich meine gelesen zu haben es wäre jetzt behoben. Mein Problem ich muß einen UMTS Router bauen und möchte keine Test-Version im Produktivbetrieb einsetzen. Weiß jemand Rat für die V3.6.2? Ich werde nun noch die aktuelle Test-Version versuchen. (Mann kommt mit dem testen ja kaum hinterher so schnell wie die Entwickler sind;-) Deshalb hier kurz vor Weihnachten auch noch ein fettes DANKE an alle! Grüße Frank From fli4l at carsten-spiess.de Fri Dec 19 17:16:45 2014 From: fli4l at carsten-spiess.de (Carsten =?UTF-8?B?U3BpZcOf?=) Date: Fri, 19 Dec 2014 17:16:45 +0100 Subject: [fli4l] nicht routender Router References: Message-ID: <20141219171645.60044f1c@cs-office2.lan.local> Hallo Enrico, > > "pci e100 Intel(R) PRO/100 Network" > Nein, nicht diese. > Ich meine damit den Treiber namens eepro100, für die Intel > i82557/i82558/i82559 PCI EtherExpressPro. > Der passt auch für Intel 82551. Der ist auf dem Kontron-Board > MOPSLX800 drauf. Was für 'ne PCI ID hat das Teil (lspci aus dem Pakte Tools) Meines Wissens sollte das 8086:1229 sein, die wird vom e100 Treiber unterstützt (evtl. ist das mal von eepro100 nach e100 gewandert) Gruß Carsten From fli4l at carsten-spiess.de Fri Dec 19 17:22:09 2014 From: fli4l at carsten-spiess.de (Carsten =?UTF-8?B?U3BpZcOf?=) Date: Fri, 19 Dec 2014 17:22:09 +0100 Subject: [fli4l] V3.6.2-UMTS geht nur mit "Warmstart" References: Message-ID: <20141219172209.21fd0a10@cs-office2.lan.local> Hallo Frank, > Mein Problem ich muß einen UMTS Router bauen und möchte keine > Test-Version im Produktivbetrieb einsetzen. Wenn Du noch ein paar Tage Geduld hast: bald ist Weihnachten ;) Gruß Carsten From Hans at Bachner.priv.at Fri Dec 19 23:13:45 2014 From: Hans at Bachner.priv.at (Hans Bachner) Date: Fri, 19 Dec 2014 23:13:45 +0100 Subject: [fli4l] =?utf-8?b?L2V0Yy9yYy5jZmcgdW4/PT0/dXRmLTg/UT9kIC9ib290?= =?utf-8?b?L3JjLmNmZyAod2FzOiBJUHMvTmV0Pz09P3V0Zi04P1E/emUgdm9uZWluYW5k?= =?utf-8?b?ZXIgdHJlbm5lbiAgIEZyYWc/PT0/dXRmLTg/UT9lbiDDvGJlciBGcmFnZW4p?= References: Message-ID: Danke, das klingt nach einer sauberen Lösung, bei der den "fortgeschrittenen" fli4l-Anwendern die gewohnten (und geschätzten) Möglichkeiten offen bleiben. Schöne Grüße, Hans. From FrBartel at hotmail.com Sat Dec 20 15:07:23 2014 From: FrBartel at hotmail.com (Friedrich Bartel) Date: Sat, 20 Dec 2014 15:07:23 +0100 Subject: [fli4l] =?utf-8?q?Sicherheitsl=C3=BCcken_in_NTP?= Message-ID: > http://www.golem.de/news/zeitserver-sicherheitsluecken-in-ntp-1412-111296.html Wie sieht es bei Chrony aus das verwendet doch auch NTP. Grüße Friedrich From fli4l at kristov.de Sat Dec 20 18:03:07 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Sat, 20 Dec 2014 18:03:07 +0100 Subject: [fli4l] =?utf-8?q?Sicherheitsl=C3=BCcken_in_NTP?= References: Message-ID: Hallo! Friedrich Bartel wrote: >> http://www.golem.de/news/zeitserver-sicherheitsluecken-in-ntp-1412-111296.html > > > > Wie sieht es bei Chrony aus das verwendet doch auch NTP. Soweit ich den Artikel verstehe, ist nur die Referenz-Implementierung betroffen. Das ist auch heute mit FFL-1130 abgefrühstückt worden. Viele Grüße, -- Christoph Schulz [fli4l-Team] From redhead.kc85 at t-online.de Sat Dec 20 22:32:13 2014 From: redhead.kc85 at t-online.de (Enrico Grämer) Date: Sat, 20 Dec 2014 22:32:13 +0100 Subject: [fli4l] =?utf-8?q?nicht_rout=3F=3D=3D=3Futf-8=3FQ=3Fender_Router?= References: <20141219171645.60044f1c@cs-office2.lan.local> Message-ID: Hallo Carsten, Zitat: > Was für 'ne PCI ID hat das Teil (lspci aus dem Pakte Tools) > Meines Wissens sollte das 8086:1229 sein, die wird vom > e100 Treiber unterstützt > (evtl. ist das mal von eepro100 nach e100 gewandert) > > Gruß > > Carsten Nicht ganz. LSPCI meldet 8086:1209 (rev 10) Die Karte wird auch namentlich als .."Intel 8255xER/82551IT"... erkannt. -- MFG Enrico From fli4l at kristov.de Sun Dec 21 11:22:05 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Sun, 21 Dec 2014 11:22:05 +0100 Subject: [fli4l] nicht routender Router References: <20141219171645.60044f1c@cs-office2.lan.local> Message-ID: Hallo! Enrico Grämer schrieb: > Nicht ganz. > LSPCI meldet 8086:1209 (rev 10) > > Die Karte wird auch namentlich als .."Intel 8255xER/82551IT"... erkannt. 1) Warum beschreitest du nicht den "üblichen Weg", baust dir eine fli4l-CD mit OPT_HW_DETECT='yes' und HW_DETECT_AT_BOOTTIME='yes' und schaust, welcher Treiber dir vorgeschlagen wird? 2) Des Weiteren verstehe ich nicht, warum du denn nicht einfach unseren Vorschlag ausprobierst. Deinetwegen habe ich jetzt extra in den Kernel- Quellcode geschaut, und siehe da: In der intel/e100.c steht: > * The driver supports Intel(R) 10/100 Mbps PCI Fast Ethernet > * controller family, which includes the 82557, 82558, 82559, 82550, > * 82551, and 82562 devices. "e100" ist somit genau der Treiber, den du brauchst. Viele Grüße, -- Christoph Schulz [fli4l-Team] From redhead.kc85 at t-online.de Sun Dec 21 15:45:35 2014 From: redhead.kc85 at t-online.de (Enrico Grämer) Date: Sun, 21 Dec 2014 15:45:35 +0100 Subject: [fli4l] =?utf-8?q?ni=3F=3D=3D=3Futf-8=3FQ=3Fcht_routender_Router?= References: Message-ID: Hallo Christian, Christoph Schulz schrieb am So, 21 Dezember 2014 11:22 > Hallo! > > Enrico Grämer schrieb: > > > Nicht ganz. > > LSPCI meldet 8086:1209 (rev 10) > > > > Die Karte wird auch namentlich als .."Intel 8255xER/82551IT"... > > erkannt. > > 1) Warum beschreitest du nicht den "üblichen Weg", baust dir eine > fli4l-CD > mit OPT_HW_DETECT='yes' und HW_DETECT_AT_BOOTTIME='yes' und schaust, > welcher > Treiber dir vorgeschlagen wird? > > 2) Des Weiteren verstehe ich nicht, warum du denn nicht einfach > unseren > Vorschlag ausprobierst. Nun den "ortsüblichen Weg" kenne ich ja nun nicht. Deswegen habe ich in der NIC-Liste nachgesehen, dort taucht meine NW-Karte unter "eepro100" auf, unter "e100" steht nichts dabei. Deswegen hatte ich diesen genommen. Mit der Hardwareerkennung hatte ich bei dem Board nichts gemacht. Die hatte ich erst danach mal mit dem Futro S200 ausprobiert. Es heisst ja auch, dass diese experimentell ist, ausserdem funktionerte es ja mit dem Treiber. Deine erste Antwort hatte ich nun auch nicht als Vorschlag zum ausprobieren verstanden. Zitat: > Deinetwegen habe ich jetzt extra in den Kernel- > Quellcode geschaut, und siehe da: In der intel/e100.c steht: > > > * The driver supports Intel(R) 10/100 Mbps PCI Fast > > Ethernet > > * controller family, which includes the 82557, 82558, > > 82559, 82550, > > * 82551, and 82562 devices. > > "e100" ist somit genau der Treiber, den du brauchst. > > > Viele Grüße, > -- > Christoph Schulz > [fli4l-Team] Entschuldigung. Ich habe das Board eben nochmal angesteckt, mit HW-Erkennung. Nun sehe ich auch, dass der Treiber vorgeschlagen wird. -- MFG Enrico From redhead.kc85 at t-online.de Sun Dec 21 16:12:18 2014 From: redhead.kc85 at t-online.de (Enrico Grämer) Date: Sun, 21 Dec 2014 16:12:18 +0100 Subject: [fli4l] =?utf-8?q?ni=3F=3D=3D=3Futf-8=3FQ=3Fcht_routender_Router?= References: Message-ID: So, ich habe den Treiber e100 ausprobiert, danke, funktioniert. -- MFG Enrico From fli4l at kristov.de Sun Dec 21 17:12:22 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Sun, 21 Dec 2014 17:12:22 +0100 Subject: [fli4l] nicht routender Router References: Message-ID: Hallo! Enrico Grämer schrieb: > Nun den "ortsüblichen Weg" kenne ich ja nun nicht. Deswegen habe ich in > der NIC-Liste nachgesehen, Die NIC-Liste ist schön und gut, aber sie basiert auf den Textinhalten, die von den Kernel-Treibern als Zeichenketten nach außen "publiziert" werden (die kannst du dir z.B. auf einem Linux-System via "modinfo" anzeigen lassen). Wenn diese Zeichenketten nicht besonders deskriptiv sind, dann ist die NIC-Liste an dieser Stelle ebenfalls nicht besonders deskriptiv. > dort taucht meine NW-Karte unter "eepro100" auf, unter "e100" steht > nichts dabei. Nun ja, in deiner ersten E-Mail stand auch nicht, welche Version du installieren willst. Erst später konnte man anhand der Informationen über den Kernel ableiten, dass du 3.6.2 installieren möchtest. Bitte zukünftig _immer_ die Version, um die es geht, an prominenter Stelle mitteilen, am besten im Betreff! Welcher Treiber bei der 3.6.2 mit deiner Karte am besten funktioniert, kann ich nicht sagen. Ich habe bei einem modernen Kernel nachgeschaut, nicht bei dem uralten Teil aus 3.6.2. Viele Grüße, -- Christoph Schulz [fli4l-Team] From redhead.kc85 at t-online.de Sun Dec 21 17:59:36 2014 From: redhead.kc85 at t-online.de (Enrico Grämer) Date: Sun, 21 Dec 2014 17:59:36 +0100 Subject: [fli4l] =?utf-8?b?QXc/PT0/dXRmLTg/UT86IFJlOiBuaWNodCByb3V0ZW5k?= =?utf-8?b?ZXIgUm91dD89PT91dGYtOD9RP2Vy?= References: Message-ID: Hallo Christoph, ich werde versuchen mich zu bessern. Allzuviel habe ich mit Linux noch nicht am Hut. Muss aber noch, nur fehlt es z.Z. an der Zeit. Aber meine ersten Eindrücke sind sehr positiv im Gegensatz zu diesem Win8, ff. Vor einer Weile kam auch die 2. USb-Netzwerkkarte an. Logilink UA0025. Der MSC7830 wird ja unterstützt, funktioniert also auch. Ich habe genau diesem genommen, weil lt. Datenblatt des ICs sich TX-, RX-, Link-LED anschliessen lassen sollen. Wie sich herrausgestellt hat werden die Hersteller aber auch immer "schlauer". Ich habe mich gewundert, warum im Gehäuse ein Gnubbel ist. Da leuchtet aber nichts. Also habe ich das Teil aufgemacht. Ist schon sehr intelligent eine LED in ein undurchsichtiges Gehäuse zu bauen... -- MFG Enrico From no_html.max50kb at nurfuerspam.de Sun Dec 21 18:13:23 2014 From: no_html.max50kb at nurfuerspam.de (Matthias Taube) Date: Sun, 21 Dec 2014 18:13:23 +0100 Subject: [fli4l] IPv6 Firewall-Regeln Message-ID: Ich habe den Fli 3.10.0 mit den default-Firewall-Regeln. ein ip6tables -L -v ergibt u.a.: > 0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp echo-request length 0:150 limit: avg 1/sec burst 5 /* PF6_INPUT_ACCEPT_DEF */ > 4732 4869K ACCEPT ipv6-icmp any any gw-101.cgn-01.de.sixxs.net anywhere ipv6-icmp echo-request /* PF6_INPUT_ACCEPT_DEF */ Weshalb wird die letzte Regel (Pings von sixxs) überhaupt getroffen? Normalerweise müsste doch die davor stehende generelle Regel für Pings von überall alle diese Anfragen abfangen? mfg Matthias From newsgroup at lan4me.de Sun Dec 21 18:45:59 2014 From: newsgroup at lan4me.de (Peter Schiefer) Date: Sun, 21 Dec 2014 18:45:59 +0100 Subject: [fli4l] IPv6 Firewall-Regeln References: Message-ID: <1szenres5l4y4.dlg@lan4me.de> Hallo Matthias, Am Sun, 21 Dec 2014 18:13:23 +0100 schrieb Matthias Taube: > Ich habe den Fli 3.10.0 mit den default-Firewall-Regeln. > > ein ip6tables -L -v ergibt u.a.: > >> 0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp echo-request length 0:150 limit: avg 1/sec burst 5 /* PF6_INPUT_ACCEPT_DEF */ >> 4732 4869K ACCEPT ipv6-icmp any any gw-101.cgn-01.de.sixxs.net anywhere ipv6-icmp echo-request /* PF6_INPUT_ACCEPT_DEF */ > > Weshalb wird die letzte Regel (Pings von sixxs) überhaupt getroffen? > Normalerweise müsste doch die davor stehende generelle Regel für Pings > von überall alle diese Anfragen abfangen? die einzige für mich logische erklärung ist, das die Paket die sixxs da nutzt länger als 150Byte sind. Gruß Peter From newsgroup at lan4me.de Sun Dec 21 18:58:12 2014 From: newsgroup at lan4me.de (Peter Schiefer) Date: Sun, 21 Dec 2014 18:58:12 +0100 Subject: [fli4l] =?iso-8859-1?q?Termin_f=FCr_das_Release_der_n=E4chsten_st?= =?iso-8859-1?q?abilen_fli4l_Version_3=2E10=2E?= Message-ID: <1owyptyvbmzqw.dlg@lan4me.de> Liebe Nutzer von fli4l, wir vom fli4l-Tea, hatten ja geplant Euch vor Weihnachten (22.12.) bereits ein Weihnachtsgeschenk zu präsentieren. Leider ist uns bei einigen Dingen die Zeit etwas weggelaufen (Überarbeitung sowie Übersetzung einiger Abschnitte der Dokumentsation, ungeplannte Sicherheitsupdates die extra Zeit benötigt haben, .....). Wir haben uns daher entschlossen das Release in den Januar 2015 zu schieben um dann auch diese offenen Punkte fertiggestellt zu haben. Gruß Peter und das fli4l-Team From fli4l at kristov.de Sun Dec 21 19:07:43 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Sun, 21 Dec 2014 19:07:43 +0100 Subject: [fli4l] IPv6 Firewall-Regeln References: <1szenres5l4y4.dlg@lan4me.de> Message-ID: Hallo! Peter Schiefer schrieb: > die einzige für mich logische erklärung ist, das die Paket die sixxs da > nutzt länger als 150Byte sind. Und genauso ist es auch. Viele Grüße, -- Christoph Schulz [fli4l-Team] From mein-fli4l-postfach at freenet.de Mon Dec 22 20:38:42 2014 From: mein-fli4l-postfach at freenet.de (Stefan Sauer) Date: Mon, 22 Dec 2014 20:38:42 +0100 Subject: [fli4l] =?utf-8?b?UGFrZXRmaWx0ZXIgUkVESVJFPz09P3V0Zi04P1E/Q1Q/?= Message-ID: Hallo zusammen, aufgrund der aktuellen NTP-Sicherheitslücke schaute ich mir meine Konfiguration auf dem Router an. Ich stellte fest, dass vor allem der in Windows verwendete Server time.windows.com nicht zuverlässig antwortete. Synchronisierte ich mit dem fli-Router (LAN seitig) ging es 100%ig. Nun verwende ich jedoch mehere Betriebsystem mit Multiboot und auch mehrere virtuelle Maschinen. Da ich keine Lust hatte, alle per Hand anzupassen, suchte ich nach einer anderen Lösung. Nach ein bischen Lesen der Dokumentation fand ich heraus, dass der chronyd an allen IPv4 Interfaces horcht (0.0.0.0:123). In der Paketfilterkonfiguration stand ein REDIRECT leitet Pakete an die Adresse 127.0.0.1 und den angegebenen Port. Ich erstelle also die folgenden Firewall-Regeln: PF_INPUT_8='tmpl:ntp ACCEPT LOG:Zeitabgleich' und PF_PREROUTING_2='if:IP_NET_3_DEV:any tmpl:ntp IP_NET_3 any REDIRECT:123 LOG:lokale_Umleitung' Ich erwartete, dass der Paketfilter die Pakete nach 127.0.0.1:123 umleitet, doch zu meiner Überraschung sagt das Log folgendes: Dec 22 20:29:13 router kern.warn kernel: lokale_Umleitung IN=eth2 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xxx SRC=192.168.7.138 DST=192.168.7.1 LEN=61 TOS=0x00 PREC=0x00 TTL=64 ID=45594 DF PROTO=UDP SPT=50188 DPT=53 LEN=41 192.168.7.138 ist die IP des Clients 192.168.7.1 ist die IP des Routers der LAN Seite Jetzt bin ich etwas irritiert. Wenn ich einen Fehler gemacht hab, seh ich ihn nicht und wäre dankbar für den entsprechenden Hinweis, oder kann es sein, dass die Dokumentation diesen Fall nicht abdeckt oder sich sogar ein Fehler eingeschlichen hat? Vielen Dank für die Antworten gandalf From fli4l at kristov.de Mon Dec 22 20:52:01 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Mon, 22 Dec 2014 20:52:01 +0100 Subject: [fli4l] Paketfilter REDIRECT? References: Message-ID: Hallo! Stefan Sauer schrieb: > In der Paketfilterkonfiguration stand > ein REDIRECT leitet Pakete an die Adresse 127.0.0.1 und den angegebenen > Port. Das ist falsch. Ein REDIRECT leitet ein Paket an die Adresse der Schnittstelle, über die das Paket hereingekommen ist. Also: Wenn das Paket via eth2 hereingekommen ist und eth2 die Adresse 192.168.7.1 hat, dann wird die Zieladresse auf 192.168.7.1 gesetzt. Nur wenn das Paket vom Router selbst stammt und dabei einem REDIRECT unterworfen wird (das kann logischerweise dann nur in der OUTPUT-Kette passieren), dann wird die Zieladresse auf 127.0.0.1 gesetzt. Viele Grüße, -- Christoph Schulz [fli4l-Team] From mein-fli4l-postfach at freenet.de Mon Dec 22 21:02:05 2014 From: mein-fli4l-postfach at freenet.de (Stefan Sauer) Date: Mon, 22 Dec 2014 21:02:05 +0100 Subject: [fli4l] =?utf-8?b?UGFrZXRmaWx0ZT89PT91dGYtOD9RP3IgUkVESVJFQ1Q/?= References: Message-ID: Vielen Dank für die schnelle Info, wenn das so ist, kommt der REDIRECT ja eine DNAT Regel wie folgender gleich: PF_PREROUTING_2='if:IP_NET_3_DEV:any tmpl:ntp IP_NET_3 any DNAT:IP_NET_3_IPADDR:123 LOG:lokale_Umleitung' Nehm ich da jetzt besser REDIRECT, oder DNAT? Gruss, gandalf From newsgroup at lan4me.de Mon Dec 22 21:16:51 2014 From: newsgroup at lan4me.de (Peter Schiefer) Date: Mon, 22 Dec 2014 21:16:51 +0100 Subject: [fli4l] =?utf-8?b?UGFrZXRmaWx0ZXIgUkVESVJFPz09P3V0Zi04P1E/Q1Q/?= References: Message-ID: <1m2biujbjwma9.dlg@lan4me.de> Hallo gandalf, Stefan Am Mon, 22 Dec 2014 20:38:42 +0100 schrieb Stefan Sauer: > aufgrund der aktuellen NTP-Sicherheitslücke schaute ich mir meine > Konfiguration auf dem Router an. Ich stellte fest, dass vor allem der in > Windows verwendete Server time.windows.com nicht zuverlässig > antwortete. Synchronisierte ich mit dem fli-Router (LAN seitig) ging es > 100%ig. Nun verwende ich jedoch mehere Betriebsystem mit Multiboot und > auch mehrere virtuelle Maschinen. Da ich keine Lust hatte, alle per Hand > anzupassen, suchte ich nach einer anderen Lösung. Nach ein bischen > Lesen der Dokumentation fand ich heraus, dass der chronyd an allen IPv4 > Interfaces horcht (0.0.0.0:123). In der Paketfilterkonfiguration stand > ein REDIRECT leitet Pakete an die Adresse 127.0.0.1 und den angegebenen > Port. Ich erstelle also die folgenden Firewall-Regeln: > > PF_INPUT_8='tmpl:ntp ACCEPT LOG:Zeitabgleich' > und > > PF_PREROUTING_2='if:IP_NET_3_DEV:any tmpl:ntp IP_NET_3 any REDIRECT:123 > LOG:lokale_Umleitung' zu deiner "Umleitung" - des kann passieren, das der fragende NTP-Client die Antworten er Umleitung nicht akzeptiert, da die src-Adresse nich der Adresse entspricht, an die die anfrage gesendet wurde (diese Problem kenn ich aus der 4ma) Ich würde als Alternative ein DNS_REDIRECT für time.windows.com definieren. Gruß Peter From mein-fli4l-postfach at freenet.de Mon Dec 22 21:25:21 2014 From: mein-fli4l-postfach at freenet.de (Stefan Sauer) Date: Mon, 22 Dec 2014 21:25:21 +0100 Subject: [fli4l] =?utf-8?b?UGFrZXRmaWx0ZT89PT91dGYtOD9RP3IgUkVESVJFQ1Q/?= References: <1m2biujbjwma9.dlg@lan4me.de> Message-ID: Hallo Peter, das ist auch eine sehr gute Idee. Mein Windows 7 scheint sich daran allerdings nicht zu stören. Hast du in der Firma eine besonders abgesicherte Umgebung? Oder stellen sich Windows Clients in einer Domänenumgebung so "zickig" an? Grüsse, gandalf From fli4l at kristov.de Mon Dec 22 21:32:27 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Mon, 22 Dec 2014 21:32:27 +0100 Subject: [fli4l] Paketfilter REDIRECT? References: Message-ID: Hallo! Stefan Sauer schrieb: > Vielen Dank für die schnelle Info, > > wenn das so ist, kommt der REDIRECT ja eine DNAT Regel wie folgender > gleich: > > PF_PREROUTING_2='if:IP_NET_3_DEV:any tmpl:ntp IP_NET_3 any > DNAT:IP_NET_3_IPADDR:123 LOG:lokale_Umleitung' Genau. > > Nehm ich da jetzt besser REDIRECT, oder DNAT? In diesem Falle nimmt sich das nichts (was letztlich im Kernel wirklich schneller ist, kann ich dir nicht sagen). Allerdings könntest du mit einer einzigen REDIRECT-Regel mehrere Interfaces abdecken; im DNAT-Fall brauchst du für jede Netzwerk-Schnittstelle eine separate Regel. Viele Grüße, -- Christoph Schulz [fli4l-Team] From mein-fli4l-postfach at freenet.de Mon Dec 22 21:37:17 2014 From: mein-fli4l-postfach at freenet.de (Stefan Sauer) Date: Mon, 22 Dec 2014 21:37:17 +0100 Subject: [fli4l] =?utf-8?b?UGE/PT0/dXRmLTg/UT9rZXRmaWx0ZXIgUkVESVJFQ1Q/?= References: Message-ID: Super, danke für die Info Christoph, ich hab tatsächlich mehrere Interfaces, dann mach ich das mit REDIRECT: Gruss, gandalf From mein-fli4l-postfach at freenet.de Mon Dec 22 22:06:09 2014 From: mein-fli4l-postfach at freenet.de (Stefan Sauer) Date: Mon, 22 Dec 2014 22:06:09 +0100 Subject: [fli4l] =?utf-8?q?Werden_DCF77_Funkm=3F=3D=3D=3Futf-8=3FQ=3Fodule?= =?utf-8?b?IHZvbSBGbGk0bCB1bnRlcnN0w7x0enQ/PT0/dXRmLTg/UT8/?= Message-ID: Nochmal hallo - Unterstützt die fli4l-Software eigentlich DCF77 Funkempfänger? Und ist das eine sicherere Alternative zum Abgleich über das Internet? Hier ein Beispiel: http://www.gtkdb.de/index_7_1958.html Gruss, gandalf From fli4l at kristov.de Mon Dec 22 23:08:45 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Mon, 22 Dec 2014 23:08:45 +0100 Subject: [fli4l] =?utf-8?q?Werden_DCF77_Funkmodule_vom_Fli4l_unterst=C3=BC?= =?utf-8?q?tzt=3F?= References: Message-ID: Hallo! Stefan Sauer schrieb: > Nochmal hallo - > > Unterstützt die fli4l-Software eigentlich DCF77 Funkempfänger? Und ist > das eine sicherere Alternative zum Abgleich über das Internet? > > Hier ein Beispiel: > http://www.gtkdb.de/index_7_1958.html Claas sollte dir da bessere Auskunft geben können, aber im Repository haben wir das ntp-Paket, das solche Empfänger als Referenzquelle nutzen kann. Allerdings steht da (in der check/ntp.exp): NTP_REFCLOCK_TYPE = 'none|mouseclock-nts|mouseclock-usb-ii|sure|neoclock4x| hopf-seriell' : 'Es werden nur Funkuhren vom Type sure, mouseclock-nts, mouseclock-usb-ii, neoclock4x und hopf-seriell unterstuetzt' Ob das auf diesen Empfänger zutrifft, weiß ich nicht. Ich vermute aber stark, dass alle Empfänger, die unter [1] zu finden sind, unterstützt werden, da das ntp-Paket und die Web-Seite vom selben Autor stammen. [1] http://www.linum.com/support/funkuhr/funkuhren Viele Grüße, -- Christoph Schulz [fli4l-Team] From Hans at Bachner.priv.at Tue Dec 23 02:22:17 2014 From: Hans at Bachner.priv.at (Hans Bachner) Date: Tue, 23 Dec 2014 02:22:17 +0100 Subject: [fli4l] =?utf-8?b?VGVybWluIGbDvHIgZGE/PT0/dXRmLTg/UT9zIFJlbGVh?= =?utf-8?q?se_der_n=C3=A4chsten_st=3F=3D=3D=3Futf-8=3FQ=3Fabilen_fli4l_Ver?= =?utf-8?q?sion_3=2E10=2E?= References: <1owyptyvbmzqw.dlg@lan4me.de> Message-ID: Der Betreff hätte also lauten sollen: "Weihnachten ist diesmal im Januar" :) Vielen Dank ans Team für die umfangreiche Arbeit. Und ein Release-Datum ein paar Tage oder auch Wochen nach dem konventionellen Weihnachts-Termin ist allemal besser als ein Freigabe wegen des "schönen" Datums, bei der die erste Patch-Release schon buchstäblich "vorprogrammiert" ist. Gönnt euch zu Weihnachten eine Verschnaufpause, wir werden die Freigabe erwarten können :) Schöne Grüße, Hans. From fli4l at robert.reschpara.de Tue Dec 23 07:31:11 2014 From: fli4l at robert.reschpara.de (Robert Resch) Date: Tue, 23 Dec 2014 07:31:11 +0100 Subject: [fli4l] =?utf-8?q?Werden_DCF77_Funkmodule_vom_Fli4l_unterst=C3=BC?= =?utf-8?q?tzt=3F?= In-Reply-To: References: Message-ID: Am 22.12.2014 um 22:06 schrieb Stefan Sauer: > Nochmal hallo - > > Unterstützt die fli4l-Software eigentlich DCF77 Funkempfänger? Und ist > das eine sicherere Alternative zum Abgleich über das Internet? Ich denke das DCF77 Funksignal lässt sich leichter 'fälschen' als das Internet (wenn die Firewall einigermaßen vernünftig konfiguriert ist. Wenn du also 'sicher' gehen willst brauchst du eine netzwerkfähige GPS Uhr, denn das GPS-Signal zu fälschen ist alles andere als trivial. Robert From f.stroeter at gmx.net Tue Dec 23 09:04:10 2014 From: f.stroeter at gmx.net (Frank Stroeter) Date: Tue, 23 Dec 2014 09:04:10 +0100 Subject: [fli4l] V3.6.2-UMTS geht nur mit "Warmstart" In-Reply-To: References: Message-ID: Am 19.12.2014 um 17:10 schrieb Frank Stroeter: > Mein Router V3.6.2 mit aktuellem Patch funktioniert mit div. > UMTS Sticks einwandfrei ausser nach einem Stromausfall. > > - Router stromlos keine UMTS Hardware gefunden. > - reboot über Imonc, HTTP oder Konsole und alles funktioniert. Nachtrag: Dieses Problem taucht nicht mit jeder Hardware auf. Getestet auf einem Fujitsu-Siemens Futro S400 o.g. Problem. Getestet auf einem Alix 2D13 keine Probleme. Grüße Frank From babel at fli4l.de Tue Dec 23 10:41:36 2014 From: babel at fli4l.de (Claas Hilbrecht) Date: Tue, 23 Dec 2014 10:41:36 +0100 Subject: [fli4l] =?utf-8?q?Werden_DCF=3F=3D=3D=3Futf-8=3FQ=3F77_Funkmodule?= =?utf-8?b?IHZvbSBGbGk0bCB1bnQ/PT0/dXRmLTg/UT9lcnN0w7x0enQ/?= References: Message-ID: Da die Funkuhr von Dir den "mode 5" nutzt wird die DCF77 Funkuhr nicht direkt funktionieren. Aber Du kannst einfach die Prüfung entsprechend erweitern in in opt/etc/rc.d/rc900.ntp einen der vorhandenen Einträge kopieren und anpassen. Im Grunde reicht es das Du den "mode 5 -> server 127.127.08.0 mode 5 iburst" mit in die ntp.conf bekommst. From fli4l at trikone.han.de Tue Dec 23 19:47:11 2014 From: fli4l at trikone.han.de (Alexander Bahlo) Date: Tue, 23 Dec 2014 19:47:11 +0100 Subject: [fli4l] =?utf-8?q?Termin_f=C3=BCr_das_Release_der_n=C3=A4chsten_s?= =?utf-8?q?tabilen_fli4l_Version_3=2E10=2E?= References: <1owyptyvbmzqw.dlg@lan4me.de> Message-ID: Am 23.12.2014, 02:22 Uhr, schrieb Hans Bachner : > Gönnt euch zu Weihnachten eine Verschnaufpause, wir werden die Freigabe > erwarten können :) Danke an das ganze Team und ich erwarte in Freude das kommende Release! Ich wünsche allen Lesern eine frohe Verschnaufpause^H^H^H^H^H^H^H Weihnachtstage und einen guten Rutsch ins neue Jahr! Alles Gute, Alexander. From f.stroeter at gmx.net Tue Dec 23 21:31:11 2014 From: f.stroeter at gmx.net (Frank Stroeter) Date: Tue, 23 Dec 2014 21:31:11 +0100 Subject: [fli4l] v3.6.2 mit ovpn Message-ID: Hallo Leute, ich kämpfe mit 2 Routern die via ovpn miteinander verbunden sind (sein sollen). 2x v3.6.2 mit Patch und div. Paketen. Router 1: 5 vpn Tunnel u.a. 1 Roadwarrior und 1x vpn-Client zu Router 2 Router 2: 2 vpn Tunnel 1x Roadwarrior 1x vpn-Server von Router 1 Router 1 geht nach reboot nur online, wenn aus dem Netz dahinter Anfragen kommen (warum auch immer. Kenn ich nicht, alle meine Router gehen nach reboot freiwillig online). Aktualisiert dann seine IP via dyndns. Router 2 geht nach reboot online, aktualisiert seine IP via dyndns. Mit dem Roadwarrior kann ich zu beiden eine Verbindung aufbauen. Router 1 baut keinen Tunnel zu 2 auf, da er die aktuelle IP nicht kennt. Beende ich die vpn-Verbindung und starte sie neu klappt auch der Tunnel (mit aktueller IP). Router 1 trenne ich die dsl-Verbindung und verbinde wieder baut sich auch der vpn-Tunnel auf. Router 2 trenne ich die dsl-Verbindung und verbinde wieder baut sich kein Tunnel auf. Router 1 zeigt im vpn-log immer nur die alte IP. Ich habe Router 1 schon komplett neu gebaut, leider kein Erfolg. Weiß jemand Rat? Grüße Frank From fli4l at kristov.de Tue Dec 23 23:05:55 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Tue, 23 Dec 2014 23:05:55 +0100 Subject: [fli4l] v3.6.2 mit ovpn References: Message-ID: Hallo! Frank Stroeter schrieb: > Hallo Leute, > > ich kämpfe mit 2 Routern die via ovpn miteinander verbunden sind > (sein sollen). > 2x v3.6.2 mit Patch und div. Paketen. > > Router 1: 5 vpn Tunnel u.a. 1 Roadwarrior und 1x vpn-Client zu Router 2 > Router 2: 2 vpn Tunnel 1x Roadwarrior 1x vpn-Server von Router 1 > > Router 1 geht nach reboot nur online, wenn aus dem Netz dahinter > Anfragen kommen (warum auch immer. Kenn ich nicht, alle meine Router > gehen nach reboot freiwillig online). Aktualisiert dann seine IP > via dyndns. > > Router 2 geht nach reboot online, aktualisiert seine IP via dyndns. Da beide Router sich anscheinend nur via DynDNS-Namen kennen, könnten die Kommentare in FFL-397 relevant sein [1], insbesondere der Verweis auf OPENVPN_DEFAULT_PERSIST_REMOTE_IP='no'. [1] https://ssl.nettworks.org/bugs/browse/FFL-397 Viele Grüße, -- Christoph Schulz [fli4l-Team] From f.stroeter at gmx.net Tue Dec 23 23:58:06 2014 From: f.stroeter at gmx.net (Frank Stroeter) Date: Tue, 23 Dec 2014 23:58:06 +0100 Subject: [fli4l] v3.6.2 mit ovpn In-Reply-To: References: Message-ID: Am 23.12.2014 um 23:05 schrieb Christoph Schulz: > Da beide Router sich anscheinend nur via DynDNS-Namen kennen, könnten die > Kommentare in FFL-397 relevant sein [1], insbesondere der Verweis auf > OPENVPN_DEFAULT_PERSIST_REMOTE_IP='no'. > > [1] https://ssl.nettworks.org/bugs/browse/FFL-397 Hallo Christoph, das scheint zu funktionieren. Ich werde noch etwas testen und berichten. Ich habe eine ähnliche Konstellation mit älteren Versionen (3.2.3 und 3.6.1), die läuft einwandfrei. Seltsam! Auf jedenfall vielen Dank Grüße Frank From f.stroeter at gmx.net Wed Dec 24 00:13:06 2014 From: f.stroeter at gmx.net (Frank Stroeter) Date: Wed, 24 Dec 2014 00:13:06 +0100 Subject: [fli4l] =?utf-8?q?Sicherheitsl=C3=BCcken_in_NTP?= In-Reply-To: References: Message-ID: Am 20.12.2014 um 18:03 schrieb Christoph Schulz: > Hallo! > > Friedrich Bartel wrote: > >>> http://www.golem.de/news/zeitserver-sicherheitsluecken-in-ntp-1412-111296.html >> >> >> >> Wie sieht es bei Chrony aus das verwendet doch auch NTP. > > Soweit ich den Artikel verstehe, ist nur die Referenz-Implementierung > betroffen. Das ist auch heute mit FFL-1130 abgefrühstückt worden. > > > Viele Grüße, > Hallo Christoph, könntest Du das bitte etwas genauer erklären. Müssen wir uns nun Gedanken machen? Das Thema wird in der Presse ja doch recht hoch gekocht. Viele Grüße Frank From fli4l at kristov.de Wed Dec 24 15:56:06 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Wed, 24 Dec 2014 15:56:06 +0100 Subject: [fli4l] =?utf-8?q?Sicherheitsl=C3=BCcken_in_NTP?= References: Message-ID: Hallo! Frank Stroeter schrieb: > Hallo Christoph, > > könntest Du das bitte etwas genauer erklären. > Müssen wir uns nun Gedanken machen? > Das Thema wird in der Presse ja doch recht hoch gekocht. Es gibt verschiedene Implementierungen des NTP-Protokolls. Bei den Bugs geht es um eine Implementierung von der Network Time Foundation (NTF) (http://www.ntp.org/). Auf dem fli4l kommt jedoch eigentlich* nur chrony zum Einsatz, der von diesem Fehler nicht betroffen ist, da es sich um eine völlig andere Implementierung handelt. * Im Repository haben wir auch ein ntp-Paket, das auf der NTF- Implementierung aufbaut. Aber wir paketieren das noch nicht offiziell, weil das Paket u.a. noch nicht dokumentiert ist. Für dieses Paket haben wir aber die NFT-ntp-Version auf die Version 4.2.8 angehoben. Viele Grüße, -- Christoph Schulz [fli4l-Team] From FrBartel at hotmail.com Wed Dec 24 22:09:00 2014 From: FrBartel at hotmail.com (Friedrich Bartel) Date: Wed, 24 Dec 2014 22:09:00 +0100 Subject: [fli4l] =?utf-8?q?Sicherheitsl=C3=BCcken_in_NTP?= In-Reply-To: References: Message-ID: Am 24.12.2014 um 15:56 schrieb Christoph Schulz: > Hallo! > > Frank Stroeter schrieb: > > > Es gibt verschiedene Implementierungen des NTP-Protokolls. Bei den Bugs geht > es um eine Implementierung von der Network Time Foundation (NTF) > (http://www.ntp.org/). Auf dem fli4l kommt jedoch eigentlich* nur chrony zum > Einsatz, der von diesem Fehler nicht betroffen ist, da es sich um eine > völlig andere Implementierung handelt. > > * Im Repository haben wir auch ein ntp-Paket, das auf der NTF- > Implementierung aufbaut. Aber wir paketieren das noch nicht offiziell, weil > das Paket u.a. noch nicht dokumentiert ist. Für dieses Paket haben wir aber > die NFT-ntp-Version auf die Version 4.2.8 angehoben. > > > Viele Grüße, > Bedeutet, Chrony ist ein NTF-Client und ruft die Zeit nur bei den Zeitservern ab, die eventuell auch diesen Bug haben könnten. Der Chrony-Dienst ist also sicher, wenn er die Zeit weitergibt. OK, danke an das vorausschauende Team. Friedrich PS: Schöne Weihnachtszeit und bitte nicht programmieren. Diese Zeit gehört der Familie und den Freunden. From fli4l at kristov.de Thu Dec 25 10:37:25 2014 From: fli4l at kristov.de (Christoph Schulz) Date: Thu, 25 Dec 2014 10:37:25 +0100 Subject: [fli4l] =?utf-8?q?Sicherheitsl=C3=BCcken_in_NTP?= References: Message-ID: Hallo! Friedrich Bartel schrieb: > Bedeutet, Chrony ist ein NTF-Client und ruft die Zeit nur bei den > Zeitservern ab, die eventuell auch diesen Bug haben könnten. Ja und nein -- Chrony ist natürlich für deine Rechner im LAN auch ein NTP- *Server*. > > Der Chrony-Dienst ist also sicher, wenn er die Zeit weitergibt. Soweit man weiß, ja. Viele Grüße, -- Christoph Schulz [fli4l-Team] From no_html.max50kb at nurfuerspam.de Fri Dec 26 11:05:53 2014 From: no_html.max50kb at nurfuerspam.de (Matthias Taube) Date: Fri, 26 Dec 2014 11:05:53 +0100 Subject: [fli4l] =?utf-8?q?Werden_DCF77_Funkmodule_vom_Fli4l_unterst=C3=BC?= =?utf-8?q?tzt=3F?= In-Reply-To: References: Message-ID: Am 22.12.2014 um 22:06 schrieb Stefan Sauer: > Unterstützt die fli4l-Software eigentlich DCF77 Funkempfänger? Und ist > das eine sicherere Alternative zum Abgleich über das Internet? Für meinen selbstgebauten Empfänger war der Treiber schnell geschrieben. Ich habe das aber schon lang nicht mehr im Einsatz. Für und wieder: + DCF ist in Deutschland "per Gesetz" die gesetzliche Zeit (Einheiten- und Zeitgesetz, BGBl. I 1985 S. 408) - die Auflösung ist äußerst gering (ein Bit pro Sekunde), man benötigt nicht nur eine Minute, um das komplette Datentelegramm zu bekommen. Für anspruchsvolle Synchronisierungen ist diese Signalhäufigkeit ebenfalls nicht zu gebrauchen. - Der Sender wird bei Gewitter auch schon mal abgeschaltet Mein Fazit: Verwende lieber den Zeitserver der PTB im Internet. mfg Matthias From fli4l at robert.reschpara.de Fri Dec 26 13:52:35 2014 From: fli4l at robert.reschpara.de (Robert Resch) Date: Fri, 26 Dec 2014 13:52:35 +0100 Subject: [fli4l] =?utf-8?q?Werden_DCF77_Funkmodule_vom_Fli4l_unterst=C3=BC?= =?utf-8?q?tzt=3F?= In-Reply-To: References: Message-ID: Am 26.12.2014 um 11:05 schrieb Matthias Taube: > Am 22.12.2014 um 22:06 schrieb Stefan Sauer: > >> Unterstützt die fli4l-Software eigentlich DCF77 Funkempfänger? Und ist >> das eine sicherere Alternative zum Abgleich über das Internet? > > Für meinen selbstgebauten Empfänger war der Treiber schnell geschrieben. > Ich habe das aber schon lang nicht mehr im Einsatz. > Für und wieder: > > + DCF ist in Deutschland "per Gesetz" die gesetzliche Zeit (Einheiten- > und Zeitgesetz, BGBl. I 1985 S. 408) > > - die Auflösung ist äußerst gering (ein Bit pro Sekunde), man benötigt > nicht nur eine Minute, um das komplette Datentelegramm zu bekommen. Für > anspruchsvolle Synchronisierungen ist diese Signalhäufigkeit ebenfalls > nicht zu gebrauchen. Die 'Auflösung' ist im Bereich von +-10-15ms bei seriellen Detector-Empfängern und darunter bei 'besseren'. Was du hier meinst ist die Übertragungsrate. Diese hat aber erstmal nur Einfluss auf die initiale Synchronisierung und nicht auf die Genauigkeit. Hinkendes Beispiel GPS braucht für einen Sync auch mindestens 30 Sekunden um den Almanach zu beziehen - und ist trotzdem bei guten Empfängern dann um die 5-10 Meter genau. aGPS kürzt diesen Teil über das Internet ab. 30 Sekunden bei Lichtgeschwindigkeit (was ja die Referenz hier ist) wären aber schon 9 Millionen km. Du siehst dass dieses super-hinkende Beispiel schon zeigt dass Bitrate nicht unbedingt die mögliche Genauigkeit darstellt. > - Der Sender wird bei Gewitter auch schon mal abgeschaltet Eine ordentliche DCF Uhr (nicht die seriellen/billigen) haben eine Uhr die bei Ausfall weiterläuft - Diese verwendet dann auch einen Quarzofen um möglichst genau zu sein und wird auch durch die bei vorhandenem Empfang eintreffenden DCF-Signale nachjustiert sodass man hier auch bei längerer Unterbrechung noch im geringen ms Bereich bleiben kann. gute GPS-Uhren können hier sogar auf einen Drift von wenigen ms auf ein _JAHR_ offline kommen. > Mein Fazit: Verwende lieber den Zeitserver der PTB im Internet. Das funktioniert idr. auch ganz gut. Robert From no_html.max50kb at nurfuerspam.de Sat Dec 27 12:02:52 2014 From: no_html.max50kb at nurfuerspam.de (Matthias Taube) Date: Sat, 27 Dec 2014 12:02:52 +0100 Subject: [fli4l] =?utf-8?q?Werden_DCF77_Funkmodule_vom_Fli4l_unterst=C3=BC?= =?utf-8?q?tzt=3F?= In-Reply-To: References: Message-ID: Am 26.12.2014 um 13:52 schrieb Robert Resch: >> - die Auflösung ist äußerst gering (ein Bit pro Sekunde), man benötigt >> nicht nur eine Minute, um das komplette Datentelegramm zu bekommen. Für >> anspruchsvolle Synchronisierungen ist diese Signalhäufigkeit ebenfalls >> nicht zu gebrauchen. > > Die 'Auflösung' ist im Bereich von +-10-15ms bei seriellen > Detector-Empfängern und darunter bei 'besseren'. Was du hier meinst ist > die Übertragungsrate. Diese hat aber erstmal nur Einfluss auf die > initiale Synchronisierung und nicht auf die Genauigkeit. Nein, bei einem Signal pro Sekunde hat die interne Uhr halt eine Sekunde Zeit zu driften, bevor sie wieder auf die exakte Zeit gesetzt wird. Wenn man mehrere verteilte Rechner synchron halten muss, kann dieses je nach Anwendung schon zuviel sein. Bei meiner damaligen Anwendung ging es um verteilte Sendeanlagen (Gleichwellennetz, Single Frequency Network), bei der DCF nicht ausreichend war. > Eine ordentliche DCF Uhr (nicht die seriellen/billigen) haben eine Uhr > die bei Ausfall weiterläuft - Diese verwendet dann auch einen Quarzofen > um möglichst genau zu sein und wird auch durch die bei vorhandenem Das kann dann evtl. tatsächlich eine bessere Alternative als das NTP-Signal aus dem Internet sein. mfg Matthias From fli4l at robert.reschpara.de Sun Dec 28 11:36:09 2014 From: fli4l at robert.reschpara.de (Robert Resch) Date: Sun, 28 Dec 2014 11:36:09 +0100 Subject: [fli4l] =?utf-8?q?Werden_DCF77_Funkmodule_vom_Fli4l_unterst=C3=BC?= =?utf-8?q?tzt=3F?= In-Reply-To: References: Message-ID: Am 27.12.2014 um 12:02 schrieb Matthias Taube: >> Die 'Auflösung' ist im Bereich von +-10-15ms bei seriellen >> Detector-Empfängern und darunter bei 'besseren'. Was du hier meinst ist >> die Übertragungsrate. Diese hat aber erstmal nur Einfluss auf die >> initiale Synchronisierung und nicht auf die Genauigkeit. > > Nein, bei einem Signal pro Sekunde hat die interne Uhr halt eine Sekunde > Zeit zu driften, bevor sie wieder auf die exakte Zeit gesetzt wird. Man kann aber messen wie weit die Uhr driftet und das mit korrigieren. Dauert halt ggf. ein paar Stunden/Tage um den Drift genau zu bestimmen und wird schwierig wenn der Drift aufgrund eines grottigen Quarzes einen übel hohen Jitter hat. > Wenn man mehrere verteilte Rechner synchron halten muss, kann dieses je > nach Anwendung schon zuviel sein. Bei meiner damaligen Anwendung ging es > um verteilte Sendeanlagen (Gleichwellennetz, Single Frequency Network), > bei der DCF nicht ausreichend war. Da brauchst aber schon Phasensynchronität wo Ethernet schon als Sync-Medium ausscheidet. Hier hast du schon extreme Probleme dass die Lichtgeschwindigkeit etwas 'lahm' ist. Robert