Fórum Root.cz

Hlavní témata => Sítě => Téma založeno: Ondrej Nemecek 08. 02. 2021, 16:15:16

Název: Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: Ondrej Nemecek 08. 02. 2021, 16:15:16
Ahoj všem,

mám Raspberry PI s Linuxem a několika síťovými rozhraními (eth0, wlan0, wlan1). Jedno wifi rozhraní (wlan1) potřebuji izolovat tak, abych:


Adresaci předem neznám a je reálné, že bude kolidovat s existující adresací ostatních síťových rozhraní (wlan1 typicky dostane 192.168.0.0/24 adresu která bude dost pravděpodobně kolidovat s existujícím připojením do lokální sítě na eth0 rozhraní). Jak toho nejelegantněji docílit? Zatím mě napadla virtualizace (kvm - na raspberry os zatím nefunguje, lxc - nezkoušel jsem a nejsem si jist, čeho všeho tam lze docílit). Existuje nějaké praktičtější kanonické řešení? Jde mi o řešení pro ipv4, síťová rozhraní jsou všechna typu ethernet a wifi.

Děkuji za podněty  :)
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: Filip Jirsák 08. 02. 2021, 17:05:42
Na linuxu se dají používat pravidla (ip rule) pro výběr routovací tabulky. Pokud dokážete sestavit pravidla, která budou schopna rozlišit komunikaci pro to jedno rozhraní, můžete použít to. Nenapsal jste, čím bude ta komunikace na tom jednom rozhraní specifická – zda třeba dokážete určit zdrojovou IP adresu, proces apod.
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: Ondrej Nemecek 08. 02. 2021, 18:16:20
Na linuxu se dají používat pravidla (ip rule) pro výběr routovací tabulky. Pokud dokážete sestavit pravidla, která budou schopna rozlišit komunikaci pro to jedno rozhraní, můžete použít to. Nenapsal jste, čím bude ta komunikace na tom jednom rozhraní specifická – zda třeba dokážete určit zdrojovou IP adresu, proces apod.

Bingo, to by mohlo být ono.

Pravidlo je možná takto: Vše co jde ze systému na cílovou adresu 192.168.0.0/16 a má cílový tcp port 9999 nebo je to icmp ping do tohoto rozsahu (+ možná ještě udp broadcast na 192.168.0.0/16), tak má jít přes wlan1, jinak dle výchozích rout případně na bránu.  K tomu bych tedy asi navíc potřeboval, aby dhcp klient nenastavoval výchozí bránu pro wlan1.  Při použití ip rule si musím pakety značkovat ve firewallu a tu značku pak použít v ip rule pravidlech nebo pravidla na port, proces atd. umí ip rule přímo?

