Möglich gleichzeitig in 2,4 Ghz mit AP und im 5 Ghz als AP zu arbeiten?

[AleXSR700]

Wieder ein bisschen was gelernt. Aber ich hatte schon befürchtet, dass es nur geht, wenn quasi zwei "unabhängige" Chips verbaut sind.
Damit ist automatisch beim RasPi der verbaute raus.
Da ich dann automatisch einen USB Dongle brauche, ist es auch egal, ob er zwei oder einen Chip hat. Denn der Dongle würde dann die Verbindung zum Hotspot herstellen und der eingebaute Chip des RasPi wäre der lokale AP für meine Endgeräte.
Der stärke, also der externe, sollte ja immer die Verbindung zur Quelle (hier dem Hotspot) aufbauen.

Schade eigentlich. Wäre richtig praktisch gewesen, wenn das softwareseitig lösbar gewesen wäre.
Interessant dann auch, wie das dann wohl bei MiMo, Mesh und Co gemacht wird.

[Sophia]

2 Raspi oder einen AP oder einen Billig-Router mit _WRT?
https://dd-wrt.com/
https://openwrt.org/
Nach eigenen Messungen (kalibriertes Digitalmultimeter zwischen Steckdose und Netzteil, Stromverbrauch arg schwankend bei eingeschalteten Rechnern, Stromverbrauch recht gleichmässig bei ausgeschaltetem Rechner, nur Wandwarze nimmt Strom) benötigen auch kleine Netzteile recht viel Strom. So etwa 15 mA bei 230 V für eine Wandwarze oder Kabel-Netzteil bei abgeschaltetem Verbraucher (PC/Laptop/Router). Bitte jedes Netzteil (für Accesspoint, Router, Raspi usw.) welches dauerhaft mit Netzspannung versorgt wird, genau überlegen. Oder abschaltbare Steckdosenleiste.

Interessant dann auch, wie das dann wohl bei MiMo, Mesh und Co gemacht wird.

_wrt (Linux) kann das, Links oben.

[AleXSR700]

Ich meinte, wie das hardwareseitig umgesetzt wird

Ich kenne natürlich OpenWRT, aber aus meinen Freetz Erfahrungen sind modifizierbare Router schön und gut, aber eben nur sinnvoll, wenn man einen Router braucht.
Das brauche ich jedoch nicht. Und sowohl bei einem NAS als auch bei einem Router stellt man fest, dass jede Zusatzkomponente wie etwa VPN deutlich Leistung abzieht.

Ein dedizierter Server ist da leistungsstärker und zukunftssicherer. Auf einem RasPi kann ich in Zukunft jede andere VPN Server, die unter Linux läuft, installieren. Ich kann Hardwarekomponenten tauschen. Ich kann weitere Dienste laufen lassen, ohne die Firmware komplett zu ändern. Es gibt kein Platzproblem (der Speicher eine Fritzbox oder allgemein eines Routers ist ja stark begrenzt).
Und und und.


Aber eine andere Frage: kann man eigentlich alle Netzwerkkarten gleichzeitig bridgen? Oder immer nur zwei?
Ich würde dann gerne den eingebauten WLAN Adapter mit eingebautem LAN bridgen und gleichzeitig den eingebauten auch mit dem externen WLAN.
Ziel ist es, dass ich den RasPi ohne Modifikationen sowohl über LAN als auch über den externen WLAN Dongle mit dem Internet verbinden kann und der interne WLAN Chip (AP) zu beiden weiterleitet, je nachdem, welcher halt in Betrieb ist.

[reox]

In die Bridge kannst du so viele einbauen wie du willst (bzw er dich lässt).
Ich hab das auch bei mir so, dass eth1, eth2 und wlan0 in der bridge sind.

[TomL]

Ich hab das auch bei mir so, dass eth1, eth2 und wlan0 in der bridge sind.

