Dotaz: Wifi: Nelze nastavit regulatory domain

[Ren]

Zdravim, narazil jsem na problem nekde, kde by vubec byt nemel. Mam tu wifi kartu (AR9380, konkretne Killer Wireless-N 1103), kterou jsem hodlal pouzit pro 5GHz AP (protoze 3x3:3). Kdyz jsem videl passive scanning na vsech 5GHz kanalech rikam si dobra, regdom je world, coz skutecne je a pridal jsem country_code=CZ do hostapd.conf. Nepomohlo, zkousim iw reg set CZ, nic, iw reg get vraci stale unset. COUNTRY=CZ crda vraci "Failed to set regulatory domain: -22" Teprve echo "options cfg80211 ieee80211_regdom=CZ" >> /etc/modprobe.d/modprobe.conf pomohlo v tom, ze iw get reg vraci:

country CZ: DFS-UNSET
        (2400 - 2483 @ 40), (N/A, 20)
        (5150 - 5250 @ 80), (N/A, 23), NO-OUTDOOR
        (5250 - 5350 @ 80), (N/A, 20), NO-OUTDOOR, DFS
        (5470 - 5725 @ 80), (N/A, 26), DFS
        (57240 - 65880 @ 2160), (N/A, 40), NO-OUTDOOR

Ale porad mam vsechny 5GHz kanaly limitovane na passive scanning. Napada nekoho, co s tim?

2.6.32-504.23.4.v6.x86_64 (ClearOS 6.6 final)

iw list

---

---

Odpovědi

[Ren]

Takze je to tak, ze ath9k ignoruje uzivatelske nastaveni regdom a na vedomi bere jen to, co ma vypaleno v EEPROM => je treba flashovat (jeste lze pouzit modnuty driver nebo patchnout kernel, ale flash spravneho kodu zeme do EEPROM je nejcistci reseni, protoze je to vlastne oprava neceho, co vyrobce podelal).

[Andrej]

Otázka je, zda má smysl zabývat se flashováním karty Atheros, což je jakýsi podivný riskantní postup s pěti různými návody neznámého původu na fórech, když stačí patchnout ath9k. Jak správně píšeš, uživatelské nastavení ignoruje ath9k, nikoliv karta samotná. Nějaký ucelenější patch se dá najít například v OpenWRT, kde se přesně tento problém řeší. Ale pokud člověk netrvá na elegantním řešení, může to třeba klidně zprasit. Můj domácí server má zkrátka a jednoduše toto:

diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 5e15e8e..083f731 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2383,7 +2383,7 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah)
        u8 ant_div_ctl1, tx_chainmask, rx_chainmask;
 
        eeval = ah->eep_ops->get_eeprom(ah, EEP_REG_0);
-       regulatory->current_rd = eeval;
+       regulatory->current_rd = 32971;
 
        if (ah->opmode != NL80211_IFTYPE_AP &&
            ah->hw_version.subvendorid == AR_SUBVENDOR_ID_NEW_A) {
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 0e347f8..11b0a52 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -2576,7 +2576,7 @@ static void restore_regulatory_settings(bool reset_user)
                        restore_custom_reg_settings(&rdev->wiphy);
        }
 
-       regulatory_hint_core(world_alpha2);
+       regulatory_hint_core("CZ");
 
        /*
         * This restores the ieee80211_regdom module parameter
@@ -3145,7 +3145,7 @@ int __init regulatory_init(void)
        user_alpha2[1] = '7';
 
        /* We always try to get an update for the static regdomain */
