"HUP bug": TCP window scaling és a hibás routerek

A levélre Stephen Hemminger azt válaszolta, hogy David S. Miller a legújabb kernelekben engedélyezte a TCP window scaling opciót, amely okozhatja ezt a hibát. Közben nekem privátban megírták, hogy nem csak a HUP nem megy ezekkel a kernelekkel, hanem gondok vannak a packages.gentoo.org oldallal is. Folyt a debug-olás, mikor John Heffner jelezte, hogy neki volt már egy évvel ezelőtt hasonló tapasztalata. Akkor a gondot a távoli gép előtt levő régi OpenBSD csomagszűrő okozta, amely megcsonkította a TCP csomagokban levő window scale opciót. Ekkor terelődött a gyanú a HUP előtt levő OpenBSD csomagszűrőre. Elképzelhető, hogy az nem tudja kezeli a TCP window scaling-et. Ekkor kiderült, hogy a Gentoo oldal is egy meglehetősen régi (2.4.20-as) Linux kernelt futtat, amely szintén gyanúsítható azzal, hogy rosszul kezeli ezt a TCP opciót.
Mivel nem csak ez a két gép érintett ebben a problémában (hiszen számos más tűzfal terméket használnak az emberek az interneten), Stephen Hemminger elkészített egy patchet, amely orvosolhatja a hibát. A patch kiszámítja azt a TCP window scaling értéket, amely a lehetséges legnagyobb TCP ablakot adja úgy, hogy a hálózat még működik. A legtöbb esetben a patch a net.ipv4.tcp_default_win_scale értékét 2-re állítja, amely még működik a hibás routerekkel, tűzfalakkal. Sajnos a patch David S. Miller és a TCP alrendszer fejlesztői által elvetésre kerültek (thread). A fejlesztők álláspontja az, hogy a hibás tűzfalak működését kompenzáló workaround hozzáadása a Linux kernelhez hiba lenne. Szerintük a megoldás az, hogy nyomást kell gyakorolni a router gyártókra, hogy azok javítsák ki a hibás ``termékeiket''. Úgy gondolják, hogy a Linuxnak van akkora súlya már a hálózati világban, hogy képes hatni a gyártókra. Egyébként a TCP window scaling nem új találmány. Minden TCP csomag fejlécében található egy window mező. A window egy olyan flow control a TCP-ben, amely meghatározza, hogy mekkora a maximálisan átvihető adat mérete a kommunikációban részt vevő hostok között, mekkora a maximális adat méret, amelyet a ``másik oldal'' fogadni képes. A TCP gyerekkorában ez a window érték meglehetősen kicsi volt, mert a gépek limitált memória mérettel rendelkeztek (nem voltak képesek nagy mennyiségű adatot pufferelni), és a hálózati eszközök sem voltak olyan kifinomultak és nagy teljesítményűek, mint manapság. A modern eszközök már képesek a nagyobb TCP csomagok fogadására és hatékony kezelésére, ezért a nagyobb teljesítmény elérése érdekében nagyobb TCP window értéket is használhatunk.
A TCP window mező szélessége 16 bitnyi, így a maximális window méret 64 kbyte lehet. A TCP dizájnerek soha nem gondolták, hogy bárkinek is szüksége lehet ennél nagyobb értékre. A 64 kbyte pedig úgy tűnik nem elég napjainkban, valahogy emleni kellene ezt az értéket. A megoldást a TCP window scaling jelenti, amely már 1992 óta létező dolog. A TCP window scaling leírását az RFC1323 fogja össze. Ezzel az eljárással a kommunkációban levő felek nagyobb adatmennyiséget is átvihetnek egymás közt, akkor ha ezt ``megbeszélik''.
Annak érdekében, hogy a TCP window scaling-et nem ismerő gépek TCP rendszerében ez ne okozzon hibát, a kommunikáció kezdeti szakaszában egy SYN csomagban elküldésre kerül a TCP window scaling opció, és csak akkor kerül alkalmazásra, ha a válaszként visszajövő SYN+ACK csomag szintén tartalmazza ezt az opciót. Maga a scale faktor (hogy mekkora legyen a windows scaling) megbeszélése a setup handshake része, az a későbbiekben nem kerül módosításra.

A probléma ott kezdődik, mikor a kommunikációban részt vevő felek között elhelyezkedik egy hibás router. Vannak olyan routerek, amelyek megváltoztatják a rajtuk keresztül haladó window scale TCP opciót a SYN csomagokban. Az eredmény: a két host között káosz lesz, mert nem tudják egyeztetni a window scaling mértékét. A feltevés az, hogy a hibás router kicserélni a küldött windows scaling értéket 0-ra, de az opciót a helyén hagyja. A ``vevő'' gép érzékeli, hogy van window scaling, el is küldi a saját értékét. A ``küldő'' gép látja, hogy a window scaling elfogadásra került, meg is kezdi a window scaling-et ennek megfelelően. Mivel a ``vevő'' gép azt hiszi, hogy a scaling 0 (mert a router kicserélte az eredeti értéket), az egészből egy össze-visszaság alakul ki.

Térjünk vissza az elejére. Tehát a Linux kernel újabb verzióiban a window scaling értéke 7. A te gépet ezt az értéket küldi a SYN csomagban, (valószínűleg) a HUP előtti csomagszűrő ezt átírja 0-ra, de meghagyja az beállított értéket. A HUP azt hiszi, hogy van window scaling, elküldi a saját scaling faktorát. A te géped azt hiszi, hogy minden OK, el is kezdi a window scaling-et. A probléma az, hogy a HUP azt hiszi, hogy 0 a window scaling, és ennek megfelelően viselkedik.
A megoldás, frissíteni kell a HUP előtti csomagszűrőt (ami meg is fog történni a közeljövőben).

Workaround: ki kell kapcsolni a problémás kernelekben a window scaling opciót. Ezt a net.ipv4.tcp_default_win_scale érték megváltoztatásával lehet elérni az alábbi módon (root-ként természetesen):

sysctl -w net.ipv4.tcp_default_win_scale=0
(tapasztalat szerint az 1 és 2 értékkel még működik)

Maradandó beállítást a /etc/sysctl.conf-ban lehet elkövetni.

A dologgal foglalkozik az LWN-net is itt.