Wireless Ad-Hoc Mode in NetBSD konfigurieren, wie geht das?

[cabriofahrer]

Ich habe auf einem Raspberry Pi 3 NetBSD aarch64 installiert, weil NetBSD im Gegensatz zu FreeBSD sowohl das WiFi- als auch das Audiomodul unterstützt. Die Installation war kein Problem, das System wird automatisch über den Router ins Heimnetzwerk eingebunden. Hier ein Screenshot von einem ssh-Login von meinem Hauptrechner mit FreeBSD:

$ ssh werner@192.168.1.45
(werner@192.168.1.45) Password for werner@NetBSD.local:
Last login: Wed Oct 22 12:04:21 2025 from 192.168.1.131
NetBSD 10.1 (GENERIC64) #0: Mon Dec 16 13:08:11 UTC 2024

Welcome to NetBSD!

NetBSD$ ifconfig
mue0: flags=0x8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
    capabilities=0x7ff80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx>
    capabilities=0x7ff80<TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx>
    capabilities=0x7ff80<TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,TSO6>
    enabled=0
    ec_capabilities=0x1<VLAN_MTU>
    ec_enabled=0
    address: b8:27:eb:e4:44:fc
    media: Ethernet autoselect (none)
    status: no carrier
lo0: flags=0x8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33624
    status: active
    inet6 ::1/128 flags 0x20<NODAD>
    inet6 fe80::1%lo0/64 flags 0 scopeid 0x2
    inet 127.0.0.1/8 flags 0
bwfm0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ssid Shitstorm nwkey *****
    powersave off
    bssid 06:b0:44:43:f2:34 chan 100
    address: b8:27:eb:b1:11:a9
    media: IEEE802.11 autoselect (VHT mode 11ac)
    status: active
    inet6 fe80::ba27:ebff:feb1:11a9%bwfm0/64 flags 0 scopeid 0x3
    inet 192.168.1.45/24 broadcast 192.168.1.255 flags 0
NetBSD$

Wie man sieht, lautet das Device "bwfm0".

Die Frage ist jetzt, wie kann ich unter NetBSD eine Ad-Hoc Verbindung einrichten? Das Ziel ist es, den Raspberry Pi 3 in einem Haushalt anzusprechen (z.B. direkt von einem Mobilfunkgerät aus), in dem es kein Internet und keinen Router gibt.
Der erste Schritt wäre mit Sicherheit erstmal ein ifconfig bwfm0 down, um die Verbindung mit dem Router zu kappen.