-       err = regulatory_hint_core(cfg80211_world_regdom->alpha2);
+       err = regulatory_hint_core("CZ");
        if (err) {
                if (err == -ENOMEM)
                        return err;

Ještě pro úplnost dodám, že uživatelské nastavení se ve skutečnosti neignoruje. Je to ještě mnohem horší. Uživatelské nastavení vytvoří průnik povolení a sjednocení zákazů mezi momentálně platnou konfigurací karty a novým nastavením. Takže v případě driveru Atheros může uživatelské nastavení možnosti karty vždy jen omezit, nikdy ne rozšířit nebo jinak plnohodnotně změnit. Tedy pokud člověk ten driver nehackne, že ano, což dělá OpenWRT nebo (chro chro) já.

[Ren]

Zdar, po pravde, nasel jsem, ze to tu popisujes v jinem vlakne, to me sem v prvni rade take privedlo. Ja jsem spis pres hw, takze mi flash prijde nejjednodusi, nejlogictejsi a take spravny, jak pisu, vlastne coby oprava, navic riskantni na tom nic neni. Bez muceni priznavam, ze nevim, jak bych Tvuj diff mel vubec pouzit. Zkompilovat na jeho zaklade novy ath9k? A co pri patchovani OS, musim pokazde znovu? Prave protoze pouzivam ClearOS, znacne specializovane distro, kde se snazim hackovani sw vyhnout co to jde, abych nenarusil nejakou navaznost; snazim se postavit co nejspolehlivejsi a bezudrzbove reseni.

[tom]

Ja jsem spis pres hw, takze mi flash prijde nejjednodusi, nejlogictejsi a take spravny

A kolikrat to to flashnuti vydrzi? Napadlo vas, ze treba nekdo bydli ve meste na hranicich dvou rozdilnych regulacnich domen a hranici prekracuje nekolikrat denne?

[Ren]

Tohle mi asi neda..Muzete mi zkusit vysvetlit, o cem si myslite, ze to tu mluvite?

[Andrej]

Qualcomm/Atheros si s takovým problémem poradí tak trochu po svém. (Myslím driver, nikoliv hardware.) Při každém setkání s další, dosud nepoužívanou doménou (tuším, že přes 802.11d či nějaký takový protokol může získat nastavení od AP) prostě nechá nahrát z userspace data pro danou doménu a zase udělá průnik povolení a sjednocení zákazů (s momentálně existujícím stavem). Takže po překročení hranice bude (software) dodržovat pravidla obou zemí, ještě navíc obohacená/ochuzená (jak se to vezme) o případné uživatelské nastavení, které může být odlišné od obou zemí, a o hodnotu nalezenou v EEPROM, která může být zase úplně jiná.

Horší ovšem je, že u spousty karet je to stejně jedno, protože mívají v EEPROM doménu 00 („world“), což je asi tak ta nejhorší varianta, protože na 5 GHz se s tím nedá vytvořit access point vůbec nikde a na 2,4 GHz to půjde jen na prvních 11 kanálech. Ovšem s omezeným vysílacím výkonem, bez 40MHz kanálů, s 80MHz kanály pouze v oblasti mokrých snů a tak dále. Skoro všechny kanály kromě prvních jedenácti na 2,4 GHz jsou pak omezené na passive scanning a nemají povolený access point. Takže má-li karta doménu 00, může přijít jakékoliv konfigurační omezení zvenčí a sada dodržovaných pravidel se už v podstatě nijak nezmění, protože 00 je v mnoha směrech nejrestriktivnější.

Omezení se zdaleka netýkají jenom dostupných kanálů, ale taky povolených vysílacích výkonů na různých kanálech. To může zásadně ovlivnit dosah AP a spolehlivost spojení, zejména v dnešním bezohledném hlučném prostředí. Zkrátka a dobře, chce-li někdo mít AP s kartou Atheros, chtě nechtě prostě musí ten driver hacknout. Tvůrci OpenWRT o tom vědí své, koneckonců. Jistě by ath9k tolik netweakovali, kdyby fakt nemuseli.

[Ren]

Zdar, zase ja. Jsem nahranej:

[root@cos7 atheros]# ./iwleeprom -d 0000:02:00.0 -s
Using device 0000:02:00.0 [RW] AR9300 Wireless Adapter (PCI-E) 
IO driver: ath9300
HW: AR9300 (PCI-E) rev 0003
RF: integrated
Trying EEPROM access...
OTP address out of range: 0fff
...

Jeste to pokracuje, ale hlavni je to OTP. One Time Programming znamena, ze na moji karte neni EEPROM, dokonce ani PROM, ale jen ciste ROM, takze neflashnu nic, dekuji pekne do Bigfoot Networks. Mohl bys prosim trochu rozvest, jak bych mohl uplatnit Tvuj hack driveru? Krome shaneni nove karty, ktere muze dopadnout stejne, jsi moje posledni sance.

Pokud to chapu spravne, mam tim diffem zmenit zdrojaky ath9k a zkompilovat upravenou verzi?

[Andrej]

Tady bych doporučil zkusit zkompilovat jenom moduly a prostě nahradit ath9k za ten hacknutý. Pokud bude konfigurace kernelu a build systém v rozumné shodě s tím, co tam už běží, mělo by to být v pohodě a nový ath9k poslouží jako drop-in replacement toho původního. Kompilovat celý kernel asi nemá smysl. Já třeba sice mám na svých počítačích vlastnoručně nakonfigurované a zkompilované kernely, ale kdyby se mě někdo zeptal na seznam výhod, asi bych fakt hodně váhal.

Co je potřeba pro build kernelu, o tom se aspoň ve zkratce zmiňuje stránka toho distra. To je ovšem hodně ve zkratce. Možná by se ale dal aplikovat nějaký návod pro CentOS, RedHat nebo Fedoru, jak se tak dívám. To by bylo potřeba zkusit.

Rád tady samozřejmě popíšu, jak bych kernel vybuildil já. Zdaleka ne všechny kroky jsou nezbytné pro tento případ, takže si z toho můžeš vybrat a poupravit jen to, co opravdu potřebuješ. Můžeš použít buď zdrojáky z distribuce, nebo aktuální kernelový strom. To první zaručí kompatibilitu modulů s aktuálně běžícím kernelem, zatímco to druhé zaručí kompatibilitu mého patche se zdrojáky, tedy přinejmenším u verze 4.1.6. Pokud se patch nepodaří aplikovat (což je u starších kernelů docela pravděpodobné), v tomto konkrétním případě se svět neposere, protože není až tak těžké příslušné řádky v souborech dohledat a aplikovat patch manuálně. Jen je to úsilí navíc. Každopádně těch pár relevantních řádků vypadá stejně už tak od kernelu 3.5, takže by měly být celkem v pohodě k nalezení, i pokud patch řekne, že neví a nezná.

Naklonování celé Git repository stačí udělat jen jednou v životě. Pak už se bude vždy pouze (celkem rychle a efektivně, s ohledem na její velikost) aktualizovat:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git ~/src/linux

Kompletní build celého kernelu bych udělal asi takto:

# Pár nastaení, která je potřeba upravit podle distribuce.
VERSION='4.1.6'
LINUX_SOURCE_PATH="${HOME}/src/linux"
KERNEL_IMAGE='/boot/vmlinuz-linux'

set -e
cd "$LINUX_SOURCE_PATH"
# Tady zruším všechny změny, všechny pozůstatky po buildech atd.
git clean -f -d
git checkout .
git checkout master
# Aktualizace repository, aby byly k dispozici nejnovější verze.
git pull
# Checkout zvolené verze do pracovních souborů.
git checkout "v$VERSION"
# Aplikace zázračného patche. Jo, přesně tady to je.
patch -lp1 <<-ATH9K_HACK
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 5e15e8e..083f731 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2383,7 +2383,7 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah)
        u8 ant_div_ctl1, tx_chainmask, rx_chainmask;
  
        eeval = ah->eep_ops->get_eeprom(ah, EEP_REG_0);
