The problem

A few month ago i bought an rt73-base usb wifi dongle to make a low-cost access-point from my old linux box. Unfortunately i couldn't make it work until last week, when i finally figured out the root of the problem. First of all, i used the latest rt2x00 development kernel (how to get it), and the latest hostapd from the git repository. The official howto on the rt2x00 wiki is quite good, but it didn't work with my TL-WN321G wifi dongle, so i had to find out what's the problem. First the hostapd started up, and the clients could associate, but when i tried to send packages, the hostapd dropped error messages in an infinite loop:

wlan0: STA 00:12:f0:76:03:b9 IEEE 802.11: association OK (aid 1)
MGMT (TX callback) fail
mgmt::assoc_resp cb
wlan0: STA 00:12:f0:76:03:b9 IEEE 802.11: did not acknowledge association
response
Sending disassociation info to STA 00:12:f0:76:03:b9
MGMT (TX callback) fail
unknown mgmt cb frame subtype 10

Investigation

And then it reassociates with the client, does it again and again. So after few days spent on trying to figure out what is the problem, i found some interesting posts on hostapd, and rt2x00 mailing lists on this topic. The most interesting is this thread. The discussion is about three patch, and the first one is the important one. They say, that the driver can not ackowledge the completion of sending certain frames, because of hardware limitations. So, the case is, that the driver can't acknowledge these frames, but the hostapd wants an acknowledgement, or it won't function function properly.

The possible solutions

There are two solutions.

• Patch the driver to acknowledge the frames even if it is not sure that they have been succesfully sent.
• Patch hostapd to ignore the lack of acknowledgement.

The second one seems to be the easier way, so i have chosen to patch hostapd.

Patching hostapd

You have to comment out two lines in the ieee802_11.c file. Search for "did not acknowledge" in the file, and comment out the "return;" command after the lines that contain the "did not acknowledge" string. So after commenting out the return lines, the two blocks look like this:

 if (!ok) {
   hostapd_logger(hapd, mgmt->da, HOSTAPD_MODULE_IEEE80211,
                  HOSTAPD_LEVEL_NOTICE,
                  "did not acknowledge authentication response");
   //return;
}


if (!ok) {
   hostapd_logger(hapd, mgmt->da, HOSTAPD_MODULE_IEEE80211,
                  HOSTAPD_LEVEL_DEBUG,
                  "did not acknowledge association response");
   //return;
}

As you can see, now the hostapd will write in the log that the acknowledgement wasn't received, but the association and authentication will continue as if nothing wrong had happened. After patching the source it works, like a charm :)

I hope you can use this guide, and won't have to google for days like i did...

Elköltöztem. Ez a leírás itt olvasható a továbbiakban.

Bevezető

A múltkori torrentes bejegyzésben arról írtam, hogy hogyan lehet torrentezni olyan hálózatból, ahol elvileg le van tiltva a dolog. Azóta több ezren használják ezt a módszert (csak tipp, lehet hogy kevesebben :D ), viszont van egy apró hátránya: ha a hálózaton le van korlátozva a hálózati forgalom mennyisége, akkor az adott korlát elérése után nem fog működni a letöltés. Ezt is meg lehet kerülni, csak néhány feltételnek kell teljesülnie: 1. a hálózaton belüli forgalom ne legyen korlátozva 2. a nem korlátozott tartományban legyen egy SSH szerver, amelynek a forgalma nincs korlátozva 3. az SSH szerveren engedélyezve legyen a port forwarding. Ez mondjuk általában egyetemi kollégiumokban teljesül (vagy csak én gondolom így?), mert az egyetemeknek általában van legalább egy UNIX-os szerverük, amire a hallgatók bejelentkezhetnek (BME egyetemi: ural2.hszk.bme.hu, BME VIK-es: centaur.sch.bme.hu, ELTE-n KCSSK kolesz: csomalin.csoma.elte.hu, stb...). Még annyit hogy a leírás Linux-ra vonatkozik, viszont windows-on is megvalósítható a dolog, kis utánajárással bárki megcsinálhatja (a "Putty" SSH-kliens-ben kell megkeresni a linuxos klienssel azonos beállításokat). Ennyit a bevezetőről, lássuk:
 

Röviden a múltkori bejegyzésről

A dolog úgy kezdődik, hogy kell egy külső SSH szerver, amit SOCKS proxy-nak használunk majd. Csatlakozunk a szerverre a következő paranccsal:

ssh felhasználónév@szervercíme -D helyiport

A következő lépés a torrent-kliens beállítása, SOCKS proxy-nak beállítjuk a localhost-ot a helyi porttal párosítva. Torrent klienst újraindít -> letöltést beindít. Na ezt fogjuk most tovább bonyolítani :). Ez eddig így néz ki:

 

Az új felállás

