[Linux] Probleem met kanaal 13: Atheros EEPROM herschrijven?

[Weapon S]

Hoi mensen,

al enkele dagen breek ik m'n hoofd over dit. De Chinezen die m'n kaartje hebben gemaakt hebben blijkbaar de regio die op de EEPROM staat op China gelaten. (Dat kan je zien met het programma ath_info.)
Linux leest dat af en vindt dus dat ik geen kanaal 13 mag gebruiken. Het schijnt een veel voorkomend probleem te zijn, en eigenlijk hoop ik op dit moment iemand te vinden die de oplossing op een presenteerblaadje heeft. Windows doet wel gewoon kanaal 13.
Nu zijn er twee mogelijkheden: of je herschrijft de driver zodanig dat ie gewoon zegt dat er iets anders op de EEPROM staat. Ik weet niet precies hoe ik aan de broncode moet komen. Ik gebruik Debian.
Of ik gebruik het programma ath_info in schrijf modus. Het probleem is dat het niet lukt. Nu kan ik het programma zeggen dat hij alvorens het schrijven GPIO's aan- of uit moet zetten (kan blijkbaar softwarematig?!), maar ik zou geen idee hebben welke waardes ik zou moeten gebruiken. Dit lijkt me nou ook niet iets dat je maar gewoon moet uitproberen... Ik zal ook eens kijken of er iets op de kaart zelf te zien is.
Waar kan ik zulke informatie vinden? Mijn Google-fu is zwak. Ik heb hier wat info; waar moet ik op zoeken?
TP-Link: TL-WN350G
Atheros: AR5007G
-==Device Information==-
MAC Revision: 2417 (0xf0)
Device type: 3

/============== EEPROM Information =============\
| EEPROM Version: 5.3 | EEPROM Size: 16 kbit |
| EEMAP: 2 | Reg. Domain: 0x809C |
|================= Capabilities ================|
| 802.11a Support: no | Turbo-A disabled: yes |
| 802.11b Support: no | Turbo-G disabled: yes |
| 802.11g Support: yes | 2GHz XR disabled: no |
| RFKill Support: no | 5GHz XR disabled: no |
| 32kHz Crystal: no | |
\===============================================/

GPIO registers: CR 0x00000003, DO 0x00000001, DI 0x00000014
STA_ID0: xx:xx:xx:xx:xx
STA_ID1: 0xXXXXXXXX, AP: 0, IBSS: 0, KeyCache Disable: 0
TIMER0: 0x00000030, TBTT: 48, TU: 0x11710030
TIMER1: 0x0007ffff, DMAb: 65535, TU: 0x1170ffff (-49)
TIMER2: 0x01ffffff, SWBA: 65535, TU: 0x117fffff (+982991)
TIMER3: 0x00000031, ATIM: 49, TU: 0x11710031 (+1)
TSF: 0x00000045c34e2c3b, TSFTU: 54155, TU: 0x1170d38b
BEACON: 0x00000000
LAST_TSTP: 0xc34d4168

Ik ben eindelijk bij deze oplossingen gekomen na 3 dagen. Ja, ik kan wel wat hulp gebruiken.

[ Voor 0% gewijzigd door Weapon S op 16-09-2012 09:38 . Reden: :-X ]

[Raven]

http://smorgasbord.gavaga...liance-and-how-to-fix-it/ ?
Heb daar een tijdje terug naar gezocht omdat bij mij de gehele 5GHz band geblocked is voor accesspoint doeleinden. Ben er verder nog niet mee bezig geweest nadat ik die site vond.

edit: de zoektermen voor dit probleem zijn: regulatory domain

[ Voor 10% gewijzigd door Raven op 12-09-2012 13:19 ]

[Weapon S]

Hey bedankt voor je post. Ik had al een beetje naar het CRDA-gedoe gekeken. Ik geloof dat Debian Squeeze een tabel gebruikt dat in de kernel zit ingebouwd... Lastig in ieder geval.
Ik ben er eindelijk uitgekomen. Als een n00b, gewoon wat proberen. (Ik had wel ergens gelezen dat ik iets op 0 moest zetten, maar dat kon ik niet meer vinden). Ze zeggen wel dat dingen tegenwoordig niet meer zo degelijk zijn als vroeger, maar hardware bricken is een stuk moeilijker geworden
Hier zijn de details:
http://www.linuxquestions...-card-731002/#post4781434
(Pin 0 t/m 4 op 0 gezet.)