Wie funktioniert das mit WLAN als Bridge-'Client'? Ich habe das mit all meinen WLAN-Devices versucht, nicht ein einziger Treiber unterstützt den Bridge-Mode. Gibt es dafür einen Trick? Im Web habe ich nur Hinweise darüber gefunden, dass das allgemein nicht so einfach geht bis hin zur Feststellung Unmöglich.

[MSfree]

Ich habe das mit all meinen WLAN-Devices versucht, nicht ein einziger Treiber unterstützt den Bridge-Mode.

Das geht mit meinem Raspberry 3B problemlos mit dem onboard WLAN (Broadcom BCM43438 ).

[TomL]

Das geht mit meinem Raspberry 3B problemlos mit dem onboard WLAN (Broadcom BCM43438 ).

Das überrascht mich noch nicht mal.... ist halt ein besonders Board. Aber die Frage ist, ob sich daraus was allgemeines ableiten lässt. Unsere drei normalen 64'er BIOS/UEFI-Boards der Laptops, sowie zwei USB-Sticks können das nicht. Ich habe mich sehr lange im Zuge des VM-Einsatzes auf den Systemen damit befasst. Mit Bridge wäre sie reguläre LAN-Clients, ich habs aber nur also "isolated net' mit DNSMasq, via NAT und eigenem Subnet hingekriegt.

Ist es also eher normal, dass es gehen muss, oder ist es eher normal, dass das mit WLAN-NICs zumeist nicht geht?

[MSfree]

Ist es also eher normal, dass es gehen muss, oder ist es eher normal, dass das mit WLAN-NICs zumeist nicht geht?

Wahrscheinlich sind es nur wenige WLAN-NICs, für die du Firmware und/oder Kernelmodule bekommst, die bridgefähig sind. Für den Raspi hat man früher gerne so einen kleinen Edimax-USB-WLAN-Stecker empfohlen, bevor WLAN auf den Raspis Standard wurde. Die Dinger sind auch bridgefähig, zumindest zusammen mit Raspbian/RaspiOS.

Ich habe zuhhause noch so ein Ding rumliegen, damit kann ich ja mal ausprobieren, ob der auch an einem PC unter Buster als Bridge nutzbar ist.

[AleXSR700]

Alle WLAN Chips, die AP geeignet sind, sind angeblich auch Bridge geeignet. Aber das trifft halt nur auf relativ wenige Chipsätze zu. Das ist auch mein Problem. Es gibt aktuell kaum Chips, die 802.11ac kompatibel sind und unter Raspian OS laufen UND dann auch noch AP können (und somit Bridge).

Deshalb verstehe ich auch nicht, wieso Raspberry sich nicht wieder einen USB Dongle aussucht und den dann supported. USB 3.0 mit 802.11ac. Oder meinetwegen gleich Wifi 6.

Deshalb wird es bei mir als Zweitkarte leider ein n Chipsatz von Ralink. Denn der läuft von Hause aus und kann AP mit Bridge.
Scheint einfach ein Kernelproblem zu sein bzw. der übliche Treibermangel unter Linux.

Ich finde, dass das die größte Schwachstelle bei Linux ist. Es gibt zu viele OS mit zu vielen Kernels, sodass fast immer irgendein Treiber oder ein Programm selbst compiliert werden muss. Und da geht dann das Chaos los.

Also, AP-geeignet -> Bridge-geeignet.

[MSfree]

Alle WLAN Chips, die AP geeignet sind, sind angeblich auch Bridge geeignet.

Grundsätlich ist jeder WLAN-Chip AP-geeignet und auch den passiven Modus (interessant für wardriving, um die Gegend zu scannen) beherrscht jeder Chip. Das Porblem ist die Firmware, die eben nicht für jeden Chip frei verfügbar ist, sondern den Herstellern von APs und DSL-Routern vorbehalten bleibt und nur gegen ein NDA und $ vom Chiphersteller rausgerückt wird.

Scheint einfach ein Kernelproblem zu sein bzw. der übliche Treibermangel unter Linux.

Keine Treibermangel sondern Mangel an frei verfügbarer Firmware. Das gleiche gilt übrigens auch für Windows. Windows kann nämlich ebenfalls als AP eingerichtet werden, aber nur, wenn man passende Firmware für den WLAN-Chip bekommt.

Also, AP-geeignet -> Bridge-geeignet.

Falsch.

[wanne]

Scheint einfach ein Kernelproblem zu sein bzw. der übliche Treibermangel unter Linux.

Nein. Das ist vollständiger Quatsch. Ich gehe jede Wette ein: Du findest keinen einzigen Dongle der unter Windows oder BSD Bridge modus kann aber unter Linux nicht. Ganz im Gegenteil: Die Dongles die unter Windows überhaupt AP können, kannst du an einer Hand abzählen. Wenn überhaupt Add-Hoc.
Viele Chips können es schlicht nicht das brauch schlicht mehr Ressourcen, wenn du 2 Sachen parallel auf der gleichen Hardware machen willst oder es hat halt nie irgend jemand passende Firmware geschrieben.
Du kannst mit airbase-ng auch alles in software machen. Wird dann halt frikelig instabil und Rechenintensiv. – Und fürs Tunig musst du halt doch wieder Filter haben, die auf 2 Kanäle filtern können. (Wenn du den AP und den STA nicht auf dem gleichen Kanal betreiben willst, wie das da üblich ist.)
Aber im Wifi-Bereich Bekommt Linux seit immer als erstes Treiber und vor allem schon immer die mit den mit Abstand meisten Funktionen. Schlicht und einfach weil auf vielen Platikrouter und Embedded Devices Linux läuft und hinter denen halt Käufer stecken die sagen ich nehme mal ein paar 10000 ab, wenn das Ding Feature XY unter Linux kann. Früher waren das die Router. Aktuell sind das die Handys.

[AleXSR700]

Okay, ich meinte damit nicht, dass die Kernel es grundsätzlich nicht können würden, sondern eben die Treiber/Firmware fehlt. Allerdings würde ich von mangelnden Treibern sprechen und weniger, wie ihr, von mangelnder Firmware. Denn die Firmware ist ja auf dem Gerät immer drauf. Die Treiber im Kernel fehlen zum korrekten Ansprechen/Steuern.

Vermutlich können hardwareseitig auch viel mehr WLAN Adapter AP Mode, aber wenn die Treiber nicht vorhanden sind (der Grund ist ja egal), dann hilft auch theoretische Fähigkeit nichts. Und wenn es prinzipiell Treiber gäbe, aber es eben oft zu Problemen beim Compilen kommt, dann ist auch niemandem geholfen.
Die meisten Probleme sind User-gemacht. Aber man darf eben auch nicht davon ausgehen, dass jeder User ein Programmierer ist. Und vor allem nicht ein Linux Programmierer. Heisst, es ist und bleibt eine große Schwäche bei Linux, dass die Hersteller nicht einfach einen Treiber für "Linux" herausgeben können, so wie sie es in der Regel für Windows tun. Deshalb muss der User ran. Und dann kann es trotzdem zu Problemen kommen, weil der Treiber funktioniert aber nicht jedes Programm mit diesem Treiber zu Recht kommt.

Ich denke schon, dass man objektiv betrachtet, Linux die Bedienerfreundlichkeit bei sowas absprechen kann.

Ansonsten würde ich mich mega freuen, wenn mir hier jemand einen 802.11ac USB 3.0 Dongle nennen würde, der wie in Windows ohne großen Aufwand mit plug&play auf einem Raspberry 4 Model B läuft. Ich konnte bisher keinen finden und habe auch keine Empfehlung finden können.
Ihr dürft mich da also sehr gerne eines besseren belehren.

[MSfree]

Denn die Firmware ist ja auf dem Gerät immer drauf.

Nein, die Firmware wird erst vom Treiber in das Gerät geladen. Ein Linuxtreiber kann praktisch immer alles, aber die Firmware, die dann hochgeladen wird, ist beschränkt. Vollständige Firmware bekommen nur Firmen wie Cisco oder AVM gegen $ und NDA und darf nicht mit der normalen Linuxdistribution verteilt werden.

Vermutlich können hardwareseitig auch viel mehr WLAN Adapter AP Mode

Alle und ich meine wirklich alle WLAN Adapter beherrschen AP Mode. Die Beschränkung findet wirklich nur softwareseitig statt, sprich via Firmware..

Die Gründe dafür sind vielfältig. Ein ganz starker Grund ist die staatliche Regulierung der frei nutzbaren Funktechniken (frei im Sinne von man braucht keine spezielle Genehmigung zum Betrieb). Um dort etwaige Fraquenzbeschränkungen und Sendeleistungen zu regulieren, wird da vieles in die Firmware gesteckt und das sollte möglichst manipulationssicher sein.

[reox]

Ich hab das auch bei mir so, dass eth1, eth2 und wlan0 in der bridge sind.

Wie funktioniert das mit WLAN als Bridge-'Client'? Ich habe das mit all meinen WLAN-Devices versucht, nicht ein einziger Treiber unterstützt den Bridge-Mode. Gibt es dafür einen Trick? Im Web habe ich nur Hinweise darüber gefunden, dass das allgemein nicht so einfach geht bis hin zur Feststellung Unmöglich.

Uhm keine Ahnung eigentlich... Ich hab das jetzt so seit 5 Jahren am laufen und es tut. Board: pcengines apu1d4 und Compex WLE200NX. Dort rennt hostapd, eine NIC ist für WAN und 2 für LAN. Da ich mal zeitweise dort keinen Switch dran hängen hatte, hab ich die 3. NIC für einen PC verwendet.

[wanne]

Alle und ich meine wirklich alle WLAN Adapter beherrschen AP Mode. Die Beschränkung findet wirklich nur softwareseitig statt, sprich via Firmware..

Und je öfter das hier behauptet wird: Nein. Die meisten älteren Intel Chips können einfach kein AP Mode. Du kannst auch keine andere Anwendung finden wo die das können.
Du wirst kein gerät finden, in dem ein Intel PRO/Wireless werkelt und das im AP Mode läuft.

Vollständige Firmware bekommen nur Firmen wie Cisco oder AVM gegen $ und NDA und darf nicht mit der normalen Linuxdistribution verteilt werden.

Auch das ist in 99% der Fälle Quatsch. Ganz im Gegenteil. Wenn du Firmware aus Router raus extrahierst ist die entweder die selbe oder sie kann deutlich weniger. Ich würde jetzt gerne sagen nenne mir ein Beispiel wo das der Fall sein soll. Aber ich weiß: Ja es gibt ein zwei Broadcom Chips, die über die Firmware beschnitten wurden. Da finden sich aber dann auch genügend online Quellen für vollwertige Firmware. Für 99% der Chips ist das absoluter Quatsch. Was der Chip irgend wo da draußen kann, kann er auch in deiner Linux-Distro.

Ein Linuxtreiber kann praktisch immer alles

Auch das ist falsch.
https://wireless.wiki.kernel.org/en/users/drivers
Z.B. ipw2200 iwlegacy kann kein AP-Mode. Liegt aber eben auch dran, das die supporteten Chipsets das nicht in HW können.

Um dort etwaige Fraquenzbeschränkungen und Sendeleistungen zu regulieren, wird da vieles in die Firmware gesteckt und das sollte möglichst manipulationssicher sein.

Da hast du aber immer wie auch immer geartete Mechanismen, die verhindern, dass du die falsche Firmware hoch lädst. Niemand wird dir die Firmware selbst vorenthalten. Die Wifi-Hersteller sind nicht wie NVIDIA und können es sich leisten Chips mit beschnittener Funktionalität raus zu geben. Wenn die weniger Funktionsumfang haben wird knallhart bei der Konkurrenz gekauft. Der Markt ist zu hart umkämpft, als das da Chips mit absichtlich reduziertem Funktionsumfang überleben würden.

