Surfen met RealDSL ... een hel ?

[wh4t3v3r]

na veel vijven en zessen werkte mijn realdsl connectie, prachtig dacht ik.
snelheid van euh streaming media en game demo's en dergelijke is perfect. Geen reden tot klagen .. behalve

surfen gaat dus gewoon weg niet ... ik ben EINDELIJK tot het "nieuw onderwerp" op userbase geraakt .. na een kleine 2 weken realdsl verbinding. Het zit zo, ik kan surfen tegen normale deftige snelheid maar neem nu www.tweakers.net .. gaat perfect vanaf ik op een link klink naar een artikel krijg ik "The page cannot be displayed".

dit geld zowat voor alle website .. incl. userbase .. met enkele keren een uitzondering dat ik wel toch door geraak .. krijg zowat het gevoel dat ik timeouts krijg ? soit ... snap niet goed aan wat het ligt dus hoop dat jullie een antwoord hebben.

heb al gemailed met de vraag of er een proxy server is maar heb daar nog geen antwoord op gekregen. dit is uiteraard zeer frustrerend ik kan dus letterlijk langs geen kanten deftig surfen .. en dit blijft tot nader order nog altijd wel de main reason dat ik een internet verbinding heb.

Het enige waar ik zowat op kom dat een probleem zou kunne zijn is de "MTU".

vroeger met telenet had ik de mtu van mijn NIC verandert naar 1500 wat volgens het programmatje TCPOptimizer het beste was. dit leverde dan ook een aanzienlijke snelheidswinst op.

dacht dit ff met realdsl ook te doen .. op mijn wireless usb nic dan maar. (het progje stuurt een aantal pings van stijgende grote naar een site naar keuze om zo de optimale mtu waarde te bekomen.) aangezien ik geen 1 website vind die ik lang genoeg pings kan sturen om een deftig resultaat te krijgen lukt het niet.. dan maar handmatig ingesteld op 1500 .. dan 700 ... 800 .. etc .. lijkt weinig verschil op te brengen. tot zover mijn geknoei heb al gedacht om de router op een pci nic aan te sluiten ipv wireless maar nog niet geprobeert.


de logica is moeilijk te vinden ... usenet via een payserver prachtige snelheden (dsl snelheden weliswaar ), surfen .. hopeloos.

hopelijk kan hier iemand helpen,

groeten

[netdata]

vroeger met telenet had ik de mtu van mijn NIC verandert naar 1500 wat volgens het programmatje TCPOptimizer het beste was. dit leverde dan ook een aanzienlijke snelheidswinst op.

Wil even reageren op de max MTU size.
Telenet gebruikt een 100% ethernet compliant netwerk.
dus je MTU size is 1500

in een PPP xDSL protocol kan de MTU size niet 1500 zijn (de routers staan dit niet toe)

ADSL gebruikt een max MTU van 1492 bytes

wat jou probleem betreft:

Dit lijkt me een DNS prob.
als je perfect kan streamen lijkt me er geen probleem met jou verbinding.

Let op dat spyware e.d. jou DNS al eens doet mislopen.

al eens met een andere browser geprobeerd?

lijkt me niet bij RealDSL te liggen maar bij jou netwerk

[wh4t3v3r]

andere browser had ik geprobeert maar heeft niet geholpen.

Ik zou persoonlijk ook denken dat het simpel weg aan mijn pc ligt (zou in theorie sneller op te lossen zijn dan dat het van realdsl afhangt )

maar aangezien er niets valt intestellen ben ik radeloos.

En zie niet hoe het aan dns kan liggen .. als tweakers.net werkt dan moet tweakers.net/nieuws/5464 het toch ook doen of zie ik dit nu verkeerd?

[Sensei Zeon]

Mja DNS ligt soms ingewikkelder heb ik de indruk (ik ken het niet in de details) maar voeg, bv, tweakers.net eens toe aan je hosts file zo sluit je al een dns probleem uit.

