erdekes hiba (halozat, megszakad, post, zorp, tproxy)
A kovetkezo erdekes hibajelenseg tortenik mostanaban, egy olyan gepen ahol korabban is zorp (GPL) volt, a hiba nem tudom, volt-e korabban is. Tehat: Ha a user post metodussal kuldd dolgokat, akkor csak bizonyos felhasznaloknak, de azoknak tobbnyire, megszakad a letoltott adat. Konkretan: egy kb. 6 kilobyte-os POST request meg a zorpnak. A zorp egy IIS-nek adja tovabb a dolgokat, ami 'belul fut', az iis feldolgozza es valaszol, a zorp a log szerint kiadja a 28 kilobyteos valaszt a kliens viszont csak kb 4-16 kilobyteot kap meg, altalaban Nx4k kozeleben levo mennyiseget, majd megszakad a kapcsolat (server reset bites csomagot kuld). Tovabbi ismervek: lecsereltem a zorp-ot 2.1.7-re, korabban 2.0.2 volt, mindkettonel ez a helyzet A zorp transparent proxy modban van, 2.4.27 + cttproxy legujabb fut, tegnap meg 2.4.26 es a regebbi cttproxy. a megszakadas ugy latom foleg lassabb, pl. adsl-es vonalakon tortenik, azaz mintha a letoltesi idonek lenne koze a dologhoz. Az atvitt adamennyiseg kb. a tcp window size-nak felel meg. azaz mintha a zorp telepakolna a tcp windowt, aztan megszakitana a kapcsolatot, ami a window-ban volt, az meg atmegy, de a keres vege mar nem A korai kapcsolatmegszakitas osszefuggesben lehet azzal, hogy POST metodus volt: A POST miatt a belso IIS 5.x MINDIG visszaad 100-Continue headert. Lehet, hogy ilyenkor valamiert a zorp mashogy zarja le a kapcsolatot, es tul koran tortenik a lezaras, majd a windows meg kiurul, de mas mar nem? Lehet koze hozza a tproxynak esetleg? Bar az a belso oldal, es a belso oldalon a zorp es az iis kozott tokeletes az adatatvitel, minden byte atmegy. a userek egyebkent " a lap nem megjelenitheto" hibara panaszkodtak, aztan errol derult ki a fenti helyzet -egyes usereknel (proxy mogott, gyors gepen, mittomen), nem jelentkezik a hiba. A http headereknel nem lattam mas zurt.. Az IIS-ben a Continue header kuldeset nem tudom, hogy kell kikapcsolni, ha egyaltalan lehetne, igy azt nem tudtam tesztelni. boldizsar ui: kerlek cc-zetek a cimemre -------------------------------- Bencsath Boldizsar boldi@mail2003.etl.hu --------------------------------
On Mon, 2004-08-09 at 15:12, Bencsath Boldizsar wrote:
A kovetkezo erdekes hibajelenseg tortenik mostanaban, egy olyan gepen ahol korabban is zorp (GPL) volt, a hiba nem tudom, volt-e korabban is. Tehat:
Ha a user post metodussal kuldd dolgokat, akkor csak bizonyos felhasznaloknak, de azoknak tobbnyire, megszakad a letoltott adat. Konkretan:
Kene rola legalabb 7-es loglevelen logreszlet az adott kapcsolatrol, illetve teljes tcpdump a tuzfal kulso es belso laban is! MCS
Major Csaba <major@balabit.hu> irta:
Ha a user post metodussal kuldd dolgokat, akkor csak bizonyos felhasznaloknak, de azoknak tobbnyire, megszakad a letoltott adat. Konkretan: na, most lehet, hogy hülyeséget fogok mondani, mert nem ismerem a teljes helyzetet, bár mindenre kitérő volt a hiba ismertetése. Szóval, a HUP-on volt nemrégen egy olyan probléma ,hogy a a 2.6 (tudom) legujabb verziójával volt egy TCP window hiba, ami miatt sok weboldal nem volt megjeleníthető, mert valami alapbeállítással valamit elkeffentettek a kernel fejlesztők. Ismétlem, nem emlékszem 100%-ig, hogy mi volt, de hasonló hibajelenség volt a felhasználói oldalon, valamint ott is a TCP window hibája fordult elő. HUP fórum archívumában lehet rá keresgélni.
üdv, Ago
On Fri, 2004-08-27 at 00:28, Deim Agoston wrote:
Major Csaba <major@balabit.hu> irta:
Ha a user post metodussal kuldd dolgokat, akkor csak bizonyos felhasznaloknak, de azoknak tobbnyire, megszakad a letoltott adat. Konkretan: na, most lehet, hogy hülyeséget fogok mondani, mert nem ismerem a teljes helyzetet, bár mindenre kitérő volt a hiba ismertetése. Szóval, a HUP-on volt nemrégen egy olyan probléma ,hogy a a 2.6 (tudom) legujabb verziójával volt egy TCP window hiba, ami miatt sok weboldal nem volt megjeleníthető, mert valami alapbeállítással valamit elkeffentettek a kernel fejlesztők. Ismétlem, nem emlékszem 100%-ig, hogy mi volt, de hasonló hibajelenség volt a felhasználói oldalon, valamint ott is a TCP window hibája fordult elő. HUP fórum archívumában lehet rá keresgélni.
nem a Linuxban volt a hiba, hanem bizonyos routerekben, es egeszen pontosan a window scale opcio hasznalata okozta a problemat. Alapbol a window scale opcio segitsegevel az eredetinel joval nagyobb TCP ablakmeretek erhetok el, viszont vannak olyan routerek, amik a window-scale-t kinullazzak, igy mast tud a window meretrol a kliens, es a szerver. -- Bazsi
Mellékelek tcpdumpot és a logfájlt 15-ös szinttel, sajna két külön mérés, de a lényeget ez egyáltalán nem befolyásolja amennyire látom. A folyam mindig máshol szakad meg, ha gyorsan bír menni az adat a szerverről, akkor azt hiszem kevésbé, van, hogy végigmegy. Ami érdekes, az az alábbi, ami mutatja, hogy a zorp "data line" sorai szépen tartanak a </html> részig. Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/server): data line: 6D 6C 3E 0A 0A ml>.. Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): Writing channel; fd='15', count='85' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): data line: 63 3D 31 22 20 77 69 64 74 68 3D 22 31 22 20 68 c=1" width="1" h Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): data line: 65 69 67 68 74 3D 22 31 22 3E 0A 3C 2F 4E 4F 53 eight="1">.</NOS Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): data line: 43 52 49 50 54 3E 0A 3C 21 2D 2D 20 4D 45 44 49 CRIPT>.<!-- MEDI Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): data line: 41 4E 20 57 45 42 41 55 44 49 54 20 45 4E 44 20 AN WEBAUDIT END Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): data line: 2D 2D 3E 0A 3C 2F 62 6F 64 79 3E 0A 3C 2F 68 74 -->.</body>.</ht Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): data line: 6D 6C 3E 0A 0A ml>.. Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/server): Reading channel; fd='18', count='0' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http): eofmask updated; old_mask='0006', eof_mask='003f' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http): exiting keep-alive loop; Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http): calling __shutdown__() event; Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http): calling shutDown() event; Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http): calling __destroy__() event; Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http): Proxy destroy; class='InHttp', module='http' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): Shutdown channel; fd='15', mode='2' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): Closing channel; fd='15' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/server): Shutdown channel; fd='18', mode='2' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/server): Closing channel; fd='18' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http): Proxy ending; class='InHttp', module='http' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0): Ending proxy instance; a belso tcpdump rész így talán lényegtelen is, a fontos, hogy az adat a zorpig megjön. ellenben ekkor ugye a belso lezárja a kapcsolatot: 00:09:44.327607 0:4:75:cf:df:8d 0:d0:b7:b7:7a:75 0800 54: 1.2.3.4.49820 > 10.1.6.1.80: . ack 28371 win 35040 (DF) 00:09:44.418416 0:d0:b7:b7:7a:75 0:4:75:cf:df:8d 0800 60: 10.1.6.1.80 > 1.2.3.4.49820: F 28371:28371(0) ack 4116 win 64993 (DF) 00:09:44.457643 0:4:75:cf:df:8d 0:d0:b7:b7:7a:75 0800 54: 1.2.3.4.49820 > 10.1.6.1.80: . ack 28372 win 40880 (DF) 00:09:44.682136 0:4:75:cf:df:8d 0:d0:b7:b7:7a:75 0800 54: 1.2.3.4.49820 > 10.1.6.1.80: F 4116:4116(0) ack 28372 win 40880 (DF) 00:09:44.682228 0:d0:b7:b7:7a:75 0:4:75:cf:df:8d 0800 60: 10.1.6.1.80 > 1.2.3.4.49820: . ack 4117 win 64993 (DF) és kb ugyenkkor, .68-kor a külső kapcsolat is változik, megkapja a maga R flagjét, és mig bent kb. 28kb ment át addig kifele már csak a 20k megy át. 00:09:44.574709 0:d0:b7:89:4f:95 0:d0:2:e0:47:fc 0800 1514: 195.228.75.150.80 > 1.2.3.4.2529: . 19189:20649(1460) ack 4118 win 14600 (DF) 00:09:44.681853 0:d0:b7:89:4f:95 0:d0:2:e0:47:fc 0800 54: 195.228.75.150.80 > 1.2.3.4.2529: R 20649:20649(0) ack 4118 win 14600 (DF) 00:09:44.720159 0:d0:2:e0:47:fc 0:d0:b7:89:4f:95 0800 60: 1.2.3.4.2529 > 195.228.75.150.80: . ack 14649 win 6000 (DF) 00:09:44.720268 0:d0:b7:89:4f:95 0:d0:2:e0:47:fc 0800 54: 195.228.75.150.80 > 1.2.3.4.2529: R 1163771020:1163771020(0) win 0 (DF) 00:09:44.720231 0:d0:2:e0:47:fc 0:d0:b7:89:4f:95 0800 60: 1.2.3.4.2529 > 195.228.75.150.80: . ack 16109 win 6000 (DF) 00:09:44.720303 0:d0:b7:89:4f:95 0:d0:2:e0:47:fc 0800 54: 195.228.75.150.80 > 1.2.3.4.2529: R 1163772480:1163772480(0) win 0 (DF) 00:09:44.720417 0:d0:2:e0:47:fc 0:d0:b7:89:4f:95 0800 60: 1.2.3.4.2529 > 195.228.75.150.80: . ack 17569 win 6000 (DF) 00:09:44.720442 0:d0:b7:89:4f:95 0:d0:2:e0:47:fc 0800 54: 195.228.75.150.80 > 1.2.3.4.2529: R 1163773940:1163773940(0) win 0 (DF) 00:09:44.720465 0:d0:2:e0:47:fc 0:d0:b7:89:4f:95 0800 60: 1.2.3.4.2529 > 195.228.75.150.80: . ack 19029 win 6000 (DF) 00:09:44.720489 0:d0:b7:89:4f:95 0:d0:2:e0:47:fc 0800 54: 195.228.75.150.80 > 1.2.3.4.2529: R 1163775400:1163775400(0) win 0 (DF) 00:09:44.728346 0:d0:2:e0:47:fc 0:d0:b7:89:4f:95 0800 60: 1.2.3.4.2529 > 195.228.75.150.80: . ack 20649 win 6000 (DF) 00:09:44.728372 0:d0:b7:89:4f:95 0:d0:2:e0:47:fc 0800 54: 195.228.75.150.80 > 1.2.3.4.2529: R 1163777020:1163777020(0) win 0 (DF) Próbáltam a window scaling mindkét oldali kikapcoslását, de az nem segített, hasonló módon a zorpos gép tcp paramétereinek állítgatása sem hozott jelentős változásokat. egyébként 2.4.27 + patchek, pl. grsecurity, tproxy amiben ugye lehetnek patch-összefüggések is. Mindenesetre ha van ötletetek ezalapján, örömmel veszem. -------------------------------- Bencsath Boldizsar boldi@mail2003.etl.hu -------------------------------- On Wed, 25 Aug 2004, Major Csaba wrote:
On Mon, 2004-08-09 at 15:12, Bencsath Boldizsar wrote:
A kovetkezo erdekes hibajelenseg tortenik mostanaban, egy olyan gepen ahol korabban is zorp (GPL) volt, a hiba nem tudom, volt-e korabban is. Tehat:
Ha a user post metodussal kuldd dolgokat, akkor csak bizonyos felhasznaloknak, de azoknak tobbnyire, megszakad a letoltott adat. Konkretan:
Kene rola legalabb 7-es loglevelen logreszlet az adott kapcsolatrol, illetve teljes tcpdump a tuzfal kulso es belso laban is!
MCS
On Tue, 2004-09-21 at 00:35, Bencsath Boldizsar wrote:
Mellékelek tcpdumpot és a logfájlt 15-ös szinttel, sajna két külön mérés, de a lényeget ez egyáltalán nem befolyásolja amennyire látom. A folyam mindig máshol szakad meg, ha gyorsan bír menni az adat a szerverről, akkor azt hiszem kevésbé, van, hogy végigmegy. Ami érdekes, az az alábbi, ami mutatja, hogy a zorp "data line" sorai szépen tartanak a </html> részig.
szerintem sajnos egyaltalan nem mindegy, hogy mi van a zorp logjaban, a tcpdump-pal egyidoben, igy nagyon nehez kielemezni a pontos okot. jol ertem, hogy a felallas igy nez ki? kliens -- internet -- zorp -- szerver a kliens IP-je: 1.2.3.4, a zorp kulso laba 195.228.75.150, a szerver pedig 10.1.6.1 elo tudod kaparni azt a logot, ami a tcpdumpnak megfelelo idopontbol van? (meg akkor is, ha az nem -v15-os) (amugy a -v10 a legnagyobb ertek)
Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/server): data line: 6D 6C 3E 0A 0A ml>.. Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): Writing channel; fd='15', count='85' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): data line: 63 3D 31 22 20 77 69 64 74 68 3D 22 31 22 20 68 c=1" width="1" h Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): data line: 65 69 67 68 74 3D 22 31 22 3E 0A 3C 2F 4E 4F 53 eight="1">.</NOS Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): data line: 43 52 49 50 54 3E 0A 3C 21 2D 2D 20 4D 45 44 49 CRIPT>.<!-- MEDI Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): data line: 41 4E 20 57 45 42 41 55 44 49 54 20 45 4E 44 20 AN WEBAUDIT END Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): data line: 2D 2D 3E 0A 3C 2F 62 6F 64 79 3E 0A 3C 2F 68 74 -->.</body>.</ht Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): data line: 6D 6C 3E 0A 0A ml>.. Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/server): Reading channel; fd='18', count='0' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http): eofmask updated; old_mask='0006', eof_mask='003f' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http): exiting keep-alive loop; Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http): calling __shutdown__() event; Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http): calling shutDown() event; Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http): calling __destroy__() event; Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http): Proxy destroy; class='InHttp', module='http' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): Shutdown channel; fd='15', mode='2' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/client): Closing channel; fd='15' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/server): Shutdown channel; fd='18', mode='2' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http/server): Closing channel; fd='18' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0/http): Proxy ending; class='InHttp', module='http' Sep 20 23:51:18 etl zorp_http[20627]: (zorp_http@boldi@etl.hu/in_http:0): Ending proxy instance;
a belso tcpdump rész így talán lényegtelen is, a fontos, hogy az adat a zorpig megjön. ellenben ekkor ugye a belso lezárja a kapcsolatot: 00:09:44.327607 0:4:75:cf:df:8d 0:d0:b7:b7:7a:75 0800 54: 1.2.3.4.49820 > 10.1.6.1.80: . ack 28371 win 35040 (DF) 00:09:44.418416 0:d0:b7:b7:7a:75 0:4:75:cf:df:8d 0800 60: 10.1.6.1.80 > 1.2.3.4.49820: F 28371:28371(0) ack 4116 win 64993 (DF) 00:09:44.457643 0:4:75:cf:df:8d 0:d0:b7:b7:7a:75 0800 54: 1.2.3.4.49820 > 10.1.6.1.80: . ack 28372 win 40880 (DF) 00:09:44.682136 0:4:75:cf:df:8d 0:d0:b7:b7:7a:75 0800 54: 1.2.3.4.49820 > 10.1.6.1.80: F 4116:4116(0) ack 28372 win 40880 (DF) 00:09:44.682228 0:d0:b7:b7:7a:75 0:4:75:cf:df:8d 0800 60: 10.1.6.1.80 > 1.2.3.4.49820: . ack 4117 win 64993 (DF)
és kb ugyenkkor, .68-kor a külső kapcsolat is változik, megkapja a maga R flagjét, és mig bent kb. 28kb ment át addig kifele már csak a 20k megy át.
00:09:44.574709 0:d0:b7:89:4f:95 0:d0:2:e0:47:fc 0800 1514: 195.228.75.150.80 > 1.2.3.4.2529: . 19189:20649(1460) ack 4118 win 14600 (DF) 00:09:44.681853 0:d0:b7:89:4f:95 0:d0:2:e0:47:fc 0800 54: 195.228.75.150.80 > 1.2.3.4.2529: R 20649:20649(0) ack 4118 win 14600 (DF) 00:09:44.720159 0:d0:2:e0:47:fc 0:d0:b7:89:4f:95 0800 60: 1.2.3.4.2529 > 195.228.75.150.80: . ack 14649 win 6000 (DF) 00:09:44.720268 0:d0:b7:89:4f:95 0:d0:2:e0:47:fc 0800 54: 195.228.75.150.80 > 1.2.3.4.2529: R 1163771020:1163771020(0) win 0 (DF) 00:09:44.720231 0:d0:2:e0:47:fc 0:d0:b7:89:4f:95 0800 60: 1.2.3.4.2529 > 195.228.75.150.80: . ack 16109 win 6000 (DF) 00:09:44.720303 0:d0:b7:89:4f:95 0:d0:2:e0:47:fc 0800 54: 195.228.75.150.80 > 1.2.3.4.2529: R 1163772480:1163772480(0) win 0 (DF) 00:09:44.720417 0:d0:2:e0:47:fc 0:d0:b7:89:4f:95 0800 60: 1.2.3.4.2529 > 195.228.75.150.80: . ack 17569 win 6000 (DF) 00:09:44.720442 0:d0:b7:89:4f:95 0:d0:2:e0:47:fc 0800 54: 195.228.75.150.80 > 1.2.3.4.2529: R 1163773940:1163773940(0) win 0 (DF) 00:09:44.720465 0:d0:2:e0:47:fc 0:d0:b7:89:4f:95 0800 60: 1.2.3.4.2529 > 195.228.75.150.80: . ack 19029 win 6000 (DF) 00:09:44.720489 0:d0:b7:89:4f:95 0:d0:2:e0:47:fc 0800 54: 195.228.75.150.80 > 1.2.3.4.2529: R 1163775400:1163775400(0) win 0 (DF) 00:09:44.728346 0:d0:2:e0:47:fc 0:d0:b7:89:4f:95 0800 60: 1.2.3.4.2529 > 195.228.75.150.80: . ack 20649 win 6000 (DF) 00:09:44.728372 0:d0:b7:89:4f:95 0:d0:2:e0:47:fc 0800 54: 195.228.75.150.80 > 1.2.3.4.2529: R 1163777020:1163777020(0) win 0 (DF)
Próbáltam a window scaling mindkét oldali kikapcoslását, de az nem segített, hasonló módon a zorpos gép tcp paramétereinek állítgatása sem hozott jelentős változásokat. egyébként 2.4.27 + patchek, pl. grsecurity, tproxy amiben ugye lehetnek patch-összefüggések is. Mindenesetre ha van ötletetek ezalapján, örömmel veszem.
-------------------------------- Bencsath Boldizsar boldi@mail2003.etl.hu --------------------------------
On Wed, 25 Aug 2004, Major Csaba wrote:
On Mon, 2004-08-09 at 15:12, Bencsath Boldizsar wrote:
A kovetkezo erdekes hibajelenseg tortenik mostanaban, egy olyan gepen ahol korabban is zorp (GPL) volt, a hiba nem tudom, volt-e korabban is. Tehat:
Ha a user post metodussal kuldd dolgokat, akkor csak bizonyos felhasznaloknak, de azoknak tobbnyire, megszakad a letoltott adat. Konkretan:
Kene rola legalabb 7-es loglevelen logreszlet az adott kapcsolatrol, illetve teljes tcpdump a tuzfal kulso es belso laban is!
MCS
-- Bazsi
participants (5)
-
Balazs Scheidler
-
Bencsath Boldizsar
-
Bencsath Boldizsar
-
Deim Agoston
-
Major Csaba