Intel N WiFi Link 5300 (iwlagn) a změna MAC adresy

6.8.2010 18:14 | Přečteno: 2281× | Linux, objevy | poslední úprava: 6.8.2010 18:16

S novým notebookem přišla i nová wifi karta. Jelikož zapojovat pořád "atherosku" do pcmcia a připojovat externí anténu není tak pohodlné, jako použít interní kartu, rozhodl jsem se dát Intelu šanci. Mnoho nestandardních uživatelů má s těmito kartami problém (nefungující injection, ...), mě se dnes podařilo úspěšně změnit MAC adresu na kartě v monitor módu. Jak na to? Čtěte dále.

Standardní vlastnosti karty, funkčnost

Napřed něco málo obecně o kartě. Karta funguje dobře. Karta vlastně funguje velmi dobře, citlivost má podobnou, jako moje "atheroska" WLAN CB9-EXT s přídavnou 60° anténou. Pravděpodobně díky vlastnosti, na kterou jsem se tady před časem ptal - vypadá to, že karta umí zkombinovat (resp. využít) obě antény i pro 802.11b. S vestavěnou intel kartou na thinkpadu R60 se nepřipojím tam, kde mi thinkpad T500 jede prakticky bez packet lossu.

Nezkoušel jsem nějaké prehistorické drivery / hooky / wireless-extensions, používám čistě mac80211 driver iwlagn a utilitku "iw" (místo iwconfig). Karta tedy bez problému zvládá "managed" mód, "ibss" (ad-hoc) mód, monitor mód (alespoň na 2.6.34-35 nativně a bez patchů) a pravděpodobně i "master" (AP) mód přes hostapd s nl80211 podporou (nezoušeno, debian testing jaksi nl80211 hostap driver nevede).

Monitor mode, packet injection

Někdo to dělá pro zábavu, jiný kvůli egu, někdo zase třeba pracovně. Mluvím především o packet injection (monitor mode nepočítám, ten se hodí v běžné praxi více, než aktivní skenování). Samotný monitor mód (jak bylo řečeno) funguje - a to i přes iwconfig. Žádné patche / 3rd party věci (wlanconfig) nejsou potřeba. Samotný packet injection vlastně taky (od 2.6.3x) funguje bez patchů na výbornou (podle aireplay-ng -B -9). Co nefunguje je změna MAC adresy pro kartu v monitor módu, driver ji ignoruje (pravděpodobně).

The 0xd4 / 0x1d (Acknowledgement) problem

Psal jsem, že injection funguje, to znamená, že karta umí vysílat packety s libovolnou MAC adresou v IEEE802.11 hlavičce, zatajil jsem však, že karta není tak dobrá v jejich příjmu. Pokud neměníme adresu karty a pokusíme se o autentikaci (authentication) s nějakým AP, povede se nám to. Jakmile MAC změníme, driver (nebo firmware? wireshark to nezachytí) nějakým záhadným způsobem nepřijde frame typu 0xD4 směřovaný přímo na jeho (falšovanou) MAC adresu. To způsobí, že se karta nemůže na nikoho "připojit". Zmíněný frame je vidět ve wiresharku / tcpdumpu jen s původní MAC adresou, při pokusu s falešnou adresou zůstane AP u posílání Clear-to-Send (0xc4 type+subtype / 0x1c type).

Zkusil jsem modifikovat zdrojáky aireplay-ng, konkrétně část s

        if( caplen == 10 && h80211[0] == 0xD4)
        {
            if( memcmp(h80211+4, opt.r_smac, 6) == 0 )
            {
                gotack++;
                if(gotack==1)
                {
                    printf(" [ACK]");
                    fflush( stdout );
                }
            }
        }

- bez úspěchu. Karta prostě ten packet zahazuje buď na úrovni firmware nebo na úrovni driveru.

Managed Mode Magic

Je to už pár let, ale pamatuji si, že na některé (snad broadcom) karty zabíralo nastavení MAC adresy v managed módu. Monitor pro ně tehdy myslím vůbec nešel. Zkusil jsem tedy (po čerstvém modprobe) kartu přehodit do managed módu, nastavit mac adresu, pro jistotu link up, následovaný link down a přepnutím do monitor módu. Nefungovalo to. Ani za použití ifconfig+iwconfig, ani přes ip+iw.

Virtuální adaptéry / interface (VAP)

Nástroj iw se od iwconfig liší především jedním velkým rozdílem - nevidí karty jako interface, ale jako PHY. Tedy lze jednodušše vytvořit více "interfaců" s různými módy, frekvencemi a vlastnostmi na jedné fyzické kartě (phy). Driver (nebo spíš stack) pak za běhu mezi interfacy přeskakuje v cyklu a obslouží postupně všechny. Jednou jsem zkoušel použít dva interface na dvě různé frekvence a packet loss byl přibližně těch 50%, nevím, jak to wlanconfig na atherosu dělal, tam ztráty byly skoro nulové.

Použití VAP pro změnu MAC adresy

Celkem náhodou jsem přišel na to, že přes VAP lze oblbnout driver (tedy vlastně spíše firmware), aby změnil MAC adresu i u interface v monitor módu. Pokud máme interface wlan0 a PHY phy0, pak můžeme vypnout (link down) wlan0, vytvořit na phy0 nový interface v managed módu, změnit (dokud jsou oba "down") jejich MAC adresy, procyklovat (up+down) interface v managed módu (to je ta klíčová část, firmware/driver si asi uvědomí novou adresu) a následně managed interface odstranit. Zůstane nám vypnutý wlan0 v monitor módu se změněnou adresou, který se dá použít třeba pro airodump-ng - následný aireplay-ng -1 0 -a <AP> wlan0 proběhne úspěšně pod falešnou MAC adresou.

Neproběhne!

Věřím, driver hlásí špatný kanál a aireplay-ng mu věří:

wlan0 is on channel -1, but the AP uses channel 5

-- řešení je ale velmi jednoduché, stačí zakomentovat daný return; u této hlášky v kódu aireplay-ng a vše opět funguje.

Post-2.6.35 upstream fixy

Docela značnou naději jsem vkládal do patchů pro iwlwifi, které jsou v linux-next, tyto patche předělávají hardwarové MAC na to, co uživatel specifikuje - zkoušel jsem tyto patche aplikovat na svoje zdrojáky kernelu, zkoušel jsem i compat-wireless, bohužel jsem nenašel žádný praktický rozdíl oproti 2.6.35 kernelu a workaround s VAP v managed módu bylo potřeba použít i tam.

Skripty na usnadnění práce

Již jsem nastínil postup, ti znalejší jej asi dokáží převést do praxe, pro ty ostatní (nebo pro znalé lenochy) přikládám svůj wifi-mac skript - stačí mu předat jméno interface a novou adresu:

#!/bin/sh -e

if [ -z "$2" ]
then
        echo "Changes MAC addresses of iwlwifi cards" 1>&2
        echo "via an \"managed interface hack\"" 1>&2
        echo 1>&2
        echo "Usage: $(basename $0) <dev> <new_address>" 1>&2
        exit 1
fi

DEV="$1"
ADDR="$2"
TEMP_DEV="temp_manag"


# optionally do an UID 0 check
# disabled: a user can have device access under special conditions
#[ "$UID" -ne 0 ] && exit 1

# check for device
dev_list="$(cat /proc/net/dev | grep -o '[^\ ]*:' | tr -d ':')"
found=0
for dev in $dev_list
do
        [ "$dev" = "$DEV" ] && found=1
done

if [ $found -lt 1 ]
then
        echo "error: Device ${DEV} not found" 1>&2
        exit 1
fi

# check for mac address
if [ -z $(echo "$ADDR" | grep -e '^[0-9a-f][0-9a-f]:[0-9a-f][0-9a-f]:[0-9a-f][0-9a-f]:[0-9a-f][0-9a-f]:[0-9a-f][0-9a-f]:[0-9a-f][0-9a-f]$' -e '^[0-9a-f][0-9a-f]-[0-9a-f][0-9a-f]-[0-9a-f][0-9a-f]-[0-9a-f][0-9a-f]-[0-9a-f][0-9a-f]-[0-9a-f][0-9a-f]$') ]
then
        echo "error: Invalid MAC address: ${ADDR}" 1>&2
        exit 1
fi

# prepare the address for iproute2
ADDR="$(echo $ADDR | tr '-' ':')"