Je ovšem otázka, zda se ta pravidla do budoucna nezkomplikují (a ony se určitě zkomplikují, jak se bude přidávat podpora pro další IOT zařízení). Pak by bylo možná lepší volit nějaký obecnější filtr. Pokud by se na danou komunikaci vyhradil například separátní proces, mohlo by se vše z toho procesu směřovat na wlan1 - což by se pak asi podobalo té mnou zmíněné virtualizaci, tj. proces by na tcp/ip úrovni komunikoval pouze a jen prostřednictvím wlan1. S procesem by se muselo nějak komunikovat, nejlépe mechanismem nezávislým na tcp/ip, takže třeba RMI over Unix Sockets - junixsocket (https://github.com/kohlschutter/junixsocket) (ty procesy jsou java)?

PS: V praxi jde o úkol zapojit IOT zařízení do zásuvky, připojit se na něj wlan1 wifinou (IOT funguje při prvním zapnutí jako AP) a nakonfigurovat ho pro připojení na wlan0 našeho systému, které je v AP režimu a kde běží dhcp server. Tím pádem se zařízení přepne do wifi client režimu a přeadresuje dle našeho dhcp. Dhcp je pod kontrolou a tím pádem bude pod kontrolou i zařízení a půjde ze systému přes tcp/ip dále ovládat. Těch zařízení tam bude samosebou více a tímto mechanismem si je postupně „přivlastním“.
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: František Ryšánek 08. 02. 2021, 18:27:32
V kombinaci s "ip rule" jsem svého času používal CONNMARK (https://home.regit.org/netfilter-en/netfilter-connmark/) na příchozí relace. Když přijde paket zvenčí konkrétním rozhraním (první ve streamu/relaci), dostane konkrétní interní značku - a kernel zařídí, že tutéž interní značku budou mít pakety, které jdou "zpátky" a patří k téže komunikační relaci.

Jinak na virtualizaci/oddělení IP stacků by měl stačit Docker (chroot on steroids). Zdá se, že na RPi funguje. Jakákoli virtualizace znamená, že si v systému vyrobíte více "písečků", které na sebe navzájem přímo nevidí, a je to tak naschvál - ovšem je mi otázkou, zda je toto žádoucí / použitelné pro Váš use case.
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: MalyTomi 09. 02. 2021, 09:29:15
pokial to ma byt jednorazovka, tak by som skor isiel cestou samostatne rpi, ktore by nerobilo nic ine, len periodicky hladalo tie ap,  a nastavovalo zariadenia.
Najlacnejsie rpi sa da zohnat za par eur a usetris si kopec casu nastavovanim a ladenim, najma, ked mozu kolidovat ip.
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: SB 09. 02. 2021, 10:07:26
Síťování moc nerozumím, takže zkusím:

Jestli to chápu, tak problémem je přidělení potenciálně kolidující adresy rozhraní wifi, jinak vše ostatní je řešitelné. Nedalo by se pomocí iptables nastavit dstnat v preroutingu a srcnat v postroutingu výhradně pro to jedno rozhraní wifi, čímž by bylo dosaženo vlastní, nekolizní adresy/podsítě?
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: Filip Jirsák 09. 02. 2021, 10:40:26
Při použití ip rule si musím pakety značkovat ve firewallu a tu značku pak použít v ip rule pravidlech nebo pravidla na port, proces atd. umí ip rule přímo?
Podívejte se na man ip-rule. Samo ip rule umí rozhodovat na základě IP adresy nebo rozhraní. A nebo pak může používat právě značky z firewallu.
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: Ondřej Caletka 09. 02. 2021, 16:06:08
Tohle je přímo ukázkový příklad pro network namespaces. Jednoduše příslušnou síťovou kartu přestěhuješ do samostatného namespace a v něm spustíš třeba shell, v něm třeba DHCP klienta, či cokoli jiného. Uvnitř daného namespace bude existovat jen tahle jedna síťová karta a prázdná směrovací tabulka. Všechno ostatní ale bude sdílené s hostitelským systémem, takže je snadné předávat si data třeba přes filesystém.

Kód: [Vybrat]
# ip netns add testovani
# ip link set eth0 netns testovani
# ip netns exec testovani bash

# ip netns delete testovani

Pokud je potřeba přesunout Wi-Fi kartu, je to trochu komplikovanější, je potřeba přesunou jí odpovídající phy rozhraní:

Kód: [Vybrat]
iw phy phy0 set ns name testovani
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: Ondrej Nemecek 09. 02. 2021, 20:05:12
Tohle je přímo ukázkový příklad pro network namespaces. Jednoduše příslušnou síťovou kartu přestěhuješ do samostatného namespace a v něm spustíš třeba shell, v něm třeba DHCP klienta, či cokoli jiného. Uvnitř daného namespace bude existovat jen tahle jedna síťová karta a prázdná směrovací tabulka. Všechno ostatní ale bude sdílené s hostitelským systémem, takže je snadné předávat si data třeba přes filesystém.

...

No vida, člověk se pořád učí, tohle vidím poprvé a nejspíš je to hotové řešení přesně mého problému  :D Ono totiž přepínat směrovací tabulky pomocí ip rule by vyžadovalo spravovat ta pravidla, kdežto namespace vypadá že bude stačit nastavit jednou pro vždy a je to přesně k tomuto účelu určené!

Teď se jen podívat jak je to integrované do systému v Raspberry OS. Používám na všechna síťová rozhraní jednu instanci dhcpcd a jednu instanci wpa_supplicant. Dále tam mám pdnsd a udhcpd, ale to jen na wlan0. Podle řečeného to vypadá, že budu muset spustit od dhcpcd i wpa_supplicant dvě instance, v jednom namespace bude eth0 + wlan0 a v druhém wlan1.

Ty namespace se budou muset vytvořit při startu. V každém namespace poběží jedna instance komunikačního software, všechno bude nakonec komunikovat přes mqtt takže by tak mohly komunikovat i obě instance komunikačního software (za předpokladu že najdu vhodnou implementaci podporující unix sockety, nebo přes unix sockety rmi).

(https://i.ibb.co/wWjysHG/iotgw-inner-scheme.png)
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: Michal Kubeček 10. 02. 2021, 00:19:50
všechno bude nakonec komunikovat přes mqtt takže by tak mohly komunikovat i obě instance komunikačního software (za předpokladu že najdu vhodnou implementaci podporující unix sockety, nebo přes unix sockety rmi).
Pro komunikaci mezi netns se používají veth rozhraní. Pomocí
Kód: [Vybrat]
ip link add veth1 type veth peer name veth2si vytvoříte pár rozhaní, který funguje tak, že paket, který se odešle přes jedno z nich, se objeví jako příchozí na druhém. Jedno rozhraní necháte v init netns a druhé přesunete do toho druhého.
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: František Ryšánek 10. 02. 2021, 08:02:19
Pro komunikaci mezi netns se používají veth rozhraní. Pomocí
Kód: [Vybrat]
ip link add veth1 type veth peer name veth2si vytvoříte pár rozhaní, který funguje tak, že paket, který se odešle přes jedno z nich, se objeví jako příchozí na druhém. Jedno rozhraní necháte v init netns a druhé přesunete do toho druhého.

A dvě instance MQTT brokera, každého v jednom namespace, a navzájem propojit nad veth linkem... až na to, že publisher/subscriber jsou klientské role, broker je jenom "prostředníkem" mezi nimi. Takže pokud nechceme vytvářet na koleně "dvojitého slava", je to řešitelné na bázi MQTT clusteringu (https://www.hivemq.com/blog/clustering-mqtt-introduction-benefits/) dvou brokerů?

Neznám MQTT - váhám, jak se bude cluster na své úrovni adresace tvářit na klienty přišedší z překrývajících se subnetů (resp. jednotlivých /32 IP adres)... Pokud cluster interně řeší jenom "topics" a nesynchronizuje si tabulky IP adres živých klientů (= těm servíruje každý uzel sám za sebe), nemusel by nastat průser.

BTW o "namespaces" jsem slyšel, ale žil jsem v nesprávném domnění, že jde o "kernel API pro podporu dockeru", že to samostatně namazat na chleba nelze. Vida, člověk se pořád učí :-) Děkuji.

Hm tak mě napadá, jaká je souvislost mezi namespaces a VRF... Aha (https://cumulusnetworks.com/blog/vrf-for-linux/).
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: SB 10. 02. 2021, 10:32:50
Nechci vás rušit ve vašem klábosení, ale na můj vkus je to už docela složité, takže jsem byl zvědavý, zda je mnou výše navržené řešení s NAT (či masquerade) proveditelné.
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: Ondřej Caletka 10. 02. 2021, 10:38:41
Hm tak mě napadá, jaká je souvislost mezi namespaces a VRF... Aha (https://cumulusnetworks.com/blog/vrf-for-linux/).
VRF je v Linuxu taky, ale nepřišel jsem na žádné smysluplné využití, pokud tedy zrovna nepůjde o linuxový router/switch. Hlavní rozdíl je v tom, že VRF odděluje síťové karty jen od třetí vrstvy výš, takže třeba takový démon pro LLDP může běžet jen jeden a obsluhovat všechna rozhraní, přestože jsou součástí jiných virtuálních routerů.

Z pohledu konfigurace je to ale proti namespaces hrozný guláš.
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: Ondřej Caletka 10. 02. 2021, 10:45:00
Teď se jen podívat jak je to integrované do systému v Raspberry OS. Používám na všechna síťová rozhraní jednu instanci dhcpcd a jednu instanci wpa_supplicant. Dále tam mám pdnsd a udhcpd, ale to jen na wlan0. Podle řečeného to vypadá, že budu muset spustit od dhcpcd i wpa_supplicant dvě instance, v jednom namespace bude eth0 + wlan0 a v druhém wlan1.
Ano, vypadá to tak, tohle může být případně kámen úrazu, pokud některé aplikace nepočítají s tím, že by běžely na jednom systému ve více instancích a budou si přepisovat stavové soubory.

Stejně tak je problém s DNS resolvingem, kde soubor /etc/resolv.conf je jen jeden, takže se klidně může stát, že v jednom z namespaces nebude DNS fungovat. Řešit se to samozřejmě dá třeba použitím mount namespace, ale tím se začne situace trochu komplikovat a postupně se dostáváme spíše k plnohodnotnému kontejneru.
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: czechsys 10. 02. 2021, 11:05:26
Na zaklade odpovedi od p. Caletky jsem si zkusil vyhledat pouziti pro haproxy, nebot tam potrebuji kvuli mpls pristupu VRF (resim to tedy via ip rule atd...)

https://cloudnull.io/2019/04/running-services-in-network-name-spaces-with-systemd/

Podle tohoto clanku je to teda dost narocnejsi nez pouhych par radku v systemd-networkd konfiguracich...
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: Jose D 10. 02. 2021, 14:13:42
Tohle je přímo ukázkový příklad pro network namespaces. ..
..  tohle vidím poprvé a nejspíš je to hotové řešení přesně mého problému  :D ..

jj, tak tak. tohle je dost zajímavé a taky jsem se s tím ještě přímo nesetkal.

.. man ip-rule ..

taky mě to napadlo, ale myslím, že tohle by nefungovalo při kolizi IP rozsahů na těch dvou interface, nebo se mýlím?
Triviální by samozřejmě bylo něco jako ip rule add uidrange 1010-1011 lookup 123456 - ale myslím, že pokud bychom měli dvě routy scope link do stejných IP rozsahů, ale fyzicky různých sítí, tak by to nefungovalo, minimálně pro lokální traffic v těch sítích..(?)
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: Ondrej Nemecek 10. 02. 2021, 15:34:26
.. man ip-rule ..
taky mě to napadlo, ale myslím, že tohle by nefungovalo při kolizi IP rozsahů na těch dvou interface, nebo se mýlím?

Tak pochopil jsem to tak, že jedna routa bude
Kód: [Vybrat]
192.168.0.0/24 na eth0 a druhá
Kód: [Vybrat]
192.168.0.0/24 na wlan1 a prostě se dle pravidla použije jedna nebo druhá bez ohledu na metriky apod. Ale asi to není z hlediska tcp/ip úplně dobrá situace a může se to klidně někde vytelit - nevím co by se např. stalo, pokud by na obou rozhraní byly úplně totožné IP adresy  >:(

Ještě mě napadlo mě jak by si s tím poradil routovací démon (RIP)? Ale to se pro účel rychlého nastavení v duplicitní siti asi nehodí, minimálně by tam byla prodleva než si RIP démon osahá topologii. A byla by to asi celkově prasárna...
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: Ondrej Nemecek 10. 02. 2021, 15:34:54
Koukám, že se tu dobře rozjela debata. Díky za všechny příspěvky a jdu si s tím pohrát. Je fakt, že jelikož budu v namespaces spouštět vícero démonů, tak to už bude možná snadnější to rovnou strčit celé do kontejneru.
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: Michal Kubeček 10. 02. 2021, 15:44:03
taky mě to napadlo, ale myslím, že tohle by nefungovalo při kolizi IP rozsahů na těch dvou interface, nebo se mýlím?
Proč by nemělo? Konfliktní routy nejsou problém, pokud nejsou ve stejné tabulce. Pravidla vám pak říkají, ve které tabulce (nebo obecně ve kterých a v jakém pořadí) se má pro daný paket provést lookup.
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: Filip Jirsák 10. 02. 2021, 15:46:09
taky mě to napadlo, ale myslím, že tohle by nefungovalo při kolizi IP rozsahů na těch dvou interface, nebo se mýlím?
Triviální by samozřejmě bylo něco jako ip rule add uidrange 1010-1011 lookup 123456 - ale myslím, že pokud bychom měli dvě routy scope link do stejných IP rozsahů, ale fyzicky různých sítí, tak by to nefungovalo, minimálně pro lokální traffic v těch sítích..(?)
ip rule umožňuje to, že máte v systému víc routovacích tabulek, a pomocí pravidel určíte, která routovací tabulka se má kdy použít. Tj. v tomto případě by se kolizní rozsahy nepotkávaly v jedné routovací tabulce, takže by nevznikala ta kolize. Samozřejmě pokud by se podařilo pakety správně pomocí pravidel rozházet mezi ty tabulky.

Každopádně Ondrovo řešení pomocí jmenných prostorů je daleko elegantnější, zaměřil bych se na to.
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: Jose D 10. 02. 2021, 16:31:07
Proč by nemělo? Konfliktní routy nejsou problém, pokud nejsou ve stejné tabulce. ...

Teď jsem si to zkusil na nějakém boxu, a jsem schopný měnit i routy s proto kernel, což jsem nevěděl, že jde. Takže poslední okrajový případ který nevím, jak by se choval jsou úplně identické IP a procesy na nich poslouchající.

Ondrovo řešení pomocí jmenných prostorů je daleko elegantnější, zaměřil bych se na to.

souhlas.
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: Ondrej Nemecek 13. 02. 2021, 00:44:26
Takže aby to fungovalo musí network namespaces podporovat explicitně příslušná wifina:

Kód: [Vybrat]
# iw phy phy1 info | grep set_wiphy_netns
* set_wiphy_netns

Což třeba rozšířené usb wifiny s rtl8188 neumí a nedaří se je přesunout do namespace :(

Kód: [Vybrat]
# iw phy phy0 set netns name iotgw-configuration
command failed: Operation not supported (-95)

Což to omezuje použití. Ani nevím, jak dohledat, které usb wifiny to umí?

Pokud to wifina umí  - jako třeba ta integrovaná v Raspberry PI - tak to funguje :)

V praxi budu muset konfigurovat IOT zařízení pomocí integrované wifiny (z namespacu) a pro běžný provoz používat externí usb wifinu.

To mne mimochodem nutí také vyřešit predikovatelné (reprodukovatelné) pojmenování síťových rozhraní protože wlan0 a wlan1 se inicializují náhodně takže nepoznám která je která.
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: Ondrej Nemecek 13. 02. 2021, 00:49:53

Nevím zda to je vlastnost hardware nebo kernel modulu, zkoumám tyhle ovladače:

https://github.com/kimocoder/realtek_rtwifi
https://github.com/aircrack-ng/rtl8188eus/issues/104

Takže aby to fungovalo musí network namespaces podporovat explicitně příslušná wifina:

Kód: [Vybrat]
# iw phy phy1 info | grep set_wiphy_netns
* set_wiphy_netns

Což třeba rozšířené usb wifiny s rtl8188 neumí a nedaří se je přesunout do namespace :(

Kód: [Vybrat]
# iw phy phy0 set netns name iotgw-configuration
command failed: Operation not supported (-95)

Což omezuje použití. Ani nevím, jak dohledat, které usb wifiny to umí?

Pokud to wifina umí  - jako třeba ta integrovaná v Raspberry PI - tak to funguje :)

V praxi budu muset konfigurovat IOT zařízení pomocí integrované wifiny (z namespacu) a pro běžný provoz používat externí usb wifinu.

To mne mimochodem nutí také vyřešit predikovatelné (reprodukovatelné) pojmenování síťových rozhraní protože wlan0 a wlan1 se inicializují náhodně takže nepoznám která je která.
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: Ondrej Nemecek 13. 02. 2021, 16:13:43
Takže realtek_rtwifi umí namespaces, ale neumí AP mód, což vylučuje použití dvou stejných wifi karet (jedna jako AP a druhá v namespace jako klient). Je možná kombinace interní wifi RPI v namespace a externí USB wifi pro běžný provoz.

Podpora namespaces v systemd vypadá docela dobře, jedna unit mi vyrobí namespace a druhá tam připojí wifinu a veth rozhraní. Na těchto unitech závisí pak ten IOT komunikační software, který běží ve dvou procesech z nichž jeden je v namespace a povídají si přes rmi. Systemd spustí proces v namespace sám díky direktivě JoinsNamespaceOf a PrivateNetwork.

Děkuji hlavně Ondřejovi Celetkovi a Michalovi Kubečkovi za nasměrování na namespaces. Pro úplně ideální řešení bych potřeboval ještě usb wifi, které umí AP mód (pomocí wpa_supplicant) i namespaces. Pokud by měl někdo tip kde hledat, uvítám to.
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: František Ryšánek 13. 02. 2021, 19:15:03
USBčkové wifiny dělával Atheros, ale konkrétně u řady ar6k tuším býval nějaký problém s provozem AP. Nevím jak u modernějšího AR9271. Ani nevím, kde takový dongle shánět - leda snad u Mousera (https://cz.mouser.com/ProductDetail/Olimex-Ltd/MOD-WIFI-AR9271/?qs=unwgFEO1A6sgSPysSQGroA%3D%3D). Netušíte někdo, co za čipset má takový "TP-LINK Archer T2U Plus" ?
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: Ondrej Nemecek 13. 02. 2021, 22:56:04
USBčkové wifiny dělával Atheros, ale konkrétně u řady ar6k tuším býval nějaký problém s provozem AP. Nevím jak u modernějšího AR9271. Ani nevím, kde takový dongle shánět - leda snad u Mousera (https://cz.mouser.com/ProductDetail/Olimex-Ltd/MOD-WIFI-AR9271/?qs=unwgFEO1A6sgSPysSQGroA%3D%3D). Netušíte někdo, co za čipset má takový "TP-LINK Archer T2U Plus" ?

Je to asi rtl8812au.  Přijde mi divné, že nikde není databáze chipsetů, driverů a podporovaných funkcí. Nebo o ní jen nevím?
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: František Ryšánek 13. 02. 2021, 23:48:09
USBčkové wifiny dělával Atheros, ale konkrétně u řady ar6k tuším býval nějaký problém s provozem AP. Nevím jak u modernějšího AR9271. Ani nevím, kde takový dongle shánět - leda snad u Mousera (https://cz.mouser.com/ProductDetail/Olimex-Ltd/MOD-WIFI-AR9271/?qs=unwgFEO1A6sgSPysSQGroA%3D%3D). Netušíte někdo, co za čipset má takový "TP-LINK Archer T2U Plus" ?

Je to asi rtl8812au.  Přijde mi divné, že nikde není databáze chipsetů, driverů a podporovaných funkcí. Nebo o ní jen nevím?

O žádná tabulce nevím. OpenWRT má svou "table of hardware", ale to jsou kompletní routery. USB wifi je u nich nejspíš na okraji zájmu.

Nakonec asi nejjistější cesta k cíli je stáhnout si kernel na disk, vlézt do drivers/net/wireless (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless) a dál se už brodit grepem, pokud víte čeho se chytit - nějaké ty příkazy v rámci netlinku, structy používané pro definici USB ID's a PCI ID's v driverech apod. Komplikuje se to ještě víc - například Atheros míval shodná PCI ID's pro více modelů a rozlišoval je nějakými interními IDčky mimo PCI config space... nebo občas najdu HW IDčka deklarovaná mimo samotný adresář driveru, buď o patro výš, nebo někde v include/linux/ (v hlavičkových souborech) apod.

Ta malina je fakt pitomá, že nemá MiniPCI-e slot :-)
Název: Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní
Přispěvatel: Ondrej Nemecek 02. 04. 2021, 19:42:47
Pokud by se to někomu hodilo, tak USB wifiny s chipem Ralink RT5370 podporují set_wiphy_netns (přířazení network namespace) i AP mód (přístupový bod). Podpora wifi 802.11b/g/n. Jaderný modul rt2800usb je součástí DietPI pro Raspberry Pi 4 (https://dietpi.com/) (32-bit image s jádrem 5.10.17-v7l+). Ke koupi třeba na Rpishop - Wifi modul do USB, s anténou, 150 Mb/s (https://rpishop.cz/wi-fi-bluetooth/1864-wifi-modul-do-usb-s-antenou-150-mbs.html) Tento konkrétní model má nevýhodu v mechanicmém provedení - pendrek lze otočit jen o 90 stupňů. Funkčnost jinak OK. Čerpal jsem z elinux.org - RPi USB Wi-Fi Adapters (https://elinux.org/RPi_USB_Wi-Fi_Adapters).

Kód: [Vybrat]
root@DietPi:~# iw phy 
Wiphy phyExt
max # scan SSIDs: 4
max scan IEs length: 2257 bytes
max # sched scan SSIDs: 0
max # match sets: 0
Retry short long limit: 2
Coverage class: 0 (up to 0m)
Device supports RSN-IBSS.
Supported Ciphers:
* WEP40 (00-0f-ac:1)
* WEP104 (00-0f-ac:5)
* TKIP (00-0f-ac:2)
* CCMP-128 (00-0f-ac:4)
* CCMP-256 (00-0f-ac:10)
* GCMP-128 (00-0f-ac:8)
* GCMP-256 (00-0f-ac:9)
* CMAC (00-0f-ac:6)
* CMAC-256 (00-0f-ac:13)
* GMAC-128 (00-0f-ac:11)
* GMAC-256 (00-0f-ac:12)
Available Antennas: TX 0 RX 0
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
Band 1:
Capabilities: 0x17e
HT20/HT40
SM Power Save disabled
RX Greenfield
RX HT20 SGI
RX HT40 SGI
RX STBC 1-stream
Max AMSDU length: 3839 bytes
No DSSS/CCK HT40
Maximum RX AMPDU length 32767 bytes (exponent: 0x002)
Minimum RX AMPDU time spacing: 2 usec (0x04)
HT TX/RX MCS rate indexes supported: 0-7, 32
Bitrates (non-HT):
* 1.0 Mbps
* 2.0 Mbps (short preamble supported)
* 5.5 Mbps (short preamble supported)
* 11.0 Mbps (short preamble supported)
* 6.0 Mbps
* 9.0 Mbps
* 12.0 Mbps
* 18.0 Mbps
* 24.0 Mbps
* 36.0 Mbps
* 48.0 Mbps
* 54.0 Mbps
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm)
* 2472 MHz [13] (20.0 dBm)
* 2484 MHz [14] (disabled)
Supported commands:
* new_interface
* set_interface
* new_key
* start_ap
* new_station
* new_mpath
* set_mesh_config
* set_bss
* authenticate
* associate
* deauthenticate
* disassociate
* join_ibss
* join_mesh
* remain_on_channel
* set_tx_bitrate_mask
* frame
* frame_wait_cancel
* set_wiphy_netns
* set_channel
* set_wds_peer
* probe_client
* set_noack_map
* register_beacons
* start_p2p_device
* set_mcast_rate
* connect
* disconnect
* set_qos_map
* set_multicast_to_unicast
software interface modes (can always be added):
* AP/VLAN
* monitor
valid interface combinations:
* #{ AP, mesh point } <= 8,
   total <= 8, #channels <= 1
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
* supported channel width
* short GI for 40 MHz
* max A-MPDU length exponent
* min MPDU start spacing
Device supports TX status socket option.
Device supports HT-IBSS.
Device supports SAE with AUTHENTICATE command
Device supports low priority scan.
Device supports scan flush.
Device supports AP scan.
Device supports per-vif TX power setting
Driver supports full state transitions for AP/GO clients
Driver supports a userspace MPM
Device supports configuring vdev MAC-addr on create.
max # scan plans: 1
max scan plan interval: -1
max scan plan iterations: 0
Supported TX frame types:
* IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
* P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
Supported RX frame types:
* IBSS: 0x40 0xb0 0xc0 0xd0
* managed: 0x40 0xb0 0xd0
* AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* mesh point: 0xb0 0xc0 0xd0
* P2P-client: 0x40 0xd0
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
* P2P-device: 0x40 0xd0
Supported extended features:
* [ RRM ]: RRM
* [ FILS_STA ]: STA FILS (Fast Initial Link Setup)
* [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
* [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
root@DietPi:~#
root@DietPi:~# iw dev
phy#3
Interface wlan0
ifindex 8
wdev 0x300000001
addr 06:da:35:e1:b2:59
ssid IOTGW
type AP
channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz
txpower 20.00 dBm
root@DietPi:~#