-       regulatory->current_rd = eeval;
+       regulatory->current_rd = 32971;
  
        if (ah->opmode != NL80211_IFTYPE_AP &&
            ah->hw_version.subvendorid == AR_SUBVENDOR_ID_NEW_A) {
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 0e347f8..11b0a52 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -2576,7 +2576,7 @@ static void restore_regulatory_settings(bool reset_user)
                        restore_custom_reg_settings(&rdev->wiphy);
        }
  
-       regulatory_hint_core(world_alpha2);
+       regulatory_hint_core("CZ");
  
        /*
         * This restores the ieee80211_regdom module parameter
@@ -3145,7 +3145,7 @@ int __init regulatory_init(void)
        user_alpha2[1] = '7';
  
        /* We always try to get an update for the static regdomain */
-       err = regulatory_hint_core(cfg80211_world_regdom->alpha2);
+       err = regulatory_hint_core("CZ");
        if (err) {
                if (err == -ENOMEM)
                        return err;
ATH9K_HACK
# Získání konfiguračního souboru existujícího kernelu.
# Buď je v /proc/config.gz, nebo taky ne.
if [[ -f /proc/config.gz ]]; then
	zcat /proc/config.gz > ./.config
else
	if ! scripts/extract-ikconfig "$KERNEL_IMAGE" > ./.config; then
		cp "/boot/config-${VERSION}" ./.config
		# A jinak konec, tady už prostě vaříme z vody.
	fi
fi
# Proč ne native, když už to stejně celé kompilujeme.
export KCFLAGS='-march=native -O2 -pipe'
export KAFLAGS='-march=native -O2 -pipe'
# Spuštění buildu ve screenu; oldconfig a menuconfig s trochou interakce.
# modules je v podstatě to jediné, co je potřeba spustit v případě modulů.
screen -d -m sh -c \
	'for i in oldconfig menuconfig clean prepare bzImage modules;
		do make -j 8 $i;
	 done'
# S následujícím opatrně, ať to ještě vůbec někdy nabootuje.
sudo make -j modules_install

Z výše uvedeného bude asi nejlepší zvolit kompilaci pouze modulů (cíl modules) a pak najít, kde je ath9k (find -type f -name ath9k.ko) a přepsat jím manuálně ten původní v /lib/modules/…/<verze_kernelu>. Pokud po přebootování (nebo případně po modprobe -r ath9k && modprobe ath9k) bude vše v pořádku, tj. v dmesg se objeví blablabla CZ a bude možné zvolit nějaké kanály pro access point (tj. hostapd bude provozuschopný a nebude nadávat), poté se dá uvažovat o tom, jak takovou změnu uložit nějak nastálo. Variant je několik:

1. Vlastní build distribučního kernelu (pokud jsou všechny moduly zabalené přímo s ním).
2. Vlastní build balíčku s Atherosem (pokud je ath9k v nějakém odděleném balíčku).
3. Jednoduchý skript, který prostě hrubou silou zkompiluje a nahradí ath9k, kdykoliv to bude potřeba, a na kterém bude záviset třeba hostapd. (Například vhodný systemd unit file spouštějící nějaký build skript. Tedy podle toho, co daná distribuce používá.)
4. Nějaké sofistikovanější automatizované řešení pomocí akmod, jestli distribuce něco takového má. akmod například na Fedoře automaticky kompiluje a aktualizuje moduly od grafických karet NVidia a další podobné těžko balíčkovatelné kusy kernelu.

Tohle už ale záleží na tom, co konkrétně distribuce dělá a umí, jaký systém pro build balíčků používá a tak dále. Abych to shrnul, doporučil bych napřed nějakým rychlým manuálním hackem vyzkoušet, jestli to celé vůbec má smysl, tj. jestli upravený modul bude fungovat, jak má. Teprve pokud se ukáže, že je to v pohodě, stojí za to investovat čas a úsilí do nějakých trvalejších úprav, které budou v lepším souladu s danou distribucí.

„Instalace“ samotného kernelu (například pokud by se zkompilovaná verze modulů lišila od verze distribučního kernelu a šlo by fakt jen o to nabootovat aspoň jednou alternativní kernel a zkusit, co to dělá) se dá provést zhruba nějak takto:

# Po editaci /boot/grub*/grub*.cfg a přidání kopie nějaké funkční položky:
cp /var/inst/linux/System.map /boot/System.map-alternative
cp /var/inst/linux/arch/x86_64/boot/bzImage /boot/vmlinuz-linux-alternative
# Následující je pouze pro ArchLinux; Fedora má dracut, ostatní kdovíco.
mkinitcpio -g /boot/vmlinuz-linux-alternative.img -c /etc/mkinitcpio.conf -k "$VERSION"-dirty
# Přípona -dirty se po některých patchích u verzí objeví, jindy ne.
# Poslední řádka výstupu z make modules_install ukáže, jak to je.

Pozor ovšem na ten initrd / initramfs / initcpio / kdovíjaktomuříkají, protože bez vygenerování správného obrazu pro daný kernel to většinou nenabootuje. Zažil jsem ty krásné časy, kdy initramfs nebyl povinný, takže stačilo zakompilovat přímo do kernelu jeden filesystémový driver, aby kernel dokázal otevřít hlavní filesystém s ostatními kernelovými moduly a initem, a bylo vys(ta)ráno. Leč časy se mění.

Možná se vyplatí vsadit na jistotu a zkusit spíš vybuildit kernelový balíček přímo build systémem dané distribuce. Tam je aspoň menší riziko, že člověk na něco podstatného zapomene. I tak doufám, že tahle odpověď aspoň něco ozřejmí — třeba to, kde se vyrábějí kernelové moduly.

[Ren]

Peklo. Diky moc! Behem par dnu k tomu sednu a zacnu se tim prokousavat, schvalne, jestli se ztratim nebo ne (dobre, jsem si jist ze ano ).

[Andrej]

A hned je tu první errata v podobě sed 's|/var/inst|${HOME}/src|' u toho instalačního rádobyskriptu — to mi už zase unikl nějaký copy&paste z dvou různých systémů. Grrr.

cp ${HOME}/src/linux/System.map /boot/System.map-alternative
cp ${HOME}/src/linux/arch/x86_64/boot/bzImage /boot/vmlinuz-linux-alternative

[gogol]

Passive scan nevadi ak nepouzivas hidden ssid. Je maly predpoklad, ze vo vnutornom prostredi budes chytat desiatky cudzich sieti. S kartou 3x3:3 sa predpoklada jej vyuzitie na maxime prenosovej sirky pasma, co znamena byt v blizkosti AP. V eeprom by ziadny reg nemal byt vypaleny. Ak tam je, znamena to blokovanie pre urcity region. Ak tam nieje znamena to, ze je tu kartu mozne pouzit celosvetovo podla nastavenia OS. Notebooky dovezene z US to maju casto blokovane. Klasicke PCI/USB karty to naopak nemaju blokovane.

[Ren]

Ahoj, pisu, ze to mam prece na AP. A jen tak pro zajimavost, v 2.4GHz pasmu na me ted sviti 45 radii ze vsech stran, nevyhoda centra mesta.

World domain znamena takova nastaveni, ktera se daji pouzit kdekoliv na svete, neboli nejvice limitujici a ano, jsou soucasti predprogramovani vyrobce.

[gogol]

Myslel som, ze ta zaujima predovsetkym pouzitie na 5G. Ani 45 sieti nemusi byt na zavadu ak sa da riadit citlivost radia. Ak sa zatlmi radio, tak tam moze vysielat co len chce pokial to nieje moc silne. Mam to tak spravene v ovladaci pre vonkajsiu siet kde vidim viac ako 50 sieti + viac ako 100 klientov na max citlivosti. Ked to zatlmim tak ani 10 sieti na rovnakom kanali mi nevadi.

[Andrej]

Passive scanning většinou vadí. Tazatel jasně píše, že chce provozovat AP na 5 GHz. Bez nastavení nějaké rozumné regulatory domain je ovšem nanejvýš pravděpodobné, že všechny 5GHz kanály budou omezené na passive scanning a nebude tedy možné na žádném z nich provozovat AP. Totéž většinou postihne kanály 12 a 13 na 2,4 GHz, na nichž rovněž nesmí být AP, pokud člověk něco nezastaví „násilím“.

[gogol]

To je omyl priatelu. "passive scanning" nezabranuje pouzitiu AP a to ani na CH13. Tazatel si mysli, ze nastavil regdom na CZ. V skutocnosti sa regdom nenastavila, pretoze je hw blokovana. Mozes si vsimnut, ze 5G kanaly mu umoznuju pouzit sirku kanalu 80MHz. Na AR9380 take nieco nieje mozne.

To, ci sa nastavi regdom je mozne monitorovat: udevadm monitor --environment kernel

[Ren]

Tazatel si nemysli, ze nastavil CZ, vzdyt to tady sakra celou dobu resime, ze to nefunguje..? A ty sam o par radku vys tvrdis, ze v hw nic napevno nastavene neni a ted uz souhlasis? A 80MHz kanal se sem ted dostal jak? Chjo. S vama lidma je nekdy tezky porizeni.:-P

[gogol]

Bolo by fajn ak by sa podaktori naucili riadne citat. Som dost presvedceny, ze teba sa netyka ta "neblokovana" :) To, ze sa ti tam "nieco" nastavilo neznamena, ze sa nastavil spravne regdom. Kukni si to tym monitoringom. Niektore konfiguratory obsahuju bug. Nenapadlo ta to ?

