Beiträge von gschoen57

    zu den hdmi-Einträgen in der oot.config hab ich jetzt nochmal eine Frage:

    hier soll ja offensichtlich ein Eintrag rein der dafür sorgt, daß der Desktop auf dem

    Remote Gerät angezeigt werden kann. Wenn dem so ist, müsste ja für das iPad

    ein andrer Eintrag drinstehen als für ein iPhone als Client, da die Displays

    ja durchaus unterschiedlich sein können. Würde weiterhin bedeuten daß

    Ein Eintrag, der mir den Desktop dann auf dem iPhone anzeigt bewirkt, daß

    der Desktop auf dem größeren iPad (mit anderer Auflösungf) dann nicht

    funktionieren würde - oder hab ich das was falsch verstanden ????

    Ich habe mir die /boot/config.txt mal angesehen, die einzigen nicht auskommentierten Zeilen sind:

    Code
    [pi4]
    # Enable DRM VC4 V3D driver on top of the dispmanx display stack
    dtoverlay=vc4-fkms-v3d
    max_framebuffers=2
    
    [all]
    #dtoverlay=vc4-fkms-v3d

    Zeilen, die hdmi enthalten:

    Code
    #hdmi_safe=1
    # uncomment if hdmi display is not detected and composite is being output
    #hdmi_force_hotplug=1
    #hdmi_group=1
    #hdmi_mode=1
    #hdmi_drive=2
    #config_hdmi_boost=4

    Klar, der VNCserver wird mit Display :1.0 gestartet, der Desktop den ich auf dem angehängten Bildschirm bekomme ist

    :0.0. Bei der Bindung über VNC zum raspberry gebe ich NUR das in tightvnc hinterlegte passwort ein, also VNC-login.

    Als Benutzer muss ich mich dann gar nicht mehr anmelden ich bekomme meinen Desktop für den Benutzer pi

    automatisch.

    Glaube nicht, daß es an der Bildschirmauflösung liegt. Es wird ja gar kein X gestartet. Ich habe jetzt den

    VNC über raspi-config deaktiviert, tightvncserver installiert und nun wird beim Start des tightvnc auch

    X und lxsession gestartet und man kann sich über VNC mit dem REchner verbinden. Die Frage, warum der

    "native" vncserver in Raspbian nicht funktioniert ist damit zwar nicht geklärt, aber ich kann auch mit

    dem tightvnc leben.

    Hallo zusammen,

    ich habe auf einem PI4 mit Bullseye 32-bit folgendes Problem:

    wenn ich mich über VNC mit dem Raspberry verbinde kann ich noch das login-Passwort eingeben, dann

    kommt die Meldung "Der Desktop kann derzeit nicht angezeigt werden". Das ganze ging aber auch schon mal

    Weiß jemand abhilfe bzw. warum diese Meldung kommt?

    Gestartet wird beim booten /usr/bin/vncserver, es laufen auf dem Rechner folgende Prozesse:

    /usr/bin/vncserver-x11-serviced -fg

    /usr/bin/vncserver-x11-core -service

    Bei der Verbindung habe ich im Client nur die IP angegeben, er geht dann wohl über 5900. Wie gesagt

    das ging auch schon mal und ich habe eingentlich nichts geändert.

    ... habe noch etwas weiter recherchiert: wenn ich den Raspberry mit angehängtem Bildschirm starte

    wird auch X gestartet und ich bekomme dann auch über VNC einen Desktop angezeigt. D.h. wenn

    der PI ohne Bildschirm gestartet wird, wird auch X nicht gestartet und auch kein Windowmanager,

    d.h. in diesem Fall müsste beim Verbinden X gestartet werden. Eigentlich sollte das doch

    passieren wenn der vncserver gestartet wird. Das geschieht aber leider nicht.

    Ich hänge mich mal hier rein. Habe auch das Problem mit VLC auf einem PI4 8GB.

    smplayer funktioniert. Ich wollte nun mal den omxplayer ausprobieren, der ist

    aber auf meinem PI nicht installiert und ich kann den auch nicht installieren, da

    es das Paket offensichtlich nicht mehr gibt (zumindest nicht in den gängingen

    Repositories). Für VLC (habe 3.0.13) gibt es ja wohl keine Lösung (das obige

    Vorgehen mit Videospur ... funktioniert bei mir nicht). Kann man den omxplayer

    auf einem 64-bit System (Bullseye) irgendwie installieren?

    file FuguHub bringt

    Code
    FuguHub: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.26, BuildID[sha1]=aa1082928e60dcc3b1dcdba23744fa2cadd82edc, not stripped

    ... ich habe ein Raspbian Bullseye 64-bit, d.h. FuguHub wird auf dem Rechner

    nicht laufen - danke für den Tip

    ... oder gibt's eine Möglichkeit FuguHub auch auf 64-bit laufen zulassen.

    Was wäre denn ggf. eine Alternative dazu?

    Ich habe jetzt das System komplett neu und jungfräulich installiert (Bullseye 64-bit).

    Wenn ich mir aber jetzt diese Seite durchlese scheint ja systemd-networkd nicht der Standard in Raspbian zu sein, d.h. man muss das komplette vorhandene Netzwerksystem deaktivieren und dann systemd-networkd aufsetzen.

    Ich habe natürlich in der Datei nicht "<adresse>" drin stehen gehabt sonder die tatsächliche Mac-Adresse von wlan0. Ob das Interface zwei wlan-adressen bekommen hat weiß ich nicht und kanns ja auch nicht mehr nachsehen, siehe oben.

    c

    Da ich null Ahnung habe wie man diesen systemd-networkd konfiguriert habe ich mal eine Datei 08-wifi.network

    angelegt (aus irgendeiner Anleitung im Internet). Habe mal folgendes reingeschrieben:

    Das hat jetzt zur Folge, daß der Raspberry zwar hochfährt, von der FritzBiox eine IP bekommt, ich aber nicht mehr in der Lage

    bin mich über das WLAN auf dem RB anzumelden:

    connect to host 192.168.179.99 port 22: connection refused

    Das ganze Thema hat sich jetzt aber ohnehin erstmal erledigt, da der Raspberry, obwohl alle Prozesse bezüglich X und LXDE laufen

    (das habe ich vor der systemd-networkd-änderung noch gesehen) laufen jetzt nichts mehr auf den Bildschirm ausgeibt. Es kommt noch

    beim Hochfahren das "Raspberry"-Bild, dann ist der Bildschirm Dunkel, d.h. er bekommt keine Daten mehr.

    D.h. ich muss jetzt erstmal das komplette System wieder neu intsallieren und kann dann wieder vorn vorne anfangen.

    wenn ich mir diese Anleitung ansehe scheint systemd-networkd ziemlich aufwändig und kompliziert zu sein, da scheint es erstmal

    nötig zu sein, tagelang irgendwelche Anleitungen zu lesen, wobei ich ja mittlerweile ohnehin festgestellt habe daß die meisten

    im Internet mit Vorsicht zu geniessen sind.

    Ich habe nun die Datei /etc/network/interfaces ergänzt:

    Code
    auto wlan0
    allow-hotplug wlan0
    iface wlan0 inet manual
    wpa-roam /etc/spa/supplicant/wpa_supplicant.conf
    iface default inet dhcp

    dieser Eintrag bewirkt, daß nun tatsächlich wlan0 von der FritzBox mit der IP

    versorgt wird. Der darunter liegende Eintrag für wlan1 wird aber jetzt ignoriert, d.h.

    wlan1 ist jetzt 'not associated'.

    Ich habe gerade festgestellt, daß

    Code
    cat /sys/class/net/wlan1/address

    mal die eine, mal die andere MAC-Adresse ausgibt, also für wlan1 einmal

    08:be:ac:15:8e:a9, beim nächstem mal d8:3a:dd:1e:0f:6f

    d.h. man weiß tatsächlich nicht welche MAC Adresse zu welcher Hardware gehört.

    ich habe trotzdem mal die d8:3a:dd:1e:0f:6f in die Datei eingetragen,allerdings

    erschließt sich mir ohnehin nicht, wie das System eine Verknüpfung vom Interface wlan1 zur Datei 00-mywlan1if.link herstellen soll.

    In dhcpcd.conf habe ich das interface wlan1 auskommentiert, es steht also

    nur noch "interface wlan0" drin (da soll er ja die ip von der FritzBox bekommen).

    In /etc/network/interfaces habe ich stehen:

    Nach einem reboot habe ich nun:

    - für das interface wlan1 eine IP von der Fritzbox bekommen (192.168.179.99)

    - das Interface wlan0 ist "not associated".

    ... funktioniert also auch nicht

    (die interfaces ist schon richtig, es heißt dort iface wlan1 inet static ...)

    Stimmt, in der 00-mywlan1if.link hat er die MAC Adresse des internen WLAN-Chips hinterlegt, da hab ich nicht richtig hingeschaut. Die MAC Adresse des externen USB Dongles ist lt. "cat /sys/class/net/wlan1/address" "d8:3a:dd:1e:0f:6f".

    Kapiert hab ich, daß die MAC Adresse eine eindeutige Hardware-Adresse ist. Die Zuordnung MAC-Adresse - Interface Name hat er wohl, zumindest nach dem was /sys/class/net/wlan1/address sagt richtig gemacht. Eine IP-Adresse wird entweder statisch im System vergeben oder von einem DHCP-Server, in meinem Fall die FritzBox. Und hier hakts wohl beim mit ziemlich: in der dhcpcd.conf steht momentan:

    Code
    interface wlan1
    static ip_address=192.168.1.1/24
    
    #interface wlan0

    das bewirkt, daß

    - wlan1 not associated ist und

    - wlan0 von meiner FritzBox eine richtige IP-Adresse (192.168.179.99) bekommt.

    Wenn ich in der dhcpcd.conf

    Code
    #interface wlan1
    #static ip_address=192.168.1.1/24
    
    interface wlan0

    hinterlege, dann ist

    - wlan0 not assicioated und

    - wlan1 wird eine abenteuerliche IP-Adresse (NICHT 192.168.1.1) zugeordnet und es gibt keine Verbindung ins Internet

    das ergibt:

    Code
    [Match]
    MACAddress=08:be:ac:15:8e:a9
    
    [Link]
    Name=wlan1Die MAC Adresse stimmt

    wlan0 ist verbunden mit meiner FritzBox, der Raspi hat die IP 192.168.179.99.

    Auf dieser Basis hab ich nun folgendes gemacht:

    Die Datei /etc/hostapd/hostapd.conf sieht jetzt so aus:

    wenn man dann rechts oben auf das WLAN-Symbol geht ist folgendes

    passiert:

    Die Verbindung zur FritzBox geht jetzt über wlan1,

    wlan0 ist "Not Associated"

    die dhcpcd.conf sieht in diesem Fall so aus:

    Code
    #interface eth0
    #fallback static_eth0
    
    
    #interface wlan1
    #static ip_address=192.168.1.1/24
    
    interface wlan0

    Ein WLAN-Netz "raspiwifi2" wird von meinen Geräten nicht gefunden.

    Aktiviere ich nun die Zeilen für das interface wlan1 in der dhcpcd.conf

    und reboote, dann bekomme ich rechts oben folgendes angezeigt:

    wlan0 not associated

    wlan1 associated with <FritzBox>

    wlan1 configuerd 192.168.1.1/24

    eine Internetverbindung über die Fritzbox kommt nicht zustande.

    Das zeigt mir, daß ich der dhcpcd.conf eigentlich nur ein Interface

    eintragen kann, das zweite Interface wird schlicht ingnoriert.

    Ich habe heute sehr viel rumprobiert und bin auf eine Lösung gestossen,

    die mir sympatischer wäre als mit zwei WLAN Interfaces: über eine Bridge (br0).

    Habe dazu mehrere Anleitungen im Internet gefunden und ausprobiert,

    leider funktionieren alle nicht. Die letzte, die ich probiert habe:

    Elektronik Kompendium

    funktionierte leider auch nicht: ich hatte zwar dann auf dem Handy das in

    hostapd.conf definierte Netzwerk unter den WLANs angezeigt bekommen,

    aber verbinden ging nicht (ohne Fehlermeldung) und zudem war auf dem

    Raspi dann wlan0 (meine Verbindung zur FritzBox) ebenfalls weg.

    Nichtsdestotrotz habe ich mal die Datei 00-mywlan1if.link angelegt.

    ip a brachte darauf folgendes:

    die ausgabe von iwconfig: