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

[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.

[TomL]

Ok, dann wäre das doch ne 'klassische' Bridge... kannst Du mal die Ausgabe von ip a posten und wie das Bridgedevice erstellt und konfiguriert wird?

[reox]

Code: Alles auswählen

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
    link/ether 00:0d:b9:xx:xx:xx brd ff:ff:ff:ff:ff:ff
4: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN group default qlen 1000
    link/ether 00:0d:b9:xx:xx:yy brd ff:ff:ff:ff:ff:ff
5: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000
    link/ether 02:f0:21:xx:xx:zz brd ff:ff:ff:ff:ff:ff
7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:0d:b9:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 172.16.23.1/24 brd 172.16.23.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::20d:xx:xx:xx/64 scope link
       valid_lft forever preferred_lft forever

aus /etc/network/interfaces

Code: Alles auswählen

auto br0
iface br0 inet static
	bridge_ports eth1 eth2 wlan0
	address 172.16.23.1
	netmask 255.255.255.0
	broadcast 172.16.23.255

[TomL]

Danke!

Das sieht aus wie ne popelige Standard-Konfiguration.... völlig normal... aber genau das lehnen alle meine mir verfügbaren WLAN-NICs ab.... also nicht dergestalt, dass ich Fehlermeldungen bekomme, nee, keine Fehlermeldungen... die sind einfach tot. Ich kann mit tcpdump keinerlei Traffic feststellen oder Traffic auf irgendeiner Art und Weise provozieren, der vom oder zum WLAN-NIC passiert. Ich bin deswegen zu dem Schluss gekommen, dass die Firmware meiner WLAN-Interfaces keinen bridge-mode unterstützen.

[bluestar]

Poste mal deine hostapd.conf ohne Passwort

[reox]

Code: Alles auswählen

interface=wlan0
bssid=02:f0:21:xx:xx:xx
ssid=ABCD
bridge=br0
auth_algs=1
macaddr_acl=0

driver=nl80211
hw_mode=a

# automatic channel selection https://askubuntu.com/a/465843/341537
country_code=AT
ieee80211d=1
ieee80211h=1
channel=36
max_num_sta=5


# Logging
logger_stdout=-1
logger_stdout_level=2

# WPA
wpa_passphrase=youwillneverguessme
wpa=2
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

# enable n mode
ieee80211n=1
ht_capab=[HT40+][SHORT-GI-40][DSSS_CCK-40][TX-STBC][RX-STBC1]

### IEEE 802.11ac - not supprted by the card
#ieee80211ac=1
#vht_oper_chwidth=1
#vht_capab=[MAX-MPDU-11454][RXLDPC][SHORT-GI-80][TX-STBC-2BY1][RX-STBC-1]
#vht_oper_centr_freq_seg0_idx=62

### WMM
wmm_enabled=1
uapsd_advertisement_enabled=1
wmm_ac_bk_cwmin=4
wmm_ac_bk_cwmax=10
wmm_ac_bk_aifs=7
wmm_ac_bk_txop_limit=0
wmm_ac_bk_acm=0
wmm_ac_be_aifs=3
wmm_ac_be_cwmin=4
wmm_ac_be_cwmax=10
wmm_ac_be_txop_limit=0
wmm_ac_be_acm=0
wmm_ac_vi_aifs=2
wmm_ac_vi_cwmin=3
wmm_ac_vi_cwmax=4
wmm_ac_vi_txop_limit=94
wmm_ac_vi_acm=0
wmm_ac_vo_aifs=2
wmm_ac_vo_cwmin=2
wmm_ac_vo_cwmax=3
wmm_ac_vo_txop_limit=47
wmm_ac_vo_acm=0


### TX queue parameters
tx_queue_data3_aifs=7
tx_queue_data3_cwmin=15
tx_queue_data3_cwmax=1023
tx_queue_data3_burst=0
tx_queue_data2_aifs=3
tx_queue_data2_cwmin=15
tx_queue_data2_cwmax=63
tx_queue_data2_burst=0
tx_queue_data1_aifs=1
tx_queue_data1_cwmin=7
tx_queue_data1_cwmax=15
tx_queue_data1_burst=3.0
tx_queue_data0_aifs=1
tx_queue_data0_cwmin=3
tx_queue_data0_cwmax=7
tx_queue_data0_burst=1.5