Onderwerp: Telenet DHCP in panne?

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

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>

[RFC2131]
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.
[/RFC2131]

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):

[RFC2131]
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.
[/RFC2131]

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:
[RFC2131]
The client records the local time at which the DHCPREQUEST
message is sent for computation of the lease expiration time.
[/RFC2131]

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/>

"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/>