Bekijk Volledige Versie : Telenet DHCP in panne?
Heeft er iemand iets opgevangen of ondervonden van een DHCP panne bij
telenet?
Ik zit hier op logs van een firewall (Watchguard Firebox SOHO) te kijken
met een eindeloze stroom van meldingen zoals deze:
>> DHCP: DHCP response has incorrect id 4294954780 @2004-01-05-13:54:18
Het ID-nummer zit verdacht dicht bij de 4 giga (4294954780 = 0xFFFFCF1C),
het zou dus wel eens met een overflow (32 bit) kunnen te maken hebben.
Intussen is het bakske zijn IP-adres blijkbaar kwijt (die hierboven is de
laatste melding die ik doorkreeg: de meldingen worden via syslog-protocol
gelogd, en zolang het lukt worden error-niveau en hoger via een VPN-tunnel
naar mij doorgesluisd, ik zit er 7 kilometer vanaf, de tunnel ligt al bijna
een uur plat nu).
op/on 05-01-2004 14:52 schreef/wrote Lucvdv :
> Heeft er iemand iets opgevangen of ondervonden van een DHCP panne bij
> telenet?
Ja
Zie statuspagina (sinds kort - hoe vaag kan een melding zijn)
Zie <news:pandora.pub>
zie PUB forum.
--
De VRT moet de video voor iedereen aanbieden op
http://www.50jaar.tv/
Teken de petitie !
http://www.petitiononline.com/50Jaar/petition.html/
On Mon, 05 Jan 2004 15:16:45 +0100, Wannes wrote:
> op/on 05-01-2004 14:52 schreef/wrote Lucvdv :
>
>> Heeft er iemand iets opgevangen of ondervonden van een DHCP panne bij
>> telenet?
>
> Ja
>
> Zie statuspagina (sinds kort - hoe vaag kan een melding zijn)
> Zie <news:pandora.pub>
> zie PUB forum.
Het probleem is dat ik de pandora-groepen en de statuspagina niet kan zien
zonder IP-adres, en waar ik nu zit (easynet ADSL) al evenmin :)
Ik kan wel vanavond thuis eens kijken (in de veronderstelling dat ik daar
wel een IP krijg), bedankt voor de tip.
"Lucvdv" <name@null.net> schreef in bericht
news:1a62zfiz8q57j$.1l0ckyuzsun8o.dlg@40tude.net.. .
> On Mon, 05 Jan 2004 15:16:45 +0100, Wannes wrote:
>
> > op/on 05-01-2004 14:52 schreef/wrote Lucvdv :
> >
> >> Heeft er iemand iets opgevangen of ondervonden van een DHCP panne bij
> >> telenet?
> >
> > Ja
> >
> > Zie statuspagina (sinds kort - hoe vaag kan een melding zijn)
> > Zie <news:pandora.pub>
> > zie PUB forum.
>
> Het probleem is dat ik de pandora-groepen en de statuspagina niet kan zien
> zonder IP-adres, en waar ik nu zit (easynet ADSL) al evenmin :)
>
> Ik kan wel vanavond thuis eens kijken (in de veronderstelling dat ik daar
> wel een IP krijg), bedankt voor de tip.
Wachtebeke (ten noorden van Gent)
Hier werkt het opnieuw, gans de namiddag zonder ip gezeten. Vanaf half zes
opnieuw een ip gekregen.
Dank u Telenet.
Lame 'T Rust
05/01/04, 19:30
begin van antwoord op Wannes <Wannes@gmx.net.invalid>
>
>Ja
>
>Zie statuspagina (sinds kort - hoe vaag kan een melding zijn)
>Zie <news:pandora.pub>
>zie PUB forum.
LOL, 't is weer te simplistisch hoor... heb jij wel door dat 90 % van
Internet gebruikers niet weten wat een DHCP is? Voor de gevorderden
(waar je jezelf toerekent) had je kunnen verwijzen naar
http://www.telenet.be/klantendienst/internet/statuspagina/statusservers/index.php,
of hoe uitgebreid meldingen kunnen zijn.
--
In a perfect world... spammers would get caught,
go to jail, and share a cell with many men
who have enlarged their penisses, taken Viagra
and are looking for a new relationship.
Lame 'T Rust
/ignore
..end
op/on 05-01-2004 19:22 schreef/wrote Lame 'T Rust :
>> Zie statuspagina (sinds kort - hoe vaag kan een melding zijn)
>> Zie <news:pandora.pub>
>> zie PUB forum.
>
> LOL, 't is weer te simplistisch hoor... heb jij wel door dat 90 % van
> Internet gebruikers niet weten wat een DHCP is? Voor de gevorderden
> (waar je jezelf toerekent) had je kunnen verwijzen naar
> http://www.telenet.be/klantendienst/internet/statuspagina/statusservers/index.
> php
> of hoe uitgebreid meldingen kunnen zijn.
Leuter maar verder, toen mijn bericht gepost werd stonden er daar alleen
groene bollen te blinken.
Lucvdv wrote:
> Heeft er iemand iets opgevangen of ondervonden van een DHCP panne bij
> telenet?
>
> Ik zit hier op logs van een firewall (Watchguard Firebox SOHO) te kijken
> met een eindeloze stroom van meldingen zoals deze:
>
>
>>>DHCP: DHCP response has incorrect id 4294954780 @2004-01-05-13:54:18
>
>
> Het ID-nummer zit verdacht dicht bij de 4 giga (4294954780 = 0xFFFFCF1C),
> het zou dus wel eens met een overflow (32 bit) kunnen te maken hebben.
>
> Intussen is het bakske zijn IP-adres blijkbaar kwijt (die hierboven is de
> laatste melding die ik doorkreeg: de meldingen worden via syslog-protocol
> gelogd, en zolang het lukt worden error-niveau en hoger via een VPN-tunnel
> naar mij doorgesluisd, ik zit er 7 kilometer vanaf, de tunnel ligt al bijna
> een uur plat nu).
Problemen met internet-aansluitingen bij Telenet
------------------------------------------------
18:57:27
BRUSSEL - Er zijn problemen met de internet-aansluitingen van provider
Telenet. Dat bevestigt woordvoerster Paskal Deboosere vanavond aan
Belga. ,,Sommige mensen geraken niet op het internet. Wij proberen het
probleem zo snel mogelijk op te lossen. Veel klanten bellen naar ons
call-center, maar dat heeft momenteel weinig zin", zegt Deboosere.
"In theorie kan één op de twee klanten problemen hebben. Het heeft te
maken met het soort modem dat ze gebruiken. Klanten met een bepaalde
modem krijgen geen verbinding met onze server", aldus nog de woordvoerster.
,,We pakken het streek per streek aan. Momenteel zijn de verbindingen al
helemaal hersteld in Gent en omstreken", zegt Deboosere, die hoopt dat
de problemen "zo snel mogelijk", misschien vanavond, al zouden kunnen
opgelost zijn.
(bron :snelnieuws Standaard)
"achaos" <wanorde@hotmail.com> schreef in bericht
news:3ff9b535$0$1129$6c56d894@feed0.news.be.easyne t.net...
> Lucvdv wrote:
> > Heeft er iemand iets opgevangen of ondervonden van een DHCP panne bij
> > telenet?
> >
> > Ik zit hier op logs van een firewall (Watchguard Firebox SOHO) te kijken
> > met een eindeloze stroom van meldingen zoals deze:
> >
> >
> >>>DHCP: DHCP response has incorrect id 4294954780 @2004-01-05-13:54:18
> >
> >
> > Het ID-nummer zit verdacht dicht bij de 4 giga (4294954780 =
0xFFFFCF1C),
> > het zou dus wel eens met een overflow (32 bit) kunnen te maken hebben.
> >
> > Intussen is het bakske zijn IP-adres blijkbaar kwijt (die hierboven is
de
> > laatste melding die ik doorkreeg: de meldingen worden via
syslog-protocol
> > gelogd, en zolang het lukt worden error-niveau en hoger via een
VPN-tunnel
> > naar mij doorgesluisd, ik zit er 7 kilometer vanaf, de tunnel ligt al
bijna
> > een uur plat nu).
> Problemen met internet-aansluitingen bij Telenet
> ------------------------------------------------
>
> 18:57:27
>
> BRUSSEL - Er zijn problemen met de internet-aansluitingen van provider
> Telenet. Dat bevestigt woordvoerster Paskal Deboosere vanavond aan
> Belga. ,,Sommige mensen geraken niet op het internet. Wij proberen het
> probleem zo snel mogelijk op te lossen. Veel klanten bellen naar ons
> call-center, maar dat heeft momenteel weinig zin", zegt Deboosere.
>
> "In theorie kan één op de twee klanten problemen hebben. Het heeft te
> maken met het soort modem dat ze gebruiken. Klanten met een bepaalde
> modem krijgen geen verbinding met onze server", aldus nog de
woordvoerster.
>
> ,,We pakken het streek per streek aan. Momenteel zijn de verbindingen al
> helemaal hersteld in Gent en omstreken", zegt Deboosere, die hoopt dat
> de problemen "zo snel mogelijk", misschien vanavond, al zouden kunnen
> opgelost zijn.
> (bron :snelnieuws Standaard)
>
>
Gent en omstreken al opgelost? Ik zit regio Aalst en sinds 14:30 ongeveer
geen internet meer.
Zit nu lekker snel via modem :(
Dank U wel Telenet, hopelijk geven ze een vergoeding want dit betekent
achterstand in het werk ...
Jeroen
----
www.be-hosted.be
On Mon, 05 Jan 2004 19:11:08 GMT, "Jeroen" <info@nospam.be-be-hosted>
wrote:
>Dank U wel Telenet, hopelijk geven ze een vergoeding want dit betekent
>achterstand in het werk ...
U heeft een SLA op uw verbinding ?
"xeno" <xenoREMOVE@pandora.be> schreef in bericht
news:s0ejvvkr32117r03r559bofbo6h88s7esi@4ax.com...
> On Mon, 05 Jan 2004 19:11:08 GMT, "Jeroen" <info@nospam.be-be-hosted>
> wrote:
>
> >Dank U wel Telenet, hopelijk geven ze een vergoeding want dit betekent
> >achterstand in het werk ...
>
> U heeft een SLA op uw verbinding ?
Dunno, maar ik hoop dat ze voor hun business klanten toch iets kunnen doen,
heb ooit toch maand gratis internet gehad door problemen van hun kant ...
Kelly De Koninck
05/01/04, 22:34
> > >Dank U wel Telenet, hopelijk geven ze een vergoeding want dit betekent
> > >achterstand in het werk ...
> >
> > U heeft een SLA op uw verbinding ?
>
> Dunno, maar ik hoop dat ze voor hun business klanten toch iets kunnen
doen,
> heb ooit toch maand gratis internet gehad door problemen van hun kant ...
Business-klant of niet; als je geen SLA hebt, heb je in principe geen recht
op compensatie... Business-klant betekent trouwens maar al te vaak gewoon
dat je een factuur krijgt, en het bedrag excl. BTW betaalt...
K
On Mon, 5 Jan 2004 14:52:26 +0100, Lucvdv <name@null.net> wrote:
>Heeft er iemand iets opgevangen of ondervonden van een DHCP panne bij
>telenet?
Hier is het net terug in orde (20u58 - regio Vilvoorde)
mvg,
Marc
Lucvdv <name@null.net> schreef:
> Het probleem is dat ik de pandora-groepen en de statuspagina niet kan
> zien zonder IP-adres, en waar ik nu zit (easynet ADSL) al evenmin :)
Als je een PSTN-modem hebt kan je ook inbellen bij Telenet, de inbelnummers
staan op de helpdesk-site.
--
JanC
"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9
achaos brought next idea :
> "In theorie kan één op de twee klanten problemen hebben. Het heeft te maken
> met het soort modem dat ze gebruiken. Klanten met een bepaalde modem krijgen
> geen verbinding met onze server", aldus nog de woordvoerster.
Er dus duidelijk op aandringen dat ze mijn Motorola meepakken met de
verhuis :D
--
<chris/>
http://www.daily.be/ - your daily fuel...
Sven Teirlinck
05/01/04, 22:45
Op Mon, 05 Jan 2004 21:17:08 GMT, ÷ chris ÷ schreef in bericht
<mesnews.2d397d41.d3481cda.3.5639@Milovetechno.com>:
>achaos brought next idea :
>> "In theorie kan één op de twee klanten problemen hebben. Het heeft te maken
>> met het soort modem dat ze gebruiken. Klanten met een bepaalde modem krijgen
>> geen verbinding met onze server", aldus nog de woordvoerster.
>
>Er dus duidelijk op aandringen dat ze mijn Motorola meepakken met de
>verhuis :D
Euh, juist niet. Die krijgen namelijk wel een ip. Het zijn de docsis
modellen die problemen hebben.
--
Sven Teirlinck spreekt in eigen naam met eigen mening
Ik usenet, dus ik ben (s|b)
<http://www.briachons.org/>
Sven Teirlinck submitted this idea :
> Op Mon, 05 Jan 2004 21:17:08 GMT, ÷ chris ÷ schreef in bericht
> <mesnews.2d397d41.d3481cda.3.5639@Milovetechno.com>:
>
>> achaos brought next idea :
>>> "In theorie kan één op de twee klanten problemen hebben. Het heeft te maken
>>> met het soort modem dat ze gebruiken. Klanten met een bepaalde modem
>>> krijgen geen verbinding met onze server", aldus nog de woordvoerster.
>>
>> Er dus duidelijk op aandringen dat ze mijn Motorola meepakken met de
>> verhuis :D
>
> Euh, juist niet. Die krijgen namelijk wel een ip. Het zijn de docsis
> modellen die problemen hebben.
Ik was misschien niet hélemaal duidelijk: ik bedoelde dus weldegelijk
dat ik de Motorola *mee* wil nemen naar m'n nieuwe huis ;) Desnoods
koppel ik hem zelf af en pak hem mee... "Ha? Mocht da ni?"
--
<chris/>
http://www.daily.be/ - your daily fuel...
On Mon, 05 Jan 2004 14:52:26 +0100, Lucvdv wrote:
> Heeft er iemand iets opgevangen of ondervonden van een DHCP panne bij
> Telenet?
De DOCSIS modems hebben er allemaal uitgelegen van 14u tot nu ongeveer.
Het probleem lag bij de DHCP server voor DOCSIS modems.
>>> DHCP: DHCP response has incorrect id 4294954780 @2004-01-05-13:54:18
De CDLP modems hebben er vandaag ook heel even uitgelegen als deze een
nieuw IP aanvroegen of een IP hernieuwden.
--
Heavy-G
#define QUESTION (BB || !BB)
http://users.skynet.be/jaguar/thequestion.html
GigaSurfer
06/01/04, 05:15
"xeno" <xenoREMOVE@pandora.be> wrote in message
news:s0ejvvkr32117r03r559bofbo6h88s7esi@4ax.com...
> On Mon, 05 Jan 2004 19:11:08 GMT, "Jeroen" <info@nospam.be-be-hosted>
> wrote:
>
> >Dank U wel Telenet, hopelijk geven ze een vergoeding want dit betekent
> >achterstand in het werk ...
>
> U heeft een SLA op uw verbinding ?
Als +200.000 klanten een hele namiddag zonder verbinding zitten lijkt het
mij normaal dat ze één of andere compensatie geven, zelfs als ze dat niet
verplicht zijn.
On Mon, 5 Jan 2004 14:52:26 +0100, Lucvdv wrote:
> Heeft er iemand iets opgevangen of ondervonden van een DHCP panne bij
> telenet?
>
> Ik zit hier op logs van een firewall (Watchguard Firebox SOHO) te kijken
> met een eindeloze stroom van meldingen zoals deze:
>
>>> DHCP: DHCP response has incorrect id 4294954780 @2004-01-05-13:54:18
>
> Het ID-nummer zit verdacht dicht bij de 4 giga (4294954780 = 0xFFFFCF1C),
> het zou dus wel eens met een overflow (32 bit) kunnen te maken hebben.
>
> Intussen is het bakske zijn IP-adres blijkbaar kwijt (die hierboven is de
> laatste melding die ik doorkreeg: de meldingen worden via syslog-protocol
> gelogd, en zolang het lukt worden error-niveau en hoger via een VPN-tunnel
> naar mij doorgesluisd, ik zit er 7 kilometer vanaf, de tunnel ligt al bijna
> een uur plat nu).
Stand 's anderendaags 10u30: probleem opgelost(?) vanaf 2 uur vannacht,
maar zet dat "opgelost" maar tussen aanhalingstekens, want ik krijg nog
regelmatig een of meer van diezelfde DHCP-foutmeldingen waar het gisteren
mee begonnen is (incorrect ID).
Die meldingen kwamen trouwens sporadisch al voor vanaf 31/12.
> Stand 's anderendaags 10u30: probleem opgelost(?) vanaf 2 uur vannacht,
> maar zet dat "opgelost" maar tussen aanhalingstekens, want ik krijg nog
> regelmatig een of meer van diezelfde DHCP-foutmeldingen waar het gisteren
> mee begonnen is (incorrect ID).
>
> Die meldingen kwamen trouwens sporadisch al voor vanaf 31/12.
Wat zou er juist defect geweest zijn?
En hoe hebben ze het juist opgelost?
On Mon, 05 Jan 2004 20:04:23 +0100, achaos wrote:
> "In theorie kan één op de twee klanten problemen hebben. Het heeft te
> maken met het soort modem dat ze gebruiken. Klanten met een bepaalde
> modem krijgen geen verbinding met onze server", aldus nog de woordvoerster.
Iedereen met een DOCSIS modem dus.
Nu wil het toeval dat ik twee telenet-accounts gebruik, een met DOCSIS en
een met een oudere modem, en al *maanden* DHCP-rariteiten ondervind met die
DOCSIS.
Een eerste rariteit is dat een DHCP Release die van achter een DOCSIS modem
komt, door de server genegeerd wordt.
Hoe release je dan wel? Truc voor wie van PC wil wisselen en geen hele
nacht wil wachten eer de nieuwe op internet kan (want zo lang duurt het):
netstekker van de modem even uittrekken en terug insteken.
Tweede rariteit: een DHCP server geeft bij een lease twee tijdstippen,
T1 = het tijdstip dat aangeraden wordt om een verlenging aan te vragen,
T2 = vanaf wanneer de client, als een verlenging nog niet gelukt is, er van
moet uitgaan dat de server weg is en in plaats van een renew een discover
proberen om een nieuwe server te vinden.
Bij DOCSIS modems zitten T1 en T2 in omgekeerde volgorde: T2 is altijd
kleiner dan T1. Bij de oudere (CuberSurfr Wave) modems is dat niet het
geval, terwijl je nochtans zou vermoeden dat het om dezelfde server gaat.
Een goedgeschreven DHCP client interpreteert het verstrijken van T2 als "ik
hoor de server wel niet meer, maar voor in het geval dat hij mij nog kan
horen stuur ik best toch een release voor ik een andere server ga zoeken".
Adres kwijt dus: meestal maar een paar seconden (de klant merkt het niet
eens), tenzij er iets fout gaat.
Wanneer een DHCP client probeert zijn lease te verlengen vóór het tijdstip
dat de server daarvoor opgegeven heeft (T1), al is het maar 1 seconde te
vroeg, wordt de lease niet verlengd maar gewoon het restant van de periode
nog eens bevestigd met een nieuwe T1 en T2 erbij (bij telenet: ik heb dit
onderzocht bij andere DHCP servers, en die geven wel een volledige nieuwe
lease).
Gebeurt de volgende poging _weer_ te vroeg, dan negeert de DHCP server een
tijd lang alle verdere aanvragen van die client -- meestal is dat tot een
aantal minuten voor de lease echt verstreken is, maar af en toe heb ik het
zien gebeuren tot *nadat* die verstreken was (en de klant dus geen IP meer
had).
Hier is het dat de problemen beginnen als je toevallig een D-Link firewall
in huis hebt (tenminste het type dat hier naast mij terug in de verpakking
staat, een DI-804V). Of het nu is doordat hij in de war raakt door die
omgekeerde T1 en T2, of het een andere bug is: die negeert blijkbaar T2 en
doet pas een discover als hij zijn adres echt kwijt is, probeert *altijd*
zijn lease te hernieuwen kort voor de opgegeven T1 in plaats van te wachten
tot die volledig verstreken is, staat bijgevolg regelmatig te roepen tegen
een DHCP-server die hem niet wil horen, en raakt tot een paar keer per dag
zijn adres kwijt. Soms voor seconden, soms voor minuten.
Bij telenet hebben ze hun eigen DHCP server geschreven.
Vermoedelijk bedoelen ze met T2 < T1 dat een DOCSIS client nooit een renew
moet aanvragen, maar altijd direct een discover moet doen *terwijl hij zijn
oude adres zolang nog houdt*.
Analyse van netwerklogs wijst echter uit dat sommige clients (software,
externe zoals firewalls zijn moeilijker te loggen) het er allesbehalve mee
eens zijn dat dat een geldige configuratie is.
Je ziet dus de gekste dingen gebeuren. Bijvoorbeeld: clients die spontaan
hun adres releasen op tijdstip T2, dat onmiddellijk laten volgen door een
discover en vervolgens hetzelfde IP-adres terugkrijgen -- soms met een
kortere lease (T2 < T1, en de server geeft pas een echte verlenging als de
aanvraag binnenkomt nadat T1 verstreken is).
Hier of daar kan ik er nog wel naast zitten, maar dit is het beeld dat ik
me in de loop van 4 maanden zoeken naar een oplossing voor problemen met
o.a. de D-Link opgebouwd heb.
(Een oplossing om zo'n D-Link achter een DOCSIS te gebruiken is er niet).
On Mon, 05 Jan 2004 21:35:17 GMT, Sven Teirlinck wrote:
> Op Mon, 05 Jan 2004 21:17:08 GMT, ÷ chris ÷ schreef in bericht
> <mesnews.2d397d41.d3481cda.3.5639@Milovetechno.com>:
>
>>achaos brought next idea :
>>> "In theorie kan één op de twee klanten problemen hebben. Het heeft te maken
>>> met het soort modem dat ze gebruiken. Klanten met een bepaalde modem krijgen
>>> geen verbinding met onze server", aldus nog de woordvoerster.
>>
>>Er dus duidelijk op aandringen dat ze mijn Motorola meepakken met de
>>verhuis :D
>
> Euh, juist niet. Die krijgen namelijk wel een ip. Het zijn de docsis
> modellen die problemen hebben.
De DOCSIS waar ik geen IP mee kreeg was er een van Motorola...
Je hebt bij telenet (minstens) twee modellen Motorola-modems: de oude
platte zwarte, en witte die vertikaal tegen de moor kunnen gemonteerd
worden. Die laatste zijn DOCSIS modems.
On Tue, 06 Jan 2004 10:47:20 GMT, .no1sname wrote:
> Wat zou er juist defect geweest zijn?
> En hoe hebben ze het juist opgelost?
Telenet gebruikt een zelfgeschreven DHCP server.
Ofwel hebben ze die willen upgraden en zat er een bug in de nieuwe versie,
ofwel hebben ze gisteren in alle haast een upgrade moeten schrijven om een
oudere bug op te lossen.
Dat er in de foutmelding een ID-nummer stond dat vlak tegen de limiet zit
van wat in 32 bits past, zou wel eens op het tweede kunnen wijzen
(volgnummers die geincrementeerd worden tot ze aan 4 miljard en zoveel
komen en een overflow de server ziek maakt).
Aan de andere kant, het feit dat het zich bij hernieuwingen van de lease
nog altijd in mindere mate voordoet kan op het tegendeel wijzen.
Ik heb de foutmeldingen nog gehad om 4u46, 9u46 en daarnet om 12u15.
Om 4u46 is gelijktijdig ook heel even de verbinding weggeweest.
On Tue, 06 Jan 2004 04:06:16 GMT, "GigaSurfer" <GigaSurfer@in.valid>
wrote:
>> U heeft een SLA op uw verbinding ?
>
>Als +200.000 klanten een hele namiddag zonder verbinding zitten lijkt het
>mij normaal dat ze één of andere compensatie geven, zelfs als ze dat niet
>verplicht zijn.
Doet Electrabel dat ook als een hele regio ineens een half uur zonder
stroom zit ? In het geval van Electrabel mag je al blij zijn dat er
een mededeling komt dat er een probleem was...
Tijdje terug nog een uurtje een dode BC vaste lijn gehad. Naderhand
eens bij storingen geinformeerd. Probleem ? Er waren geen problemen
geweest.
Skynet die vorig jaar maaaaanden een mail-malaise gehad heeft. Hebben
ze daar ooit enige compensatie voor gegeven ? Ze hebben de problemen
amper toegegeven...
Maar nu gebeurt er iets bij TN en plots verwacht iedereen 6 maanden
gratis surfen.
Beetje kortzichtige hypocrieten hier medunkt.
On Tue, 06 Jan 2004 12:31:16 GMT, xeno wrote:
> Doet Electrabel dat ook als een hele regio ineens een half uur zonder
> stroom zit ? In het geval van Electrabel mag je al blij zijn dat er
> een mededeling komt dat er een probleem was...
De elektriciteit die je in dat half uur verbruikt hebt wordt niet
aangerekend ;-)
> Tijdje terug nog een uurtje een dode BC vaste lijn gehad. Naderhand
> eens bij storingen geinformeerd. Probleem ? Er waren geen problemen
> geweest.
Dat eenvoudig de laatste zijn waar je mee gebeld hebt die zijn telefoon
slecht opgelegd heeft. Dat geeft alle symptomen van een dode lijn.
> Skynet die vorig jaar maaaaanden een mail-malaise gehad heeft. Hebben
> ze daar ooit enige compensatie voor gegeven ? Ze hebben de problemen
> amper toegegeven...
Vorig jaar? Wij zijn drie jaar geleden van bij skynet naar easynet
verhuisd om die reden...
> Maar nu gebeurt er iets bij TN en plots verwacht iedereen 6 maanden
> gratis surfen.
>
> Beetje kortzichtige hypocrieten hier medunkt.
Al ooit iets anders geweten bij telenet-klanten?
Ze willen allemaal de snelheid van ethernet en onbeperkte trafiek voor een
lagere prijs dan je in het buitenland betaalt voor 256 kilobit.
Aan de andere kant, dat is wat telenet in de tenten _beloofde_ toen ze
opkwamen, en wat ze van hun eerste klanten (die het hadden) zonder boe of
ba terug afgenomen hebben.
On Tue, 6 Jan 2004 13:40:10 +0100, Lucvdv <name@null.net> wrote:
>De elektriciteit die je in dat half uur verbruikt hebt wordt niet
>aangerekend ;-)
De paar internet loze uren zorgen ook voor geen volume verbruik :-)
>Dat eenvoudig de laatste zijn waar je mee gebeld hebt die zijn telefoon
>slecht opgelegd heeft. Dat geeft alle symptomen van een dode lijn.
Tiens, dan hadden mijn buren links en rechts toevallig net hetzelfde
voor op dezelfde dag rond hetzelfde uur ?
>Aan de andere kant, dat is wat telenet in de tenten _beloofde_ toen ze
>opkwamen, en wat ze van hun eerste klanten (die het hadden) zonder boe of
>ba terug afgenomen hebben.
BC belooft de was te komen laten ophangen door een installateur...
Reclame praat moet je steeds met een korrel zout nemen...
"xeno" <xenoREMOVE@pandora.be> schreef in bericht
news:fdalvvocpvt9jgaoib3u5dqu810kaqavj5@4ax.com...
> On Tue, 06 Jan 2004 04:06:16 GMT, "GigaSurfer" <GigaSurfer@in.valid>
> wrote:
>
> >> U heeft een SLA op uw verbinding ?
> >
> >Als +200.000 klanten een hele namiddag zonder verbinding zitten lijkt het
> >mij normaal dat ze één of andere compensatie geven, zelfs als ze dat niet
> >verplicht zijn.
>
> Doet Electrabel dat ook als een hele regio ineens een half uur zonder
> stroom zit ? In het geval van Electrabel mag je al blij zijn dat er
> een mededeling komt dat er een probleem was...
Tja, er is nog een tijd geweest als je 2h na de melding van jou kant nog
zonder electriciteit zit wegens een technisch defect, dan kreeg je 50 ?
schadevergoeding.
On Tue, 06 Jan 2004 12:57:43 GMT, xeno wrote:
> On Tue, 6 Jan 2004 13:40:10 +0100, Lucvdv <name@null.net> wrote:
>
>>De elektriciteit die je in dat half uur verbruikt hebt wordt niet
>>aangerekend ;-)
Rapper getikt dan mijn gedachten konden volgen: daar had moeten staan "zou
verbruikt hebben" ;)
Je betaalt voor een maand. Werkt het maar 30 dagen van de 31 door hun
eigen fout, dan verwacht je een compensatie. In andere gevallen
(olieprospector boort dwars door de backbone, sportvliegtuig crasht op
datacenter, ...) wil ik toegeeflijker zijn, zelfs al duurt het een paar
dagen in plaats van een halve.
>>Dat eenvoudig de laatste zijn waar je mee gebeld hebt die zijn telefoon
>>slecht opgelegd heeft. Dat geeft alle symptomen van een dode lijn.
>
> Tiens, dan hadden mijn buren links en rechts toevallig net hetzelfde
> voor op dezelfde dag rond hetzelfde uur ?
En nog een snelheidsfoutje: moest zijn "Dat kan eenvoudig ..." - met de
gegevens uit je bericht kon ik niets weten over je buren.
>>Aan de andere kant, dat is wat telenet in de tenten _beloofde_ toen ze
>>opkwamen, en wat ze van hun eerste klanten (die het hadden) zonder boe of
>>ba terug afgenomen hebben.
>
> BC belooft de was te komen laten ophangen door een installateur...
>
> Reclame praat moet je steeds met een korrel zout nemen...
Natuurlijk, ik reclameer ook niet, ik stel alleen maar vast.
Zo'n voorwaarden zouden niet rendabel te verwezenlijken zijn. Als het te
mooi klinkt om te geloven, geloof je het best ook niet.
Ik probeer gewoon de argumenten van de twee kanten naast elkaar te zien, en
ga er van uit dat de beste weg er in het midden tussen loopt.
op/on 06-01-2004 13:05 schreef/wrote Lucvdv :
> Bij DOCSIS modems zitten T1 en T2 in omgekeerde volgorde: T2 is altijd
> kleiner dan T1. Bij de oudere (CuberSurfr Wave) modems is dat niet het
> geval, terwijl je nochtans zou vermoeden dat het om dezelfde server gaat.
Eurodocsis en CDLP (CyberSurfr) modems hebben een andere DHCP.
op/on 06-01-2004 13:07 schreef/wrote Lucvdv :
>>> Er dus duidelijk op aandringen dat ze mijn Motorola meepakken met de
>>> verhuis :D
>>
>> Euh, juist niet. Die krijgen namelijk wel een ip. Het zijn de docsis
>> modellen die problemen hebben.
>
> De DOCSIS waar ik geen IP mee kreeg was er een van Motorola...
>
> Je hebt bij telenet (minstens) twee modellen Motorola-modems: de oude
> platte zwarte, en witte die vertikaal tegen de moor kunnen gemonteerd
> worden. Die laatste zijn DOCSIS modems.
Er zijn 5 Motorola's :o)
http://www.telenet.be/klantendienst/internet/hardware/kabelmodem/index.php
2 versies van Motorola's proprietary CDLP, de CyberSurfr en de CyberSurfr
(wit) Wave (donkergrijs)
3 versies naar Eurodocsis standaard, de SurfBoards SB4100, SB4200E en SB5100
On Tue, 06 Jan 2004 15:36:49 +0100, Wannes wrote:
> op/on 06-01-2004 13:05 schreef/wrote Lucvdv :
>
>> Bij DOCSIS modems zitten T1 en T2 in omgekeerde volgorde: T2 is altijd
>> kleiner dan T1. Bij de oudere (CuberSurfr Wave) modems is dat niet het
>> geval, terwijl je nochtans zou vermoeden dat het om dezelfde server gaat.
>
> Eurodocsis en CDLP (CyberSurfr) modems hebben een andere DHCP.
Of één DHCP die multihomed is...
Zie screenshot, link gisteren ergens in deze thread gepost: je ziet daar
twee verschillende DHCP servers babbelen met dezelfde client.
On Tue, 6 Jan 2004 16:08:41 +0100, Lucvdv wrote:
> Zie screenshot, link gisteren ergens in deze thread gepost: je ziet daar
> twee verschillende DHCP servers babbelen met dezelfde client.
Sorry, was niet hier gepost.
De URL is http://users.pandora.be/dweezil/ethereal.jpg
De client stuurt een release naar 195.130.132.97, dus je mag er van uitgaan
dat zijn vorige lease van daar verkregen was. De nieuwe lease komt van
81.82.214.65, en je ziet ook nog DHCP broadcasts komen van 81.83.103.129 en
10.18.220.1 (private range, dus ergens een totaal verkeerde configuratie
als dat bij de klant aankomt).
Lucvdv <name@null.net> schreef:
>> Eurodocsis en CDLP (CyberSurfr) modems hebben een andere DHCP.
>
> Of één DHCP die multihomed is...
CDLP & DOCSIS hebben verschillende DHCPs (volgens meldingen op de
statuspagina zelfs meerdere voor elk, aangezien ze afzonderlijk off-line
kunnen gaan).
--
JanC
"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9
Jan (rot13 prefix)
06/01/04, 17:45
On Tue, 6 Jan 2004 13:05:32 +0100, Lucvdv <name@null.net> wrote:
>--snip--helaas geknipt vanwege de lengte van mijn posting--
Tegen dezelfde problemen ben ik ruim een jaar geleden ook opgelopen.
Nooit geweten dat het modem afhankelijk was.
Gemaild naar support: geen antwoord en gepost op pandora.pub
Poting naar pandora.pub 12-20-02 01:35:
Na ingebruikneming van een Sitecom broadband routertje (zo broadband
bleek deze niet te zijn, max gemeten throughput 310kB/s) viel het mij
op dat er iets met het verlengen van de DHCP lease op het Telenet
netwerk niet goed ging.
Op het tijdstip dat de Sitecom de lease wilde verlengen stuurde deze
een request naar de DHCP server waarvan het adres bekend was uit de
vorige verlengde lease. De DHCP server komt echter NOOIT terug op deze
requests.
De Sitecom router blijft vervolgens anderhalf uur lang, elke minuut,
requests sturen die nooit beantwoord worden. (frames 1 en 237, zie
onder)
Hierna geeft de router het kennelijk op (aflopen counter t2?) want de
router stuurt nu een DHCP request BROADCAST (frame 250) die meteen
door de DHCP server beantwoord wordt (frame 253) met het verlenen van
een nieuwe lease.
Dit is niet iets om wakker over te liggen want de lease wordt immers
verlengd en de hoeveelheid overbodig uitgezonden frames valt ook mee.
Windows doet het iets anders. Die stuurt bij aflopen van de lease een
DHCP request broadcast die meteen beantwoord wordt door de server (zie
frames 1001 en 1002).
Nu kreeg ik ook de beschikking over een Edimax routertje (deze is
beter "broadband", beter dan 500kB/s). Ik verwachte, omdat het
concept en ontwerp totaal anders is dan de Sitecom, dat deze geen
problemen zou hebben met de DHCP lease. Bleek echter niet zo te zijn.
Eerst leek de router eender te reageren als de Sitecom door om de
minuut de requests naar de DHCP server te sturen maar naarmate de tijd
verstreek begon de Edimax steeds vaker frames te zenden. Dit liep tot
vlak voor het verlopen van de lease op tot 40 packets/seconde. Bij
elke lease verlenging werden tienduizenden overbodige packets
verstuurd. Nu hoop ik en verwacht ik dat deze frames niet verder komen
dan het kabelmodem want het zou anders een zware (upload) belasting
voor het netwerk zijn met een aantal van dergelijke gebruikers.
Toch denk ik dat de manier van lease verlengen door de 2 routertjes
geen onjuiste manier is zoals beschreven in rfc1541.
Tekst en statediagram zijn hier, vind ik, niet eenduidig over.
Maar de DHCP server zou m.i. moeten antwoorden op requests gericht aan
het DHCP server adres dat in een eerdere vernieuwing gegeven is.
Naast deze 2 type routers is het aan te nemen dat er meer
hardware/software is die op dezelfde manier reageert.
Bovendien werkt een relase of een renew IP niet.
met vriendelijke groet,
Jan A
bijl.:
DHCP rfc 1541 http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1541.html
-----------------------------------------------------------------------------------------------------
---Mijn client vraagt aan de DHCP server (195.130.132.97) (t1=0)
vernieuwing van de lease-
(op basis van een eerder verkregen lease zoals frame 253)
Frame 1 (590 bytes on wire, 590 bytes captured)
Ethernet II, Src: 00:80:5f:5d:b8:98, Dst: 02:00:00:00:00:00
Internet Protocol, Src Addr: 213.119.89.98 (213.119.89.98), Dst Addr:
195.130.132.97 (195.130.132.97)
User Datagram Protocol, Src Port: 68 (68), Dst Port: bootp (67)
Bootstrap Protocol
Message type: Boot Request (1)
Hardware type: Ethernet
Hardware address length: 6
Hops: 0
Transaction ID: 0x3a8d0300
Seconds elapsed: 7936
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 213.119.89.98 (213.119.89.98)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 0.0.0.0 (0.0.0.0)
Client hardware address: 00:80:5f:5d:b8:98
Server host name not given
Boot file name not given
Magic cookie: (OK)
Option 53: DHCP Message Type = DHCP Request
Option 55: Parameter Request List
1 = Subnet Mask
3 = Router
6 = Domain Name Server
15 = Domain Name
Option 61: Client identifier
Hardware type: Ethernet
Client hardware address: 00:80:5f:5d:b8:98
Option 12: Host Name = "SCE62100"
End Option
Padding
-------------Anderhalf uur lang, 1 frame/minuut zoals frame 1-----
Frame 237 (590 bytes on wire, 590 bytes captured)
Ethernet II, Src: 00:80:5f:5d:b8:98, Dst: 02:00:00:00:00:00
Internet Protocol, Src Addr: 213.119.89.98 (213.119.89.98), Dst Addr:
195.130.132.97 (195.130.132.97)
User Datagram Protocol, Src Port: 68 (68), Dst Port: bootp (67)
Bootstrap Protocol
Message type: Boot Request (1)
Hardware type: Ethernet
Hardware address length: 6
Hops: 0
Transaction ID: 0x1ad50300
Seconds elapsed: 7936
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 213.119.89.98 (213.119.89.98)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 0.0.0.0 (0.0.0.0)
Client hardware address: 00:80:5f:5d:b8:98
Server host name not given
Boot file name not given
Magic cookie: (OK)
Option 53: DHCP Message Type = DHCP Request
Option 55: Parameter Request List
1 = Subnet Mask
3 = Router
6 = Domain Name Server
15 = Domain Name
Option 61: Client identifier
Hardware type: Ethernet
Client hardware address: 00:80:5f:5d:b8:98
Option 12: Host Name = "SCE62100"
End Option
Padding
------------------------------------------------------------
Mijn DHCP client heeft het opgegeven (t2=0 )en stuurt nu een DHCP
request aan ff ff ff ff
----------------------------------------------------------------------------
Frame 250 (590 bytes on wire, 590 bytes captured)
Ethernet II, Src: 00:80:5f:5d:b8:98, Dst: ff:ff:ff:ff:ff:ff
Internet Protocol, Src Addr: 213.119.89.98 (213.119.89.98), Dst Addr:
255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: 68 (68), Dst Port: bootp (67)
Bootstrap Protocol
Message type: Boot Request (1)
Hardware type: Ethernet
Hardware address length: 6
Hops: 0
Transaction ID: 0x2ed50300
Seconds elapsed: 7936
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 213.119.89.98 (213.119.89.98)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 0.0.0.0 (0.0.0.0)
Client hardware address: 00:80:5f:5d:b8:98
Server host name not given
Boot file name not given
Magic cookie: (OK)
Option 53: DHCP Message Type = DHCP Request
Option 55: Parameter Request List
1 = Subnet Mask
3 = Router
6 = Domain Name Server
15 = Domain Name
Option 61: Client identifier
Hardware type: Ethernet
Client hardware address: 00:80:5f:5d:b8:98
Option 12: Host Name = "SCE62100"
End Option
Padding
-----Nieuwe lease info van DHCP server als antwoord op frame 250
---------
Frame 253 (345 bytes on wire, 345 bytes captured)
Ethernet II, Src: 02:00:00:00:00:00, Dst: 00:80:5f:5d:b8:98
Internet Protocol, Src Addr: 81.82.46.129 (81.82.46.129), Dst Addr:
213.119.89.98 (213.119.89.98)
User Datagram Protocol, Src Port: bootp (67), Dst Port: 68 (68)
Bootstrap Protocol
Message type: Boot Reply (2)
Hardware type: Ethernet
Hardware address length: 6
Hops: 0
Transaction ID: 0x2ed50300
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 213.119.89.98 (213.119.89.98)
Your (client) IP address: 213.119.89.98 (213.119.89.98)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 81.82.46.129 (81.82.46.129)
Client hardware address: 00:80:5f:5d:b8:98
Server host name not given
Boot file name not given
Magic cookie: (OK)
Option 53: DHCP Message Type = DHCP ACK
Option 54: Server Identifier = 195.130.132.97 <*********DHCP
Server ADDRESS**
Option 51: IP Address Lease Time = 2 hours
Option 1: Subnet Mask = 255.255.255.0
Option 58: Renewal Time Value = 30 minutes, 1 second
Option 59: Rebinding Time Value = 30 minutes
Option 6: Domain Name Server
IP Address: 195.130.131.3
IP Address: 195.130.130.3
Option 15: Domain Name = "pandora.be"
Option 3: Router = 213.119.89.1
End Option
----------------------------------------------------------------------------------------------------
-------DHCP request en verlenging door Windows (winsock2 1998)-------
Frame 1001 (342 bytes on wire, 342 bytes captured)
Arrival Time: Dec 16, 2002 18:47:32.371767000
Time delta from previous packet: 0.000000000 seconds
Time relative to first packet: 0.000000000 seconds
Frame Number: 1
Packet Length: 342 bytes
Capture Length: 342 bytes
Ethernet II, Src: 00:80:5f:5d:b8:98, Dst: ff:ff:ff:ff:ff:ff
Destination: ff:ff:ff:ff:ff:ff (Broadcast)
Source: 00:80:5f:5d:b8:98 (Compaq_5d:b8:98)
Type: IP (0x0800)
Internet Protocol, Src Addr: 213.119.89.98 (213.119.89.98), Dst Addr:
255.255.255.255 (255.255.255.255)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN:
0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 328
Identification: 0x1219
Flags: 0x00
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: UDP (0x11)
Header checksum: 0xf8b2 (correct)
Source: 213.119.89.98 (213.119.89.98)
Destination: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: 68 (68), Dst Port: bootp (67)
Source port: 68 (68)
Destination port: bootp (67)
Length: 308
Checksum: 0x5bc3 (correct)
Bootstrap Protocol
Message type: Boot Request (1)
Hardware type: Ethernet
Hardware address length: 6
Hops: 0
Transaction ID: 0xec0d4b02
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 213.119.89.98 (213.119.89.98)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 0.0.0.0 (0.0.0.0)
Client hardware address: 00:80:5f:5d:b8:98
Server host name not given
Boot file name not given
Magic cookie: (OK)
Option 53: DHCP Message Type = DHCP Request
Option 61: Client identifier
Hardware type: Ethernet
Client hardware address: 00:80:5f:5d:b8:98
Option 12: Host Name = "Compaqje"
Option 81: Client Fully Qualified Domain Name (12 bytes)
Option 60: Vendor class identifier = "MSFT 98"
Option 55: Parameter Request List
1 = Subnet Mask
15 = Domain Name
3 = Router
6 = Domain Name Server
44 = NetBIOS over TCP/IP Name Server
46 = NetBIOS over TCP/IP Node Type
47 = NetBIOS over TCP/IP Scope
43 = Vendor-Specific Information
77 = User Class Information
End Option
Padding
Frame 1002 (359 bytes on wire, 359 bytes captured)
Arrival Time: Dec 16, 2002 18:47:32.971733000
Time delta from previous packet: 0.599966000 seconds
Time relative to first packet: 0.599966000 seconds
Frame Number: 2
Packet Length: 359 bytes
Capture Length: 359 bytes
Ethernet II, Src: 02:00:00:00:00:00, Dst: 00:80:5f:5d:b8:98
Destination: 00:80:5f:5d:b8:98 (Compaq_5d:b8:98)
Source: 02:00:00:00:00:00 (02:00:00:00:00:00)
Type: IP (0x0800)
Internet Protocol, Src Addr: 81.82.46.129 (81.82.46.129), Dst Addr:
213.119.89.98 (213.119.89.98)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN:
0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 345
Identification: 0x4fd7
Flags: 0x04
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 249
Protocol: UDP (0x11)
Header checksum: 0x820f (correct)
Source: 81.82.46.129 (81.82.46.129)
Destination: 213.119.89.98 (213.119.89.98)
User Datagram Protocol, Src Port: bootp (67), Dst Port: 68 (68)
Source port: bootp (67)
Destination port: 68 (68)
Length: 325
Checksum: 0x78a5 (correct)
Bootstrap Protocol
Message type: Boot Reply (2)
Hardware type: Ethernet
Hardware address length: 6
Hops: 0
Transaction ID: 0xec0d4b02
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 213.119.89.98 (213.119.89.98)
Your (client) IP address: 213.119.89.98 (213.119.89.98)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 81.82.46.129 (81.82.46.129)
Client hardware address: 00:80:5f:5d:b8:98
Server host name not given
Boot file name not given
Magic cookie: (OK)
Option 53: DHCP Message Type = DHCP ACK
Option 54: Server Identifier = 195.130.132.97
Option 51: IP Address Lease Time = 1 hour, 29 minutes, 58 seconds
Option 1: Subnet Mask = 255.255.255.0
Option 58: Renewal Time Value = 44 minutes, 59 seconds
Option 59: Rebinding Time Value = 1 hour, 18 minutes, 43 seconds
Option 15: Domain Name = "pandora.be"
Option 6: Domain Name Server
IP Address: 195.130.131.3
IP Address: 195.130.130.3
Option 81: Client Fully Qualified Domain Name (12 bytes)
Option 3: Router = 213.119.89.1
End Option
Lucvdv wrote:
> Je betaalt voor een maand. Werkt het maar 30 dagen van de 31 door hun
> eigen fout, dan verwacht je een compensatie.
Maar langs de andere kant: dit jaar telt een dag meer, je betaalt dit jaar
dus minder dan andere jaren.
--
Mvg, JeroenV
<URL:http://www.briachons.org/>
÷ chris ÷ wrote:
> Ik was misschien niet hélemaal duidelijk: ik bedoelde dus weldegelijk
> dat ik de Motorola mee wil nemen naar m'n nieuwe huis ;) Desnoods
> koppel ik hem zelf af en pak hem mee... "Ha? Mocht da ni?"
Dat zal naar alle waarschijnlijkheid niet eens werken (is nodeafhankelijk
AFAIK).
--
Mvg, JeroenV
<URL:http://www.briachons.org/>
op/on 06-01-2004 18:37 schreef/wrote JeroenV :
>> Je betaalt voor een maand. Werkt het maar 30 dagen van de 31 door hun
>> eigen fout, dan verwacht je een compensatie.
>
> Maar langs de andere kant: dit jaar telt een dag meer, je betaalt dit jaar
> dus minder dan andere jaren.
Sterk argument.
Not.
On Tue, 06 Jan 2004 16:36:53 GMT, Jan (rot13 prefix) wrote:
> Eerst leek de router eender te reageren als de Sitecom door om de
> minuut de requests naar de DHCP server te sturen maar naarmate de tijd
> verstreek begon de Edimax steeds vaker frames te zenden.
Ik weet niet meer waar, maar ik heb ooit ergens gelezen dat dit het
aanbevolen gedrag is.
In het begin is het nog niet dringend (T1 is doorgaans op 1/2 van de
lease-periode), dus traag proberen, maar hoe dringender het wordt, hoe
harder proberen om aan een nieuwe lease te raken.
On Tue, 06 Jan 2004 19:01:55 GMT, lucvdv <name@null.net> wrote:
>On Tue, 06 Jan 2004 16:36:53 GMT, Jan (rot13 prefix) wrote:
>
>> Eerst leek de router eender te reageren als de Sitecom door om de
>> minuut de requests naar de DHCP server te sturen maar naarmate de tijd
>> verstreek begon de Edimax steeds vaker frames te zenden.
>
>Ik weet niet meer waar, maar ik heb ooit ergens gelezen dat dit het
>aanbevolen gedrag is.
>
>In het begin is het nog niet dringend (T1 is doorgaans op 1/2 van de
>lease-periode), dus traag proberen, maar hoe dringender het wordt, hoe
>harder proberen om aan een nieuwe lease te raken.
nee, de edimax was fout, de regels zeggen:
(4.1 Constructing and sending DHCP messages)
DHCP clients are responsible for all message retransmission. The client MUST
adopt a retransmission strategy that incorporates a randomized exponential
backoff algorithm to determine the delay between retransmissions. The delay
before the first retransmission MUST be 4 seconds randomized by the value of a
uniform random number chosen from the range -1 to +1. Clients with clocks that
provide resolution granularity of less than one second may choose a non- integer
randomization value. The delay before the next
retransmission MUST be 8 seconds randomized by the value of a uniform number
chosen from the range -1 to +1. The retransmission delay MUST be doubled with
subsequent retransmissions up to a maximum of 64 seconds.
Maar het probleem met de Telenet dhcp is dat het niet op de bedoelde manier
werkt.
Waarschijnlijk is het nog wel volgens de regels maar veel clients hebben er
moeite mee want het zit op de rand van de specs.
het zou moeten zijn:
If the server is identified in the 'server identifier' option in the DHCPREQUEST
message, the server checks to confirm that the requested parameters are
acceptable. Usually, the requested parameters will match those returned to the
client in the DHCPOFFER message; however, the client may choose to request a
different lease duration. Also, there is no requirement that the server cache
the parameters from the DHCPOFFER message. The server must simply check that the
parameters requested in the DHCPREQUEST are acceptable. If the parameters are
acceptable, the server records the new client binding and returns a DHCPACK
message to the client.
maar de server geeft geen antwoord en daarom gebeurt er na gedurende een half
tot anderhalf uur dhcprequest packets verzonden te hebben (En JA, dit komt bij
je UPLOAD gebruik!!!!) dit:
:
If no DHCPACK arrives before time T2 (T2 > T1) before the expiration of the
client's lease on its network address, the client moves to REBINDING state and
sends (via broadcast) a DHCPREQUEST message to extend its lease. The client sets
the 'ciaddr' field in the DHCPREQUEST to its current network address. The client
MUST NOTinclude a 'server identifier' in the DHCPREQUEST message.
Sommige Linux software heeft ook problemen met deze afhandeling.
Jan Anker
On Tue, 06 Jan 2004 20:59:33 +0100, Jan (rot13 prefix) wrote:
> <snip alles: toevoeging ipv commentaar>
4.4.5 Reacquisition and expiration
The client maintains two times, T1 and T2, that specify the times at
which the client tries to extend its lease on its network address.
T1 is the time at which the client enters the RENEWING state and
attempts to contact the server that originally issued the client's
network address. T2 is the time at which the client enters the
REBINDING state and attempts to contact any server. T1 MUST be
earlier than T2, which, in turn, MUST be earlier than the time at
which the client's lease will expire.
Ik wou dat ik de laatste zin in het rood kon zetten: bij DOCSIS modems
voldoet telenet hier *niet* aan.
'MUST' is in de RFC ondubbelzinnig gedefinieerd als "absolute requirement",
toch geeft telenet een T2 die kleiner is dan T1.
Ik denk dat het state transistion diagram in RFC2131 ook belangrijk is.
Onderaan vind je daar de volgorde, vertaald in woorden:
(1) Is T1 verstreken?
Ja --> DHCPREQUEST versturen _naar "leasing server"_
DHCPACK antwoord?
Zo ja, nieuwe lease in orde
Zo nee:
T2 verstreken?
(2) Zo ja, DHCPREQUEST versturen _via broadcast_.
DHCPACK antwoord?
Zo ja, nieuwe lease in orde
DHCPNAK antwoord?
Zo ja: terug naar start (init en DHCPDISCOVER sturen)
Met T2 kleiner dan T1 _zou_ dit ook nog _moeten_ werken, alleen wordt de
eerste DHCPREQUEST voor niks verstuurd. Blijkbaar zijn er echter veel
clients die het diagram niet letterlijk volgen.
Dat het met die clients niet werkt ligt echter niet aan hen, telenet is
degene die in de fout gaat door T2 kleiner te maken dan T1.
Nog een fout van telenet, volgens RFC2131 sectie 4.3.2 (dit komt neer op
een herhaling van wat ik eerder al eens zei, maar nu gedocumenteerd adhv
RFC):
A client MAY choose to renew or extend its lease prior to T1. The
server may choose not to extend the lease (as a policy decision by
the network administrator), but should return a DHCPACK message
regardless.
Bij CLDP modems blijft de server op elke request antwoorden.
Bij DOCSIS wordt hier alleen een eerste keer op geantwoord.
Gebeurt het tweemaal na elkaar, dan negeert de server de client gedurende
enige tijd. Die periode is meestal altijd even lang, maar af en toe
(altijd met dezelfde DHCP client) zijn er afwijkingen: ik heb gevallen
gezien waar het duurde tot nadat de lease verstreken was.
Om dit laatste nog wat erger te maken:
The client records the local time at which the DHCPREQUEST
message is sent for computation of the lease expiration time.
Telenet is zeer strikt (tot op de seconde) in de interpretatie van "vroeger
dan T1", en rekent vanaf het terugsturen van de ACK. Dat is soms echter 1
tot 3 seconden na de request, wat voor gevolg heeft dat een client die de
tijd begint te rekenen vanaf het verzenden van zijn request, zoals in de
RFC opgegeven, in ongeveer een derde van de gevallen "te vroeg" is (ik heb
kilometers logs die dit aantonen, zowel bij DOCSIS als CLDP), bijgevolg bij
een DOCSIS in ongeveer 1/9 van de gevallen in de "geen antwoord" fase
terechtkomt, en een keer op [gelukkig redelijk veel] leidt dit tot
kortstondig verlies van het IP-adres.
Het verlies duurt nooit zeer lang, ik veronderstel dat de gebruiker er in
de meeste gevallen niets van zal merken.
Wannes wrote:
> op/on 06-01-2004 18:37 schreef/wrote JeroenV :
>
>>> Je betaalt voor een maand. Werkt het maar 30 dagen van de 31 door hun
>>> eigen fout, dan verwacht je een compensatie.
>>
>> Maar langs de andere kant: dit jaar telt een dag meer, je betaalt dit
>> jaar dus minder dan andere jaren.
>
> Sterk argument.
> Not.
En dat van luc wel, dat valt mee...
Moest ik compensatie krijgen elke keer één of andere dienst hier uitvalt
zouden ze me elke maand kunnen compenseren. Maar zo werkt het nu eenmaal
niet...
--
Mvg, JeroenV
<URL:http://www.briachons.org/>
GigaSurfer
07/01/04, 21:45
"xeno" <xenoREMOVE@pandora.be> wrote in message
news:fdalvvocpvt9jgaoib3u5dqu810kaqavj5@4ax.com...
> On Tue, 06 Jan 2004 04:06:16 GMT, "GigaSurfer" <GigaSurfer@in.valid>
> wrote:
>
> >> U heeft een SLA op uw verbinding ?
> >
> >Als +200.000 klanten een hele namiddag zonder verbinding zitten lijkt het
> >mij normaal dat ze één of andere compensatie geven, zelfs als ze dat niet
> >verplicht zijn.
>
> Doet Electrabel dat ook als een hele regio ineens een half uur zonder
> stroom zit ? In het geval van Electrabel mag je al blij zijn dat er
> een mededeling komt dat er een probleem was...
Er is al een zware brand of een natuurramp nodig om de helft van de
Electrabel-klanten zonder stroom te zetten.
> Tijdje terug nog een uurtje een dode BC vaste lijn gehad. Naderhand
> eens bij storingen geinformeerd. Probleem ? Er waren geen problemen
> geweest.
Een klein lokaal probleempje dus. Dagelijkse kost bij Telenet en andere
Internet providers.
> Maar nu gebeurt er iets bij TN en plots verwacht iedereen 6 maanden
> gratis surfen.
>
> Beetje kortzichtige hypocrieten hier medunkt.
Ik vrees dat jij hier de kortzichtige bent.
Als een bedrijf compensaties geeft omdat ze een reeds betaalde dienst niet
hebben kunnen leveren is dat in de eerste plaats om de schade te beperken.
Een poging om het geschonden vertrouwen terug te winnen.
Kijk bv. naar wat de NMBS doet als ze een dag hun diensten niet hebben
kunnen leveren (staking dus).
Doordat Telenet geen compensaties geeft bij zo'n zware panne geven ze aan
dat dit normaal is.
Telenet legt zichzelf blijkbaar geen kwaliteitsstandaard op. Werkt het: ok,
werkt het niet: pech voor de klant.
Als ze wel compensaties zouden geven zouden ze aantonen dat zo'n panne een
heel uitzonderlijke situatie is en dat ze er alles aan doen om dit in het
vervolg te voorkomen. Die compensaties kosten hun immers (op korte termijn)
veel geld.
On Wed, 7 Jan 2004 10:22:08 +0100, Lucvdv wrote:
> [RFC2131]
> 4.4.5 Reacquisition and expiration
<snip>
Zoudt ge nu niet omvallen?
Wat ik hier beschreef is opgelost, en blijkbaar is het juist bij die
omschakeling (die van zondag op maandag om middernacht gebeurd is) dat er
iets verkeerd gelopen is waardoor een halve dag later de hele DOCSIS-helft
plat op zijn buik lag.
Ze geven dus sinds zondag middernacht GEEN leases meer met T1 > T2, ze
geven zelfs leases zonder T1 en T2 en laten de clients zelf defaults
berekenen.
Vier maanden mee gesukkeld, en dan blijkt dat ze het veranderd hebben twee
dagen voor ik erop reclameer :-/
On Wed, 07 Jan 2004 22:21:15 GMT, lucvdv <name@null.net> wrote:
>On Wed, 7 Jan 2004 10:22:08 +0100, Lucvdv wrote:
>
>> [RFC2131]
>> 4.4.5 Reacquisition and expiration
><snip>
>
>Zoudt ge nu niet omvallen?
>
>Wat ik hier beschreef is opgelost, en blijkbaar is het juist bij die
>omschakeling (die van zondag op maandag om middernacht gebeurd is) dat er
>iets verkeerd gelopen is waardoor een halve dag later de hele DOCSIS-helft
>plat op zijn buik lag.
>
>Ze geven dus sinds zondag middernacht GEEN leases meer met T1 > T2, ze
>geven zelfs leases zonder T1 en T2 en laten de clients zelf defaults
>berekenen.
>
>Vier maanden mee gesukkeld, en dan blijkt dat ze het veranderd hebben twee
>dagen voor ik erop reclameer :-/
LOL!
Maar ik kom later toch nog terug op je eerdere posting, de tijd ontbrak me
vandaag om er op in te gaan.
En dat dhcp sukkelen deden ze inmiddels een paar jaar!
Wanneer ik binnenkort eens tijd heb zal ik die andere zaken ook eens nachecken.
Groeten,
Jan
GigaSurfer wrote:
> Doordat Telenet geen compensaties geeft bij zo'n zware panne geven ze aan
> dat dit normaal is.
> Telenet legt zichzelf blijkbaar geen kwaliteitsstandaard op. Werkt het:
> ok, werkt het niet: pech voor de klant.
Nu heeft je Telenetverbinding in het slechtse geval een halve dag
uitgelegen. Hoeveel compensatie wil je dan krijgen? Het equivalent van een
halve dag abonnementsgeld is 0,6 euro ofzo.
Gegarandeerde diensten zijn te verkrijgen, maar daar betaal je dan ook voor.
--
Mvg, JeroenV
<URL:http://www.briachons.org/>