Onstabiele kutverbinding :(
Martijn
Ik ging net gamen en het lagde als de ziekte!
Naja het was niet echt een lag maar het leek
alsof de verbinding elke 10 sec. verbroken voor 1 sec ofzo werd.
Op IRC heb ik ook steeds disconnects!
Pings lijken wel oke, maar wel wat sporadische verhogingen:
Lijkt me al te hoog voor binnen .nl
Reply from 194.109.6.92: bytes=32 time=32ms TTL=250
Reply from 194.109.6.92: bytes=32 time=110ms TTL=250
Reply from 194.109.6.92: bytes=32 time=110ms TTL=250
Reply from 194.109.6.92: bytes=32 time=125ms TTL=250
Reply from 194.109.6.92: bytes=32 time=16ms TTL=250
Ik heb ook nog de mogelijkheid om via de buurman mee te internetten,
(die was zo 'aardig' zijn WiFi met Essent@Home open te zetten)
en dan gaat alles wel gewoon prima.
Ook IRC blijft dan connected en die verbinding is 5.5mbps/30%, terwijl
ik intern direct op 100 mbit switched LAN zit :(
Download kom ik ook niet hoger dan 400kB, hooguit 500. (MAXX)
Gaat lekker met die homo's bij BBNed de laatste tijd :S
Mijn contract hier verloopt 2 Februari en ik was er zeker van weer BBNed
te nemen maar ik neig, hoe erg het ook mag klinken toch steeds weer meer
naar de _K_PN die wel beloofd wat ze waarmaken en niet achter de feiten
aanlopen.
--
Martijn.
Martijn
"Martijn" <REMOVE...@xs4all.invalidTHIS> wrote:
[blaat]
Ow ja, check dit:
Normaal haal ik easy 7800 kbps.
--
Martijn.
b-ART-
Heb je al eens contact met de helpdesk op genomen om ea te controleren en te
bekijken?
Bart
Martijn
"b-ART-" <b...@RT.kom> wrote:
> Heb je al eens contact met de helpdesk op genomen om ea te controleren en
te
> bekijken?
Ehmm nee die is waarschijnlijk al dicht.
En voor 8 uur 's avonds heb ik daar geen tijd voor.
Vandaar dit berichtje hier :)
--
Martijn.
Danny
>Ik ging net gamen en het lagde als de ziekte!
>Naja het was niet echt een lag maar het leek
>alsof de verbinding elke 10 sec. verbroken voor 1 sec ofzo werd.
>Op IRC heb ik ook steeds disconnects!
>Pings lijken wel oke, maar wel wat sporadische verhogingen:
>Lijkt me al te hoog voor binnen .nl
>
>Reply from 194.109.6.92: bytes=32 time=32ms TTL=250
>Reply from 194.109.6.92: bytes=32 time=110ms TTL=250
>Reply from 194.109.6.92: bytes=32 time=110ms TTL=250
>Reply from 194.109.6.92: bytes=32 time=125ms TTL=250
>Reply from 194.109.6.92: bytes=32 time=16ms TTL=250
Stel nou eens dat iemand een ping-flood op jouw ipnummer zet
omdat je te "goed" ben in het spel.
Dat heb je alle bovenstaande specs maar ben jij het niet,
cistron niet _en_ bbend niet!.
Ik zou via de verbindin van je buren eens een traceroute
naar je eigen cistron-ip mee laten lopen en kijken WAAR
dat fout gaat.
Ik heb de hele avond eea mee lopen in een hoekje en ik
kan werkelijk geen klap-verkeerd vinden!
Danny
--
Empirically speaking, common sense does not appear to be common at all.
http://www.themeatrix.com/
Olaf van der Spek
"Danny" <d...@dth.net> schreef in bericht
news:btkpn4$c7a$1...@newsbin.cistron.nl...
> Martijn <REMOVE...@xs4all.invalidTHIS> wrote:
> >Ik ging net gamen en het lagde als de ziekte!
> >Naja het was niet echt een lag maar het leek
> >alsof de verbinding elke 10 sec. verbroken voor 1 sec ofzo werd.
> >Op IRC heb ik ook steeds disconnects!
> >Pings lijken wel oke, maar wel wat sporadische verhogingen:
> >Lijkt me al te hoog voor binnen .nl
> >
> >Reply from 194.109.6.92: bytes=32 time=32ms TTL=250
> >Reply from 194.109.6.92: bytes=32 time=110ms TTL=250
> >Reply from 194.109.6.92: bytes=32 time=110ms TTL=250
> >Reply from 194.109.6.92: bytes=32 time=125ms TTL=250
> >Reply from 194.109.6.92: bytes=32 time=16ms TTL=250
>
> Stel nou eens dat iemand een ping-flood op jouw ipnummer zet
> omdat je te "goed" ben in het spel.
> Dat heb je alle bovenstaande specs maar ben jij het niet,
> cistron niet _en_ bbend niet!.
>
> Ik zou via de verbindin van je buren eens een traceroute
> naar je eigen cistron-ip mee laten lopen en kijken WAAR
> dat fout gaat.
Of de firewall zo instellen dat er niet gereageerd wordt op externe ICMP
echo requests.
Martijn
"Danny" <d...@dth.net> wrote:
> Stel nou eens dat iemand een ping-flood op jouw ipnummer zet
> omdat je te "goed" ben in het spel.
Dan hadden ze dat ook wel op het @Home ip gedaan.
En die is 4x trager dan mijn Cistron lijn.
Bovendien ben ik _niet_ zo goed in het spel en kunnen
andere gamers mijn IP niet zien.
> Dat heb je alle bovenstaande specs maar ben jij het niet,
> cistron niet _en_ bbend niet!.
Ik krijg anders nog steeds disconnects op IRC via Cistron.
Ik disconnect om de 15 sec. ofzo.
Via @Home nergens last van.
> Ik zou via de verbinding van je buren eens een traceroute
> naar je eigen cistron-ip mee laten lopen en kijken WAAR
> dat fout gaat.
Jij mag het zeggen, volgens mij gaat het toch echt bij jullie router
fout hoor:
Tracing route to 62.216.13.183 over a maximum of 30 hops
1 16 ms 16 ms <10 ms 192.168.2.1
2 31 ms 31 ms 16 ms 217.120.22.1
3 31 ms 16 ms 31 ms 213.51.145.1
4 31 ms 31 ms 32 ms 213.51.158.9
5 15 ms 79 ms 15 ms 213.51.158.2
6 63 ms 31 ms 141 ms 213.51.132.18
7 32 ms 15 ms 16 ms 195.69.144.52
8 141 ms * 31 ms 62.216.29.6 <=== ?
9 * * * Request timed out (Dit klopt ICMP staat
dicht).
Hier nog een ping (via @Home):
Reply from 62.216.29.6: bytes=32 time=187ms TTL=248
Reply from 62.216.29.6: bytes=32 time=125ms TTL=248
Reply from 62.216.29.6: bytes=32 time=125ms TTL=248
Reply from 62.216.29.6: bytes=32 time=140ms TTL=248
En mocht je dan toch niet overtuigd zijn en denken dat het aan @Home ligt!
Hier een ping via XS1.XS4ALL.NL (100 mbit AMS-IX ofzo?)
64 bytes from 62.216.29.6: icmp_seq=5 ttl=252 time=268.779 ms
64 bytes from 62.216.29.6: icmp_seq=6 ttl=252 time=1.475 ms
64 bytes from 62.216.29.6: icmp_seq=7 ttl=252 time=2.895 ms
64 bytes from 62.216.29.6: icmp_seq=8 ttl=252 time=525.700 ms <== ?
64 bytes from 62.216.29.6: icmp_seq=9 ttl=252 time=3.276 ms
64 bytes from 62.216.29.6: icmp_seq=10 ttl=252 time=1.859 ms
64 bytes from 62.216.29.6: icmp_seq=11 ttl=252 time=166.984 ms
En via PICARD.CISTRON.NL:
64 bytes from 62.216.29.6: icmp_seq=12 ttl=254 time=88.0 ms <=== ?
64 bytes from 62.216.29.6: icmp_seq=13 ttl=254 time=1.27 ms
64 bytes from 62.216.29.6: icmp_seq=14 ttl=254 time=385 ms <=== ?
64 bytes from 62.216.29.6: icmp_seq=15 ttl=254 time=1.75 ms
Lijkt me niet gezond die waarden.
> Ik heb de hele avond eea mee lopen in een hoekje en ik
> kan werkelijk geen klap-verkeerd vinden!
Tja daar heb ik weinig aan op dit moment.
Ik kan nu geen reet met heel die verbinding.
Hopelijk heb ik nu genoeg bewijsmateriaal.
--
Martijn.
Miquel van Smoorenburg
Martijn <REMOVE...@xs4all.invalidTHIS> wrote:
>Jij mag het zeggen, volgens mij gaat het toch echt bij jullie router
>fout hoor:
>
>Tracing route to 62.216.13.183 over a maximum of 30 hops
>
> 1 16 ms 16 ms <10 ms 192.168.2.1
> 2 31 ms 31 ms 16 ms 217.120.22.1
> 3 31 ms 16 ms 31 ms 213.51.145.1
> 4 31 ms 31 ms 32 ms 213.51.158.9
> 5 15 ms 79 ms 15 ms 213.51.158.2
> 6 63 ms 31 ms 141 ms 213.51.132.18
> 7 32 ms 15 ms 16 ms 195.69.144.52
> 8 141 ms * 31 ms 62.216.29.6 <=== ?
Dit is normaal.
> 9 * * * Request timed out (Dit klopt ICMP staat
>dicht).
>
>Hier nog een ping (via @Home):
>
>Reply from 62.216.29.6: bytes=32 time=187ms TTL=248
>Reply from 62.216.29.6: bytes=32 time=125ms TTL=248
>Reply from 62.216.29.6: bytes=32 time=125ms TTL=248
>Reply from 62.216.29.6: bytes=32 time=140ms TTL=248
Normaal.
>Lijkt me niet gezond die waarden.
Is niets mee aan de hand.
Zoals hier al zeker honderd keer is gepost, de gateway is
een Cisco NRP. Bij alle routers, maar zeker die dingen, heeft
het reageren op ICMP ECHO REQUEST packets de allerlaatste
prioriteit.
1e prioriteit is het routeren van packets op interrupt nivo.
2e prioriteit is het draaien van "processen" op user nivo.
1 van die processen op "user" nivo draagt zorg voor het
reageren op icmp echo requests ("pings"). Omdat de Cisco
scheduler timeslices kent van honderden milliseconden, en
dat proces absoluut de laagste prioriteit heeft, krijg je
al ping tijden van > 200 ms als er toevallig een hele
stapel DHCP requests binnen komen die door de DHCP relay
agent worden afgehandeld die een hogere prioriteit heeft.
Maar dat heeft _niets_ te maken met de performance van
het forwarden van packets. Dat gaat altijd voor.
Dat kan je ook wel zien; als de ICMP echo tijd aan zou geven
wat de snelheid van het forwarden van packets zou zijn, dan zou
je minimaal dezelfde vertraging zien voor hops erachter,
en dat is absoluut niet het geval.
Goed, nu heb ik het voor de 101e keer duidelijk gemaakt ;)
Mike.
Martijn
"Miquel van Smoorenburg" <miq...@cistron.invalid> wrote:
> Goed, nu heb ik het voor de 101e keer duidelijk gemaakt ;)
Ik moet een traceroute doen, dan doe ik dat, ik post het
en dan ligt het nog steeds aan mij!
Dus aardige uitleg maar mijn connectie valt nog steeds niet mee
te internetten en daar ging het volgens mij om.
Ik blijf het natuurlijk wel vreemd blijf vinden dat het verhaal
wat jij uitlegt alleen bij jullie routers is.
Ik heb al genoeg isp's gehad en nog nooit routers gezien die geen
tijd hadden voor mijn ICMP pakketje, zeker om 1 uur 's nachts!
@Home is zwaar kut en zelfs die dingen hebben er geen last van.
Bij XS4ALL ook niets.
Overdag niet eens, maar die zijn dan natuurlijk verkeerd ingesteld.
Ik disconnect steeds op IRC, binnen iedere minuut zeker 1x, dus dan
vind ik die timeouts op die router die dan komen ook niet toevallig meer.
En een ping van 550ms via xs4all vind ik wel erg hoog!
Die router moet het wel uberdruk hebben dan, als ik om de 2 pings
een megahoge ping krijg en soms zelfs timeouts.
Heeft ie nog wel genoeg CPU om fatsoenlijk te routeren?
Maar goed, technisch lullen jullie mij toch onderuit dus heb ik geen
poot om op te staan.
Ik ga morgen hier alles testen met een andere modem en mijn notebook,
met zo kort mogelijke kabels etc etc etc etc.
Als het dan nog niet werkt kom ik hier weer ff een flame bait houden :)
Ik heb trouwens nog wel iets 'positiefs' te melden en dat is dat jullie
zelfs 's nachts
reageren :P
--
Martijn.
b-ART-
> wat jij uitlegt alleen bij jullie routers is.
> Ik heb al genoeg isp's gehad en nog nooit routers gezien die geen
> tijd hadden voor mijn ICMP pakketje, zeker om 1 uur 's nachts!
Dus de klanten welke aangesloten zijn geven volgens jou minder traffic rond
01.00 uur dan zeg 's middags?
> Ik ga morgen hier alles testen met een andere modem en mijn notebook,
> met zo kort mogelijke kabels etc etc etc etc.
> Als het dan nog niet werkt kom ik hier weer ff een flame bait houden :)
> Ik heb trouwens nog wel iets 'positiefs' te melden en dat is dat jullie
> zelfs 's nachts reageren :P
Tja, we willen je inderdaad prima helpen, alleen zoals ik al aangaf is het
telefonisch misschien gemakkelijker om ea na te gaan en te laten
controleren. Want de disconnects die jij meemaakt kunnen ook je dsl lijn
zijn (sync) tussen jou en de bbned dslam in je centrale.
Traceroute geeft soms nuttige informatie, maar hoge latencies van routers
etc is niet echt boeiend zoals dhr Miquel al aangaf. 't Gaat om de
end-to-end latency.
Bart
Martijn
"b-ART-" <b...@RT.kom> wrote:
> Tja, we willen je inderdaad prima helpen, alleen zoals ik al aangaf is het
> telefonisch misschien gemakkelijker om ea na te gaan en te laten
> controleren. Want de disconnects die jij meemaakt kunnen ook je dsl lijn
> zijn (sync) tussen jou en de bbned dslam in je centrale.
Ik zal wel eens bellen morgen.
Thx voor je reactie.
--
Martijn.
Olaf van der Spek
"Martijn" <REMOVE...@xs4all.invalidTHIS> schreef in bericht
news:btku3h$36a$1...@news.cistron.nl...
>
> "Miquel van Smoorenburg" <miq...@cistron.invalid> wrote:
>
> > Goed, nu heb ik het voor de 101e keer duidelijk gemaakt ;)
>
> Ik moet een traceroute doen, dan doe ik dat, ik post het
> en dan ligt het nog steeds aan mij!
>
> Dus aardige uitleg maar mijn connectie valt nog steeds niet mee
> te internetten en daar ging het volgens mij om.
>
> Ik blijf het natuurlijk wel vreemd blijf vinden dat het verhaal
> wat jij uitlegt alleen bij jullie routers is.
> Ik heb al genoeg isp's gehad en nog nooit routers gezien die geen
> tijd hadden voor mijn ICMP pakketje, zeker om 1 uur 's nachts!
Bij Fedora Core zit zo'n mooi grafisch traceroute tooltje dat continue pings
uitvoerd en ook packet-loss in de gaten houdt. Heb je zo'n tooltje niet bij
de hand?
Dan kun je misschien zien waar packet-loss optreed.
Maarten te Paske
wrote:
> Of de firewall zo instellen dat er niet gereageerd wordt op externe ICMP
> echo requests.
Op het moment dat je dat verkeer dropt is het verkeer al je lijn over,
dus echt helpen tegen een pingflood doet dat niet.
Verder kan het blocken hiervan PMTU discovery stukmaken, hoewel dat bij
een standaard Cistron setup wat minder van belang is.
Maarten
--
Meet your meat
http://maarten.tepaske.net/mym-hi.rm
Willem
<ne...@tepaske.net.invalid> wrote:
>On Fri, 9 Jan 2004 01:07:35 +0100, Olaf van der Spek <Ovd...@LIACS.NL>
>wrote:
>
>> Of de firewall zo instellen dat er niet gereageerd wordt op externe ICMP
>> echo requests.
>
>Op het moment dat je dat verkeer dropt is het verkeer al je lijn over,
>dus echt helpen tegen een pingflood doet dat niet.
>
>Verder kan het blocken hiervan PMTU discovery stukmaken, hoewel dat bij
>een standaard Cistron setup wat minder van belang is.
>
>Maarten
Ping je niet je EERSTE HOP NA je eigen IP ? ofwel jouw.ip.nummer.1 ?
Die geeft geen goede waarde bij drukte en technisch mag je cistron
vragen hoe dat zit :-)
neem de website van cistron bv: :-)
ping www.cistron.nl -t
Pinging www.cistron.nl [62.216.30.254] with 32 bytes of data:
Reply from 62.216.30.254: bytes=32 time=31ms TTL=61
Reply from 62.216.30.254: bytes=32 time=15ms TTL=61
Reply from 62.216.30.254: bytes=32 time=15ms TTL=61
Reply from 62.216.30.254: bytes=32 time=15ms TTL=61
Reply from 62.216.30.254: bytes=32 time=15ms TTL=61
Reply from 62.216.30.254: bytes=32 time=15ms TTL=61
Reply from 62.216.30.254: bytes=32 time=16ms TTL=61
Reply from 62.216.30.254: bytes=32 time=16ms TTL=61
Reply from 62.216.30.254: bytes=32 time=16ms TTL=61
Reply from 62.216.30.254: bytes=32 time=16ms TTL=61
Reply from 62.216.30.254: bytes=32 time=32ms TTL=61
Reply from 62.216.30.254: bytes=32 time=16ms TTL=61
Reply from 62.216.30.254: bytes=32 time=16ms TTL=61
Reply from 62.216.30.254: bytes=32 time=16ms TTL=61
Reply from 62.216.30.254: bytes=32 time=16ms TTL=61
Ping statistics for 62.216.30.254:
Packets: Sent = 15, Received = 15, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 15ms, Maximum = 32ms, Average = 17ms
Control-C
^C
werkt nu wel goed omdat het minder druk is ....
->
ping 62.216.12.1 -t
Pinging 62.216.12.1 with 32 bytes of data:
Reply from 62.216.12.1: bytes=32 time=31ms TTL=254
Reply from 62.216.12.1: bytes=32 time=16ms TTL=254
Reply from 62.216.12.1: bytes=32 time=15ms TTL=254
Reply from 62.216.12.1: bytes=32 time=15ms TTL=254
Reply from 62.216.12.1: bytes=32 time=15ms TTL=254
Reply from 62.216.12.1: bytes=32 time=15ms TTL=254
Reply from 62.216.12.1: bytes=32 time=31ms TTL=254
Reply from 62.216.12.1: bytes=32 time=15ms TTL=254
Reply from 62.216.12.1: bytes=32 time=15ms TTL=254
Reply from 62.216.12.1: bytes=32 time=15ms TTL=254
Reply from 62.216.12.1: bytes=32 time=15ms TTL=254
Reply from 62.216.12.1: bytes=32 time=31ms TTL=254
Reply from 62.216.12.1: bytes=32 time=15ms TTL=254
Reply from 62.216.12.1: bytes=32 time=15ms TTL=254
Reply from 62.216.12.1: bytes=32 time=15ms TTL=254
Reply from 62.216.12.1: bytes=32 time=15ms TTL=254
Reply from 62.216.12.1: bytes=32 time=31ms TTL=254
Reply from 62.216.12.1: bytes=32 time=15ms TTL=254
Reply from 62.216.12.1: bytes=32 time=15ms TTL=254
Reply from 62.216.12.1: bytes=32 time=15ms TTL=254
Reply from 62.216.12.1: bytes=32 time=15ms TTL=254
Reply from 62.216.12.1: bytes=32 time=16ms TTL=254
Reply from 62.216.12.1: bytes=32 time=16ms TTL=254
Ping statistics for 62.216.12.1:
Packets: Sent = 23, Received = 23, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 15ms, Maximum = 31ms, Average = 17ms
Control-C
^C
Tracing route to www.cistron.nl [62.216.30.254]
over a maximum of 30 hops:
1 * * * Request timed out.
2 32 ms 15 ms 16 ms nrp-4.bras-1.ams-tel.cistron.net
[62.216.12.1]
3 31 ms 16 ms 15 ms ve-4.rtr-1.ams-sar.cistron.net
[62.216.29.1]
4 32 ms 15 ms 16 ms www.cistron.nl [62.216.30.254]
Trace complete.
hier geen probleem
Willem
<ne...@tepaske.net.invalid> wrote:
>On Fri, 9 Jan 2004 01:07:35 +0100, Olaf van der Spek <Ovd...@LIACS.NL>
>wrote:
>
>> Of de firewall zo instellen dat er niet gereageerd wordt op externe ICMP
>> echo requests.
>
>Op het moment dat je dat verkeer dropt is het verkeer al je lijn over,
>dus echt helpen tegen een pingflood doet dat niet.
>
>Verder kan het blocken hiervan PMTU discovery stukmaken, hoewel dat bij
>een standaard Cistron setup wat minder van belang is.
>
>Maarten
installeer ook eens een goede TCP logger: De firewall van mij SYGATE 5
loggede eens dat ik steeds op port 8 ge-icmpt werkt geen invloed enzo
had het maar toch :-) of anders een grafische programma dat ziet of er
veel verkeer over je Netwerk kaart gaat: heet DUMETER
succes!
Maurice Janssen
>installeer ook eens een goede TCP logger: De firewall van mij SYGATE 5
>loggede eens dat ik steeds op port 8 ge-icmpt werkt geen invloed enzo
>had het maar toch :-) of anders een grafische programma dat ziet of er
>veel verkeer over je Netwerk kaart gaat: heet DUMETER
ICMP kent geen poorten, dus ik neem aan dat je type 8 bedoelt.
In gewonen mensen taal: iets/iemand pingt je.
Zie ook RFC 777 voor alle ICMP types.
--
Maurice mauricej (at) xs4all (dot) nl
J.F. van Baarlen
news:cbnsvv04mliqdsfik...@4ax.com
> installeer ook eens een goede TCP logger: De firewall van mij SYGATE 5
> loggede eens dat ik steeds op port 8 ge-icmpt werkt geen invloed enzo
> had het maar toch :-)
Gewoon een doodordinaire icmp-echo-request dus. Als je je daar al zorgen
over maakt kan je maar beter de stekker eruit trekken. Installeren van een
tcp-logger (beter bekend als netwerksniffer of -analyzer) heeft alleen maar
zin als je de output daadwerkelijk snapt, en de hoeveelheid data is nogal
fors als je niet precies weet wat je allemaal over je scherm ziet vliegen
:-)
Sommige problemen kan je best met een sniffer aanpakken (dhcp-troubles, in
het bijzonder) maar je moet wel erg veel mazzel hebben om iets te vinden dat
te maken heeft met algemene instabiliteit.
Steven Kroesbergen
"Martijn" <REMOVE...@xs4all.invalidTHIS> wrote in message
news:btku3h$36a$1...@news.cistron.nl...
>
> "Miquel van Smoorenburg" <miq...@cistron.invalid> wrote:
>
> > Goed, nu heb ik het voor de 101e keer duidelijk gemaakt ;)
>
> Ik moet een traceroute doen, dan doe ik dat, ik post het
> en dan ligt het nog steeds aan mij!
>
Doen dan een traceroute naar de server waarmee je problemen hebt.
Danny
Installeer mtr of win-mtr en post de output daarvan:
Dit was gisteren om 23:50 naar www.hoho.nl
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 195.64.87.000 - 0 | 16 | 16 | 0 | 0 | 15 | 0 |
| sms-3.ams-tel.cistron.net - 0 | 15 | 15 | 15 | 15 | 16 | 16 |
| ve-23.rtr-1.ams-sar.cistron.net - 0 | 15 | 15 | 15 | 15 | 16 | 16 |
| vhost1.hoho.nl - 0 | 15 | 15 | 15 | 15 | 16 | 15 |
|________________________________________________|______|______|______|______|______|______|
Maarten te Paske
wrote:
> On Fri, 9 Jan 2004 05:27:43 +0000 (UTC), Maarten te Paske
> <ne...@tepaske.net.invalid> wrote:
>
> > Op het moment dat je dat verkeer dropt is het verkeer al je lijn
> > over, dus echt helpen tegen een pingflood doet dat niet.
> >
> > Verder kan het blocken hiervan PMTU discovery stukmaken, hoewel dat
> > bij een standaard Cistron setup wat minder van belang is.
>
> installeer ook eens een goede TCP logger: De firewall van mij SYGATE 5
> loggede eens dat ik steeds op port 8 ge-icmpt werkt geen invloed enzo
> had het maar toch :-) of anders een grafische programma dat ziet of er
> veel verkeer over je Netwerk kaart gaat: heet DUMETER
Ik neem aan dat dit eigenlijk geen reactie op mijn posting was ? :)
Wichert Akkerman
Maarten te Paske <news[at]tepaske[dot]net> wrote:
>On Fri, 9 Jan 2004 01:07:35 +0100, Olaf van der Spek <Ovd...@LIACS.NL>
>> echo requests.
>Verder kan het blocken hiervan PMTU discovery stukmaken, hoewel dat bij
>een standaard Cistron setup wat minder van belang is.
icmp echo_request wordt niet gebruikt voor pMTU dus die kan je
probleemloos wegfilteren.
Wichert.
--
Wichert Akkerman <wic...@wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
bram van der voet
Goede tip Martijn, als je kut, homo' en ziekte's schrijft krijg je meteen de
volledige aandacht van het Cistron team...
Bram
Han Willemsen
> Goede tip Martijn, als je kut, homo' en ziekte's schrijft krijg je
> meteen de volledige aandacht van het Cistron team...
Dat was inderdaad wel opvallend ;-)
]-[an.
--
==================================================
= Han Willemsen - <will...@xs4all.nl> =
= Utrecht - Netherlands =
==================================================
Jochem van Dieten
>
> Ik blijf het natuurlijk wel vreemd blijf vinden dat het verhaal
> wat jij uitlegt alleen bij jullie routers is.
Jij leest zeker niet zo veel nieuwsgroepen? Ik heb deze uitleg de
afgelopen maanden bij 3 verschillende Nederlandse ISPs talloze
malen voorbij zien komen.
Jochem
Martijn
"bram van der voet" <br...@HaalDitWeGanv.xs4all.nl> wrote:
> Goede tip Martijn, als je kut, homo' en ziekte's schrijft krijg je meteen
de
> volledige aandacht van het Cistron team...
Tja dat is nou eenmaal mijn taalgebruik.
Iedereen snapt dan direct wat ik bedoel :)
--
Martijn.
Olaf van der Spek
"Maarten te Paske" <ne...@tepaske.net.invalid> schreef in bericht
news:slrnbvseu...@zero.analogue.nl...
> On Fri, 9 Jan 2004 01:07:35 +0100, Olaf van der Spek <Ovd...@LIACS.NL>
> wrote:
>
> > Of de firewall zo instellen dat er niet gereageerd wordt op externe ICMP
> > echo requests.
>
> Op het moment dat je dat verkeer dropt is het verkeer al je lijn over,
> dus echt helpen tegen een pingflood doet dat niet.
Dat is niet waar. Ik neem aan dat het probleem zich voordoet op de upstream
en niet op de downstream en dat het gaat over ADSL.
Als het probleem zich wel voordoet op de downstream, dan is het type van het
verkeer (pingflood) niet relevant.
> Verder kan het blocken hiervan PMTU discovery stukmaken, hoewel dat bij
> een standaard Cistron setup wat minder van belang is.
De MTU veranderd toch niet tussen de eerste en tweede hop vanaf een klant
gezien?
Als een remote host PMTU uitvoert, gaat dat dus goed. En omdat je alleen
externe ICMP echo requests negeerd, heeft je eigen PMTU daar geen last van.
Nu werkt PMTU niet met ICMP echo requests, maar hetzelfde geldt voor de ICMP
messages waar het wel mee werkt natuurlijk.
Foetsji
"Martijn" <martij...@THIScentric.nl> wrote in message
news:3ffe8c33$0$332$e4fe...@news.xs4all.nl...
Als je mij zo aangesproken had, had je met je gore kanis de tyfus kunnen,
kuttekop.
Snappie? ;-))
En Foets su(r)ft weer vrolijk verder.
--- Geen recht spoor zonder dwarsliggers. ---
Martijn
"Foetsji" <Foe...@hotmail.com> wrote:
> Als je mij zo aangesproken had, had je met je gore kanis de tyfus kunnen,
> kuttekop.
> Snappie? ;-))
Geweldig :)
Dat is tenminste duidelijk en ik snap gelijk wat je bedoeld, hoewel ik
niemand (persoonlijk) heb aangevallen, behalve BBNeD maar die lezen
dit waarschijnlijk niet eens.
--
Martijn.
Foetsji
"Martijn" <martij...@THIScentric.nl> wrote in message
Kan je nagaan hoe duidelijk het was, ik was zelfs het woord 'krijgen'
vergeten te typen.;-))
Maar ... een goede verstaander heeft maar een half woord nodig.
Succes met je krommunicatie.
Maarten te Paske
wrote:
> "Maarten te Paske" <ne...@tepaske.net.invalid> schreef in bericht
> news:slrnbvseu...@zero.analogue.nl...
>
> > Op het moment dat je dat verkeer dropt is het verkeer al je lijn
> > over, dus echt helpen tegen een pingflood doet dat niet.
>
> Dat is niet waar. Ik neem aan dat het probleem zich voordoet op de
> upstream en niet op de downstream en dat het gaat over ADSL. Als het
> probleem zich wel voordoet op de downstream, dan is het type van het
> verkeer (pingflood) niet relevant.
Ik neem aan dat het ging over "mede-gamers" die bewust zijn verbinding
negatief probeerden te beinvloeden. Het is vrij makkelijk om de
downstream van een DSL "lijntje" vol te krijgen. In dat geval heeft
droppen dus geen zin meer.
Pingflood noemde ik omdat men het hier eerder over had.
> Nu werkt PMTU niet met ICMP echo requests, maar hetzelfde geldt voor
> de ICMP messages waar het wel mee werkt natuurlijk.
Daar heb je gelijk in, Wichert wees me hier ook al terecht op. Ik was
ervan uitgegaan dat alle typen ICMP geblokkeert werden, maar ik zie dat
het er toch duidelijk stond.
Julius
> Tja dat is nou eenmaal mijn taalgebruik.
> Iedereen snapt dan direct wat ik bedoel :)
Ik moest deze week op het matje komen bij de bazen
van het bedrijf waar ik veel werk voor verricht, omdat ik
in een email (overigens op persoonlijke titel geschreven)
aan het Commissariaat v.d. Media schreef, and I quote;
"Verder zijn uw eisen sowieso belachelijk dom, grenzend
aan debiel, om niet te zeggen flink amateuristisch. U
heeft er gewoon absoluut geen verstand van, typerend voor een
door oude stoffige mensen gerunde staatsgefinancierde nazi-toko.
Doe er uw voordeel mee dat er mensen als ik rondlopen,
die u eens durven te wijzen op uw gepruts in de marge."
Ik vond hem zelf hilarisch, bijna poëzie eigenlijk wel,
dus de [Send] knop was niet moeilijk in te drukken :-)
Het grappige was dat de mail aanvankelijk heel erg serieus
technisch kritiek geeft op hun eisen aangaande de zgn. bewaarplicht
voor radio-stations, maar dat 'ie dus met deze alinea eindigt :-D
Ik moest zelf denken aan een Monty Python scetch. Ik weet
dat er hier mensen zijn die daar wel begrip voor hebben,
maar die instantie dacht dat ik serieus was. Haha.
Just another day in the life of een vuurpaard, nietwaar Danny?
--
Julius
http://jult.net/ http://jthz.com/
"I'm holding an 'I Don't Give A Shit'-o-meter
and the needle's not moving." - D. Coupland
michael
"Julius" <meo...@the.moon> wrote in message
news:ijmuvvg2ot8ckp9u29n1il05dq54ed8l7g@julius...
> Ik moest deze week op het matje komen bij de bazen
> van het bedrijf waar ik veel werk voor verricht, omdat ik
> in een email (overigens op persoonlijke titel geschreven)
> aan het Commissariaat v.d. Media schreef, and I quote;
>
Danny
>Just another day in the life of een vuurpaard, nietwaar Danny?
Heeeeeeeeeeeeeel herkenbaar ;-)
Milan
"Willem" <geenem...@cistron.nl> schreef in bericht
news:61nsvvkabk732u0j8...@4ax.com...
> Pinging www.cistron.nl [62.216.30.254] with 32 bytes of data:
>
> Reply from 62.216.30.254: bytes=32 time=31ms TTL=61
> Reply from 62.216.30.254: bytes=32 time=15ms TTL=61
> Reply from 62.216.30.254: bytes=32 time=15ms TTL=61
Jemig die van mij doet time=27 ongeveer. Heb een SMC 7401 over analoog. Waar
kan dat aan liggen?
Milan
Aldert Zomer
"Milan" <mi...@nee.geen.spam.selwerd.nl.nospam> wrote in message
news:btojr3$b80$1...@news.cistron.nl...
Geen last van, je draait zeker linux? Een gratis OS, dat kan nooit goed
zijn....
--
Aldert
www.zomeronline.net
Ma$$!m0
Als je geen verstand hebt van OS'en , moet je er niet over praten.
groetjes Msss
The Legend
"Jochem van Dieten" <nom...@devnull.invalid> schreef in bericht
news:btm0ak$7qh$1...@news.tudelft.nl...
En dan blijf jij vervolgens bij 3 verschillende ISP's dezelfde topics lezen?
Man wat zal jij een saai internet leven hebben.
Ed