Blog domo

Czas wrócić do ndiswrappera… Moduł sprawuje się nie tak jakbym chciał. Są ogromne problemy z nawiązaniem połączenia z AP i pobraniem ustawień interfejsu poprzez dhcp. Trwa to bardzo długo. Jest to bardzo denerwujące, bo po uruchomieniu KDE okazuje się, że interfejs nie zdążył wstać. To samo przy powrocie lapka z hibernacji. Tyle cierpliwości to ja nie mam. Jeśli chodzi o samo działanie, już po połączeniu, to muszę przyznać że nie było żadnych problemów. No może poza działaniem kismeta, którego nie udało mi się odpalić, ale przyznaje że nie szukałem zbyt długo na google . Tak jak zacząłem- witaj ndiswrapperku ponownie….

P.S. właśnie zobaczyłem, że jest już 2.6.24 Zatem znów będę testować. Obawiam się tylko, że sporych zmian nie będzie od wersji rc8…

Zauważyłem, że w repozytoriach Archa w unstable, dodana została nowa paczka- kernel linux-2.6.24-rc8.mm1. Na co dzień nie używam niczego z unstable, ale w tym przypadku zbyt byłem ciekaw, aby nie skorzystać. Niedawno bawiłem się z 2.6.24-rc8 i efekt nie był zbyt pozytywny, ale tym razem miałem gotową paczkę, skompilowaną zapewne inaczej niż przeze mnie, a co istotniejsze dodany został patch z gałęzi Andrew Morton’a. Kto wie? Być może tym razem będzie działać inaczej. Zainstalowałem i reboot. Po uruchomieniu Archa z tym kernelem okazało się, że interfejs wlan0 wstał, załadowany moduł b43 i wygląda na to, że działa.

W dalszym ciągu jest problem z wstawaniem interfejsu i jego domyślnym rate, który jest ustawiany na 1Mb/s. Zmiana na wyższy nie przysparza żadnych problemów- wszystko działa poprawnie. Również niezmienna jest kwestia wyładowania modułu-trwa to bardzo długo. W przypadku ponownego załadowania modułu, nie zawsze udaje się nawiązać połęczenie z AP- przeważnie za 2-3 razem.

Zaobserwowałem dziwne zachowanie, dotyczące bardzo częstych zmian w poziomie jakości połączenia. Link Quality potrafi zmieniać się w ciągu ok 2-3 sekund przynajmniej kilka razy. Niejednokrotnie różnica wynosiła 20%. Jednocześnie nie zauważyłem, aby wpływało to w jakiś sposób na działanie internetu. Wygląda na to, że w przypadku modułu b43, karta jest bardziej czuła na czynniki wpływające na zmiany w jakości połączenia, tudzież sam sterownik po prostu jest bardziej „nadgorliwy” i ma inny interwał w sprawdzaniu poziomu sygnału. Innych zauważalnych rzeczy póki co nie ma. Poużywam sobie go trochę dłużej, to może coś się jeszcze znajdzie, wtedy dopiszę zmiany do tego posta. Na razie działa poprawnie.

Od jakiegoś czasu, w źródłach kernela jest moduł b43, który ma zastąpić (?) bcm43xx. Przyznaję, że nie wczytuję się jakoś nałogowo we wszelakiego rodzaju informacje, które dotyczą obsługi mojej karty (bcm4318), więc mogę być w błędzie. W pewnym momencie natknąłem się na linuxwireless.org, gdzie okazało się, iż (jeśli dobrze pamiętam) w którejś wersji 2.6.23 pojawił się nowy moduł- tytułowy b43. Nie omieszkałem przetestować, korzystając z opisu na linuxwireless. Skopiowałem w /lib/firmware odpowiedni firmware do karty i uruchamiałem. Działać, działało, ale bez większych różnic względem bcm43xx. Problem z połączeniem z konkretnym essid-em, nie zawsze udawało się pobrać dane z dhcpd. Przetestowałem kilka wersji kernela, w których patrząc na Changelog widziałem jakieś zmiany odnośnie mojej karty. Niestety, zawsze kończyło się na tym samym- powrót do ndiswrappera. Ostatnio stwierdziłem, że z nudów skompiluję 2.6.24.-rc8. Okazało się, że owszem- działa, ale niestety nie tak jak działać winno. Znów podobne problemy- nie chce się połączyć z siecią, a jak się połączy, to nie za każdym razem jest w stanie skorzystać z dhcp. Czasem o dziwo działało „od kopa” . Do tego jeszcze doszedł pewien symptom, a mianowicie problem z wyładowaniem modułu b43. Polecenie rmmod br43 kończyło się dość długim zwisem konsoli. Wyładowywał dość długo. Przy wyłączaniu systemu niestety efekt był taki, że moja cierpliwość się kruszyła i stosowałem przycisk power. Generalnie shit. I znów to samo- witaj ndiswrapper .
Stosowałem opisy z linuxwireless, gdzie co istotne, było opisane, iż jest konieczne skorzystanie z różnych firmware w przypadku różnych modułów/kerneli. Robiłem „po bożemu” i efekt podobny- sporo problemów.
Zdaję sobie sprawę z tego, że jest to ciągle „rc”, chociaż ktoś ten moduł już umieścił w 2.6.23.x (i wtedy też było kiepsko), ale nie ukrywam, że obecna sytuacja jest daleka od normalności.

Może kiedyś doczekam czasów, gdy bcm4318 będzie działało na „prawdziwym” module z kernela, który nie będzie wymagać żadnego firmware. Pewnie już wtedy nie będę mieć swojego lapka .

P.S Może to i lepiej, że w kernelu od ArchLinux nie ma domyślnie skompilowanego b43- zawsze to mnij nerwów dla chcących potestować .

Niestety… Poświęcony przeze mnie czas na skompilowanie dwóch wersji kernela (2.6.24-rc1 i rc2), okazał się być poniekąd zmarnowany. Rzecz jasna zawsze można zaliczyć to na poczet testów, doświadczeń itd.
Ad rem. Kilka zauważonych przeze mnie problemów:
1. po załadowaniu modułu ustawiany domyślnie jest rate o wartości „aż” 1mb/s
2. po zmianie rate (testowane od 24mb/s do 54mb/s) często okazywało się, że net łapał czkawkę (dnsy)
3. przy uruchamianiu interfejsu poprzez dhclient wyskakiwały błedy (nie przytoczę w tej chwili, bo używam już innego kernela) i częstokroć zabiegi kończyły się na niczym- tzn. nie pobierało danych z dhcpd
4. po uruchomieniu systemu, pomimo niedokonywania żadnych zmian internet jest lub nie ma. Efekt jest taki, że wlan jest skonfigurowany ok (iwconfig pokazuje, że essid, WEP key jest przydzielone, sygnał ok) ifconfig wskazuje na to, że znów dhclient nie pobrał danych

Biorąc pod uwagę, że mimo wszystko jest to dość nowy projekt (b43), a sam kernel ma jeszcze długą drogę do miana stable, to nie ma się co dziwić. Poczekam jeszcze trochę. W zasadzie to nie odczuwam jakiegoś wielkiego entuzjazmu b43, bo dopóki nie będzie moduł działał bez zewn. sterowników, dopóty nie będzie to dla mnie „normalne” rozwiązanie.