RasPi WLAN AccessPoint funktioniert nur manchmal

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo Ihr Lieben

    ich verzweifele langsam ...
    Ich habe eine gar nicht SOOOO komplexe Konfiguration, aber die überlebt keinen Shutdown und Reboot.

    Wenn ich dann einige (bis zu drei) Male nach einem Hochfahren reboote, funktionierts (!) ...

    DAS bringt mich echt zur Verzweiflung - nicht reproduzierbarer Fehler, der bei gleichbleibender Konfiguration von alleine verschwindet...

    Worum geht es:

    WLAN Accesspoint nach etlichen Anleitungen hier und auf anderen Pages gefunden, entsprechend konfiguriert.

    Ist ein RasPi, der mit zwei WLAN Antennen arbeiten soll: eine (wlan0) für die Verbindung zum Home-Router ins Internet,
    die andere (wlan1), die als Accesspoint arbeiten soll

    Meine Komfiguration:

    ifconfig gibt bei Funktionieren und nicht Funktionieren halbwegs gleiche Meldungen;

    Ich habe mich im Net zu Tode gesucht, aber keine Antwort gefunden.
    Hat einer von Euch eine Idee???

    Ich danke vielmals für jede Rückmeldung.

    Gruß,
    Ralf

    Einmal editiert, zuletzt von rkorell (16. Dezember 2015 um 22:13)

  • Setze per udev-Regel, die auf den Namen und die MAC-Adresse des WLAN-Interfaces geht, für jedes der beiden Interfaces einen festen, beliebigen Namen, so dass du auch wirklich immer das richtige Interface erwischt.

    Beispiel:
    Datei:
    Datei "/etc/udev/rules.d/70-persistent-net.rules" erweitern oder anlegen.
    Wichtig: Es werden die MAC-Adressen der WLAN-Dongles eingetragen und dann, bei den Konfigurationsskripten mit den hier definierten Namen ("wlanHR" bzw "wlanAP") gearbeitet

    Code
    # USB device 0x:0x (rtl8821au)
    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="74:da:38:2a:d3:86", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlanHR"
    
    
    # USB device 0x:0x (rtl8188eu)
    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="e8:94:f6:25:f0:f4", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlanAP"

    Computer ..... grrrrrr

  • Hallo PatrickS, Rasp-Berlin,

    DANKE auf jeden Fall für Eure Mühe.

    Beide Ideen helfen leider nicht.

    Zunächst eine etwas bessere Problembeschreibung:
    Sorry, es war spät und der Fehler ist mir ja bekannt, daher habe ich schlicht vergessen, den Fehler exakt zu beschreiben.

    Die WLANs fahren hoch, das HomeRouter WLAN (jetzt heißt es wlanHR) immer stabil und zugreifbar, keinerlei Probleme. (billiger VILROS USB-Mini-Dongle, der in einem Raspi Basiskit enthalten war)
    Der Fehler taucht auf beim zweiten Adapter, hier nutze ich einen TL-WN722N USB Adapter von TP-Link, der AP-fähig ist.
    Er wird konfiguriert (heißt jetzt wlanAP), die SSID wird auch gebroadcastet, man sieht also das WLAN, nur die Anmeldung funktioniert nicht - oder halt nach mehreren reboots. Gestern - noch viel später- hat er auch einige Male direkt nach shutdown und wieder hochfahren direkt funktioniert, das hat heute noch nicht geklappt ...

    Status im Moment:

    beim checken des WLAN Tools in der RaspiGui zeigt er
    wlanHR: Associated
    wlanHR: configured 172.34.34.160/24
    wlanHP.Associated with PyroLan
    wlanAP.Configured 169.254.103.37/16
    eth0: Link is down
    (jetzt beim Abschreiben fällt mir auf, dass hinter wlanHR ein Doppelpunkt, hinter wlanAP nur ein einfacher Punkt steht.)

    Nach Hochfahren (mit der neuen udev Konfiguration) Ich finde mit einem Tablet die SSID, er versucht ewig, zu kontaktieren, dann sagt er nach ca. 10 Minuten: "schlechte Verbindung", hat aber keine Verbindung und zeigt auch keine "WLAN-Balken" in der Statusleiste oben.
    Nach Reboot (sic!) verbindet er sich quasi sofort und die Verbindung bleibt bestehen und funktioniert auch (ich kann den unter der Basisadresse des Servers 192.168.1.1 den Apache Webserver wie gewünscht ansprechen.
    Ich komme allerdings NICHT mehr (über den wlanAP Adapter) ins Internet (Routing jetzt verkehrt??).

    Die /etc/Interfaces sieht jetzt (für den wlanAP) so aus:

    auto wlanAP
    allow-hotplug wlanAP
    iface wlanAP inet static
    address 192.168.1.1
    netmask 255.255.255.0
    up /sbin/iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE
    down /sbin/iptables -D POSTROUTING -t nat -o eth0 -j MASQUERADE


    ifconfig sieht in beiden Fällen identisch jetzt so aus:

    Die udev-Idee ist gut, sorgt für Ordnung und Verständnis in den Konfigurationsdateien, danke hierfür, das Problem löst sich dadurch leider nicht ...

    Die Idee mit dem schwachen Netzteil ist auch gut, ist aber hier ausgeschlossen durch den Betrieb der beiden USB Adapter an einem externen USB Hub mit 2,5A eigener Stromversorgung.


    Ich hasse nicht-reproduzierbare Fehler, die durch reboot manchmal verschwinden ...

    Hat einer von Euch noch eine Idee???

    Ich habe irgendwo bei meiner Recherche gefunden, dass das o.a. "Verbindungsproblem" auftaucht, wenn der DHCP Server nicht funktioniert.
    DHCP scheint aber zu funktionieren ...

    DANKE an Alle, die helfen.

    Gruß,
    Ralf

    Einmal editiert, zuletzt von rkorell (16. Dezember 2015 um 22:15)

  • Du musst dann noch die beiden Netzwek-Interfaces zu einer Bridge verbinden, oder den PI als Router definieren. Dann muss auf diesem auch, für das AP-Netzwerk, ein eigener DHCP-Dienst mit einem eigenen Netz laufen.

    Im Moment bekommt du auf dem AP-Netzwerk eine zeroconf-IP (https://de.wikipedia.org/wiki/Zeroconf )

    Wenn du die beiden Netzwerk-Interfaces bridgest, wird im AP-Netzwerk das Netzwerk, das der PI auf seiner HR-Seite hat, weitergeleitet, alle Systeme, die sich am AP anmelden, bekommen eine IP vom DHCP-Server im HR-Netz.

    Konfigurierst du den PI als Router, bietet er den Clients, die sich an seinem AP anmelden, ein eigenes Netz mit eigenen IP-Adressen und leitet den verkehr über sein HR-Netz in das Netz, in dem dieser angebunden ist.
    Hier wäre dann wichtig, in diesem HR-Netz eine Route einzurichten, dass der für die im AP-Netz vorhandenen Rechner im HR-Netz ankommenden Daten an das AP-Netz weitergeleitet werden. (Das kann man z.B. oft dadurch erreichen, dass man beim 'echten' Router des HR-Netzes eine Route in das AP-Netz einträgt. Der PI sollte auf der HR-Netz-Seite immer die gleiche IP-Adresse bekommen.)

    Computer ..... grrrrrr

  • Hallo Rasp-Berlin,
    danke.

    Ich habe das Ganze so verstanden, dass dnsmasq den DHCP Dienst für wlanAP liefern soll ...
    Wenn ich denn eine Verbindung bekomme, erhalte ich auch eine Adresse aus dem definierten Pool (aktuell 192.168.1.188).

    Wenn ich Dich richtig verstanden habe, führt ein bridging dazu, dass die wlanAP eine IP Adresse vom wlanHR (Netzeinstiegsrouter) bekommen.
    Das aber möchte ich gar nicht. Ich hatte gedacht, dass die iptables einträge das Routing und das NAT erledigen (hat ja auch bisher funktioniert)

    Leider löst das bridging auch nicht mein Problem des "manchmal nicht Funktionierens".
    Für den Zweck, den dan Ganze final erfüllen soll, ist es nicht zwingend erforderlich, dass der Rechner, der sich am wlanAP anmeldet, ins Internet kommt.
    Wäre nur nett, ist aber wie gesagt optional. nicht optional allerdings ist das sichere Funktioieren beim Hochfahren.
    Hast Du hierzu noch eine Idee?

    DANKE vielmals!

    Gruß,
    Ralf

  • NACHTRAG:

    ich habe jetzt offensichtlich den Fehlerkandidaten gefunden ...
    Nachdem ich meine Konfigurationsdateien nochmals durchgegangen bin, ist mir der Fehler aufgefallen:

    in der /etc/network/Interfaces hatte ich stehen:
    up /sbin/iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE
    down /sbin/iptables -D POSTROUTING -t nat -o eth0 -j MASQUERADE

    das ist natürlich Blödsinn.
    eth0 habe ich ja gar nicht mehr aktiv, da ich wegen WLAN ha das Patchkabel gezogen habe...

    JETZT wurde es interessant!
    denn nach Ändern der Konfiguration auf (das vermeintlich richtige wlanHR)
    up /sbin/iptables -A POSTROUTING -t nat -o wlanHR -j MASQUERADE
    down /sbin/iptables -D POSTROUTING -t nat -o wlanHR -j MASQUERADE

    kann ich mich auch nach zehn reboots NICHT mehr verbinden...

    Wenn ich die iptables Einträge komplett entferne, verhält sich das System, wie beschrieben - nach shutdown kein connect möglich, nach reboot connect möglich, allerdings zeigt das WLAN Stussymbol des Test-Tablets die WLAN Balken mit einem Ausrufezeichen, also irgendwas stimmt nicht 100%.
    Internet ist auch nicht möglich....
    Hat jemand eine Idee, wie das Alles zusammenpasst?
    Dass iptables auf das wlanHR den connect komplett verhindert, kann ich übehaupt nicht verstehen.

    Danke für jede Idee!

    Gruß,
    Ralf

    Einmal editiert, zuletzt von rkorell (15. Dezember 2015 um 15:59)

  • NACHTRAG 2: -- Internetzugriff wird jetzt via leicht modifizierter iptables-Anweisugen geroutet --

    Hallo Ihr Lieben,
    habe jetzt noch ein bisschen weiter gesucht ...

    mit sudo iptables --table nat --append POSTROUTING --out-interface wlanHR -j MASQUERADE
    habe ich einen Internetzugriff über das wlanAP .

    Dementsprechend habe ich meine /etc/network/interfaces Konfiguration angepasst.
    Diese sieht jetzt so aus:
    # Include files from /etc/network/interfaces.d:
    source-directory /etc/network/interfaces.d
    # Localhost
    auto lo
    iface lo inet loopback

    # Ethernet
    auto eth0
    allow-hotplug eth0
    iface eth0 inet dhcp

    # WLAN Interface ins Korell WEB
    auto wlanHR
    allow-hotplug wlanHR
    iface wlanHR inet dhcp
    wpa-ssid KORELL Web
    wpa-psk 1234567890123456789


    # WLAN Accesspoint mit dem TP Link Modul
    auto wlanAP
    allow-hotplug wlanAP
    iface wlanAP inet static
    address 192.168.1.1
    netmask 255.255.255.0

    up /sbin/iptables --table nat --append POSTROUTING --out-interface wlanHR -j MASQUERADE
    down /sbin/iptables --table nat --delete POSTROUTING --out-interface wlanHR -j MASQUERADE

    Damit habe ich jetzt alle Zugriffe so, wie ich sie tatsächlich brauche.

    Das Ursprungsproblem allerdings besteht nach wie vor:
    Der wlanAP Dongle sieht immer gleich aus (zumindest, da wo ich hinschaue = ifconfig und WLAN -Statusmeldung in der Raspi GUI), lässt aber nach shutdown keinen connect zu.
    Nur ein oder mehrere Reboots führen dann dazu, dass die gleiche (!) Konfiguration plötzlich funktioniert.
    WENN sie denn funktioniert übrigens, ist das absolut stabil, es gibt keine Abbrüche oder so ...

    Hat irgendjemand noch eine Idee für dieses doch sehr merkwürdige Verhalten?

    DANKE!

    Gruß,
    Ralf


  • Hat irgendjemand noch eine Idee für dieses doch sehr merkwürdige Verhalten?

    Du hast den hostapd automatisch beim Systemstart laufen. Ich würde das abschalten und manuell mit der Option -dd starten. Das hat den Vorteil, dass Du die Client-Anmeldung auf der Konsole beobachten kannst. Wenn da ein Fehler auftritt, kannst Du dem nachgehen.

    Was Du vorher noch ausprobieren kannst, In der Interfaces-Datei folgendes eintragen:

    Code
    up service hostapd restart

    Vielleicht löst das Dein Problem.

  • Hallo PatrickS,
    danke für diese Idee.

    Das habe ich schon ausprobiert.
    Wenn ich hostapd manuell restarte, erscheint wlanAP als "disaccociated from PyroLan" und macht gar nix mehr ...
    Das gleiche passiert, wenn ich den von Dir vorgeschlagenen "up" Befehl in der Interfaces Datei eintrage.

    Das Problem liegt wohl im DHCP Server dnsmasq ..
    Habe heute morgen herumprobiert und mal eine vollkommen abgespeckte Version der dnsmasq.conf erstellt, die wirklich nur die notwendigen Parameter enthält, um evtl. ein aus Versehen gelöschtes Kommentarkreuz auszuschließen,
    Interessanterweise lief es damit über fünf reboots.

    Danach nie wieder ...

    habe dann die originale .conf Datei zurückkopiert, damit konnte ich nach reboot connecten.
    Im Moment hilft gerade gar nichts, ich bekomme keinen connect.
    Habe bei weiteren Recherchen jetzt immerhin eine LOG Möglichkeit gefunden und habe jetzt zumindest eine Fehlermeldung:


    Diese Fehlermeldung nun aber kann ich gar nicht interpretieren.
    Es wird ja ein verfügbarer Bereich genannt, der ist auch so konfiguriert ...

    Habe gelesen, dass die DHCP Probleme mit /etc/resolv.conf zusammenhängen, die hier aber gar nicht gelesen wird. Die resolv.conf aber soll 127.0.0.1 als erste Zeile enthalten ...

    Ich dreh noch durch...
    Hat jemand eine Idee??


    DANKE!
    Gruß,
    Ralf
    Automatisch zusammengefügt:

    Ich habe trotzdem mal testweise hostapd gestoppt und den debug-modus aktiviert.
    Das gibt natürlich ein Riesen Log.

    Das TestTablett versucht, sich zu verbinden, das dauert ein Weilchen und bricht dann mit " pairwise key handshake completed (RSN)" ab ...

    Die Kurzvariante (OHNE -dd) sieht so aus:

    Configuration file: /etc/hostapd/hostapd.conf
    Using interface wlanAP with hwaddr 60:e3:27:0d:cc:6d and ssid "PyroLan"
    wlanAP: interface state UNINITIALIZED->ENABLED
    wlanAP: AP-ENABLED
    wlanAP: STA 8c:18:d9:22:94:f9 IEEE 802.11: authenticated
    wlanAP: STA 8c:18:d9:22:94:f9 IEEE 802.11: associated (aid 1)
    wlanAP: AP-STA-CONNECTED 8c:18:d9:22:94:f9
    wlanAP: STA 8c:18:d9:22:94:f9 RADIUS: starting accounting session 56716C5A-00000000
    wlanAP: STA 8c:18:d9:22:94:f9 WPA: pairwise key handshake completed (RSN)
    wlanAP: AP-STA-DISCONNECTED 8c:18:d9:22:94:f9
    wlanAP: STA 8c:18:d9:22:94:f9 IEEE 802.11: authenticated
    wlanAP: STA 8c:18:d9:22:94:f9 IEEE 802.11: associated (aid 1)
    wlanAP: AP-STA-CONNECTED 8c:18:d9:22:94:f9
    wlanAP: STA 8c:18:d9:22:94:f9 RADIUS: starting accounting session 56716C5A-00000001
    wlanAP: STA 8c:18:d9:22:94:f9 WPA: pairwise key handshake completed (RSN)
    wlanAP: AP-STA-DISCONNECTED 8c:18:d9:22:94:f9
    wlanAP: STA 8c:18:d9:22:94:f9 IEEE 802.11: authenticated
    wlanAP: STA 8c:18:d9:22:94:f9 IEEE 802.11: associated (aid 1)
    wlanAP: AP-STA-CONNECTED 8c:18:d9:22:94:f9
    wlanAP: STA 8c:18:d9:22:94:f9 RADIUS: starting accounting session 56716C5A-00000002
    wlanAP: STA 8c:18:d9:22:94:f9 WPA: pairwise key handshake completed (RSN)


    hier das komplette Log (mit -dd):


    NACHTRAG 3 --- Jetzt habe ich ein LogFile mit nicht-funktionierender und funktionierender Verbindung.
    Der Unterschied erhellt sich mir leider NICHT...


    Hat jemand ... ???


    DANKE!
    Gruß,
    Ralf

    Einmal editiert, zuletzt von rkorell (16. Dezember 2015 um 22:03)

  • Sooooooooooo ....

    Ich habe jetzt die Holzhammer-Methode gewählt.
    Nach fünf Tagen Sucherei hab ich die Nase gestrichen voll.
    Es "müsste" funktionieren, tut es aber nicht und dann noch nicht reproduzierbar.

    Ich habe mir den neusten Raspbian Kernel geholt und auf einem jungfräulichen System mit der WLAN AP Konfiguration angefangen.

    Diesen ein paar dutzend Male hoch- und runtergefahre, reboots ausgeführt etc.

    Läuft absolut stabil, das Testtablett verbindet sich jedesmal sofort.
    Leider ist die Verbindung mit einem Ausrufezeichen versehen, das bekomme ich nicht weg und das NAT / IP-Masquerading und vor allem der IP-Forward funktioniert über die mir bekannten iptables Befehle leider nicht mehr, cih habe auf dem Tablet also keinen Internetzugriff.

    Wer dazu noch eine Idee hat - Wäre sehr dankbar.
    Bridge kommt nicht in Frage, müsste also iptables konform sein oder eine andere Lösung.

    Wegen der noch offenen Frage lasse ich das Thema noch bis morgen Abend unerledigt.

    Herzlichen Dank für alle die mitgedacht haben und evtl. noch mitdenken.

    Sorry auch, dass ich die "code" Funktion erst so spät entdeckt habe, ich habe jeweils den Schenllantwort Dialog benutzt, daher die Postings etwas aufgeblasen - tut mir leid.

    Gruß,
    Ralf

  • Hallo, Ihr Lieben,


    Ich hab es gefunden...

    :shy:

    Warum auch immer das über iptables Befehle nicht (mehr?) funktioniert....
    Das Problem war das Forwarding - wie erwartet.

    Die Anpassung der /etc/sysctl.conf hat die Lösung gebracht .
    Das Asukommentieren des Forwarding Parameters net.ipv4.ip_forward=1 lässt das Forwarding einfach passieren und schon hab ich Internet auf dem Versuchs-Tablet.

    Was mich jetzt noch heftig irritiert, ist der Beitrag von PatrickS [Raspbian] Manuelle IPv4-Konfiguration ab Raspbian Wheezy vom 2015-05-05 vom 8. Juli...

    Ich habe keine Informationen gefunden, wie ich einigermassen sicher die Konfiguration von /etc/Network/Interfaces auf "/etc/dhcpcd.conf" umstellen kann.
    Oder ist das tatsächlich nur für STATISCHE Konfigurationen zu erledigen?
    Ich habe keinerlei Hinweise für eine dynamische Konfig gefunden.

    Kann ich also bei /etc/Network/Interfaces bleiben?

    Danke nochmals herzlich an die Mitdenker für Ihre Zeit und Mühe!

    Gruß,
    Ralf

    Einmal editiert, zuletzt von rkorell (17. Dezember 2015 um 00:00)

  • Was mich jetzt noch heftig irritiert, ist der Beitrag von PatrickS [Raspbian] Manuelle IPv4-Konfiguration ab Raspbian Wheezy vom 2015-05-05 vom 8. Juli..

    Ich habe keine Informationen gefunden, wie ich einigermassen sicher die Konfiguration von /etc/Network/Interfaces auf "/etc/dhcpcd.conf" umstellen kann.

    Kann ich also bei /etc/Network/Interfaces bleiben?

    Was die Netzwerk-Konfiguration angeht, kannst Du alles lassen wie Du es hast. Die Konfiguration in der dhcpcd.conf ist zu empfehlen, aber nicht zwangsläufig zu bevorzugen. Insbesondere deshalb nicht, weil man nicht so einfach von interfaces auf dhcpcd.conf umstellen kann.

    Die dhcpcd.conf hat verschiedene Nachteile, aber auch Vorteile. Es kommt darauf an, was man machen will.

    Wenn Du die interfaces verwendest, dann solltest du darauf achten, dass der dhcpcd deaktiviert ist. Ein Mischbetrieb ist fehleranfällig.

  • Hallo PatrickS,

    danke für diese Einschätzung.
    Da alles stabil läuft (auch heute Morgen noch :) ) werde ich wohl dabei bleiben.

    Noch eine kurze Rückfrage: Ich habe mehrere Anleitungen für den Raspi Betrieb eines WLAN Accesspointes gefunden, die ausdrücklich das Vorhandensein und die Funktionalität von dhcpd prüfen, die Konfiguration dann aber über die Interfaces-Datei vornehmen.
    Du sagst jetzt, dass der Parallelbetrieb fehleranfällig sei.
    (Was mir irgendwie sinnvoller erscheint).

    Funktioniert das Ganze noch, wenn ich dhcpd deaktiviere???

    Danke und Gruß,
    Ralf


  • Funktioniert das Ganze noch, wenn ich dhcpd deaktiviere???

    Wenn Du die IP-Konfiguration in der interfaces grundsätzlich statisch ("static") machst, dann kannst Du auf den dhcpcd (exakte Schreibweise beachten) verzichten.

    Aber nehmen wir mal an, dass Deine WLAN-AP-Konfiguration fehlerhaft ist und nur deshalb läuft, weil der dhcpcd läuft, dann geht es natürlich hinterher nicht mehr. Wer weiß das schon.

    Ob Du das ausprobieren möchtest hängt von Deiner Frusttoleranz ab.

  • NaJa ...
    Die Konfiguration (s.o., , meine Frage zur statischer dhcpcd vs. dynamischer Interface Konfiguration) bei mir ist ja eben NICHT statisch.
    ??? Kann ja auch gar nicht, wenn der RasPi als Router fungieren und DHCP Adressen zuweisen soll.
    Das Internet Beinchen (wlanHR) ist ebenfalls "dynamisch", da es ja seine IP Adresse vom DHCP Server des Internetgateways bekommt (die ist "virtuell statisch", da ich diesen angewiesen habe, eine definierte IP Adresse an die zugehörige MAC Adresse zuzuweisen).

    Ich probiers einfach mal aus ..
    Denn DHCP kommt ja von dnsmasq ...

    Gruß,
    Ralf

    edit: Jetzt habe ich beim Lesen des notwendigen Befehls deine Bemerkung bzgl Schreibweise verstanden :)
    ICh spreche von dhcpcd ...

    edit 2: Funktioniert ...

    Einmal editiert, zuletzt von rkorell (17. Dezember 2015 um 17:37)


  • NaJa ...
    Die Konfiguration (s.o., , meine Frage zur statischer dhpcd vs. dynamischer Interface Konfiguration) bei mir ist ja eben NICHT statisch.
    ??? Kann ja auch gar nicht, wenn der RasPi als Router fungieren und DHCP Adressen zuweisen soll.

    Die meinten nicht deinen RasPi in seiner Funktion als Router (... mit DHCP-Server für seine Clients), sondern wie der RasPi (seinerseits evtl. als DHCP-Client) seine IP-Adresse bekommt.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!