[Ren]

Ano, to by skutecne pomohlo. My tu s Andrejem resime prave ten tzv. PRUNIK, neboli to, ze se karta sice tvari jako regdom CZ, ale ve skutecnosti tam CZ neni.

[gogol]

Pokial budes vyhladavat konfrontacie, tak sa malo dozvies. Mozes si vsimnut, ze uzivatel tom ti chcel naznacit nieco co povazujem za zaujimave a ty si ho odpiskal. Vobec sa necudujem, ze stratil zaujem dalej pokracovat.

[Ren]

Vyhledavat konfrontace? Lol, ted uz si ale fakt delas legraci, ze? Jestli nepoznas trolla, s tim ti tezko pomuzu a je vyhra vsech, ze "ztratil zajem". Tehle lidi, co se s idealne nulovou znalosti problematiky chytnou absurdniho argumentu, ktery si vymysli a k nemu zkusi strhnout diskuzi jsou plna fora. A ja o ne ve svem vlakne zajem nemam, dekuji. A pokud v jeho zcestnem komentari vidis neco zajimaveho, misto abys poznal jeho nepochopeni tematu, no....good luck.

[gogol]

Myslim, ze uz davno si pochopil, ze ti pomoze len hacknut ten ovladac. Pokial to chces rozpytvavat dalej, tak bude zrejme treba spravit vlastny research ci a ako je mozne pripojit seriovu flash. Moznost tam je. Radic pamate v tom cipe vie pristupovat aj na externu flash a je dost mozne, ze len nieje osadena na plosaku z hladiska co najnizsich vyrobnych nakladov. Ako hardwarista by to nemal byt problem pre teba dobastlit. Viem dost presne co sa deje v systeme ak sa flasne do eeprom kod 00. Na Ralinkoch sa to sprava rovnako ako na inych kartach napriklad na Ath. Ovsem myslim si, ze toto ta nezaujima, tudiz je asi zbytocne sa rozpisovat.