Im Freebsd Handbook ist sehr schön beschrieben, wie man eine Ad-Hoc Verbindung herstellt (Kap. 34.5 https://docs.freebsd.org/en/books/handbook/advanced-networking/), aber unter NetBSD funktioniert das so natürlich nicht und ich kann in der NetBSD Doku nichts entsprechendes finden.

Irgendeine Idee?

 

[medV2]

Beschreibe doch mal genau was du machen möchtest. Ad-Hoc ist bei WLAN sehr eingeschränkt und wird deshalb auch kaum verwendet, eventuell ist es für deinen Anwendungsfall genau so gut oder sogar besser geeignet, auf dem Pi3 einen AccessPoint einzurichten. Dafür gibts auch diverse NetBSD Anleitungen

 

[cabriofahrer]

OK. Das Ziel ist, in einem internetlosen Haushalt auf dem Raspi einen MPD-Server mit mp3's einzurichten, der mittels eines Minijack zu Chinch Kabels an einen Stereoreceiver mit Boxen angeschlossen und mittles eine MPC-Clients (MaximumMPC auf Android) bedient werden kann.
Da dachte ich eben, eine Ad-Hoc Verbindung mit einer statischen IP Adresse auf dem Raspi, die dann im Smartphone einfach eingegeben werden kann, wäre die beste Lösung. Natürlich kann man das Smartphone auch direkt mit dem o.g. Kabel an den Receiver anschließen, oder auch ein Laptop mit mp3's, aber ist im ersten Fall natürlich blöd, wenn man zwischendurch telefonieren will.

 

[medV2]

Für diesen Fall würde ich einen AP auf dem Raspi erstellen. Auf Mobiltelefonen musst du dann nur die SSID+PW eintragen. Theoretisch kannst du natürlich dennoch eine fixe IP Zuweißung machen, aber ich würde da einfach dhcp machen lassen. Auch bei einem Ad-Hoc Netz würdest du zusätzlich zu IP noch SSID+PW benötigen.

Hier ist ne Anleitung. Achtung da wird WEP und WPA beschrieben, WEP NICHT (auf keinen Fall nicht nein!) verwenden, sondern direkt den WPA Teil lesen: https://www.tumblr.com/mrrooster/62694672/netbsd-wpa-wireless-ap

Da ich selbst kein NetBSD verwende kann ich das aber nicht überprüfen. Musst du ausprobieren. Sieht schon etwas älter aus..

 

[morromett]

Die Frage ist jetzt, wie kann ich unter NetBSD eine Ad-Hoc Verbindung einrichten?

Das sollte mit "mediaopt adhoc" in der zuständigen "ifconfig.<interface>"-Datei möglich sein:

The following media options are defined for IEEE802.11 Wireless LAN:

           IFM_IEEE80211_ADHOC
                         Ad-hoc (IBSS) mode.  [adhoc, ibss]

Quelle: https://man.netbsd.org/ifmedia.4

 

[CommanderZed]

Also ein kurzes googeln hat ergeben das z.B. Android den Ad-Hoc modus garnicht mehr unterstützt, nur noch etwas was sich wireless direct nennt.

Wie

Für diesen Fall würde ich einen AP auf dem Raspi erstellen. Auf Mobiltelefonen musst du dann nur die SSID+PW eintragen. Theoretisch kannst du natürlich dennoch eine fixe IP Zuweißung machen, aber ich würde da einfach dhcp machen lassen. Auch bei einem Ad-Hoc Netz würdest du zusätzlich zu IP noch SSID+PW benötigen.

Hier ist ne Anleitung. Achtung da wird WEP und WPA beschrieben, WEP NICHT (auf keinen Fall nicht nein!) verwenden, sondern direkt den WPA Teil lesen: https://www.tumblr.com/mrrooster/62694672/netbsd-wpa-wireless-ap

Da ich selbst kein NetBSD verwende kann ich das aber nicht überprüfen. Musst du ausprobieren. Sieht schon etwas älter aus..

richtig schreibt ist es vermutlich die beste Option das Gerät dann in den "AP" Modus zu setzen. Da statische IP-Addressen frimelig sind würde ich die in richtung mobiltelefon per DHCP machen - der Raspberry hätte ja dann eh eine statische IP und man kann die entspannt eingeben.

Man muss je nach Android oder iOS version evtl. das Gerät etwas deutlich überzeugen die wifi-verbindung auch dann zu verwenden wenn sie kein Internet bereit stellt. Solange man aber per DHCP kein DNS/Route verteilt sollte das weniger Probleme machen.

Es ist auch ganz charmant an der Lösung das sich mehrere Geräte verbinden können.

 

[cabriofahrer]

Ausgehend von dem Artikel, den @medV2 oben in #4 gepostet hat, leider mit WPA keinen Erfolg. Zunächst die /etc/hostapd.conf:

Dann service hostapd start(Der Eintrag hostapd=YES in /etc/rc.conf wurde erstellt):

Tja, sch...

Auch die andere Variante mit WEP aus dem Artikel wollte ich mal ausprobieren, doch da scheitert auch schon der erste Schritt:

Was mache ich falsch? Oder wird vielleicht unter NetBSD die Hardware doch nicht vollständig unterstützt? Was heißt denn "ifconfig: SCIOCSIFMEDIA: Invalid argument"? Das Ganze vielleicht doch besser mit Raspios (debian) ausprobieren? Wie wäre da die Anleitung?

 

[CommanderZed]

Host-AP Mode muss vom treiber unterstützt werden, in der netbsd manpages stehen leider gar keine modi.

Sollte das der gleiche treiber sein sieht das unter openbsd besser aus:

bwfm(4) - OpenBSD manual pages

Ich hab unter Linux mit nem raspberrypi3 / raspbian den hostap modus schonmal genutzt, da hatte ich mir für den Wohnwagen einen wlan empfänger / nat repeater gebastelt. Anleitung hab ich aber nicht mehr da ich auf 5g gewechselt bin, war etwas bastelig

 

[cabriofahrer]

Host-AP Mode muss vom treiber unterstützt werden, in der netbsd manpages stehen leider gar keine modi.

Die Sache hatte mich nicht mehr losgelassen, ich hatte aber lange keine Zeit, mich mit dem Thema weiter zu beschäftigen, ich musste auch erstmal Hardware zusammenbekommen, um irgendwie weiterzukommen. Das Problem war auch, dass NetBSD wohl ziemlich zickig ist mit Hardware im Gegensatz zu FreeBSD, hängt wahrscheinlich zusammen mit der Nichteinhaltung der ACPI-Spezifikationen einiger Hardwarehersteller.
Beispielsweise hatte ich mit dem 2006-er Mac(Schrott)-Book das Problem, dass die Einrichtung von einem einfachen AP mit WEP zwar klappte und das Mobiltelefon sich auch mit statischer IP verbinden ließ, die Verbindung aber sofort abbrach. Wie sich herausstellte, lag das aber daran, dass das Mac-Book sofort einen Freeze bekam, was sehr eigenartig ist, denn mit FreeBSD kein Problem (siehe anderen Thread https://www.bsdforen.de/threads/mod...verbindung-mit-smartphone-klappt-nicht.37468/). Der einzige Unterschied der mit einfällt, ist dass NetBSD im Gegensatz zu FreeBSD automatisch den drm-kmod für den alten Intel GMA 950 Chip lädt, auch wenn man X nicht startet.
Auf dem alten ACER Schrottbook (an anderer Stelle in diesem Forum vor Jahren schon erwähnt), lässt sich NetBSD im Gegensatz erst gar nicht installieren. Ich musste also an eine alte Wi-Fi PCI-Karte herankommen, die in der Wohnung meiner Freundin seit Jahren unbenutzt in einer alten Krücke steckt. Es handelte sich um einen alten PC mit einem Socket 939 Prozessor und ASUS-Board, auf dem ein FreeBSD 12.1 installiert war.
Auch hier ließ sich NetBSD nicht installieren, um es mit der eingebauten Wi-Fi-Karte ausprobieren zu können. Zudem funktioniert der Onboard Sound auch nicht, womit man das Projekt auch nicht mit FreeBSD realisieren könnte. Sehr ärgerlich. Welchen Schrott konnte ich also noch auftreiben? Zwar habe ich im Schrank noch ein Board mit einem PII 400 Mhz liegen, das ist aber sehr groß und da hatte ich erstmal keinen Bock drauf, das in ein Gehäuse zu verbauen. Und siehe da, da kam ich auf die Idee, ein altes M863G Board mit Athlon XP-Prozessor auszuprobieren, für welches ich damals vor mehr als 10 Jahren schon keine Verwendung fand und es seitdem nur Staub fangen ließ. Es hat Onboard SiS-Grafik und Sound, mehr braucht man für einen Musikserver zum Anschluss an die Stereoanlage auch nicht. Zudem funktioniert wohl auch das Onboard IDE nicht. Abhilfe schaffte eine alte Promise 133 IDE PCI Karte, mit der ich dann eine alte Festplatte anschließen konnte. Das Board hat nur zwei PCI-Steckplätze, der andere war also für die Wi-Fi-Karte. Und jetzt die große Freude: NetBSD ließ sich auf dem Teil problemlos installieren und läuft stabil.
Der AP mit WEP ließ sich laut Anleitung problemlos mit

ifconfig ral0 192.168.2.1 netmask 255.255.255.0 nwid Netzwerkname nwkey MeinPasswort mediaopt hostap mode 11g

einrichten. Ich konnte dann auch eine Verbindung mit dem Mobiltelefon herstellen und per M.A.L.P. den mpd steuern, das Ziel ist also erreicht.

sondern direkt den WPA Teil lesen:

Ich nehme mal an, dass die Anleitung das nicht erwähnt, aber wenn man direkt den WPA Teil liest, bekommt man doch gar keine IP Adresse?
Also müsste man doch vorher zumindest ein ifconfig ral0 192.168.2.1 netmask 255.255.255.0machen, oder? So habe ich es zumindest getan und so hat es auch geklappt. Ich konnte mit WPA zwar auch eine Verbindung mit dem Mobiltelefon herstellen, doch M.A.L.P. konnte dann keine Verbindung herstellen, also belasse ich es erstmal doch bei WEP. Den Sicherheitsaspekt hatten wir ja im anderen Thread schon besprochen. Das Teil steht ja jetzt auch bei meiner Freundin in der Wohnung und da schauen wir eh nur 1-2 Mal im Monat vorbei.

Zu der Hardware selbst: Ist natürlich alter Schrott, doch für den Zweck erstmal gut genug. Eleganter wäre natürlich ein Raspberry mit einem USB-Dongle, der die erforderliche Funktion für einen Host-AP unterstützt. Aber auf der anderen Seite hat man mit dem Raspi das Problem, dass er sich nicht per Knopfdruck herunterfahren lässt, wie eben ein alter PC. Man braucht also gar keinen Monitor für den PC.

 

[medV2]

Ich nehme mal an, dass die Anleitung das nicht erwähnt, aber wenn man direkt den WPA Teil liest, bekommt man doch gar keine IP Adresse?
Also müsste man doch vorher zumindest ein ifconfig ral0 192.168.2.1 netmask 255.255.255.0machen, oder? So habe ich es zumindest getan und so hat es auch geklappt. Ich konnte mit WPA zwar auch eine Verbindung mit dem Mobiltelefon herstellen, doch M.A.L.P. konnte dann keine Verbindung herstellen, also belasse ich es erstmal doch bei WEP. Den Sicherheitsaspekt hatten wir ja im anderen Thread schon besprochen. Das Teil steht ja jetzt auch bei meiner Freundin in der Wohnung und da schauen wir eh nur 1-2 Mal im Monat vorbei.

Zu der Hardware selbst: Ist natürlich alter Schrott, doch für den Zweck erstmal gut genug. Eleganter wäre natürlich ein Raspberry mit einem USB-Dongle, der die erforderliche Funktion für einen Host-AP unterstützt. Aber auf der anderen Seite hat man mit dem Raspi das Problem, dass er sich nicht per Knopfdruck herunterfahren lässt, wie eben ein alter PC. Man braucht also gar keinen Monitor für den PC.

Ja natürlich war das so gemeint, dass du die WEP Config weglässt und direkt zu WPA springst, die Basisdinge bleiben natürlich. Und weil ich sonst nicht schlafen kann: Mach das WLAN öffentlich, ohne Verschlüsselung. Wenn du das nicht möchtest, mach WPA. Wenn WPA nicht geht, du aber nicht öffentlich ohne Passwort willst, kauf neue HW. WEP ist nämlich nichts anderes als öffentlich.

 

[cabriofahrer]

Mach das WLAN öffentlich, ohne Verschlüsselung. Wenn du das nicht möchtest, mach WPA. Wenn WPA nicht geht, du aber nicht öffentlich ohne Passwort willst, kauf neue HW. WEP ist nämlich nichts anderes als öffentlich.

Verstehe ich nicht ganz. Mit neuer Hardware und öffentlich ohne Passwort ist sicherer als WEP mit Passwort?
Noch eine Anmerkung zu einer Beobachtung von mir: Bei WEP zeigte mir ein ifconfigauf der Maschine mit NetBSD das Passwort an! Das fand ich schon mal sehr verwunderlich und beunruhigend, denn bei WPA ist das natürlich nicht der Fall. Aber: Als ich mit einem Notebook (FreeBSD) mit wifimgrnach Netzwerken scannte, wurde das Netzwerk erkannt, aber das Passwort nicht angezeigt. Also doch schon mal beruhigend.
Natürlich wäre mir WPA lieber, zumal es ja auch grundsätzlich funktioniert, aber wenn der mpd-Client dann keine Verbindung herstellen kann, habe ich nichts davon. Der Rechner steht jetzt auch wie gesagt in der Wohnung meiner Freundin, wo wir nur ab und zu hingehen.
Und jetzt bin ich aber doch sehr neugierig, @medV2 . Gib mir doch bitte eine Anleitung, wie ich ein WEP-Netztwerk hacke, damit ich das Problem der Unsicherheit nachvollziehen kann. Wir reden hier natürlich von "ethical hacking" zu Ausbildungszwecken.
Und neue Hardware kommt für diesen konkreten Anwendungsfall nicht in Frage. Es ging gerade darum, mit altem Schrott noch etwas Brauchbares zu machen. Und um Musik über die Kopfhörerbuchse auszugeben, ist sogar ein Athlon XP noch ein Overkill.

 

[Andy_m4]

Mit neuer Hardware und öffentlich ohne Passwort ist sicherer als WEP mit Passwort?

Nein. Das war nicht seine Aussage.
Seine Aussage war: Wenn Du Sicherheit willst, verschlüssele ordentlich (sprich: Nimm WPA bzw. WPA2 bzw, WPA3). Wenn Deine Hardware WPA nicht unterstützt, dann solltest Du sie austauschen.

Wenn Du keine Sicherheit willst, lass Verschlüsselung ganz weg.

Die schlechteste Wahl ist WEP zu nehmen.
Weil das suggeriert zwar Sicherheit, ist aber letztlich sicherheitstechnisch kaum über "unverschlüsselt". Und dann kann mans auch gleich bleiben lassen.

Sicherlich ist das auch immer eine Frage der persönlichen Risikobetrachtung.
In einer Waldhütte wo vielleicht allenfalls mal ein Förster vorbei kommt, ist man mit WEP sicherlich weniger gefährdet als im Zentrum einer Großstadt.

Aber das sind Sicherheitsbetrachtungen unabhängig von der Sicherheit des Verfahrens.
Von der Sicherheit des Verfahrens würde ich als Annahme machen:
WEP schützt vor versehentlichen einloggen ins WLAN.

Wenns nur darum geht, dann kann man WEP nehmen. Wenns darum geht, das niemand unbefugt in den Datenverkehr reinschaut oder das WLAN benutzt, dann ist WEP als unzureichend anzusehen.

Gib mir doch bitte eine Anleitung, wie ich ein WEP-Netztwerk hacke, damit ich das Problem der Unsicherheit nachvollziehen kann.

Ich weiß nicht, ob das zielführend ist.
Erstens bereitet man damit dem Forenbetreiber potentiell Probleme, wenn man hier Hack-Anleitungen reinpostet.
Zweitens gibt es im Internet genügend Material dazu.
Drittens: Selbst wenn Du es selbst nicht schaffst WEP zu hacken, heißt es ja noch lange nicht, das es objektiv betrachtet sicher ist.

Vielleicht solltest Du die Aussage das WEP unsicher ist, einfach mal annehmen.

Und selbst, wenn Du Dir jetzt so denkst: "So ein dahergelaufener Foren-Nutzer kann mir ja sonst was erzählen":
Du kannst ja das als Anlass nehmen selbst zu recherchieren, um diese WEP-ist-unsicher-Behauptung zu verifizieren.
Ein guter erster Anlaufpunkt ist Wikipedia:
https://de.wikipedia.org/wiki/Wired_Equivalent_Privacy

Es ging gerade darum, mit altem Schrott noch etwas Brauchbares zu machen.

Naja. Aber wenn es aus Gründen nicht geht, dann nützt Dir ja auch ein Trotziges "Ich will aber" nicht.

Ich meine, wenn Du es trotzdem machst, ists ja letztlich auch Deine Sache.
Es ist ja erst mal nett, wenn man darauf hinweist. Und entweder Du berücksichtigst das oder Du lässt es bleiben.
Aber da noch großartig herumzudiskutieren macht eigentlich keinen Sinn.

 

[medV2]

Und jetzt bin ich aber doch sehr neugierig, @medV2 . Gib mir doch bitte eine Anleitung, wie ich ein WEP-Netztwerk hacke, damit ich das Problem der Unsicherheit nachvollziehen kann. Wir reden hier natürlich von "ethical hacking" zu Ausbildungszwecken.
Und neue Hardware kommt für diesen konkreten Anwendungsfall nicht in Frage. Es ging gerade darum, mit altem Schrott noch etwas Brauchbares zu machen. Und um Musik über die Kopfhörerbuchse auszugeben, ist sogar ein Athlon XP noch ein Overkill.

Eigentlich hat @Andy_m4 schon alles gesagt was es zu sagen gibt. Du findest ganz leicht Anleitungen um WEP zu hacken, hier rein posten werde ich sie nicht, aber eine Anlaufstelle wäre eventuell die Seite von aircrack-ng. Es gibt auch für Pentesting spezialisierte Linuxdistros, die das ganze nochmal vereinfachen, hier sei zB Kali Linux genannt.

Ad alte HW weiter nutzen: Dann häng nicht dogmatisch an *BSDs fest, sondern geh den Weg zu Linux, da ist mE der Pi deutlich besser unterstützt. Und Tutorials gibts auch wie Sand am Meer.

 

[cabriofahrer]

Nein. Das war nicht seine Aussage.
Seine Aussage war: Wenn Du Sicherheit willst, verschlüssele ordentlich (sprich: Nimm WPA bzw. WPA2 bzw, WPA3). Wenn Deine Hardware WPA nicht unterstützt, dann solltest Du sie austauschen.

Dann liegt hier ein Missverständnis vor. Ich hatte ja gesagt, dass die Verbindung mit WPA zustande kam, aber der M.A.L.P. keine Verbindung aufbauen konnte. Die Hardware scheint also in Ordnung zu sein.

Zweitens gibt es im Internet genügend Material dazu.

Ich hatte auch kurz nach meinem Post selbst einen guten Artikel dazu gefunden.

Vielleicht solltest Du die Aussage das WEP unsicher ist, einfach mal annehmen.

Und selbst, wenn Du Dir jetzt so denkst: "So ein dahergelaufener Foren-Nutzer kann mir ja sonst was erzählen":

Das tue ich ja auch. Und so ist das ja nicht, ich schätze die hier gemachten Beiträge sehr und nehme diese auch zu Herzen. Ich will auch nicht einfach rumdiskutieren.

Naja. Aber wenn es aus Gründen nicht geht, dann nützt Dir ja auch ein Trotziges "Ich will aber" nicht.

Nun, es scheint ja wie gesagt kein Hardwareproblem zu sein, sondern vielleicht ein Konfigurationsproblem des mpd unter NetBSD. Kann aber der Sache nicht weiter auf den Grund gehen, da die Kiste eben nicht mehr bei mir steht.

aircrack-ng. Es gibt auch für Pentesting spezialisierte Linuxdistros, die das ganze nochmal vereinfachen, hier sei zB Kali Linux genannt.

Ja, das steht in dem Artikel, den ich gefunden habe. aircrack-ng gibt es auch für FreeBSD und andere Linux Distros.

Ad alte HW weiter nutzen: Dann häng nicht dogmatisch an *BSDs fest, sondern geh den Weg zu Linux, da ist mE der Pi deutlich besser unterstützt. Und Tutorials gibts auch wie Sand am Meer.

Sicherlich. Auf meinem Raspi nutze ich Raspios zum Kodi-Gucken, weil es eben nicht anders geht. Aber NetBSD schien mir einfach sympathisch, weil es zumindest das Audiomodul unterstützt und das war dann eben der Ausgangspunkt, nachdem sich alles Weitere ergeben hat.

Ich meine, wenn Du es trotzdem machst, ists ja letztlich auch Deine Sache.

Klar. Also wenn ich jetzt einen Heimserver mit sensiblen Daten aufsetzen wollte, wäre das natürlich auch etwas ganz anderes und schlichtweg leichtsinnig. Ich werde vielleicht in Zukunft das Projekt noch verbessern, aber im Moment bin ich erstmal froh, dass ich Musik in der besagten Wohnung hören kann, wenn wir denn mal für zwei Tage dort sind, ohne mein Mobiltelefon an ein Kabel zum Receiver stöpseln zu müssen.
Ich bedanke mich für Eure Beiträge hier.

 

[Andy_m4]

Nun, es scheint ja wie gesagt kein Hardwareproblem zu sein,

Wobei mir "Hardwareproblem" ja auch gemeint sein kann, das die Hardware unter besagten Betriebssystem nicht richtig supportet wird, obwohl sie damit unter anderen Betriebssystemen kein Problem hat.

Ich hatte so was in der Art letztens auch. Allerdings unter FreeBSD. Es machte den Eindruck, als ob sich alles brav für WPA konfigurieren lässt aber letztlich kam keine stabile Verbindung zustande. Da lag es am mangelhaften Treibersupport.

In der Regel kriegt man so was aber raus, in dem man sich den Treiber anschaut und guckt, ob das konkrete Device wirklich explizit unterstützt wird.

 

[cabriofahrer]

Ich hatte so was in der Art letztens auch. Allerdings unter FreeBSD. Es machte den Eindruck, als ob sich alles brav für WPA konfigurieren lässt aber letztlich kam keine stabile Verbindung zustande. Da lag es am mangelhaften Treibersupport.

Um welchen Wi-Fi Chip handelte es sich da? Also meiner muss wohl mind. 15 Jahre alt sein und wird als "ral0" erkannt. Scheint wohl ziemlich standard zu sein und dürfte von daher auch keine Probleme machen.

 

[CommanderZed]

Sag mal, du hattest doch ursprünglich da nen PI3 - hast du den jetzt äh gegen den Athlon XP getauscht mit einer ral-karte? Oder ist das das "Quellgerät" zum ansteuern des Pis?

 

[cabriofahrer]

Sag mal, du hattest doch ursprünglich da nen PI3 - hast du den jetzt äh gegen den Athlon XP getauscht mit einer ral-karte?

Ja, genau. Alternativ hätte ich mir einen Wi-Fi USB-Dongle für den PI3 kaufen können, aber so konnte ich erstmal mit dem, was ich hatte, sichergehen, ob es mit NetBSD und unterstützter Hardware funktioniert. Der mpd liegt also auf dem alten PC mit dem Athlon XP und wird per Smartphone mit M.A.L.P. gesteuert.

 

[Andy_m4]

Um welchen Wi-Fi Chip handelte es sich da?

Gute Frage. Der war auch jeden Fall neuer und brauchte den rtwn-Treiber.
Was auch immer man hat, man sollte gucken ob der WLAN-Stick in der Hardware-Compatiblity-List auftaucht:
https://www.freebsd.org/releases/15.0R/hardware/#wlan
Manche Treiber sind auch in den Packages/Ports. Wird man da auch nicht fündig, sieht es eher schlecht aus. Theoretisch kann man noch was mit wifibox reißen. Aber dieser Weg über Linux-VM ist natürlich nicht besonders schön.

und wird als "ral0" erkannt

Das ist dann wohl der Treiber:

ral(4)

man.freebsd.org

Bei NetBSD muss man dann natürlich entsprechend dort gucken.
Hier mal exemplarisch für ral:

ral(4) - NetBSD Manual Pages

man.netbsd.org

 

[Yamagi]

Ralink ist am 5. Mai 2011 von Mediathek aufgekauft worden. Soweit ich mich erinnere - und das ist wirklich lange her - hat Ralink niemals mehr als 802.11N Chips gebaut. Das ist alles nicht unbedingt jungfräulich und man sollte auch nicht vergessen, dass neuere 802.11N Karten durch mehr Rechenleistung und dadurch bessere Algorithmen zur Entstörung robuster sind, aber es ist auch nicht komplett Scheiße. Im Sinne von 802.11G, möge es in Frieden ruhen.

Ich würde erstmal ein richtiges Laptop oder so in das Ad Hock Netzwerk hängen und schauen, ob das den mpd-Server erreichen kann. Wenn nicht, schauen wie weit man überhaupt kommt und dann von da an versuchen rauszufinden, wo es hakt.

 

[CommanderZed]

Moin,

ich hatte etwas Zeit und wollte eh mit dem Raspberry 3 den ich noch hab ein bisschen rumprobieren:

1. Bei mir funktioniert das mit dem Raspberryos / Raspbian alles sehr entspannt inkl. WPA2 out of the box, den hostap-modus hatte ich vorher schonmal konfiguriert, das hatte mich damals ne halbe stunde gekostet und mpd (über alsa) mit dem build-in audiojack zum laufen zu kriegen hat nochmal ca, ne halbe Stunde gedauert.

2. Ich hab das dann nochmal mit OpenBSD nachgebaut weil ich schon ewig mal OpenBSD auf dem Berry probieren wollte.
Da ich noch nie OpenBSD auf dem Berry verwendet hatte, hat das etwas gedauert, allein schon weil die performance eher mäßig ist aber auch weil es doch ne gewisse Lernkurve gab.
MPD und host-ap mit WPA2 waren dann aber auch schnell eingerichtet und haben sofort funktioniert, unter OpenBSD mangels treiber für das Audio-Interface über so einen USB-Audio-Adapter den ich noch rumfliegen hatte und die es bei ali immer mal für unter nen euro gibt. Tendenziell würde ich aber wohl da dann doch Linux den vorzug geben, für so ein einfachs setup aus hostap, dhcp-server und mpd ist das auch nicht sonderlich komplex.

Wirklichen "zweck" hat das bei mir nicht, ich brauche kein MPD aber ich war neugierig

Als Client hab ich sowohl mein aktuelles ios gerät (iPhone) als auch ein älteres Android das ich als ersatzgerät nutze vertestet. Es hat mit beiden funktioniert.

Allerdings:
Insbesondere Android ist "zickig" - und ich weiß aus Erfahrung das es auf die Detail-Android-Version ankommt - wenn ein WLAN mit dem man Verbunden ist keinen Zugang zum Internet zur Verfügung stellt - das ist unabhängig vom hostap (Das könnte auch genauso gut ne Fritzbox sein ohne Internet) aber etwas blöd. Mit etwas rumprobieren konnte ich das bei meiner älteren Version hinkriegen. Generell hab ich für die Installation und erste Tests den Raspberry auch als nat-router über den LAN-Port konfiguriert, so konnte ich die Fehlerquelle ausschließen da ios/android dann über den raspberry eine Internetverbindung bekommen haben.

 

[cabriofahrer]

und mpd (über alsa) mit dem build-in audiojack zum laufen zu kriegen hat nochmal ca, ne halbe Stunde gedauert.

Eine halbe Stunde? Sehr unangenehm. Bei NetBSD hat zumindest das sofort ohne weiteres Zutun geklappt. Bezüglich Sound bei RaspiOS (Bookworm) habe ich zumindest die Erfahrung gemacht, dass der Sound besser / lauter ist, wenn man das Minimalimage ohne Desktop nimmt. Ich glaube, da ist ALSA dann noch nichtmal dabei.

MPD und host-ap mit WPA2 waren dann aber auch schnell eingerichtet und haben sofort funktioniert, unter OpenBSD mangels treiber für das Audio-Interface über so einen USB-Audio-Adapter den ich noch rumfliegen hatte und die es bei ali immer mal für unter nen euro gibt.

Will man auf dem Raspi beharren, kann man natürlich auch anders herum mit NetBSD einen Wi-Fi Dongle nehmen.

Tendenziell würde ich aber wohl da dann doch Linux den vorzug geben, für so ein einfachs setup aus hostap, dhcp-server und mpd ist das auch nicht sonderlich komplex.

Wie hast Du den dhcp-server konfiguriert? In allen Beispielen, die ich gesehen habe, wird immer auch ein DNS Server mit eigener IP als Eintrag aufgeführt. Angeblich soll ein DNS-Server für dhcp aber nicht zwingend nötig sein. Und wäre auch eine Lösung mit mDNS/avahi möglich?

 

[CommanderZed]

Eine halbe Stunde? Sehr unangenehm. Bei NetBSD hat zumindest das sofort ohne weiteres Zutun geklappt. Bezüglich Sound bei RaspiOS (Bookworm) habe ich zumindest die Erfahrung gemacht, dass der Sound besser / lauter ist, wenn man das Minimalimage ohne Desktop nimmt. Ich glaube, da ist ALSA dann noch nichtmal dabei.

Ich fand jetzt ne halbe stunde um erstmal
-> zu googeln was mpd überhaupt ist, das paket zu installieren
-> Nochmal kurz das Netzdesign durchdenken
-> mich da erstmals in meine Leben durch die config zu wühlen wo ich wie wie musik speichern muss, playlist
-> Kurz mal das konzept lernen (aha, das ist ein client-server konzept wo der server die Musik gespeichert hat und ich mit dem client das Gerät fernsteuer und die musik auch lokal vom Server abgespielt)
-> googeln das beim raspi alsa und der jack sinnvoll ist und mit welchen kommandos ich den einstelle (Man muss ihm ja irgendwie sagen welche Audiodevice das ist)
-> noch klassische mp3 musik erstmal in meinen archiv finden (Nur nen paar als Demo, aber ich höre seit jahren nur noch per spotify)
-> welche app ich auf dem iphone verwende, diese dort installieren, runterschmeißen weil kostenpflichtig, ne andere versuchen
-> Noch 2,3 andere kleinigkeit
Die aktive "MPD" Zeit am Raspberry waren wenige Minuten. Aber ich lese grundsetzlich mich erstmal in ein Konzept rein wie etwas im groben funktioniert bevor ich in die Tasten hauhe.
Finde das dafür garnicht so lang ehrlich gesagt.

Will man auf dem Raspi beharren, kann man natürlich auch anders herum mit NetBSD einen Wi-Fi Dongle nehmen.

Wie hast Du den dhcp-server konfiguriert? In allen Beispielen, die ich gesehen habe, wird immer auch ein DNS Server mit eigener IP als Eintrag aufgeführt. Angeblich soll ein DNS-Server für dhcp aber nicht zwingend nötig sein. Und wäre auch eine Lösung mit mDNS/avahi möglich?

DHCP ist ja letztlich vor allem die vergabe von IP-Addressen durch einen DHCP-Server an Clients und ersetzt die manuelle konfiguration.
Je nach dem welchen DHCP-Server man verwendet kann man da dann recht Granular steuern was er den Clients neben der IP-Addresse gibt. Gateway und DNS machen in den meisten Szenarien natürlich schon irgendwie sinn.
Wenn das ding keine Internetconnectivität bereit stellt würde ich Gateway und DNS weg lassen.

 

[pit234a]

In allen Beispielen, die ich gesehen habe, wird immer auch ein DNS Server mit eigener IP als Eintrag aufgeführt. Angeblich soll ein DNS-Server für dhcp aber nicht zwingend nötig sein.

ich rede nicht über diese Beispiele und auch nicht über das hier behandelte Problem.
Vielleicht nützt aber folgende Erklärung doch was dazu:
Wenn ein Rechner eine feste (statische) IP hat, kann er darüber angesprochen werden. Das gilt auch, wenn Rechner = Internet-Router, also auch aus dem Internet heraus. Wenn ich die IP kenne, die mein Internet-Provider mir vergeben hat, kann ich also auch aus der Ferne (über Regeln im Router) auf mein eigenes Netz zu Hause zugreifen. Nur zum Beispiel, das gesagte gilt aber nicht nur für Internet.
Das Problem lässt sich am Internet-Beispiel aber recht gut darstellen, denn feste IP-Adressen vergeben die Provider nicht (an kleine Privatpersonen).
Sobald also die IP-Adresse eines Rechners nicht statisch ist, kann man sie ohne Weiteres nicht wissen. Nicht von außen jedenfalls. Genau das macht aber ein DHCP-Server: er vergibt IP-Adressen und zwar erst mal dynamisch. Nur bei entsprechender Konfiguration, vergibt er Adressen auch statisch, in der Regel an eine MAC-Adresse gebunden.
Um nun unabhängig von einer IP-Adresse einen Rechner ansprechen zu können, kann man diesen mit seiner (wechselnden) IP-Adresse bei einem DNS registrieren und dann unter einem einfachen Namen ansprechen. Der DNS löst über den vergebenen Namen dann die IP-Adresse auf.
Man kann vielleicht daraus ableiten, dass für eine Verbindung von außen zu seinem eigenen Netzwerk ein entsprechender Mechanismus hilfreich oder sogar notwendig ist, mit dem sich der Internet-Router mit seiner IP-Adresse bei einem DNS (im Internet) registriert.
Bewegt man sich nur innerhalb seines eigenen Netzes, kann man natürlich auch einen eigenen DNS betreiben und mit entsprechenden Informationen füttern. Dann braucht man sich keine weiteren Gedanken über wechselnde IP-Adressen zu machen, braucht aber eben einen Mechanismus (eine SW), die den DNS über einen Wechsel der IP-Adressen informiert.
Vergibt man nur statische IP-Adressen, kann man auf den Registrier-Mechanismus verzichten und den DNS entsprechend fest konfigurieren.
Aber: wenn man sich mit mobilen Endgeräten in unterschiedlichen Netzen bewegt, hat man mehr Hirnschmalz zu investieren, wie man die immer gleichen Adressen realisieren kann, als wenn man sich auf die erwähnten Automatismen verlässt.
Vielleicht erklärt sich dadurch die Behauptung, dass DNS mit DHCP notwendig wird, aber eine technische Grundlage dafür gibt es nicht wirklich.
Es kann dir das Leben vereinfachen, wenn du PCs über ihren Namen ansprechen kannst, ohne dafür erst noch ihre IP-Adresse auslesen zu müssen.

etwas nebenbei:
Zu "Unix-Zeiten" hatte man schon eine vergleichbare Lösung mit der Datei /etc/hosts.
Die ist quasi so etwas wie ein mini-DNS für feste IP-Adressen auf einem lokalen PC, kann also von anderen Rechnern aus nicht genutzt werden, während ein DNS den Service ja im Netzwerk bereit stellt.

 

[cabriofahrer]

Wenn das ding keine Internetconnectivität bereit stellt würde ich Gateway und DNS weg lassen.

Ja, so hatte ich mir das auch gedacht. Ist ja auch durchaus sinnvoll für das hier besprochene Vorhaben.
Wie sieht denn dann Deine /etc/dhcpd.conf(oder wie die Config-Datei bei Dir heisst) aus? Ich frage, weil ich bei NetBSD immer die Meldung "/etc/dhcpd.conf not readable" bekam, obwohl ich den Beispielen gefolgt war.

etwas nebenbei:
Zu "Unix-Zeiten" hatte man schon eine vergleichbare Lösung mit der Datei /etc/hosts.
Die ist quasi so etwas wie ein mini-DNS für feste IP-Adressen auf einem lokalen PC, kann also von anderen Rechnern aus nicht genutzt werden, während ein DNS den Service ja im Netzwerk bereit stellt.

Ja, das wusste ich auch und das ist ein cooles Feature, gerade für kleinere Netzwerke. Aber soweit ich weiß, müssen alle /etc/hosts im Netzwerk die Einträge haben. Das wäre in diesem Fall also auch das Android Smartphone, was natürlich nicht so auf Anhieb nicht geht.