[Limburg]

...als tweakers.net werkt dan moet tweakers.net/nieuws/5464 het toch ook doen ....

doet me denken aan het verhaal van Prodata hierboven dat de mtu 1492 moet zijn.
Heb je dat al veranderd?

Ga eens naar http://www.dslreports.com/tweaks en doe de test.
Met een klein tooltje, drtcp, en de adviezen als resultaat van de test kun je daarna je tcpip parameters instellen.

[wh4t3v3r]

mja het is dus opgelost .. none of the above though .. het was een kwestie van de firewall van mijn router af te zetten. ra ra ra ....

[Limburg]

En hoe staat je mtu nu?

[Sloppy Joe]

Even opletten met de MTU settings:

- voor een Connection Type = PPPoA is de MTU = 1500
- voor een Connection Type = PPPoE is de MTU = 1492


Joe

[cL]

ik heb vroeger ook eens gevraagd of realdsl een proxy had, en ze hebben er dus geen.

[wh4t3v3r]

1492

[netdata]

1492

mss ter info maar weet je want max MTU size wilt zeggen.
want anders post ik et wel is int lang ent breed, maar ga nie ligge type als niemand er iets aan heeft e

[nickxbe]

Graag.

Ik haal iig weer beroerde speed// 888kbs : 0 damn klote hoor

[wh4t3v3r]

please do prodata ...


ik zat in mijn hoofd met de groote van de pakketjes die worde verstuurd .. is maar een wilde gok

[netdata]

Inleiding:

Je weet waarschijnlijk wel dat al het internet verkeer volgens de standaarden van TCP/IP verlopen.
Als je dit weet, dan weet je waarschijnlijk ook dat TCP/IP een ISO-standaard protocol is.
In het ISO standaard model vind je layers (lagen) terug.
ik som ze even op:

Layer7: Application layer
Layer6: Presentation layer
Layer5: Session Layer
Layer4: Transport layer
Layer3: Network Layer
Layer2: Datalink layer
Layer1: Physical Layer

Ik ga nu niet iedere functie van iedere layer uitleggen.

wat is hier nu belangrijk aan?
de max MTU size of a packet. is vastgesteld in Layer2
(in layer2 vind je bijvb Ethernet, PPP,X.25,xDSL,...)
Vermits dit in layer2 zit heeft dit invloed voor de hogere layers

MTU sizel:

MTU staat voor:
Maximum Transmission Unit

Deze is kenmerkend voor layer 2 en is dus afhankelijk van het 'medium' waarover je de data gaat sturen.
de MTU size is een waarde in bytes.

een ethernet protocol staat een max MTU size toe van 1500 bytes.
ga je hieronder is dit geen probleem.
maar zoals je dan ziet verstuur je minder data in 1 packet wat natuurlijk trager is.

Maar als je de MTU size te groot neemt zal die niet meer oké zijn voor de ethernet standaard. De kans is dan groot dat het packetje niet bij de bestemmeling aankomt.

dus het kan zijn dat:
een DNS lookup bijvb een size heeft van 1200 bytes
terwijl je MTU 1500 is.
na de DNS lookup ga je bijvb via HTTP een web pagina laden.
dit is een data stream die meestal groter gaat zijn dan een DNS lookup.
je gaat je data splitsen (fragment flag is set to one: zie hieronder) volgens de MTU size. als je MTU in ehternet dus hoger is dan 1500 zal ieder packetje dus groter zijn dan 1500 waardoor het kan zijn dat jou packets NIET aankomen.

wat ik wil zeggen is als je een te keine MTU size kiest gaat het altijd werken maar niet optimaal.

Kies je een te grote MTU size zal het soms (afhankelijk van de packet grote) wel lukken.

De MTU is dus zoals reeds gezegd afhankelijk van het medium.
enkele voorbeelden:

MTU voor:

ethernet: 1500
PPPoE: 1492
PPPoA: 1500
Dial-up: 576

de meeste andere protocolen X.25, frame-relay kunnen een MTU size van 1500 of meer aan.

wat eigenlijk wilt zeggen dat men een ethernet packet over frame relay kan sturen. (om maar een voorbeeld te geven)


IP protocol:

Om de data in een IP packet vast te stellen kan je mss eerst beter iets weten over een IP packet



Hierboven zie je een voorbeel van 1 IP packetje.
Het lijks mss wat ingewikeld maar dat is het zeker niet!
Het diagram wordt gelezen van links naar rechts en van boven naar onder.

In de het packet vind je een header part terug en een data part.
het header part loopt van 'vers' to 'padding' dit is de IP header.
daaronder zie je 'data'

een goede link naar alle informatie over ieder header veldje vind je <a href="http://www.networksorcery.com/enp/protocol/ip.htm">hier</a>

Wat je eigenlijk echt dient te weten is dat een IP header ALTIJD
20 bytes bevat (1byte = 8 bits = 00000001) deze kan echter ook meer bytes bevatten.

en dat het aantal bytes in het data part afhankelijk is van de max MTU size.



denk dat dit alles zowat snel samengevat is.
moest ik ergens fout zijn correct me, maar denk dat et wel correct is.

Moest het niet 'verstaanbaar' zijn zeg et dan dan probeer ik et anders te schrijven.

[X-2datop]

Toch ook ff reageren:

1. Als je een router gebruikt die NAT voorziet en jij dus niet rechtstreeks op de modem bent aangesloten moet je MTU op 1500 blijven !!!! Deze op 1492 zetten heeft dan totaal geen nut invloed omdat de MTU enkel belangrijk is voor het apparaat dat de PPPoE sessie openhoud.

2. MTU = Max. Transmission Unit
3. 'tweaken' van je lijn gaat geen drops of boosts van meer 1000kbit geven hoor. Als jij slechts 800+ kbits haalt en regelmatig disconnects heeft dit NIKS met uw MTU size te maken. Als er dan toch iets "getweaked" is zullen het eerder wat andere TCP settings zijn. Eventueel een softwarefirewall of andere softwareinstellingen die verkeerd zijn.
4. Indien je een Ethernet modem hebt, zet dan je MTU eens op 1492 en connecteer rechtstreeks met de modem (zonder je router e.d. ertussen dus)


Grtz,
X

[netdata]

1. Als je een router gebruikt die NAT voorziet en jij dus niet rechtstreeks op de modem bent aangesloten moet je MTU op 1500 blijven !!!! Deze op 1492 zetten heeft dan totaal geen nut invloed omdat de MTU enkel belangrijk is voor het apparaat dat de PPPoE sessie openhoud.

Vind persoonlijk dit niet helemaal correct.

Waarvoor koop je een router/nat?

om packets te routen of te natten, juist?
hiervoor is hij gemaakt.

een router kan daarenboven ook ander dingen zoals ook je packet aanpassen aan de MTU size van de ander drager....

dat wil zeggen dat je (in jou geval) 1500 bytes naar de router stuurt.
de router weet dat de 2de interface een PPPoE interface is aan 1492 bytes.
dus de router moet 8bytes per packet bufferen ! (wil zetten 2 packets voor 1500byte, 1tje met 1492bytes en een anders met 28byte)

plus er is een aanpassing gebeurd in de IP headers dus een nieuwe checksum moet berekend worden.
dit is tijd die je van de router vraagt.
als jou router dit aan het doen is. kan die niet meer doen waarvoor je hem gekocht hebt, namelijk routing/natting

ok ik spreek hier slechts over µs tot kleine ms maar het is tijd verlies.
op een groot belast netwerk ga je dit wel voelen!

het heeft dus wel degelijk zit om jou MTU size aan te passen naar de laagste MTU size in jou path dat je doorkruis is dit geval de PPPoE verbinding.

