Karta Intel WiFi Link 4965AGN i Ubuntu 9.04

Ostatnia aktualizacja: 27 lipca 2009
strona główna

Mimo że nie jestem już użytkownikiem Ubuntu i nie używam już 4965AGN do prac "aircrackowskich", ze względu na pojawiające się w mailach pytanie jak prezentuje się sprawa sterowników i ich współpracy z aircrackiem na najnowszej wersji Ubuntu 9.04 "Jaunty Jackalope", zdecydowałem się zorientować jak sytuacja wygląda. Po pierwsze, zmieniła się nazwa modułu sterownika - z iwl4965 (który to obsługiwał tylko karty 4965AGN) na iwlagn (który to obsługuje 4965 i wszystkie 5xxx).

Niestety, nie mam dobrych wiadomości. Karta działa mniej więcej tak, jak działała - czyli w sumie sama nie wie, czego chce. Jedynym plusem jest to, że wszelkie łatki, które trzeba było zastosowywać do źródeł sterowników zostały już w tych sterownikach zawarte, tak więc ręczne patchowanie nie jest już potrzebne. Zdarza się też, że działa atak -1, czyli fakeauth. W dużej mierze zależy to jednak od szczęścia.

Artykuł ten powstał na podstawie jądra 2.6.28-13-generic, informacje w nim zawarte mogą (i zapewnie będą) się zmieniać w zależności od wersji jądra.

Polecam ładowanie modułu karty z parametrami swcrypto=1 disable_hw_scan=1, czyli poprzez komendę :

# modprobe iwlagn swcrypto=1 disable_hw_scan=1

Lub poprzez dodanie odpowiedniego wpisu w konfiguracji modprobe (/etc/modprobe.d).

Obsługa fakeauth dalej jest kiepawa. Mimo że znaleziono źródło błędu - nie był nim, wbrew spekulacjom, firmware, lecz kod aireplay-ng, jako że wysyłał on więcej niż jedną ramkę do AP, przez co firmware karty szalał i wywalał się. Aireplay domyślnie wysyła tylko jedną ramkę na wszystkich kartach. 4965 jednak swoje wie i łatwo się nie podda. Bardzo często zdarza się, że atak wygląda mniej więcej tak :

# aireplay-ng -1 0 -e Dauthalagith mon0
No source MAC (-h) specified. Using the device MAC (00:13:E8:BA:B5:59)
03:18:04  Waiting for beacon frame (ESSID: Dauthalagith) on channel 8
Found BSSID "00:7D:BA:97:06:3D" to given ESSID "Dauthalagith".

03:18:04  Sending Authentication Request (Open System)
03:18:04  Authentication successful
03:18:04  Sending Association Request

03:18:09  Sending Authentication Request (Open System)
03:18:09  Authentication successful
03:18:09  Sending Association Request

03:18:14  Sending Authentication Request (Open System)

03:18:16  Sending Authentication Request (Open System)

03:18:18  Sending Authentication Request (Open System)
03:18:19  Authentication successful
03:18:19  Sending Association Request

03:18:24  Sending Authentication Request (Open System)

03:18:26  Sending Authentication Request (Open System)

03:18:28  Sending Authentication Request (Open System)

03:18:31  Sending Authentication Request (Open System)

I tak w nieskończoność. Dzieje się tak dlatego, że podczas gdy aireplay próbuje wysłać pakiet auth/assoc do AP, karta czasami "przestaje widzieć" jakikolwiek ruch - coś podobnego działo się wcześniej, lecz wtedy wywalał się cały sterownik. Czasami zdarza się, że po wielu takich próbach (tj. Sending Authentication Request) karta w końcu się przełamuje i pomyślnie wysyła pakiet oraz odbiera potwierdzenie. Zdarzyło mi się też pomyślnie zaasocjować z siecią za pierwszym razem, ale to była tylko i wyłącznie kwestia szczęścia. Sytuacja trochę (ale nieznacznie) poprawia się, gdy zainstalujemy spatchujemy patchem frag+ack mac80211.

Jedynymi atakami, które udało mi się pomyślnie przeprowadzić, są ataki deauth (-0), interactive packet replay (-2) oraz arpreplay (-3). Chopchop (-4) oraz fragmentation (-5, nawet po spatchowaniu mac80211) nie chciały działać - a wydaje mi się że w starszych wersjach działały. Jestem pewny, że AP na którym przeprowadzałem testy działał poprawnie, jako że moja inna karta nie miała problemów z atakami.

Co ciekawe, mój sposób na obejście braku fakeauth'u, czyli ten z wykorzystaniem wpa_supplicant, nadal działa. Przypomnę go : wywołujemy po prostu normalną asocjację na normalnym interfejsie karty (czyli tym wlan0, który jest ciągle w trybie Managed). Jeśli potrzebujemy asocjację wykonać z innym adresem MAC, zmieniamy go PRZED wywołaniem wpa_supplicant. Program ten potrzebuje jednak pliku konfiguracyjnego do poprawnego działania. Powinien on wyglądać tak :

network={
	ssid="ESSID"
	key_mgmt=NONE
	wep_key0="fake"
}

Gdzie ESSID zamieniamy na ESSID naszej sieci (tj. tej, do której chcemy się zaasocjować). Jeśli mamy już ten plik zapisany, wywołujemy suplikanta następującą komendą :

# wpa_supplicant -i wlan0 -c plik.conf -D wext -dd

Gdzie wlan0 to interfejs karty sieciowej (ten domyślny, a nie ten w trybie monitor, jako że wpa_supplicant nie współpracuje z interfejsami w trybie monitor), plik.conf to nazwa naszego pliku konfiguracyjnego, wext to sterownik używany przez program, a -dd powoduje, że jest on bardziej szczegółowy w raportowaniu swoich bieżących czynności. Gdy na ekranie zobaczymy :

State: ASSOCIATED -> COMPLETED
CTRL-EVENT-CONNECTED - Connection to 00:7d:ba:97:06:3d completed (auth) [id=0 id_str=]

To AP przyjął asocjację i możemy teraz wysyłać do niego dane za pomocą aireplay-ng.

Biorąc pod uwagę wszystkie powyższe rozważania, moim zdaniem używanie tej karty do aircracka to po prostu STRATA CZASU. Mimo że sprawuje się ona całkiem nieźle w normalnej pracy wifi, to nie da się tego powiedzieć o aircracku.
strona główna