[Andrej]

Passive scanning zabraňuje vytváření AP, přinejmenším tedy u driveru ath9k (ve vanilla verzi, bez OpenWRT patchsetu). Poněvadž AP jako takový je přesným opakem pasivní detekce AP, je takové omezení koneckonců celkem logické, že ano. Otázka je, co myslíš souslovím použití AP. Passive scanning skutečně nijak nebrání připojit se jako klient k AP, který už na „pasivně scanovaném“ kanále existuje a vysílá. Neumožňuje ovšem používat WiFi rozhraní jako AP na daném kanále. A použitím rozhraní jako AP se myslí přepnutí rozhraní z implicitního managed režimu do režimu AP, vysílání beaconů, autentifikace klientů a zkrátka všechno možné, co dělá hostapd.

Zkus si opravdu spustit hostapd a nastavit kanál 13 na kartě, která tam má pro daný kanál passive scanning (přinejmenším podle výpisu z iw list). Hint: Ne, fakt to nepůjde. On už je ath9k prostě takový.

[gogol]

Ja to tak mam nastavene ako AP na ch13, inak by som sa neodvazil pisat, ze to funguje. Je pravda, ze to nemam na OpenWRT, ale na Fedore18. A je pravda, ze to nefungovalo bez upravy prislusneho konfiguraku kde je potrebne upravit znamienko na ht_capab=[HT40-]. Povodne tam bolo [HT40+]