dan stuurt jou PC een packet uit met 1492 bytes
jou router/nat stuur dit door naar de modem

de modem stuurt dit via PPPoE buiten.

er dient GEEN buffering gedaan te worden alsook geen checksum recalculation.

[khsw]

In mijn geval is http://www.hln.be niet bereikbaar. Nog RealDSL'ers waarbij dit niet lukt. Ik heb voorlopig mijn host file aangepast zodat ik toch mijn gazetje kan lezen

[Lukse]

In mijn geval is http://www.hln.be niet bereikbaar. Nog RealDSL'ers waarbij dit niet lukt.

Hier hetzelfde.

[The_Borg]

ok ik spreek hier slechts over µs tot kleine ms maar het is tijd verlies. op een groot belast netwerk ga je dit wel voelen!

We spreken hier natuurlijk maar over een huis-tuin-keuken oplossing, Persoonlijk denk ik dat je dit toch een beetje overschat zelfs. Op grote netwerken staan er meestal ook grote switches, routers, bridges, ... . Die paar extra cpu cycles zullen dan wel niet zoveel meer uitmaken.

[wh4t3v3r]

dan zat ik er met mijn wilde gok dus toch wel goed in de buurt


nog ff over het feit dat als je achter een router zit het geen zin heeft om de mtu aan te passen op de pc ...

1. Als je een router gebruikt die NAT voorziet en jij dus niet rechtstreeks op de modem bent aangesloten moet je MTU op 1500 blijven !!!! Deze op 1492 zetten heeft dan totaal geen nut invloed omdat de MTU enkel belangrijk is voor het apparaat dat de PPPoE sessie openhoud.

lijkt mij eerlijk gezegd niet logisch ... het pakketje word toch samengesteld op de pc en word toch niet gewijzigd door de router voor het de vrije wereld word ingestuurd ?

[netdata]

lijkt mij eerlijk gezegd niet logisch ... het pakketje word toch samengesteld op de pc en word toch niet gewijzigd door de router voor het de vrije wereld word ingestuurd ?

Toch wel,

een router doet veel meer dan je denkt.
Hij doet niet alleen aan routing.

het packetje wordt samengesteld op de PC maar indien de router er anders over beslist gaat hij het packetje wijzigen zodat het conform is de instellingen.
en indien hij een packetje veranderd zal hij zelfs enkele rekensommen uitvoeren om zodoende de checksum terug te doen kloppen.

mss even de functie van een router toelichten (geen NAT)

een router is een device met 2 of meer ingangen. Deze verbind 2 netwerken.
dus met verschillende subnets en/of ip-ranges (layer 3)

sommige routers zijn ook in staat 2 verschillende netwerken met elkaar te koppelen (layer2) hiervoor moet hij de packets ofwel 'aanpassen' conform de andere standaard en/of de packets encapsuleren in de ander standaard. snap je?

een voorbeeld van zo'n toestel is een ADSL modem/router.

deze koppelt 2 verschillende netwerken (op layer 2 verschillend)
namelijk een PPP (Point to Point Protocol) en een Ethernet

als de max MTU size van PPPoE 1492 is en die van de ethernet kant 1500 is
dient de router (niet jou PC!) het ethernet packet aan te passen zodat het klaar is voor 'verwerking' in de PPPoE standaard

een router is een erg complex device
vandaar dat een professionele router al snel 400€ kost

overigens houd je router ook al heel wat trafiek tegen. zodat het niet van de ene kant van het netwerk kan lopen naar de andere.

Een voorbeeld is data dat afkomstig is van volgende netwerken:

127.0.0.x (verlaat het toestel nooit niet wat is local loop)
192.168.x.x (non routable adress)
10.x.x.x (non routable adress)
172.16.x.x tot 172.31.x.x

