ADSL - Problem sa web browsing-om, greške u prenosu

[Dandy]

U poslednjih par nedelja mi se često događa da prilikom browse-ovanja dobijam oštećene web strane, čak su mi i slike nekada pune grešaka. Problem je izraženiji kod nekih sajtova, npr IMDB, TV.com itd. , gde moram da uradim refresh nekoliko puta da bih uopšte dobio stranicu u celosti (često u browser-u vidim samo deo HTML koda koji je stigao do mene).
Na net idem preko SezamPro ADSL-a.
Problem se ispoljava u bilo kom web browser-u (probao sam Firefox i IE), a interesantno je da kada koristim Sezamov proxy, sve radi ok, što bi trebalo da bude indikator da nije problem između mene i provajdera.
U isto vreme, P2P radi besprekorno.
Nije mi jasno kako je moguće da uopšte postoji mogućnost prijema oštećene web strane, s obzirom da bi sam TCP protokol trebalo da garantuje prenos podataka bez grešaka.
Nisam siguran da li se početak ovog problema poklapa sa vremenom kada su počeli da dodeljuju IP adrese iz drugačijeg opsega nego do sada, ali je timeframe tu negde.

Da li još neko ima ovakve probleme ili ideju šta bi mogao biti uzrok?

 

[Sgi]

Ako ti je MTU postavljen na 1500, smanji ga na 1492.

 

[Dandy]

MTU mi je podešen na 1448.

 

[shku]

meni se to desavalo kad sam imao dosta izgubljenih paketa

 

[Geek_master]

Ja imam apsolutno isti problem. Beogrid wireless (verat link), isto i firefox i ie, isto lose web strane i poremecene slike, i losi zipovi sa http-a. Sve vreme paralelno news radi bez ijedne greske. I tako vec sto ti kazes sigurno 2-3 nedelje.

U medjuvremenu sam uz taj wireless instalirao adsl, medjutim telekom me je posle dva dana "castio" iskljucenjem adsla iz centrale iz samo njima znanih razloga. Moguce je da se nesto poremetilo u mreznim protokolima dok sam cackao obe konekcije. Cim mi vrate adsl reinstaliracu win i instalirati samo njega pa cu videti sta ce da se desi.

 

[Dandy]

Moguce je da se nesto poremetilo u mreznim protokolima dok sam cackao obe konekcije. Cim mi vrate adsl reinstaliracu win i instalirati samo njega pa cu videti sta ce da se desi.

Meni se ovo događa na oba računara, a na jednom imam i dva operativna sistema (WinXP i Win2003) i u svakom se isto manifestuje, pa otpada mogućnost softverskog problema. Takođe, s obzirom da preko proxy-a sve funkcioniše kako treba, eliminisao sam mogućnost da je problem kod mene.
Moraću da uradim traceroute prema najproblematičnijim sajtovima, da probam da utvdim gde bi moglo da dolazi do gubitka paketa (opet, TCP protokol ne bi smeo to da dozvoli uopšte... :trust: ).
Pada mi na pamet da prosto postoji tehnički problem na nekom mrežnom uređaju koji ne pakuje podatke kako treba kada ih prosleđuje.
Hajde neka se javi još neko ako ima ovaj problem, da probamo da utvrdimo razmere pojave.

 

[Sgi]

A zbog cega bas 1448? Ne mogu da tvrdim da je problem bas do mtu-a, iako mi na to najvise lici. Anyway, vrati mtu na 1492 jer je to default za ADSL PPPoE konekciju bez dodatnih tunela, pa probaj onda.

 

[Dandy]

A zbog cega bas 1448? Ne mogu da tvrdim da je problem bas do mtu-a, iako mi na to najvise lici. Anyway, vrati mtu na 1492 jer je to default za ADSL PPPoE konekciju bez dodatnih tunela, pa probaj onda.