Most a dolog úgy fog kinézni, hogy a kolin belüli SSH szerverhez csatlakozunk, ő fogja továbbítani az adatokat a külső SSH szervernek, és ez a külső SSH továbbítja a torrent kliens forgalmát az internet felé. Ezen a két csatornán keresztül fog menni a letöltés, vagyis mi csak a belső SSH szervernek küldünk adatokat, ez nem számít bele a forgalomkorlátozásba, és ő továbbítja az adatokat a külső szerverhez, anélkül hogy tudná milyen jellegű a forgalom, mert az is titkosítva van. Na ez kicsit bonyolultan hangzik, talán ábrával könnyebb megérteni:

Megvalósítás

Megvalósításhoz szükséges parancsok: (két külön terminált kell használni, és nem szabad bezárni őket!)

• ssh felhasznalonev1@szerver1.belsohalozat.hu -L 8888:szerver2.tavoliszerver.com:22

• ssh felhasznalonev2@localhost -p 8888 -D 7777

A parancsokban a szerver1.belsohalozat.hu a belső szervert (ábrán 'A'), a szerver2.tavoliszerver.com a külső szervert jelenti (ábrán 'B'), az ezekhez tartozó felhasználónév (felhasznalonev1, felhasznalonev2) értelemszerűen az adott szerveren használt felhasználóneved. A 8888 azt a helyi portot jelöli, amelyiken az első (ábrán vastag kék sávval jelölt) SSH csatorna elérhető: az ide csatlakozó programok forgalma valójában a szerver2.tavoliszerver.com 22-es portjára lesz átirányítva (ha a külső szerver ssh-ja más porton érhető el, akkor ide a megfelelő portszámot kell írni!). A második parancsban erre a portra csatlakozunk (-p 8888), és megadjuk, hogy a 7777-es porton nyisson egy újabb alagutat (-D 7777), ezt fogja a torrent program használni. Egyébként ez a második alagút más típusú mint az első, a különbség az, hogy az első típusú alagútnál minden forgalom egy adott géphez irányítódik (most a külső szerver), a másodiknál meg az SSH SOCKS proxyként működik, és az alagúton keresztül bármely címre lehet csatlakozni (pl. az ábrán látható disznóhoz). Nincs más hátra, mint beállítani a torrent programot, hogy használja a localhoston a 7777-es portot SOCKS proxyként (lsd. multkori leírás), és örülni :)
 

Zárszó

Igazából aki ezt megvalósítja, az már nagyon akar torrentezni :) minden tiszteletem az övé. Ha valaki kipróbálja a dolgot, kommentben tudassa pls., kiváncsi vagyok vannak-e ilyen elvetemültek :) .

A gonosz, torz lelkű rendszergazdák gyakran pusztán azért letiltják a torrentezést a hálózatukon, hogy szenvedést okozzanak a usereknek :). De az mindegy is hogy miért, a lényeg az hogy sok helyen nem fog működni a torrentezés, ezen viszont lehet segíteni. A windowsosoknak jó dolga van, mert már írt valaki egy jó leírást erről: http://torrentfreak.com/bittorrent-over-ssh-071014/ , aki linuxot használ annak meg még jobb :) mert könnyebb beállítani. Az utóbbiról fog szólni ez az írás.

1. SSH hozzáférés

Tehát először szereznünk kell valahol egy shell hozzáférést. Vannak ingyenesek is, de valószínűleg ezek elég lassúak lesznek, helyette én a nagyonolcsó fizetősöket ajánlanám, amiknek az ára havonta 1-2$. Én pl ezt használom, havi 1$ és nagyon gyors. Fizetni egyébként itt PayPal-on kell, ez elég biztonságos, nem fogják leemelni az összes pénzt a bankszámláról.

2. SSH csatlakozás

Ez valahogy így néz ki:

ssh felhasználónév@szervercíme -D helyipor

Kellhet még egy "-p szerverport" kapcsoló a végére, ha a szolgáltató nem az alapértelmezett 22-es portot használja (a fent említett szerver pl. a 2345-ös portot használja). A helyi port értéke 1024 és 65535 legyen, egyébként tetszőleges. A trükk a -D kapcsoló, mert ez utasítja az SSH-t, hogy a szerverrel létrejövő titkosított csatornán keresztül továbbítsa más programok hálózati forgalmát - pl. a torrent kliensét. Tehát a parancs beírása után már csak a jelszót kell beírni, ezután ezt az ablakot nem szabad bezárni, mert akkor megszakad az SSH kapcsolat!

3. Torrent kliens beállítása

A beállítások között a SOCKS proxy-t kell keresni, címnek localhost-ot kell beírni, port-nak meg a fentebb 'helyiport'-nak nevezett számot. Deluge-ban ez így néz ki (7777-es helyi porttal):

4. Örülni

Ezek után nem árt ujrainditani a torrentklienst, azután már mennie kell a dolognak, szóval lehet örülni :) .

UPDATE: Az írás folytatása megtalálható ITT