# all set, do the work, "sh -e" is set
# shut the interface down  - see note [1] below
ip link set ${DEV} down
# create a managed interface on the same PHY
iw dev ${DEV} interface add ${TEMP_DEV} type managed
# assign new mac address to both interfaces
ip link set ${DEV} address ${ADDR}
ip link set ${TEMP_DEV} address ${ADDR}
# cycle the managed interface, so driver can register it's new address
ip link set ${TEMP_DEV} up
ip link set ${TEMP_DEV} down
# cleanup the temporary interface
iw dev ${TEMP_DEV} del
# bring original device up
#ip link set ${DEV} up

# all done
exit 0


# notes:
# [1] - this also serves as a workaround for a rfkill "bug" on iwlagn driver,
#       whenever rfkill module/option isn't available (kconfig option unset)
#       and the RFKILL hardware switch is turned off, the iwlagn driver
#       actually does BUG() call and renders the interface unable to power up
#       even though it appears like "up" to the system (LED remains off)
#       - one has to manually "set link down" and "set link up" to make it work
#       .. so this step actually ensures the interface is REALLY down
#       Q: does this mean some RFKILL functionality is in iwlagn itself?
#       A: yes, it "works" even without rfkill module / kernel builtin,
#          ath5k, for example, completely ignores the switch

Dále je možné si vytvořit řadu podobných skriptů - třeba takový, který vytvoří (a nesmaže) interface v managed módu, který bude mít stejnou MAC, jako jiný interface na stejném PHY (užitečné pro použití s iw na připojení se k AP):

#!/bin/sh -e

if [ -z "$2" ]
then
        echo "Makes a managed interface on the same PHY" 1>&2
        echo "as <dev> is on, copies it's MAC address from it" 1>&2
        echo "and brings it up, ie. for usage with \"iw connect\"" 1>&2
        echo 1>&2
        echo "Usage: $(basename $0) <newdev> <dev>" 1>&2
        exit 1
fi

NEWDEV="$1"
DEV="$2"


# optionally do an UID 0 check
# disabled: a user can have device access under special conditions
#[ "$UID" -ne 0 ] && exit 1

# check for device
dev_list="$(cat /proc/net/dev | grep -o '[^\ ]*:' | tr -d ':')"
found=0
for dev in $dev_list
do
        [ "$dev" = "$DEV" ] && found=1
done

if [ $found -lt 1 ]
then
        echo "error: Device ${DEV} not found" 1>&2
        exit 1
fi

# extract MAC address
# TODO: find a better way
ADDR="$(ip link show ${DEV} | grep "^\ *link" | awk '{print $2}')"


# all set, do the work, "sh -e" is set
# create a managed interface on the same PHY
iw dev ${DEV} interface add ${NEWDEV} type managed
# assign new mac address
ip link set ${NEWDEV} address ${ADDR}
# bring the new device up
ip link set ${NEWDEV} up

# all done
exit 0

A tak podobně dál a dál.

Proč? Využití?

No přece protože to jde! Ačkoli se mi takový airdrop-ng designem nelíbí (je to pythoní wrapper pro airodump/replay-ng) a má přebližně tolik bugů, jako airoscript-ng, jeho autor mě nadchnul moc pěkným nápadem - "osekáváním jablíček" ze stromu (sítě). Třeba to taky někdy zkusím

       

Komentáře

[rofl.rofl]

Pěkné, možná bys to mohl přidat i sem

[Jiří J.]

Přidávám aktualizovanou verzi skriptu - umí rozpoznat MAC adresy typu a:b:c:1:2:e a mění 2. argument (adresu) na nepovinný - pokud není adresa zadána, vygeneruje se náhodná (první byte má vždy nuly, moje intel karta tam nějak nestrpí nic jiného). Narazil jsem na neexistující $RANDOM v dashi, spíš než abych změnil interpreter nahoře na bash, rozhodl jsem se to vyřešit daleko šíleněji ... ale aspoň to funguje i mimo bash (SEED musí mít aspoň 10 znaků a-f 0-9):

# no MAC address specified, generate a random one
# -- sorry, no RANDOM variable in dash/sh :(
SEED="/dev/urandom"
rnd=$(tr -c -d a-f0-9 < ${SEED} | head -c10)
ADDR="00:${rnd%????????}:$(t=${rnd#??};echo ${t%??????}):$(t=${rnd#????};echo ${t%????}):$(t=${rnd#??????};echo ${t%??}):${rnd#????????}"