[AleXSR700]

Denn die Firmware ist ja auf dem Gerät immer drauf.

Nein, die Firmware wird erst vom Treiber in das Gerät geladen. Ein Linuxtreiber kann praktisch immer alles, aber die Firmware, die dann hochgeladen wird, ist beschränkt. Vollständige Firmware bekommen nur Firmen wie Cisco oder AVM gegen $ und NDA und darf nicht mit der normalen Linuxdistribution verteilt werden.

Alle und ich meine wirklich alle WLAN Adapter beherrschen AP Mode. Die Beschränkung findet wirklich nur softwareseitig statt, sprich via Firmware..

Die Gründe dafür sind vielfältig. Ein ganz starker Grund ist die staatliche Regulierung der frei nutzbaren Funktechniken (frei im Sinne von man braucht keine spezielle Genehmigung zum Betrieb). Um dort etwaige Fraquenzbeschränkungen und Sendeleistungen zu regulieren, wird da vieles in die Firmware gesteckt und das sollte möglichst manipulationssicher sein.

Wäre mir neu. Eine Firmware ist eigentlich immer von Hause aus auf jedem Gerät vorhanden.
https://de.m.wikipedia.org/wiki/Firmware
Sei es drum. Macht hier letztlich keinen inhaltlichen Unterschied.

Ebenso wäre es letztlich egal, ob tatsächlich jeder Chipsatz hardwareseitig in der Lage ist als AP und als Monitor zu funktionieren. Denn am Ende des Tages bringt das absolut überhaupt nichts, wenn es dann im Betriebssystem nicht funktioniert. Das wäre so als verkaufte man einen Router als Elektroherd, weil die Hardware an sich heiß werden kann. Wenn ich den Router nicht benutzen kann, um darauf in einer Pfanne Bratkartoffeln zu machen, dann kann der Router die Funktion eines Herds nicht übernehmen und die Aussage "der Router ist nicht Herd-fähig" ist korrekt.

Und wenn dem wirklich so ist, dass ausnahmslos ALLE Chipssätze geeignet sind, dann wäre das nur umso trauriger, denn defacto sind die Treiber (meinetwegen auch die Firmware, die Linux dann vermeintlich einspielt) nicht in der Lage diese Funktion zu liefern, während sie unter Windows meist problemlos funktioniert.
Ich musste noch nie unter Windows einen Treiber kompilieren, damit das Gerät überhaupt funktioniert. Unter Linux schon.

Wenn es also alles so einfach ist und es gibt zahllose WLAN USB Dongles, die unter Windows als AP funktionieren wieso dann nicht out-of-the-box mit plug&play in Linux?

Egal auf wen man die Schuld schieben will. Am Ende des Tages bleibt das Linux spezifische Problem, dass die meisten WLAN Sticks NICHT im AP Modus funktionieren.

[wanne]

enn defacto sind die Treiber (meinetwegen auch die Firmware, die Linux dann vermeintlich einspielt) nicht in der Lage diese Funktion zu liefern, während sie unter Windows meist problemlos funktioniert.
[…]
Egal auf wen man die Schuld schieben will. Am Ende des Tages bleibt das Linux spezifische Problem, dass die meisten WLAN Sticks NICHT im AP Modus funktionieren.

Kannst du mal mit dieser wilden Rumlügerei aufhören? Es gibt keinen keinen eigen Chip, bei dem die unter Linux kein AP mode kann aber unter Windows schon-
Es gibt aber massenhaft Chips, die das unter Linux Linux könnten und unter Linux nicht. Z.P die prism54 und ZyDAS geräte. Daneben gibt es ein Haufen Geräte für die es einfach gar keine Windows Treiber gibt. AR9331 IPQ* Wenn du nur Windows 10 anguckst praktisch alle älteen Atheros Geräte.
Für den Wifi-Bereich ist das einfach erstunken und erlogene Bullshit.