Tako sam podesio po uputstvu koje sam dobio od SezamPro-a, a ne vidim kakve to ima veze kada nisam menjao tu vrednost od marta 2005. kada sam dobio ADSL i do sada je radilo normalno.
Pre nego što uopšte probam da čačkam vrednost MTU-a, voleo bih da mi objasniš zbog čega misliš da bi to mogao da bude uzrok problema?

 

[Sgi]

Trenutno nemam vremena da ti detaljno objasnim zbog cega je bas 1492 vrednost koju bi trebalo da stavis, ako ti imas vremena pogledaj detaljnije PPPoE protokol (rfc stranice 2516). Maksimalna velicina paketa koji se salje preko Ethernet-a je 1500 pa od toga oduzmes 8 bajtova nekakvog pppoe headera i dobijes tu vrednost. Istina je da ona nikako ne sme da bude veca, a da manja ne bi trebalo da dovodi do problema. E sad slanje paketa i njihova eventualna fragmentacija ne zavisi samo od klijenta i servera, vec i od rutera izmedju. Mozda su u Sezamu vrsili neke korekcije u tom smislu (slican problem pojavio se i na sbb-u npr. pre nekoliko dana) pa se sada usled toga paketi negde ne fragmentisu dobro, ili se odbacuju. Opet kazem, na osnovu tvojih simptoma, najvise mi lici da je problem do mtu-a, ali ne mogu da tvrdim. Ako se negde maksimalne vrednosti ne pogode, a sajt nije u mogucnosti da salje pakete bez DF (don't fragment) taga i pritom nije u mogucnosti ni da dinamicki sazna vrednost koju klijent moze da primi (blokira icmp pakete), te onda ruter ne sme da menja njihovu vrednost, takvi paketi se odbacuju i ne dolaze do klijenta.

U svakom slucaju, ne znam iz kog razloga su iz Sezama insistirali da bas stavis 1448, to mi deluje pomalo diletantski ili jednostavno previse obazrivo. Promena mtu-a nije nikakav major zahvat, treba samo jednom ili dva puta da resetujes racunar u procesu Mozda pomogne, a mozda i ne. Probaj da stavis i neku manju vrednost od 1448 (recimo 1400), na kraju, obavesti provajdera, duzan je da odgovori.

 

[Geek_master]

Gde se MTU uopste podesava?

Ali to u svakom slucaju nije razlog, bar ne kod mene, jer sve vec godnu po radi kako treba sa istim parametrima

Fora je dandy sto ti i ja imamo potpuno razlicit net i link a iste simptome. Mozda je neki virus u pitanju, koji se ne snalazi sa proxy-jem?

 

[Dandy]

Trenutno nemam vremena da ti detaljno objasnim zbog cega je bas 1492 vrednost koju bi trebalo da stavis, ako ti imas vremena pogledaj detaljnije PPPoE protokol (rfc stranice 2516). Maksimalna velicina paketa koji se salje preko Ethernet-a je 1500 pa od toga oduzmes 8 bajtova nekakvog pppoe headera i dobijes tu vrednost. Istina je da ona nikako ne sme da bude veca, a da manja ne bi trebalo da dovodi do problema. E sad slanje paketa i njihova eventualna fragmentacija ne zavisi samo od klijenta i servera, vec i od rutera izmedju.

Ma znam čemu služi MTU i to da je 1500 veličina za Ethernet, ali baš zato mislim da ova manja vrednost ne bi trebalo da ima uticaja.

Mozda su u Sezamu vrsili neke korekcije u tom smislu (slican problem pojavio se i na sbb-u npr. pre nekoliko dana) pa se sada usled toga paketi negde ne fragmentisu dobro, ili se odbacuju. Opet kazem, na osnovu tvojih simptoma, najvise mi lici da je problem do mtu-a, ali ne mogu da tvrdim. Ako se negde maksimalne vrednosti ne pogode, a sajt nije u mogucnosti da salje pakete bez DF (don't fragment) taga i pritom nije u mogucnosti ni da dinamicki sazna vrednost koju klijent moze da primi (blokira icmp pakete), te onda ruter ne sme da menja njihovu vrednost, takvi paketi se odbacuju i ne dolaze do klijenta.

Ono što mene buni je činjenica da i u slučaju fragmentacije na ruti, po TCP protokolu moraju da stignu svi fragmenti paketa ili se ceo paket odbacuje, a paket koji ne stigne bi trebalo da se pošalje ponovo. Ovde se očigledno nešto od toga ne odigrava kako treba.

U svakom slucaju, ne znam iz kog razloga su iz Sezama insistirali da bas stavis 1448, to mi deluje pomalo diletantski ili jednostavno previse obazrivo. Promena mtu-a nije nikakav major zahvat, treba samo jednom ili dva puta da resetujes racunar u procesu Mozda pomogne, a mozda i ne. Probaj da stavis i neku manju vrednost od 1448 (recimo 1400), na kraju, obavesti provajdera, duzan je da odgovori.

Dok je sve radilo nisam ni gledao te vrednosti, tek sam juče u stvari ukapirao da je tako podešeno. Probaću da promenim (ruter je u pitanju), ništa me ne košta, mada sumnjam da je u tome problem.

 

[stoske]

dok sam bio ne ptt-u (njima je default MTU 1400) sam imao dosta muke... MTU na ruteru su mi podesili u Netiksu, a nakon toga mora da se podesi i na racunaru (svakom koji je na tom netu)

bez podesavanja MTU nije mi radio msn, nisam mogao da otvaram microsoft website....

 

[Sgi]

Ono što mene buni je činjenica da i u slučaju fragmentacije na ruti, po TCP protokolu moraju da stignu svi fragmenti paketa ili se ceo paket odbacuje, a paket koji ne stigne bi trebalo da se pošalje ponovo. Ovde se očigledno nešto od toga ne odigrava kako treba.

Nije to bas to. Klijent zatrazi neku stranu od servera, Server krene transmisiju tcp paketa i u vecini slucajeva (jer mu je klijent tako dozvolio) sa vrednoscu od 1500, ako se nadje neki ruter na putanji do klijenta na kome je mtu manji od 1500 mogu da se dese dve stvari. Paket ce biti fragmentovan i na taj nacin prosledjen pod uslovom da na paketu ne postoji DF tag. Ukoliko postoji, paket se odbacuje (na ruteru) i serveru salje icmp sa porukom fragmentation needed. Problem nastaje sa serverima koji blokiraju icmp i efektivno omnemogucuju PMTU proces (rfc 1191)... Retransmisija o kojoj ti pricas desava se usled drugih gresaka. Sustina problema nastaje kada je na racunaru-klijentu mtu=1500, time govori serveru da je sto se njega tice ok da primi paket do te velicine (sto je naravno greska jer ne zna za PPPoE tunel na adsl-u...). Proveri i u windows-u koliki je mtu...

Dakle ne mora sve da zavisi od tvoje strane.

 

[Dandy]

Upravo sam promenio MTU na 1492 i opet se iste stvari događaju. Dakle, to nije bio problem

 

[Sgi]

Probaj jos jedanput sa 1400. Ne zaboravi da namestis i na racunaru.

 

[Dandy]

Probaj jos jedanput sa 1400. Ne zaboravi da namestis i na racunaru.

Koliko vidim, to se podešava u registry-u?
Nemam sada vremena da se zezam više sa time. Preko proxy-a sve radi, što mi je trenutno najbitnije. Probaću za par dana kada odvojim vreme za čačkanje računara.

 

[Heinz]

Instaliraj cFosSpeed pa probaj onda Odnosno, daj prioritete određenim aplikacijama.

 

[Sgi]

Koliko vidim, to se podešava u registry-u?
Nemam sada vremena da se zezam više sa time. Preko proxy-a sve radi, što mi je trenutno najbitnije. Probaću za par dana kada odvojim vreme za čačkanje računara.

Moze i ovako...

 

[Heinz]

Ili sa TCPOptimizer programčićem.