Posts by miriki

    Wenn Linux/Unix auch die Windows Sonderzeichen von Dateinamen "richtig", also in UTF8 behandeln und anzeigen soll, musst Du das beim Mounten mit der Zeichenumwandlungsoption bekanntgeben.


    Wann wo wie genau? Wie gesagt: Die Platte hängt an einem Windows-Rechner und wird über's Netz gemounted.
    Es hängt keine von Windows beschriebene Platte direkt am RasPi.


    Und ein "ls -la" auf das Mount erzeugt korrekte Darstellung, siehe Screenshot. Erst, wenn ich das Verzeichnis per PHP einlese und über Apache an den Client ausgebe, wird's Murks.


    Nochmal: Windows Apache braucht das utf8_encode der (eigenen) Dateinamen, sonst kommt Murks raus. Der RasPi wiederum reagiert allergisch darauf und produziert den Murks durch ebendieses encode. Bei der Übertragung vom Windows-Server auf den RasPi-Server aber alle Scripte anzupassen, ist nicht unbedingt ein gangbarer Weg. Ich würde lieber die Rahmenbedingungen so anpassen, daß die Scripte sich auf beiden gleich verhalten.


    Gruß, Michael

    Moinsens!


    Ich bin vor ein paar Tagen über ein Problem gestolpert, bei dem ich nicht so recht weiter weiß: Es geht um ein (etwas umfangreicheres, mehrere Klassen) PHP-Script, das schon seit einiger Zeit klaglos läuft, aber jetzt bei einer Transformation Ärger macht. Mal zuerst die Basics:


    a) Da ist ein Windows-10-Server 192.168.1.20 mit Apache 192.168.2.1, PHP und MySQL. Daran angeschlossen ist u.a. eine externe USB-Festplatte, die im intranet als "video1" freigegeben ist. Windows-Clients haben diese i.a. als V: verbunden, am RasPi hängt die unter /mnt/video1.


    b) Dann ist da noch ein (einer von mehreren) RasPi2 192.168.1.50 (LAN) / .51 (WLAN) mit ebenfalls Apache, PHP und MySql. Der läuft headless, kann aber in der Konfigurations-Phase über Dongle mit Maus und Tastatur versehen und an einem alten TFT angeschlossen werden.


    Auf dem Windows-Apache läuft ein Script, das die HDD nach bestimmten Files scannt und aus dem Dateinamen Meta-Informationen herausliest. Diese werden dann in einem Frameset dargestellt. Soweit so gut...


    Jetzt wollte ich diesen Job, wie einige andere auch, mal auf einen der RasPi umstellen, den ich direkt an die Fritz!Box hängen möchte. Die Platte kann (vorerst) auch gerne am Windows-Rechner bleiben. Vielleicht häng ich sie später auch direkt an den RasPi.


    Jetzt stellt sich aber das Problem, daß Umlaute in den Dateinamen, die vorher vom Windows-Server korrekt dargestellt wurden, am RasPi plötzlich murksig aussehen. Mit einem kleinen Test-Script habe ich das nachvollzogen. Am Windows-Rechner werden die Dateinamen mittels utf8_encode umgewandelt und daraufhin korrekt angezeigt. Laß ich das weg, erscheinen schwarze Rauten mit einem ? drin. Am RasPi aber genau umgekehrt: Mittels utf8_encode erhalte ich Murks-Zeichen (großes A mit Tilde drüber usw.), während die Dateinamen unverändert korrekt dargestellt werden. Und da frag ich mich doch so: Warum?


    index.php - Anpassung Windows / RasPi nur an Zeile mit "$directory = ..."


    Und falls noch jemand in die metatags.txt sehen möchte:


    Warum nicht einfach von beidem ableiten?^^


    Code
    class Button (object, ttk.Button):


    Dann sollte die "property"-Methode auch funktionieren, oder übersehe ich da was?^^


    Oh mein Gott... :wallbash:
    In dem ganzen Gewusel drumherum hab ich dieses Posting glatt übersehen.


    Und es war die einzig richtige Lösung für mein Problem bislang!


    Du hast da gar nichts übersehen. Das habe ich schon ganz alleine geschafft. :blush:


    Ich weiß jetzt nur eins nicht: Macht es einen Unterschied, in welcher Reihenfolge ich ableite? Ich hab mal vorsichtshalber erst ttk.Button, dann object als 2. Parameter dahinter.


    Auf alle Fälle funktioniert damit, nach erstem Test, der Setter für die Property!


    Gruß, Michael

    Ich würde auf jeden Fall eine Datenbank nehmen.


    Ich ebenfalls. Wenn man denn erstmal apache, php und mysql zum Laufen gebracht hat, wird man es nicht mehr missen möchten.


    Quote

    Zu Python und MySQL gibts jede Menge Infos im Web.


    Ich hab mal vor einiger Zeit hier im Beitrag #6 ein Mini-Python-Script gepostet, mit dem eine Tabelle angelegt, mit Daten gefüllt und wieder ausgelesen wird.


    Ansonsten ist das Schreiben in eine CSV-Datei die gleich dahinter 2.beste Wahl. Die läßt sich Anwender-freundlich mit Excel verarbeiten und kann später, wenn man denn doch auf eine Datenbank umschwenken möchte, problemlos dort importieren.


    Und die Kombination, an ggf. sogar mehreren Standorten jeweils, CSV-Dateien zu erzeugen, die dann als Tages-Abschluß gesammelt in die Datenbank gehen, ginge ja auch noch. Und man hat dann mit den CSV-Dateien auch quasi nebenbei ein Backup der Daten.


    Gruß, Michael

    Was du machst hast du zwar wortreich beschrieben - den kompletten, relevanten Code behältst du uns aber nach wie vor vor. Ergo: konkrete Fehlersuche nicht möglich, weil _wir_ nicht sehen, was du machst.


    Ach herrjeh... Es geht doch nicht darum, ob, was und wie ich in den Setter-/Getter-Routinen mache. Geh bitte nochmal zurück zum Eingangs-Posting und lies: Die Getter-/Setter-Methoden werden gleich gar nie nicht aufgerufen. Stell Dir einfach vor, ich hab nur ein 'print "xxx"' drin stehen und sehe nie eine Ausgabe auf der aufrufenden Konsole. Ich bekomme gleichzeitig aber auch keine Fehlermeldung des Hauptprogramms, daß es das Attribut nicht kennen würde. Also _irgendwas_ passiert da ja, nur eben nicht das Gewünschte.


    Quote

    Quote

    [...]dann kann `Foo` alles, was es können muss.


    ... außer Properties. ;)


    Eine exakte Kopie des Setter, nur mit dem anderen Namen "setImgFile", also ohne die beiden _ vorweg, macht ja genau das, was ich will, wenn ich sie denn direkt als public Methode vom Hauptprogramm aus aufrufe.



    Quote

    Quote


    Erschwert? Es ist lediglich ein bisschen mehr getippe, weil man mehr Prefixe braucht.


    Ja. Aber das ist keine Qualitäts-Aussage. Und das mit dem Schlüsselbund im Briefkasten schrieb ich ja schon.


    Nicht vorhandenes, "echtes" private ist kein Feature, sondern fehlende Funktionalität. Und die darauf jetzt wahrscheinlich kommende Antwort "braucht man ja auch nicht" (was, im Übrigen, sehr subjektiv ist): Bill Gates hat seinerzeit mal gesagt: "Mehr als 640 KB Arbeitsspeicher braucht kein Mensch in seinem PC.".



    Gruß, Michael

    Der von dir verlinkte Python-Kurs bezieht sich auf P3 - du nutzt aber nach eigenen Angaben P2.


    Ja, das war mir durchaus bewußt. Deswegen war ja einer meiner ersten Blicke auch, ob die "property" Geschichte womöglich erst mit P3 eingeführt wurde. Dann hätte ich "halbgar" mit public Setter und Getter weiter gemacht. Aber u.a. in dem von mir ja weiter oben schon verlinkten Stack Overflow Artikel stand ja eindeutig: Referenz auf "object" und es funktioniert mit P2.


    Quote

    Attribute und Methoden, die man als nicht öffentlich kennzeichnen möchte, bekommen nur einen führenden Unterstrich. Zwei führenden Unterstriche werden benutzt, wenn man Namenskollisionen mit Subklassen vermeiden möchte


    Ja, so hatte ich es irgendwo anders auch schon mal gelesen. Aber letztendlich paßt es trotzdem, auch wenn die Erklärung vielleicht nicht ganz korrekt ist: Nur 1 _ hindert niemanden daran, die Methode trotzdem aufzurufen, Konvention hin oder her. Das wäre so, als wenn ich mein Cabrio mit offenem Verdeck und offenen Türen auf das Parkdeck stelle, aber einen Zettel "bitte Autoradio drin lassen!" auf den Beifahrersitz lege. Bei 2 _ wird die Sache aber durch das mangling schon bedeutend erschwert. Das ist dann das, was für mich am nächsten an "private" herankommt.



    Quote

    Die richtige Verwendung von `property` - in den Regel nimmt man das als Decorater - wird auch in der offiziellen Python Doku zu P2.7 erklärt: Link. Da steht auch, wie man Attribute (richtig) read-only macht.


    Naja, die @property Syntax finde ich eher unübersichtlich. mit "x = property( ..." habe ich in einer Zeile die direkte Kontrolle über die Schnittstellen-Methoden und kann das auch im Source später einfacher lesen / nachvollziehen. Aber das mag Geschmackssache sein...



    Quote

    Und man kann auch über die Property steuern, dass Werte erst geprüft / verarbeitet / ... werden, bevor sie gesetzt werden.


    Ähm, ja? Und? Genau das mache ich doch jetzt. *verwirrt*


    [code=php]import math


    class Foo(object):[/php]


    Da ist es ja wieder, das böse "object". Mit "class Foo( ttk.Button ):" scheint es ja aber nicht mehr zu gehen. Und genau _das_ war ja meine ursprüngliche Frage... ;)


    Gruß, Michael

    [font="Verdana, sans-serif"]ich habe alles Mögliche probiert, aber leider ohne Erfolg.[/font]


    Das kommt mir bekannt vor...


    Ich hatte in einem anderen Thread hier[font="Verdana, sans-serif"] ein sehr ähnliches (wenn nicht sogar gleiches) Problem geschildert. Aber letztendlich, nach vielem Hin und Her, was soll ich sagen: Es funktioniert noch immer nicht.


    Also freue ich mich schon auf die Lösung, die dann hier zustande kommt. ;-)[/font]


    Gruß, Michael

    miriki: was hast du denn letztendlich vor? Getter und Setter sind in Python unüblich (und in der Regel überflüssig), weil es durch die Bank direkten Zugriff auf Attribut gibt. Warum hast du zwei Underscores vor dem Funktionsnamen?


    Deine zweite Frage ist recht gut hier beantwortet, bevor ich das selbst versuche, zusammenzufassen.


    Setter / Getter benutze ich prinzipiell gerne, vor allem sicherlich auch, weil ich diese Kapselung von anderen Sprachen her einfach gewohnt bin. Es ist aber auch die Kontrolle über die Werte, die ich gerne behalten will. So wird ein Setter gern mal den Werte-Bereich im Auge behalten. Außerdem sind ggf. nach dem Setzen eines Wertes unverzüglich weitere Aktionen notwendig. Eine andere Möglichkeit, auf Veränderung der Attribute zu reagieren, habe ich ja nicht, oder?


    Außerdem möchte ich ungern direkten Zugriff auf gespeicherte sensible Daten (z.B. Paßwort) zulassen - "write-only" nur per Setter ohne Getter. Und es macht auch keinen Sinn, den Temperatur-Wert eines Sensors zu setzen - da macht "read-only" über nur den Getter alleine Sinn. Ja, ich weiß... Auch mit __ läßt sich das alles nur mehr oder weniger stark verschleiern und letztendlich auch umgehen. Aber wenn ich mein Schlüsselbund in meinen Briefkasten werfe, tue ich das absichtlich und bin selbst schuld für die Folgen.


    Hier konkret in diesem Beispiel: mein von ttk.Button abgeleiteter mrk.Button bekommt das neue Attribut "imgfile", in dem ein Dateiname zu einem Bild gespeichert wird. Wenn jetzt ein Dateiname gesetzt wird, dann überprüft der Setter ggf., ob die Datei existiert, ein gültiges Bild ist usw. und setzt ansonsten "None" als Wert, bevor mir nachgeschaltete Routinen unkontrolliert gegen die Wand fahren. (Ja, eine Warnung gebe ich vielleicht zusätzlich auch noch aus...)


    Die könnten natürlich auch alle jeweils jedesmal auf die Existenz / Gültigkeit der Datei prüfen, aber wenn dies in einer Timer-Loop jede Sekunde passiert, killt das die Performance ohne Ende. Da teste ich doch lieber schnell mal auf imgfile != None und verlaß mich ansonsten darauf, daß eine vorgeschaltete Routine (eben dieser Setter) einmal überprüft hat, daß es ein Bild ist, daß ich verarbeiten kann.


    Und wenn ein neuer Dateiname gesetzt wird, dann soll das Bild auch sofort aktualisiert werden, und nicht erst, wenn das nächste Event (Timer, Interrupt, wasauchimmer...) eintritt.



    Aus Performance-Gründen speichere ich das geladene Bild auch intern. Das Bild soll nämlich dynamisch an die Größe des Buttons angepaßt werden. Da will ich aber nicht bei jeder Größenänderung das Bild (von Platte, Netz, Staffelei ;) ...) neu laden.


    Deswegen habe ich
    - property imgfile --> Setter/Getter für self.__imgfile
    - self.__imgfile --> Dateiname
    - self.__bitmap --> Image.open( self.__imgfile )
    - self.__image --> ImageTk.PhotoImage( self.__bitmap )
    - self.onConfigure() --> setzt self['image'] = self.__image nach Anpassung


    Gruß, Michael

    Wenn ich nach "python2 property python3" google gibts einige Themen dazu


    Naja, wenn ich mir den 1. Treffer auf Stack Overflow dazu ansehe (was ich schon vor Erstellen meiner Frage hier übrigens getan habe, den kannte ich also u.a. schon), dann steht dort das, was ich schrieb:


    Der OP fragt nach Problemen mit "class A:", "class B:" und "property" und bekommt den Hinweis, daß er "new-style classes" in Python 2.x benutzen muß, die von "object" abgeleitet sind. Ich will aber nicht von "object", sondern von "ttk.Button" ableiten.


    Und ich will auch nicht unbedingt auf Python 3.x umstellen, weil ich mir damit wahrscheinlich nur noch mehr Probleme neu schaffe. Es sei denn, die Aussage ist definitiv, daß ein Ableiten von ttk.Button mit Benutzung von property _nicht_ _möglich_ ist, dann überleg ich mir das noch mal.


    Gruß, Michael

    Moinsens!


    Ich krieg hier ein Problem mit "property" nicht gelöst und verwende deswegen als Notlösung eine public "Setter" Routine. Ich möchte es aber schon gerne mal als "echte" property zum Laufen kriegen.


    Was ich habe:

    Code
    class Button( ttk.Button ):
    [...]
    def __getImgFile( self ):
    [...]
    def __setImgFile( self, v ):
    [...]
    imgfile = property( __getImgFile, __setImgFile )


    Nun stieß ich beim Suchen nach dem Problem auf den Hinweis mit "old-style" und der Notwendigkeit, Klassen von "object" abzuleiten, damit "property" überhaupt funktioniert. Das scheint mir aber, soweit ich das verstanden habe, darauf gemünzt zu sein, daß früher Klassen gerne als


    Code
    class Button:


    deklariert wurden, also ganz ohne Referenz. Ich will ja aber explizit von ttk.Button ableiten. Da wäre es doch wohl kontraproduktion, stattdessen von object abzuleiten, oder?


    Nichtsdestotrotz: Die properties haben keine Wirkung. Weder Getter noch Setter werden überhaupt durchlaufen. Eine Debug-Ausgabe in den Routinen erfolgt nicht, das Hauptprogramm meldet aber auch keinen Fehler.


    Was muß ich noch beachten / ändern?


    Gruß, Michael

    Wenn von extern ein Ping an die .40 (auch ohne Kabelverbindung) funktioniert hat, dann muss tcpdump (mit dem Filter icmp) diesen Ping auch anzeigen.


    Ich krieg's ums Verrecken nicht mehr nachgestellt. Ich boote frisch mit LAN + WLAN, route zeigt alles richtig an, tcpdump reagiert auf ping von außen. Und dann, irgendwann... ist das Netz tot, komplett, alles wech. Ich find nur keinen direkten Auslöser, zumindest nicht reproduzierbar.


    Wenn der RasPi am Prompt steht, kann ich eine Stunde lang ping auf .40 und .41 absetzen, alles bleibt ok.


    Starte ich aber tcpdump, dann ist das Netz mehr oder weniger schnell weg.



    Quote

    Poste mal die Ausgaben von:

    Code
    systemctl status systemd-networkd networking
    ls -la /etc/init.d/networking
    systemctl is-enabled networking



    a) sagt "Loaded: loaded ... enabled", "active (running)" und "Processing requests...". Er jammert aber über falsche Einträge "IPv6LL" und "LinkLeasedAddressing" in section "Network". Ansonsten sind lo, eth0 und wlan0 "link configured" und "gained carrier".
    Dann kommt aber im letzten Abschnitt ein "Loaded: loaded ..." (ohne "enabled") und ein paar Zeilen drunter "Active: Inactive (dead)".
    Pings on der .10 auf den RasPi .40/.41 werden aber nach wie vor beantwortet.


    b) ergibt

    Code
    -rwxr-xr-x 1 root root 4760 Dez 14 2014 /etc/initd/networking


    c) Und zuletzt dann:

    Code
    Failed to get unit file state for networking service: No such file or directory


    Kein "networking" Service? Und wer antwortet dann auf die Pings?


    Gruß, Michael

    OK, d. h. Du hast immer die Pings auf sich selbst gemeint und nicht Pings von einem anderen Gerät (aus dem WLAN des Routers)? Dann hatte ich das nicht richtig verstanden.


    Nein, nein, schon richtig. Es sei denn, ich versteh Dich jetzt falsch.


    Der .10 ist ein Win10-Rechner. Dieser hängt per LAN an einem Switch, der Switch wiederum am SpeedPort-Router.


    Der .40 ist der RasPi, per LAN über den gleichen Switch im LocalNet, per WLAN als .41 direkt über den SpeedPort im LocalNet.


    Die pings "von außen" waren immer von .10 (an dem sitz ich gerade und tippe diesen Beitrag) auf .40/.41 gemeint. Dieser "auf sich selbst" ping war jetzt nur der Vollständigkeit halber mit aufgeführt.


    Gruß, Michael

    Hast Du auf deinem PI:

    Code
    tcpdump [...]

    vor dem:

    Code
    ping [...]

    gestartet?


    Natürlich, sonst macht das ja wenig Sinn. ;)


    Ich hab jetzt mal ganz frisch den RasPi mit LAN + WLAN neu gestartet, "route" zeigt alles sauber an.


    Dann tcpdump gestartet.


    Dann vom Win10-DOS das "ping" auf .40 (eth0) gestartet


    Ergebnis: 4 Antworten vom RasPi, 8 (wenn ich das richtig sehe) 3-zeilige Reaktionen auf dem RasPi parallel dazu.


    Dann vom Win10 noch den ping auf .41 (wlan0)


    Ergebnis: 4x Zeitüberschreitung, keine Reaktion auf dem RasPi.


    Nach Ctrl-C sagt tcpdump auch noch was von 8 packets.


    Danach war auf dem RasPi das Netz tot. Er war auch auf .40 nicht mehr erreichbar und "route" machte auch wieder Mucken, ping raus auf 192.168.1.1 ergibt nur noch "Destination Host Unreachable".


    Ein ping auf sich selbst, also vom RasPi auf .40 oder .41, funktioniert.


    Das ganze spielte sich innerhalb 1 Minute nach Reboot des RasPi ab.


    Gruß, Michael

    Schau mal in der FritzBox nach, ob der Ping ohne Kabel zu .40, evtl. über das wlan0-Interface (.41) umgeleitet wird.


    Ich wüßte jetzt nicht, wo ich das auf meinem SpeedPort-Router nachsehen könnte. Ich wüßte aber auch nicht, wo ich das vorher auf meiner Fritz!Box (7270v3) hätte nachsehen können.


    Quote

    Mit tcpdump kannst Du es auch auf deinem PI anschauen:


    Code
    sudo tcpdump -vvveni eth0 icmp


    Nachdem ich das nachinstallert habe, erzeugt der Befehl _null_ Reaktion auf dem Bildschirm. Also irgendwie fühlt sich da rein gar nichts angesprochen. Auch nach Ctrl-C kommt nur "0 packets ..." in den 3 Zeilen der Ausgabe.



    Quote

    BTW: Es heißt ja nicht umsonst, dass man auf einem Gerät, keine 2 Interfaces in einem Subnetz konfigurieren soll.


    Hups? Das hör ich jetzt zum ersten mal. Und ich hab früher schon mehrere Interfaces unter Linux auf einer Kiste betrieben. Das war allerdings noch Anfang der 90er unter SUSE mit bis zu 4 Ethernet (3Com) in einem Rechner. Und die liefen alle im selben Subnetz.


    Da hatte ich dann aber "der Ordnung halber" dann später irgendwann die NICs in verschiedene Subnetze verschoben. Und deswegen meinte ich auch, daß man dann die Netzmaske anpassen muß. Ich erinner mich, daß ich mit /24 dann Probleme hatte und auf /16 ändern mußte. Aber ist lange her und die Erinnerung trübe.


    Gruß, Michael


    PS: Jetzt ist es wieder so weit: Boot mit WLAN und LAN, alles ging, dann LAN abgezogen, ping machte fröhlich weiter, aber jetzt dann nach einiger Zeit: Komplettes Netz tot, auch nach Einstöpseln vom LAN bleibt das Netz weg.


    Boot mit LAN alleine macht Pause beim Boot, aber Netz ist stabil. Boot mit WLAN alleine macht keine Pause, aber auch kein Netz danach.


    Das verd... WLAN ist alleine einfach nicht überlebensfähig.


    Die Seite kannte ich schon, aber die Erklärungen sind dort etwas "dünne". Auf elektronik-kompendium wird der gleiche Inhalt, soweit ich das erkennen kann, beschrieben, aber eben in den kleinen Details etwas ausführlicher. Während auf der Wiki nur steht "Dienst abschalten" steht auf EK eben auch, mit welchem Befehl oder in welcher Datei das geschieht.


    Zumindest konnte ich im eigentlichen Inhalt keinen Unterschied zwischen den beiden Seiten sehen. Oder hab ich was übersehen? Wie gesagt, mein Ablauf (1. Post) ist von EK. Wenn ich da was ggü. dem Wiki anders machen sollte, hab ich das nicht gesehen.


    Gruß, Michael
    Automatisch zusammengefügt:[hr]

    Code
    root@raspi002:~# route
    
    
    Kernel-IP-Routentabelle
    Ziel          Router         Genmask         Flags   Metric   Ref   Use   Iface
    default       speedport.ip   0.0.0.0         UG      0        0     0     wlan0
    default       speedport.ip   0.0.0.0         UG      0        0     0     eth0
    192.168.1.0   *              255.255.255.0   U       0        0     0     wlan0
    192.168.1.0   *              255.255.255.0   U       0        0     0     eth0


    So sieht's aus, nachdem ich mit LAN + WLAN frisch gebootet habe.


    Ich bin mir nicht sicher, ob es jetzt stabil ist, aber ein paar Tests heute nachmittag verheißen Gutes, wenn auch nicht unbedingt Richtiges. ;)


    Status jetzt: Nach dem Boot wie oben beschrieben, alles geht, der RasPi ist von einem anderen Rechner (Windows 10 auf 192.168.1.10 im DOS-Fenster) per "ping" auf beiden Adressen erreichbar. Alles gut...


    Jetzt kommt die Twilight Zone... Ein Zustand, mit dem ich leben kann, der mir aber nicht richtig erscheint... Ich ziehe das eth0 vom RasPi ab und rufe (mehrmals, 2 Minuten lang) "route" auf. Das Ergebnis bleibt unverändert das obige, die beiden eth0-Zeilen verschwinden nicht aus dem Routing. Und: Der RasPi ist nach wie vor auf _beiden_ IPs per "ping" erreichbar. und liefert Antworten innerhalb 2..3ms. Warum?


    Dann stöpsel ich das eth0 wieder ein und rufe wieder 2 Minuten lang "route" auf. Es bleibt nach wie vor unverändert - alle 4 Zeilen werden aufgelistet. Auch "ping" liefert von beiden IP des RasPi eine Antwort. Der RasPi hat vom Ein- und Ausstöpseln des eth0 irgendwie überhaupt nichts mitbekommen. Welcher Wichtel hat aber ohne eth0-Kabel den "ping" auf der .40 beantwortet? Und über welches Interface (kann ja nur noch wlan0 gewesen sein)? Und warum?


    Jetzt der "hakelige" Teil: Es wird wlan0 abgezogen. Prompt fliegen zwei Zeilen aus der "route" Anzeige, es bleiben nur noch die beiden für eth0 erhalten. Das sieht schonmal richtig aus. Der RasPi scheint aber bummelig 30 Sekunden zu brauchen, um mit der neuen Situation klar zu kommen. Zunächst ist ein "ping" auch auf der .41 (wlan0) noch teilweise erfolgreich. Aber es kommt schon mal ein "Host nicht erreichbar". Aber auch auf der .40 (eth0) kommt es jetzt zwischendurch zu Timeouts. Aber nach ca. 30..40 Sekunden hat sich das eingespielt, .40 antwortet stabil und .41 nicht (mehr) auf "ping".


    Und als letztes kommt wlan0 jetzt wieder ran: Die 2 Zeilen im "route" werden prompt wieder mit angezeigt, alle 4 sind wieder da und es wird auch nach wie vor "default" und "speedport.ip" (statt "0.0.0.0" und "192.168.1.1") angezeigt. Letzteres wäre, zusammen mit der Anlauf-Pause von "route" ja wieder das Zeichen, daß das Netzwerk nicht mehr erreichbar ist. Aber nein: Beide IPs sind, zumindest nach 30..40 Sekunden stabil, wieder per "ping " erreichbar und auch der RasPi selbst kann sauber nach z.B. http://www.google.de pingen.


    Im Moment läuft es also. Ich weiß bloß mal wieder nicht, warum... Die letzte Änderung dürfte das Deaktivieren von IPv6 gewesen sein. Und wenn .40 auf "ping" antwortet, obwohl kein Netzkabel in der Buchse steckt, dann ist das auch irgendwie nicht richtig.


    Aber vielleicht gibt's hier ja noch 'n schlauen Kopf, der da Licht ins Dunkel bringen kann.


    Gruß, Michael
    Automatisch zusammengefügt:[hr]

    Im Moment läuft es also.


    Zu früh gefreut...


    Nachdem ich jetzt nochmal das eth0 abgezogen hatte, war auch wlan0 ohne Funktion. Im Routing wurde "default" und "192.168.1.1" (schlechtes Zeichen) angezeigt, aber alle 4 Zeilen aufgelistet. Der RasPi war aber auf beiden IPs nicht mehr erreichbar und ein "ping" vom RasPi aus ging auch nicht mehr.


    Aber: Nachdem eth0 wieder eingestöpselt war, lief wieder alles rund. Alle 4 Zeilen im "route", auch wieder mit "speedport.ip" (gutes Zeichen), das "ping" auf beide IPs usw.


    Gna gna gna


    Gruß, Michael

    Das geht z. B. mit:

    Code
    ipv6.disable=1


    in der Zeile der /boot/cmdline.txt


    Ah, damit ist IPv6 dann gants deaktiviert? Die gänse Konfiguration kann sich dann auf IPv4 beschränken? Das klingt dann ja gans einfach so, werd ich gleich mal ausprobieren. Danke! ;)


    Gruß, Michael

    pi@raspberrypi:~ $ cat /etc/systemd/network/mylan.network


    Mal 'ne grundsätzliche Frage: Braucht man nicht für jedes Interface eine .network Datei? Ich hab eine
    "eth0.network" und eine "wlan0.network". Beide sehen fast gleich aus, unterscheiden sich nur in "Name" und "Address":


    Die Namensgebung Deines .network Files klingt ja eher so, als wenn es nur _eine_ Konfiguration für das gesamte Netzwerk gibt.


    Beim DHCP Eintrag sind sich die Leute wohl uneinig über "no" oder "none", deswegen habe ich beide drin. ;) Deine beiden Einträge für IPv6LL und LinkLocalAddressing werd ich mal übernehmen und mal nachschauen, was sie bewirken.


    IPv6 würde ich sowieso erstmal ganze gerne irgendwie komplett aus der ganzen Geschichte heraus bekommen. Da fehlt mir aber noch ein bißchen der Leitfaden.


    Gruß, Michael

    welches Interface soll er denn nehmen? eth0 oder wlan0?


    Is' mir doch egal! ;)


    Ne, im Ernst: Genau mit _dieser_ Situation funktioniert es ja gerade eben noch so. Ich kann zwar nicht sagen, über welches Interface der ping jetzt raus und wieder zurück kommt, aber es liefert Antworten.


    "ip r" sagt dazu:

    Code
    default via 192.168.1.1 dev wlan0
    default via 192.168.1.1 dev eth0
    192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.41
    192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.40


    Und das wiederum, denke ich mal, sieht ja geradezu wieder gut aus, oder? Source .40 geht über eth0 und Source .41 über wlan0 - so wie gewollt.


    Quote

    Wenn Du mal die beiden Einträge für wlan0 löscht, geht's wieder, oder?


    Da wäre meine Frage: Wie? Tipp-Ex auf den Monitor fällt aus, oder? ;)


    Wie gesagt: So wie o.a. funktioniert es ja. Und wenn ich wlan0 abstöpsel, geht's ebenfalls noch - und die beiden wlan-Zeilen bei "route" sind dann auch weg.


    Quote

    dumm ist, dass beide Interfaces im selben Netzsegment liegen.


    Ich hatte schon überlegt, ob es (hier generell) Sinn macht, die WLAN-Geräte pauschal in ein anderes Netz zu packen. Also 192.168.1.* für LAN und 192.168.2.* für WLAN. Dann muß aber überall die Netzmaske auf 255.255.0.0 bzw /16 angepaßt werden, richtig?



    Quote

    ich glaube, das kann man über die metric beeinflussen.


    Tja, die metric... Da hab ich auch mal versucht, ein bißchen mehr drüber zu verstehen. Das war, als ich versucht habe, per if-up / if-down die default-route auf das jeweils andere Interface umzustellen. Das war noch, als ich das Netz über die "interfaces" Datei konfiguriert hatte. Und da sollte, wenn beides aktiv ist, das eth0 über die metric priorisiert werden. Klappte aber auch nicht. Auf meinem raspi001 sind noch die ganzen Versuche dieser Methode in den Files zu sehen. Deswegen wollte ich jetzt mal raspi002 "stilgerecht" nach aktueller Technik über systemd konfigurieren.



    Quote

    Evtl. findest Du ja im Netz einen Lösungsansatz ... Du hast ja mal ein paar Stichpunkte zur Suche.


    Glaub mir, bevor ich hier gefragt habe, hatte ich mich einige Abende in Zusammenarbeit mit Google damit beschäftigt. Da wird gerne immer wieder mal darauf hingewiesen, daß "interfaces" seit Jessie "deprecated" ist und im gleichen Atemzug wird die Konfiguration über genau diesen Weg erklärt. Das elektronik-kompendium bot bislang die m.M.n. sauberste Anleitung für systemd. Aber leider will ja auch die nicht so recht. Und dabei habe ich ja nicht mal exotische Hardware. Nach meinen anfänglichen Problemen mit meinen alten Fritz!-Sticks habe ich mir ja extra mal 2 der "official" gekauft, um zumindest das Problem auszuschließen. Pustekuchen...


    Gruß, Michael