Ich musste noch nie unter Windows einen Treiber kompilieren, damit das Gerät überhaupt funktioniert. Unter Linux schon.

Für welchen WLAN Stick musstest du Treiber kompilieren? Und jetzt bitte mal ne Wifi-Karte in ein Frisch installiertes Windows stecken. Tut zu 99% nicht.

[AleXSR700]

Von "Lügerei" zu sprechen finde ich persönlich etwas fragwürdig.
Ich sage auch nicht, dass der Adapter es nicht kann. Ich sage, dass die Adapter oft nicht ohne weiteres unter Linux überhaupt laufen, geschweige denn im AP Modus. Ich persönlich würde dann nicht davon sprechen, dass der WLAN Dongle xyz als AP in Raspian OS funktioniert, obwohl ihn niemand zum Laufen kriegt, nur weil der Chip es theoretisch könnte.

Es gibt genug Quellen, in denen massenhaft Adapter genannt werden, bei denen kein AP Modus funktioniert.
Es ist dabei egal, wieso es nicht geht. Läuft nicht heisst läuft nicht. Siehe mein Router als Herd Beispiel.

Aber sei es drum.
Bitte sag mir, und das ist eine echte Bitte und keine Provokation, einen USB 3.0 WLAN Adapter, der unter Raspian OS/Raspbian als AP funktioniert und das 802.11ac unterstützt.
Genau so einen suche ich nämlich und kann nur Quellen finden, die meine jeweiligen Kandidaten immer als nicht lauffähig, nicht stabil oder oder oder outen.

[wanne]

Ich sage auch nicht, dass der Adapter es nicht kann. Ich sage, dass die Adapter oft nicht ohne weiteres unter Linux überhaupt laufen, geschweige denn im AP Modus.

Und sich sage dass die dann auch 10 mal nicht unter Windows laufen.

Ich persönlich würde dann nicht davon sprechen, dass der WLAN Dongle xyz als AP in Raspian OS funktioniert, obwohl ihn niemand zum Laufen kriegt, nur weil der Chip es theoretisch könnte.

Das schöne ist: Für den PI gibt es auch Windows. Und da laufen die noch viel weniger.

Es gibt genug Quellen, in denen massenhaft Adapter genannt werden, bei denen kein AP Modus funktioniert.

Und ich habe gesagt, das ist im Normalfall ein Hardware Problem.

Bitte sag mir, und das ist eine echte Bitte und keine Provokation, einen USB 3.0 WLAN Adapter, der unter Raspian OS/Raspbian als AP funktioniert und das 802.11ac unterstützt.

Sag mir einen, der unter Windows 10 IoT, funktioniert und ich antworte dir mit einem der unter Linux tut. – Der selbe. Problem ist, dass einige USB-Dongles halt x86-"Blobs" mitbringen. Die laufen aber halt nicht auf dem ARM-PI. Völlig egal ob der unter Windows oder Linux läuft. USB-Hosts in Kombination mit ARM sind ne seltene Kombination USB und AP noch viel seltsamer. Da gibt es nicht viele die tun. – Völlig unabhängig vom OS.
Cypress bringt gerade einen Chipset raus, dass beides AP und USB kann. Im Kernel sind da auch schon mit: 0A5C:0BDC USB-IDs für registriert. Die Treiber sind also schon da. Müssten also bald auch Geräte raus kommen. Bis jetzt findet man die aber noch nicht zu kaufen.
Bis jetzt findest du von denen entweder SDIO die ac können oder halt USB-Devices, die es nicht können.
Wie gesagt. Ich finde schlicht schon keine Hardware die AP+AC+USB kann. Für kein OS. Schon zwei mal nicht für ARM. Große Datenraten und USB war eigentlich nie ne gute Idee. War schon immer der Anschluss für billig. Und da findest du halt sleten AC und schon gar keine AP-Funktionalität.
Die Hardware, die du dir da wünscht gibt es einfach nicht. Deine Rumlügerei, dass das ein Treiberproblem sei ist Erstunken und erlogen. Die Treiber sind so weit. Jetzt müsste nur noch jemand passende Hardware bauen.

[AleXSR700]

Wer hat denn was von Windows IoT oder von ARM gesagt?

Aber wenn du das sagst, dann gibt es natürlich keinen USB WLAN Adapter, der auf einem PC mit normaler Intel/AMD CPU und Windows 10 als AP funktioniert.
Passt scho.
Diskussion erledigt.

[debianoli]

Wer hat denn was von Windows IoT oder von ARM gesagt?

Du selber.

Ansonsten würde ich mich mega freuen, wenn mir hier jemand einen 802.11ac USB 3.0 Dongle nennen würde, der wie in Windows ohne großen Aufwand mit plug&play auf einem Raspberry 4 Model B läuft.

[wanne]

Wer hat denn […] von ARM gesagt?

Du hast mit dem PI angefangen. Wenn du dein Windows 10 für Intel auf dem PI zum laufen bekommst...

Aber wenn du das sagst, dann gibt es natürlich keinen USB WLAN Adapter, der auf einem PC mit normaler Intel/AMD CPU und Windows 10 als AP funktioniert.

Wie gesagt: Nenn mal einen. Dann nenne ich dir einen, der auch super unter Linux auf nem einem PC mit normaler Intel/AMD CPU funktioniert. Alle AC-USB-Sticks, die ich kenne sind halt von Realtek. Und die geben halt keine Treiber für ARM raus Weder für Windows noch für Linux. (Du kannst dir aber selber welche für Linux bauen, auch wenn ganz oben steht, dass der nicht für ARM tun würde tut er das laut Archwiki doch, was für Windows nicht geht.)
So lange du auf nem ARM unteweg bist bist du Treibermäßig also unter Linux deutlich besser unterwegs.
Aber schon immer für x86-Linux und für x86-Windows. Auf beiden Systemen läuft der nicht out of the Box. Sowohl unter Windows wie auch unter Linux musst du Treiber nachinstallieren. In beiden Fällen kann er dann als AP betrieben werden. (Vermute ich mal. Unter windows nicht getestet.)

[AleXSR700]

Nein, ich sagte nicht wie unter "Windows auf einem Pi". Ich sagte nur, wie in Windows. Klassisch ist Windows nicht für ARM geeignet. Und Windows IoT ist sicherlich nicht identisch Windows.
Mittlerweile ist es wohl möglich Windows auf dem RPi laufen zu lassen, aber nicht wirklich vollwertig.

Ich sprach also von "Windows auf x86/x64" vs. "Linux auf ARM".

Deine "Lügen"-Vorwürfe basieren also auf einem Missverständnis deinerseits.

[TomL]

Uhm keine Ahnung eigentlich... Ich hab das jetzt so seit 5 Jahren am laufen und es tut. Board: pcengines apu1d4 und Compex WLE200NX. Dort rennt hostapd, eine NIC ist für WAN und 2 für LAN.

Ja, klar, das kenne ich, das ist aber keine Bridge im klassischen Sinn. Das ist nur simples masquerading via Paketfilter, wobei hostapd + dnsmasq üblicherweise ein eigenes, isoliertes Netzwerk repräsentiert. Bei einem Bridge-Device wäre es im Unterschied dazu kein zweites Netz, sondern die hostapd-Clients hätten eine reguläre LAN-IP des DSL-Routers und befinden sich im gleichen Netz, wie der hostapd-PC.

[reox]

Bei einem Bridge-Device wäre es im Unterschied dazu kein zweites Netz, sondern die hostapd-Clients hätten eine reguläre LAN-IP des DSL-Routers und befinden sich im gleichen Netz, wie der hostapd-PC.

Tun sie ja - oder was wäre jetzt genau der unterschied? Ich hab nur auf br0 eine IP - die lokale IP des Routers. wlan0, eth1 und eth2 haben selber keine IP Adressen.
Ich kann aus dem WLAN alle Rechner im Wired-LAN erreichen und auch anders herum.