Beiträge von swissflyer

    Weil mehrere DHCP-Server in einer Konstellation, immer eine Fehlerquelle sein können und es hier ja nur um einen einzigen DHCP-Client (das iPad) geht. Machbar ist das schon, aber die 2 DHCP-Server (PI und Router) dürfen sich dann "nicht in die Quere kommen".

    Achso – ja das macht dann wiederum Sinn. In diesem Falle belasse ich die statische IP auf dem iPad so und lasse auch die AdHoc-Einstellungen bestehen wie sie sind.

    cat /etc/systemd/network/08-wifi.network

    Code
    [Match]
    Name=wl*
    
    [Network]
    Address=192.168.2.1/24

    manpage für systemd.network.

    Okay – da schaue ich mal rein.

    So wie es aussieht, wäre die Lösung damit das AdHoc-Lan, wie auch das normale Lan (eth0) korrekt laufen würde, der DHCP-Server. Ich verstehe daher nicht, warum du diesen nicht in Betrieb nehmen würdest?

    Die Ausgaben:

    systemctl status systemd-networkd

    ls -la /etc/systemd/network

    Code
    insgesamt 12
    drwxr-xr-x 2 root root 4096 Nov 30 12:21 .
    drwxr-xr-x 5 root root 4096 Nov 28 21:41 ..
    -rw-r--r-- 1 root root   52 Nov 30 12:21 08-wifi.network
    lrwxrwxrwx 1 root root    9 Sep 26 02:09 99-default.link -> /dev/null



    ps aux | grep -i [d]hc

    -> Das ergibt keine Ausgabe

    Kannst Du lokal auf dem iPad, diese feste IP-Adresse nicht persistent/dauerhaft konfigurieren?

    Doch das geht schon – das iPad merkt sich die Einstellungen des jeweiligen WLAN-Netzwerkes. Aber die Lösung mit DHCP wäre doch etwas eleganter, oder hätte ich durch dessen Aktivierung irgendwelche Nachteile?

    dort einen DHCP-Server konfigurieren.

    GIbt es diesbezüglich irgendwelche Anleitungen? Bis jetzt ist die Buster-Installation noch sehr "sauber" und ich möchte da jetzt nichts mehr verkonfigurieren.


    Hier noch die Ausgaben:

    ip a

    route -n

    Code
    Kernel-IP-Routentabelle
    Ziel            Router          Genmask         Flags Metric Ref    Use Iface
    192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0

    ip n s

    Code
    192.168.2.5 dev wlan0 lladdr e4:98:d6:95:f6:ac STALE

    Welche IP-Adresse hat das Gerät mit dem VNC-Viewer?

    Es ist ein iPad und so wie es aussieht, bekommt es keinerlei Netzwerk-Informationen vom AdHoc-Netzwerk mitgeteilt.

    EDIT:

    Habe gerade dem iPad manuell eine IP-Adresse im gleichen Subnet zugewiesen (inkl. Netmask & Gateway) und siehe da: so kann ich mich mit dem PI über VNC verbinden... Das ist schon einmal ein grosses Ergebnis für mich, heisst das doch, dass die vorherigen Einstellungen in Ordnung waren.

    EDIT2 :

    – Das bestätigt dann aber wohl meinen Verdacht, dass es am DHCP-Server liegt – oder nicht? Falls ja: Wie kann ich diesen in Betrieb nehmen?

    und als zweite Frage:

    – Warum läuft mein Heimnetzwerk nicht mehr (angeschlossen via Netzwerkkabel)?

    Hallo zusammen

    Nachdem ich auf Raspbian Buster upgedatet habe (neue Installation), wollte ich nun mit dem Pi ein AdHoc-Netzwerk erstellen. Mit Hilfe des Forum habe ich das bereits einmal unter Stretch hinbekommen, da aber noch mit der interfaces-Lösung, welche gemäss mehreren User-Aussagen aber nicht mehr zeitgemäss ist. Daher wollte ich nun unter Buster die Lösung mit systemd-networkd und wpa_supplicant einrichten. Vorgegangen bin ich nach dieser Anleitung: *Klick*. Damit es keine Missverständnisse gibt; folgende Punkte habe ich ausgeführt:

    Setup systemd-networkd

    Setup unprotected ad-hoc interface using wpa_supplicant

    Was funktioniert zurzeit:

    – Ich habe ein AdHoc-Netzwerk mit dem Namen IBSS-RPiNet mit welchem ich mich verbinden kann

    Und nun noch was zurzeit nicht funktioniert:

    – Ich würde gerne mit VNC auf den Rechner zugreifen, dass klappt aber nicht und ich frage mich wieso?

    – Das Heimnetzwerk ist auch nicht mehr sichtbar/erreichbar

    VNC-Viewer – mit welchem ich auf den Pi zugreifen möchte, teilt mir nur mit: "Error - The computer's IP address could not be contacted" (VNC-Server auf dem Pi gibt mir unter "Konnektivität" die IP-Adresse 192.168.2.1 aus -> das habe ich auch so in der wlan-interface-Datei festgelegt)

    Kann es allenfalls an einem DHCP-Problem liegen? Bei der Stretch-Lösung musste ich damals einen solchen installieren...

    Schon einmal vielen Dank im Voraus für eure Hilfe.

    Hi

    Danke dir für deine ausführliche Antwort. Ja das ist richtig, dass mein Pi auch an einem LAN betrieben wird.

    Zurzeit bezieht also mein PI die Systemzeit ausschliesslich von der RTC – auch wenn dieser am LAN hängt. Damit in letzterem Falle aber der NTP-Service genutzt wird, braucht es zusätzliche Software.

    Hier kommt das in #64 erwähnte C# Progamm ins Spiel

    Kann das denn nicht einfacher gelöst werden? Allenfalls irgendwie über die Boot-Reihenfolge der services?

    Noch eine Bemerkung die Batterie der kleinen RTC hält nicht lange.

    Hast du da genauere Werte? Denke zwar, dass wird nicht einfach nachvollziehbar sein, da wohl die Knopfbatterie schon bei der Auslieferung unterschiedliche Ladezustände hat (bei mehreren Modulen).

    Bei mir sind es schon 2 Stück da werde ich mal eine CR2032 anschließen und Testen.

    Wäre toll, wenn du dann deine Erkenntnisse teilen könntest.

    ALSO – ich (oder wir) habe(n) einen Erfolg zu vermelden:

    Die Systemzeit wird nun auch nach einem Stromunterbruch und ohne LAN korrekt ausgegeben! Wow!

    Die service-unit "new_hwclock.service" ist ja auch nicht aktiviert (enabled), sondern wird via eine udev-Regel gestartet.

    Da stellt sich auch die Frage, welche "Wirkung" in diesem Fall die Zeilen "Wants=" bzw. "After=" noch haben?

    Vielleicht kann das md_fg ja noch abschliessend beantworten. Dann kann ich die new_hwclock-services noch aufräumen und habe dann endlich die längst ersehnte saubere RTC-Lösung.

    Eventuell könnte man ja auch den Beitrag #83 von md_fg bereinigen (denn Kommentar noch löschen) und an einer geeigneten Stelle mit dem Beitrag #59 zusammenführen -> das wäre dann eine vollständige Anleitung zur Einrichtung der RTC (mit Buster).

    Hier wäre noch die Ausgabe von systemd-analyze plot:

    An dieser Stelle auf alle Fälle nochmals ein riesen Dankeschön an alle die zur Lösung beigetragen haben (insbesondere an rpi444  md_fg  hyle ) :danke_ATDE:

    Warum sollte new_hwclock.service vom dhcpcd.service abhängig sein.

    Das war die Vermutung von md_fg (Beitrag #92). Deshalb die Frage, ob ich die den Inhalt von new_hwclock.service wieder analog Post #59 setzen soll.

    Zurzeit stimmt die Systemzeit nach einem Reboot. Werde noch versuchen zu klären, ob dies auch nach einer Stromunterbrechung und ohne LAN der Fall sein wird.

    Ich glaube ich habe zumindest einen Fehler entdeckt (wohl ganz im Sinne von "auch ein Blindes Huhn findet mal ein Korn")... Das hier hat mich etwas stutzig gemacht:

    Code
    Nov 29 12:54:23 raspberrypi hwclock[435]: hwclock: 8 too many arguments given

    Ich habe mich gefragt, woher diese 8 Argumente denn überhaupt kommen sollen? In der Datei new_hwclock.service war in der Zeile "execStart=/sbin/...." ein Kommentar angehängt, also habe ich diesen testweise einmal entfernt und neu gestartet. Siehe da – die Fehlereinträge sind nun verschwunden:

    systemctl status new_hwclock.service

    Code
    ● new_hwclock.service - Synchronize system clock from RTC
       Loaded: loaded (/etc/systemd/system/new_hwclock.service; disabled; vendor preset: enabled)
       Active: inactive (dead) since Fri 2019-11-29 14:02:38 CET; 2min 0s ago
      Process: 420 ExecStart=/sbin/hwclock --hctosys --utc (code=exited, status=0/SUCCESS)
     Main PID: 420 (code=exited, status=0/SUCCESS)
    
    Nov 29 14:02:27 raspberrypi systemd[1]: Starting Synchronize system clock from RTC...
    Nov 29 14:02:38 raspberrypi systemd[1]: new_hwclock.service: Succeeded.
    Nov 29 14:02:38 raspberrypi systemd[1]: Started Synchronize system clock from RTC.

    journalctl _PID=420

    Code
    -- Logs begin at Fri 2019-11-29 14:02:23 CET, end at Fri 2019-11-29 14:04:20 CET. --
    -- No entries --

    Bei systemd-analyze blame wird new_hwclock.service allerdings immer noch vor dhcpcd.service geladen. Muss ich das nun noch etwas ändern, oder kann das mit dem wegfallen der obigen Fehlermeldungen als "kein Problem" angesehen werden?


    EDIT:

    rpi444 Da warst du wohl schneller :)

    Wurde die RTC nach #83 eingerichtet

    Ja, ich bin genau danach vorgegangen. I

    systemctl status new_hwclock.service

    Hier gibt es mir einen Fehler aus:

    Hier die Ausgabe von journalctl _PID=321 (zumindest nehme ich an, dass ich hier den PID-Wert des obigen Prozesses eingeben sollte):

    Code
    -- Logs begin at Thu 2019-11-28 22:43:45 CET, end at Fri 2019-11-29 12:34:48 CET. --
    Nov 28 22:43:49 raspberrypi hwclock[321]: hwclock: 4 too many arguments given
    Nov 28 22:43:49 raspberrypi hwclock[321]: Try 'hwclock --help' for more information.

    Die Ausgabe von systemd-analyze blame:

    Da hier new_hwclock.service vor hcpcd.service gestartet wird (zumindest gehe ich davon aus, da der hwclock-service schneller antwortet), habe ich deine Anpassungen – bis zur Zeile 14 – in der new_hwclock.service vorgenommen.

    -----------

    Nach dem daemon-Reload habe ich einen Reboot ausgeführt und dann nochmals die obigen Abfragen ausgeführt. Die Ausgaben sind nun wie folgt:

    systemctl status new_hwclock.service

    Die Ausgabe von journalctl _PID=435

    Code
    -- Logs begin at Fri 2019-11-29 12:54:18 CET, end at Fri 2019-11-29 12:56:37 CET. --
    Nov 29 12:54:23 raspberrypi hwclock[435]: hwclock: 8 too many arguments given
    Nov 29 12:54:23 raspberrypi hwclock[435]: Try 'hwclock --help' for more information.


    Die Ausgabe von systemd-analyze blame:

    Hinweis: Ich bin nicht zuhause, daher kann ich den Strom/Lan nicht trennen. Die Systemzeit wird aktuell nur korrekt sein, weil das LAN verbunden ist.

    Nach ein wenig Nachdenken ist mir der Beitrag #59 in den Sinn gekommen, welcher ja die RTC-Zeit an das System weiter gibt (also genau, dass was bei mir eben nicht passiert).

    Habe nun die udev-Rule und den Service angelegt – also Pi wieder vom Strom & LAN getrennt und ohne letzteres wieder neu gestartet.

    Fazit: Funktioniert auch damit nicht.

    So – mein Feedback:

    Buster ist installiert – ging vom Download des Images bis zu den finalen Updates nach der Installation insgesamt eine gute Stunde.

    Dann habe ich mich an die Anleitung von md_fg gehalten und diese durchgespielt. Aktueller Stand:

    RTC wird erkannt und gibt auch die richtige Zeit aus

    – Nach einem Neustart (Strom war weg) und ohne LAN zieht das System aber die Uhrzeit nicht mehr richtig (es nimmt die letzte bekannte Uhrzeit als der Pi noch am Strom hing)

    – Hänge ich das LAN wieder an, updated das System die Zeit

    Ich könnte nun natürlich wieder anfangen herumzuspielen und Sachen zu verändern, aber das lasse ich diesesmal ganz schön sein und frage euch was zu tun ist?

    Was mir aufgefallen ist: systemctl status hwclock.service ist zwar "masked" (wie es ja sein soll) - aber auch inactive.

    Code
    ● hwclock.service
       Loaded: masked (Reason: Unit hwclock.service is masked.)
       Active: inactive (dead)

    Ist das richtig so?


    --------

    EDIT: Hier noch ein paar Ausgaben:

    systemctl status hwclock.service

    timedatectl (ohne LAN gleich nach dem Neustart)

    Code
                   Local time: Do 2019-11-28 22:06:48 CET
               Universal time: Do 2019-11-28 21:06:48 UTC
                     RTC time: Do 2019-11-28 21:18:31
                    Time zone: Europe/Zurich (CET, +0100)
    System clock synchronized: no
                  NTP service: active
              RTC in local TZ: no

    timedatectl (mit angeschlossenem LAN)

    Code
                   Local time: Do 2019-11-28 22:31:52 CET
               Universal time: Do 2019-11-28 21:31:52 UTC
                     RTC time: Do 2019-11-28 21:31:53
                    Time zone: Europe/Zurich (CET, +0100)
    System clock synchronized: yes
                  NTP service: active
              RTC in local TZ: no

    wenn Du manuell:


    sudo sh -x /etc/init.d/hwclock.sh

    ausführst.

    Ausgabe:

    Auch hier taucht das Bad-setting mehrmals auf; denke das ist ein schlechtes Zeichen...


    Dann noch eine Frage zur sudo nano /lib/udev/hwclock-set

    Bei mir sind die Zeilen

    Code
    if [ -e /run/systemd/system ] ; then
       exit 0
    fi

    zurzeit aktiv. Habe aber in anderen Beiträgen gesehen, dass diese teilweise inaktiv (mit #) gesetzt sind und in den Beitrag-Kommentaren hat dann auch jemand bestätigt, dass dies unter Buster funktioniert hat. Weiss jemand, was nun unter Buster korrekt/"richtiger" ist?

    systemctl cat hwclock.service

    Das geht leider nicht; nach der Eingabe kommt dann:

    Code
    # Unit hwclock.service could not be loaded.


    Code
    BTW: Ich hätte an deiner Stelle buster neu aufgesetzt und nicht updatet.

    Werde ich dann vielleicht noch nachholen. Ich brauche den Pi in rund zwei Wochen im Einsatz – und ich wollte die anderen bestehenden Installationen (du hast da ja auch mitgeholfen -> Mediaplayer und iPad-Monitor via AdHoc) nicht unnötig kaputt machen. Deswegen habe ich mich für das Update entschieden, in der Hoffnung, dass die Dinge dann auch noch laufen werden (ohne das ich alles nochmals neu machen muss).

    Hmm – schaut nicht gut aus:

    sudo systemctl enable hwclock

    sudo systemctl start hwclock

    Code
    Failed to start hwclock.service: Unit hwclock.service has a bad unit file setting.
    See system logs and 'systemctl status hwclock.service' for details.


    systemctl status hwclock

    Code
    ● hwclock.service
       Loaded: bad-setting (Reason: Unit hwclock.service has a bad unit file setting.)
       Active: inactive (dead)
    
    Feb 14 22:54:16 raspberrypi systemd[1]: hwclock.service: Service has no ExecStart=, ExecStop=, or SuccessAction=. Refusing.

    Und da war "systemctl enable hwclock" bzw. "systemctl enable hwclock.service" bzw. start/reloard-or-restart/status/disable usw., auch dabei ?

    Nein, war es nicht. Aufgrund deines Inputs in Post #70 ist dies aber wohl offensichtlich notwendig. Ich werde das ausführen und schauen wie dann die Ausgabe von timedatectl ist...


    Zurzeit sieht es wie folgt aus:

    systemctl status systemd-timesyncd

    Code
    Warning: The unit file, source configuration file or drop-ins of systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
    ● systemd-timesyncd.service - Network Time Synchronization
       Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; disabled; vendor preset: enabled)
      Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
               └─disable-with-time-daemon.conf
       Active: inactive (dead)
         Docs: man:systemd-timesyncd.service(8)

    Hinweis: systemctl daemon-reload bringt die Warnungs-Meldung nicht weg.

    timedatectl

    Code
                   Local time: Do 2019-02-14 22:39:31 CET
               Universal time: Do 2019-02-14 21:39:31 UTC
                     RTC time: Do 2019-11-28 09:05:46
                    Time zone: Europe/Zurich (CET, +0100)
    System clock synchronized: no
                  NTP service: inactive
              RTC in local TZ: no

    Die RTC wird zumindest noch erkannt (d.h. kein i2c-Problem), zudem ist es die einzigste Zeit die korrekt ist (obwohl der Pi zurzeit mit dem Netzwerk verbunden ist).

    PS: Kann den Pi erst heute Abend wieder vom Strom und dem LAN nehmen um die RTC-Funktion zu testen...