Egyszer szivtam hasonloval.
Akkor a megoldas az volt, hogy a kulonbozo alhalozatoknak kulonbozo volt a maximalis csomagmerete, olyan 4 byte volt a kulonbseg. Ilyenkor az a halozat, akinek kisebb, detektalja a hibat, es visszakuld egy uzenetet, hogy kisebb csomagot szeretne. A problema ezzel az volt, hogy a firewall olyan paranoidra volt konfiguralva, hogy ezeket az uzeneteket sem engedte at :-).
Az eredmeny az volt, hogy ha 1500 byte alatti volt a dolog, amit mozgatni akartal, akkor gyonyoruen megallt, ha meg nagyobb, akkor elkezdodott a kommunikacio, es megszakadt, es vart es vart. Az egyik gep arra, hogy megkapja a visszajelzest a csomagokrol , amiket elkuldott, a masik meg arra, hogy megjojjenek a csomagok kisebbre szabdalva.
Probald ebbol a szempontbol is nezni a halodat.
Adott egy igen csunya hiba, es gyakorlatilag nincs mar tippem az okara.
Adott egy smtp server ami furmanyos tunnelen, ipfwadm filteren, meg ip forwardon keresztul latja a vilagot. A dolog jol be van love, de kizarolag ket geprol:
A duna.pronet.hu es a cnn.com -rol nem birnak megjonni a levelek.
Elkezd jonni(sniffit mutatja a fel levelet) es megall. Var,var,var, majd timeout. Ez megy egesz nap. Es minden mas site-rol jo a letoltes.
A lokalis halozatban van egy kliens gep. O ezen az smtp serveren (sendmail 8.9.3) nem tud kuldeni leveleket, de mas, a lokalis vagy tavoli halozaton levo gepen keresztul sem. Semmilyen programbol. Mashonnan,lanrol, vagy modemrol tud kuldeni.
Az effekt ugyanaz: megall a kuldes es timeout. A lokalis haloban switch van, VLAN is elofordul. oda vissza DNS a gepre jol be van allitva, bar belso IP-je van. A traceroute szerint is kozvetlenul eri el az smtp szervert.
Tippem sincs mi lehet a gond, mert mas gepnel, mint a fenti 3 nincs semmi gond.
Akinek van tippje, szoljon. En low level tcp/ip gondokra gyanakszom a VLAN-nal osszefuggesben.