als een device met zulk IP de andere kant van de router probeerd te bereiken zal dit niet lukken. aangezien deze IP ranges non routeble zijn
vandaar dat er op jou LAN een NAT draait. deze zorgt er op ingeneuze wijze voor dat jou IP 'routeble' wordt naar de WAN kant.

[Ofloo]

In mijn geval is http://www.hln.be niet bereikbaar. Nog RealDSL'ers waarbij dit niet lukt.

Hier hetzelfde.

ik kan derop maar is wel een beke traag..

[Ofloo]

lijkt mij eerlijk gezegd niet logisch ... het pakketje word toch samengesteld op de pc en word toch niet gewijzigd door de router voor het de vrije wereld word ingestuurd ?

Toch wel,

een router doet veel meer dan je denkt.
Hij doet niet alleen aan routing.

het packetje wordt samengesteld op de PC maar indien de router er anders over beslist gaat hij het packetje wijzigen zodat het conform is de instellingen.
en indien hij een packetje veranderd zal hij zelfs enkele rekensommen uitvoeren om zodoende de checksum terug te doen kloppen.

mss even de functie van een router toelichten (geen NAT)

een router is een device met 2 of meer ingangen. Deze verbind 2 netwerken.
dus met verschillende subnets en/of ip-ranges (layer 3)

sommige routers zijn ook in staat 2 verschillende netwerken met elkaar te koppelen (layer2) hiervoor moet hij de packets ofwel 'aanpassen' conform de andere standaard en/of de packets encapsuleren in de ander standaard. snap je?

een voorbeeld van zo'n toestel is een ADSL modem/router.

deze koppelt 2 verschillende netwerken (op layer 2 verschillend)
namelijk een PPP (Point to Point Protocol) en een Ethernet

als de max MTU size van PPPoE 1492 is en die van de ethernet kant 1500 is
dient de router (niet jou PC!) het ethernet packet aan te passen zodat het klaar is voor 'verwerking' in de PPPoE standaard

een router is een erg complex device
vandaar dat een professionele router al snel 400€ kost

overigens houd je router ook al heel wat trafiek tegen. zodat het niet van de ene kant van het netwerk kan lopen naar de andere.

Een voorbeeld is data dat afkomstig is van volgende netwerken:

127.0.0.x (verlaat het toestel nooit niet wat is local loop)
192.168.x.x (non routable adress)
10.x.x.x (non routable adress)
172.16.x.x tot 172.31.x.x

als een device met zulk IP de andere kant van de router probeerd te bereiken zal dit niet lukken. aangezien deze IP ranges non routeble zijn
vandaar dat er op jou LAN een NAT draait. deze zorgt er op ingeneuze wijze voor dat jou IP 'routeble' wordt naar de WAN kant.

ge vergeet die in de 169 range... weet hem niet meer exact..

[netdata]

ge vergeet die in de 169 range... weet hem niet meer exact..

ja das waar.

Maar dit is ook een local adress.
een IP dat begint met 169.x.x.x wil zeggen dat jou netwerkkaart niet in staat was een DHCP IP te verkrijgen zo kunnen PC's die nog op hetzelfde netwerk zitten en geen DHCP adress hebben elkaar toch 'zien'

hieronder een quote die ik vond:

The 169.254 subnet range is for APIPA - Automatic Private IP Addressing. Microsoft uses APIPA in instances where a DHCP server is not present. When a host cannot find a DHCP server, it will assign itself an address in the 169.254 subnet range, thus allowing communications between itself and other PCs who are using APIPA.

In short, if no DHCP server exists, and both machines use APIPA to get an IP address, YES, you can ping from one to the other. It is a valid IP address, and the IP stack is still functioning.

127.0.0.1 is a logical loopback. 127.0.0.2 is nothing. The 127.0.0.0 and 192.168.0.0 ranges and a few others are reserved for special use.

maat het is dus een geldig private IP (non routable)

alhoewel het nergens geimplementeerd wordt aangezien windows het gebruikt met APIPA