(ne, nebudu zase měnit všechny < a > v kódu, je to na paste2.org)

[virt6]

Jak tak koukám, tak Atheros je nejvíc Linux friendly ze všech wifi.

Comparison of open source wireless drivers

Neznáte někdo podobnou tabulku pro klasické Ethernet nechipy? Které síťovky nepotřebují nahrávat binární blob?

[David Heidelberg]

rozhodně realtek a intel jsou v pohodě. V podstatě jsem nenarazil na eth, která by to potřebovala...

[virt6]

bavíme se o ovladači nebo binárním firmware, který musí být zahrnut v jádře a nahrát se při každém spuštění do příslušné levné síťovky bez vlastní ROM paměti?

Já měl namysli firmware a nejsem si jist, jestli zrovna Realtek a Intel nejsou tento případ OSS ovladače, ale binárního firmwaru který je třeba při kažém použití nahrát.

[Jiří J.]

Pochopitelně mít v notebooku Atheros, byl bych šťasten, jak blecha. Problém je, že T500 má jednak miniPCI express (ne jen miniPCI) a jednak thinkpady nerozjedou jen tak ledajakou kartu (díky whitelistům v BIOSu). A sehnat Lenovo-posvědcenou Atheros kartu do miniPCI-e je v této republice nadlidský úkol.

[rofl.rofl]

jo? http://www.notebook-dily.cz/wifi-karty-expresscard/

[Jiří J.]

No jo .. a zkoušel někdo některou z těch karet (z tohoto shopu) v thinkpadu? Hodně lidí si "naslepo" takhle koupilo wifi karty a pak byli zaskočeni 1802 BIOS errorem. Ostatně - je o tom celá wiki page na thinkwiki.

Řešením je koupit si kartu přímo od lenova. Taková karta stojí asi o 50% víc (jo, je to hnusný marketingový tah) a u nás by se možná dala sehnat jedině přes speciální objednávku v některém z autorizovaných servisů lenova. Byl jsem tak schopen sehnat (NMB) US klávesnici pro svůj thinkpad.

[VSi]

Na T40 se tohle dalo řešit nějakým no-1802-cd. Fungovala mi tam pak bez problémů Atheros CM10. U nových thinkpadů už nic takového není?

[Jiří J.]

Z odkazované stránky na thinkwiki:

NOTE! On the R32, T43, X41, X60, W500 and probably others, the BIOS hacks and the "no-1802" utility don't work.

Obávám se, že T500 spadá do kategorie W500.

[VSi]

Aha. Ještě na některých MiniPCI kartách šlo zásahem do EEPROM změnit PCI-ID, takže pak ta karta byla k nerozeznání od originální IBM. Ale když jsem to zjišťoval, tak to šlo jen na některých kartách, a byla jistá pravděpodobnost zničení karty. A možná ty nové BIOSy to mají ošetřené ještě jinak. Tohle je od výrobců fakt hnus.

[rofl.rofl]

Ta AR5BXB72 prej jede v Lenovech X60, T60, T61, X61. Přinejhorším můžeš zajet do Kladna a domluvit se na otestování přímo v notebooku.

[the.max]

Poeditovat EEPROMku na MiniPCI (r52 a mozna cm9) budu zrejme zkouset v nejblizsi dobe. Pred tim ale jeste zkusim v BIOSu meho x41 zmenit tabulku s povolenymi PCI-ID. Mam sice a/b/g kartu, ale porad je to intel, radeji bych taky Atheros. Mam sice i CB9-EXT, ale jsem linej udrzovat 2 ruzne wifiny v provozu

[Drew]

A je nějaký důvod, proč už tohle nefunguje s vanilla kernelem? Vím že jsem se koukal na návody už tak před dvěma lety a už tenkrát bylo třeba patchovat jádro - to je to nelegální, nebo jenom těžké udělat tak, aby to nevadilo klasickému provozu?

[Jiří J.]

Problém asi nebude v driveru, jako v uzavřeném firmwaru (kdyby to bylo v driveru, nemusí se karta zapínat/vypínat pro "zaregistrování" nové adresy). Klasickému provozu to nevadí, měnit adresu tímto způsobem nepotřebuje každý BFU. Nebo jsem špatně pochopil pointu?