[Andrej]

Pak má pravděpodobně karta v EEPROM doménu, která kanál 13 normálně povoluje i pro access pointy. (Vsadil bych se, že iw list u kanálu 13 neukazuje passive scanning, no IBSS ani další omezení. (Zákaz Ad-Hoc sítí je taky většinou v korelaci se zákazem AP, přinejmenším u většiny domén to tak je.)

Já jsem si koupil do serveru kartu, která byla poměrně podezřele levná, ale v EEPROM má tak divnou doménu, že má zakázané všechny 5GHz kanály a taky kanály 12 a 13 na 2,4 GHz. Tedy všechny umí používat v roli klienta, ale hostapd řekne hovno. (Přesněji řečeno, řekne to ten syscall, kterým se hostapd pokouší přepnout kartu do režimu AP.) Hacknutí ath9k tohle odbloukje a všichni (kernel především) si pak myslí, že je tam doména CZ/CH/kdezrovnajsem.

[Ren]

A co to mas vlastne za kartu konkretne..?

[gogol]

No praveze passive scanning tam mam, ale nemam tam flag "no IBSS". Tiez nevylucujem moznost, ze u mna moze byt nejaky bug v systeme, preto mi to chodi. Ja by som to videl tak, ze regdom 00 bude ten najvacsi problem. Neviem ci Atherosy maju v eeprom domenu 00. Nemam az tak dobre nastudovane Atherosy. Pracujem skoro vylucne s Ralinkami a tie maju v eeprom hodnotu vzdy roznu od nuly a prazdna eeprom je citana z eeprom kodom 0xff. Vynulovana eeprom ma vsade log.1 ak sa nemylim. Ovladac na kod 0xff reaguje tak, ze dovoli nastavit regdom.

[Jiří Lisický]

Zkus se podívat na configurační volby při kompilaci jádra:

1. CONFIG_ATH_USER_REGD - "Force Atheros drivers to respect the user's regdomain settings"
2. CONFIG_PACKAGE_ATH_DFS - tohle zapne detekci radaru

[Ren]

Ahoj, diky, ale jak jsem psal, pouzivam specificke distro (ClearOS), kdyz zkompiluju vlastni kernel, nejspis rozbiju vsechno vcetne automatickych updatu.

[Andrej]

Tohle bude rozumnější než můj prasácký patch výše, pokud to ovšem nevyžaduje rovnou celý OpenWRT patchset…

[Ren]

Tvuj patch je ale jen novy ath9k.ko, ne cely kernel, ne?

[Andrej]

Jo, dá se zkompilovat jenom odděleně ath9k, když člověk přijde na to, který Makefile a cíl to je. Jenom tam pak není ta podpora balíčkovacího systému kolem, takže se musí manuálně někam nakopírovat soubor ath9k.ko a tak podobně. Jinak ale nic nebrání kompilaci celého kernelu s mým patchem pro ath9k. Dokonce to může být nezbytné v případě, že se nepodaří ath9k zkompilovat tak, aby byl kompatibilní s kernelem aktuálně běžícím na tom stroji. Pak může být jednodušší prostě zkompilovat celý kernel, do kterého ten nový ath9k pasuje, nabootovat ho a zkusit, co a jak.

Ty konfigurační volby výše jsou ale opravdu specifické pro OpenWRT, jak jsem se obával. Na vanilla kernelu mi zgrep USER_REGD /proc/config.gz nedává prostě nic. (A přitom je asi jasné, že zrovna já bych tu volbu měl zapnutou, kdyby ve vanilla kernelu byla. )