Nemrég Mark Lord jelezte az LKML-en, hogy a kiadás előtt álló 2.6.17-es kernellel nem tudja olvasni a www.everymac.com-ot. Miután elvégzett egy csomó tesztet, behatárolta, hogy a problémát egy nemrég felbukkant, "set default max buffers from memory pool size" nevű patchset okozza. John Heffner válaszul azt írta, hogy valószínűleg Mark gépe és a szóban forgó webszerver közt egy hibás (lásd a korábbi cikk) gép van, amelyet javítani kellene. Addig Mark a problémára a window scaling tiltását használhatja workaround-ként.
Linus megjegyezte a problémával kapcsolatban, hogy lehet, hogy nem kellene feltétlenül alapértelmezetten engedélyezniük a window scaling-et, vagy ha igen, akkor ki kellene dolgozni egy eljárást, amely észleli, ha az valamilyen oknál fogva az nem alkalmazható.
David Miller válaszában megjegyezte, hogy a window scaling már hosszú ideje alapértelmezetten engedélyezett, de csak 1-es vagy 2-es faktorral használták eddig. Továbbá válaszában megjegyezte, hogy nem lehetséges a hibás gépek detektálása és a window scaling kikapcsolása azután, hogy azt a kommunikációban résztvevő felek megbeszélték. Ezen kívül megjegyezte, hogy a window scaling 14 éve szabványosított és itt van körünkben azóta, amióta 1992. májusában publikálták az RFC1323-ban. Feltette a kérdést, hogy vajon mennyi ideig kellene még várni arra, hogy egyesek megfelelően használják?
A KernelTrap cikke itt.
Összefoglalva: ha valaki 2.6.17-rc5-ös vagy annál újabb kerneleket* használ, akkor alapértelmezetten problémája lehet olyan oldalak böngészésekor (vagy más szolgáltatások elérésekor), amelyeket úgy ér el, hogy közte és az oldal közt hibásan működő csomagszűrő / router található. Ha ilyen oldallal találkozik, akkor workaround-ként használhatja a következőt:
root@alderaan:/home/trey# echo "0" > /proc/sys/net/ipv4/tcp_window_scaling
vagy
root@alderaan:/home/trey# sysctl -w net.ipv4.tcp_window_scaling=0
net.ipv4.tcp_window_scaling = 0
Az aktuális érték lekérdezése:
root@alderaan:/home/trey# cat /proc/sys/net/ipv4/tcp_window_scaling
0
Maradandó beállítást a /etc/sysctl.conf-ban lehet elvégezni.
* Én 2.6.17-rc5-ös kernellel tapasztaltam azt a problémát, amelyet a www.everymac.com-mal kapcsolatban írtak. Korábbi -rc verziókkal is jelentkezhet a probléma, de azokkal nem teszteltem. Megjegyzem, hogy a 2.6.17-rc5-ös kernelt május 29-e óta használom probléma nélkül, és ha nem hívják fel a figyelmet a problémára, akkor valószínűleg észre sem veszem. Magyarul, valószínűleg meglehetősen kevés oldal (szerver, szolgáltatás) érintett a problémában.
- A hozzászóláshoz be kell jelentkezni
- 2595 megtekintés
Hozzászólások
Azt hiszem ez nem csak linuxoknál jelenthet problémát, hanem szinte minden oprendszeren, ahol ez default be van kapcsolva.
- A hozzászóláshoz be kell jelentkezni
Miért csak a webbel kapcsolatban van erről szó? (trey írtad, hogy nem láttál még ilyen _weblapot_?)
A többi szolgáltatási protokollal is előjön ez? (pld ftp, de bármi is lehetne)
- A hozzászóláshoz be kell jelentkezni
A többi szolgáltatási protokollal is előjön ez?
Persze, hogy igen... ;)
- A hozzászóláshoz be kell jelentkezni
Mert valószínűleg ott fogom először észrevenni. Mint ahogy annak idején a HUP-nál is a web-nél vették észre, és most is egy weboldalnál vették észre. Az, meg hogy nem csak webet érint, azt hiszem egyértelmű. Aki megérti, hogy mi van a cikkben leírva, annak meg nem is kell magyarázni. Aki meg nem érti, annak meg tök mindegy.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Nekem vannak ilyen problémáim mostanság, de gőzöm sincs, h mi a gond. Van 1 pár gép itthon, mindenféle OS-ek, és adott weboldalak sehonnan sem jönnek be, némelyik bejön, de hibásan... stb. Akartam a router-re új firmware-t tenni, az Edimaxnak asszem nyílt forráskódú, unix-szerű firmware-e van, de az edimax.com sem jön be. Google sokmindent talál, de onnan meg szinte egy sem nyílik meg. Lehet, h SUX-Online para, de nekem nem teccik így.
- A hozzászóláshoz be kell jelentkezni
ha ADSL-ed van, akkor lehet MTU ertket kellene jol beloni
- A hozzászóláshoz be kell jelentkezni
Szinten hasonlo hibakat tud okozni az ECN nemismerete is, amugy :)
- A hozzászóláshoz be kell jelentkezni
FreeBSD-n kb 4 eve tortent hasonlo, szinten rfc1223 miatt. FreeBSD <-> barmi teljesen jol mukodott, viszont FreeBSD <-> FreeBSD csigalassu adatforgalom. Szoltam szolgaltatonak, de nem igazan tudtak mit csinalni vele, ugyhogy vegul ki lett kapcsolva a szerveren.
- A hozzászóláshoz be kell jelentkezni
Amikor ez a probléma jelentkezett a HUP-pal (FreeBSD), akkor ki lett kapcsolva a
"net.inet.tcp.rfc1323". Utána nem volt probléma. Ha valahol ilyen probléma van útközben, akkor érdemes a szerveren kikapcsolni a window scaling-et. Persze csak akkor, ha nincs mód a javításra (mert más kezeli a hibás box-ot).
A HUP-on egyébként most is 0 az "net.inet.tcp.rfc1323" sysctl érték, úgyhogy a HUP-pal biztos nem lesz ilyen problémája senkinek.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni