Forum: DHPC leasetijd - Online Gebruikers Groep

Oeps! JavaScript ontbreekt!
Uw Web browser heeft JavaScript uitstaan of ondersteund geen JavaScript.
Om deze website optimaal te kunnen zien dient u JavaScript aan te zetten in uw Web browser en/of Firewall.
Of verander van Web browser die wel JavaScript ondersteund; Firefox, Safari, Opera, Chrome of Internet Explorer nieuwer dan versie 6.

Onderwerp bekijken

Online Gebruikers Groep - Experts helpen klanten » Andere (eigen) modem / routers » Eigen modem configuratie en problemen

Wat is er mogelijk met het modem en hoe doe je het? Hoe kom je in het configuratiescherm? Heeft deze router wireless? Waar vind je wat in de schermen? Kun je nog extra dingen instellen, bijv. via telnet? Zijn er problemen bekend met dit modem? en hoe los je ze op?

Pagina 5 van 7: 1 2 3 456 7

DHPC leasetijd
Optimist	#41 Geplaatst op 04 maart 2007, 19:14
Donateur » Diemen - The Netherlands Berichten: 376 Lid sinds: 11 dec 2006	Quote Richard schreef: Quote Orange probeert vanaf 85.146.xxx.1 richting jouw LAN segment een UDP datagram to sturen naar de BOOTPC Ja, vreemd niet? Maar ik zou me kunnen voorstellen dat als ik niet alle poorten geforward zou hebben in de Livebox, deze zaken naar de Livebox zelf gestuurd zouden worden want daar komen ze dan immers terecht. Ja, dat kan ik me ook voorstellen! Quote Misschien dat de server bij Orange ingesteld is om op een reply te wachten en een beetje een erg lang time-out heeft als hij dat antwoord niet krijgt, zodat het dus zo lang duurt. Het is maar gissen mijnerzijs, ik weet niet precies hoe zoiets werkt dus ik bedenk theoretisch maar even iets wat zou kunnen passen in mijn gedachtengang. Misschien dat jij daar meer over weet. Je zou best eens gelijk kunnen hebben! Uit RFC951: A single packet exchange is performed. Timeouts are used to retransmit until a reply is received. Quote Dat bestemmings adres (broadcast) bij jou vind ik ook wel apart, kan zijn dat het van de RFC mag, maar waarom zouden ze het doen? Is toch niet nodig? Toch wel! Als een client zijn eigen IP adres niet weet, dan wordt er een request gestuurd naar het broadcast adres (255.255.255.255) met als afzender IP adres 0.0.0.0. Het request dat de client uitstuurt is voor elke host op hetzelfde subnet zichtbaar, als die luistert op de UDP BOOTPS poort. Aangezien de server niet weet aan welk IP adres het antwoord moet geven, stuurt de server een broadcast reply uit aan 255.255.255.255. Ook dit reply is voor elke host op het subnet zichtbaar, zolang die luisteren op de UDP BOOTPC poort. Om te voorkomen dat tijdens een request/reply conflicten ontstaan als twee clients tegelijkertijd een request uitsturen, is er een 4 byte transactie ID in het UDP pakketje geplaatst door de client die het request uitstuurt. Clients die wachten op een reply controleren of de server hetzelfde transactie ID in de reply zit. Zo niet, dan wordt de reply weggegooid. Zo ja, dan wordt het IP adres en de network gateway van de reply gebruikt. Quote Vage boel allemaal. Zeker -- maar dat maakt het juist zo leuk! Optimist




Richard	#42 Geplaatst op 05 maart 2007, 01:53
Activiteit » Maastricht Berichten: 2179 Lid sinds: 03 apr 2006	Het vage maakt het zeker leuk want zo ontstaat de sport om het eens uit te zoeken. Maar ik ben blij dat ik uit je reply kon opmaken dat mijn gedachtengang helemaal zo gek nog niet was. Overigens bedankt voor de uitleg omtrent die broadcast, alhoewel ik voor mezelf dan weer aan het denken sla van hoe het nu zou kunnen dat een client zijn eigen ip adres niet zou weten. Daar doorzie ik de clou even niet van. Misschien kan ik eens proberen iets anders te doen, d.w.z. de poortforwardings in mijn livebox wijzigen en dan de forwards als volgt instellen: poort 1-66 en poort 69-65535 forwarden naar mijn Linux machine en dat voor tcp en udp. Als ik het goed zie, blijven de poorten 67 en 68 dan naar de Livebox staan. Dat zou op zich geen problemen kunnen opleveren c.q. kwaad kunnen, toch? Jammer alleen dat ik dan geen log meer zie van de Livebox wat er dan gaat gebeuren. Greetings, Richard.


Optimist	#43 Geplaatst op 05 maart 2007, 09:25
Donateur » Diemen - The Netherlands Berichten: 376 Lid sinds: 11 dec 2006	Quote Richard schreef: Overigens bedankt voor de uitleg omtrent die broadcast, alhoewel ik voor mezelf dan weer aan het denken sla van hoe het nu zou kunnen dat een client zijn eigen ip adres niet zou weten. Daar doorzie ik de clou even niet van. BOOTP/DHCP gaat er vanuit dat de client niets weet -- dus zonder enige configuratie van de IP stack. De client weet dus zelfs niet het eigen IP adres of het netwerk adres. Dit is een uitgangspunt van het protocol. Een BOOTP/DHCP client moet aan het netwerk kunnen vragen wat het IP adres et cetera is. Bij BOOTP gaat het zelfs zo ver, dat met het netwerkadres, gateway, et cetera, er een TFTP server kan worden aangewezen met een filenaam die de client kan inladen om te starten! Er zit dan een klein stukje code in ROM van de netwerkkaart die dit mogelijk maakt (BOOTP en het laden van de initiele file om te booten). Zo kunnen 'diskless' clients via het netwerk opstarten. Quote Misschien kan ik eens proberen iets anders te doen, d.w.z. de poortforwardings in mijn livebox wijzigen en dan de forwards als volgt instellen: poort 1-66 en poort 69-65535 forwarden naar mijn Linux machine en dat voor tcp en udp. Als ik het goed zie, blijven de poorten 67 en 68 dan naar de Livebox staan. Dat zou op zich geen problemen kunnen opleveren c.q. kwaad kunnen, toch? Je zou alleen poort UDP/68 niet moeten forwarden. Poort UDP/67 de poort die de Livebox gebruikt met uitgaande pakketjes (bestemmingspoort). Ik zou eigenlijk verwachten dat de Livebox, ook met het forwarden van alle poorten naar jouw firewall, het UDP/68 zou afvangen. Optimist


Richard	#44 Geplaatst op 05 maart 2007, 15:31
Activiteit » Maastricht Berichten: 2179 Lid sinds: 03 apr 2006	Quote ook met het forwarden van alle poorten naar jouw firewall, het UDP/68 zou afvangen. Ja dat zou ik ook verwachten, net zoals dat met die poort 4720 gebeurt voor het voice gedeelte. Alles is geforward maar dat blijft staan. Overigens bedankt voor het vervolg van de heldere uitleg, ik heb hem nu door. Interessante materie! Greetings, Richard.


Richard	#45 Geplaatst op 05 maart 2007, 15:35
Activiteit » Maastricht Berichten: 2179 Lid sinds: 03 apr 2006	Ik heb die poortforwardings nu eens omgezet alleen vraag ik me nu af of het inderdaad TOT poorten is zoals in de Livebox staat of "tot en met" poort. Staat nu op 1-67 en van 69-65535. Wat ik me nu afvraag is of dat goed is, of dat het eigenlijk zou moeten zijn 1-68 en 69-65535. Greetings, Richard.


Fedora	#46 Geplaatst op 05 maart 2007, 17:07
Activiteit Berichten: 38 Lid sinds: 01 jul 2006	mischien een late reactie, maar de dhcp leasetijd is idd 24 uur,, tenzij je de helpdesk belt, en dat zij het mac adres releasen Dit heb ik dus gedaan vandaag, Ik internet nu via een Speedtouch 546I V6 de livebox zal onder het stof verdwijnen vrees ik:p:p:p


Optimist	#47 Geplaatst op 05 maart 2007, 17:27
Donateur » Diemen - The Netherlands Berichten: 376 Lid sinds: 11 dec 2006	Quote Fedora schreef: mischien een late reactie, maar de dhcp leasetijd is idd 24 uur,, tenzij je de helpdesk belt, en dat zij het mac adres releasen Geen idee wat de leasetijd is... Als mijn Linux server door middel van dhclient (referentie implementatie van ISC) door middel van DHCP een IP adres krijgt toegewezen, dan is dat IP adres een week (!) geldig volgens de DHCP server: epia:~# cat /var/lib/dhcp/dhclient.eth0.leases lease { interface "eth0"; fixed-address 85.148.xxx.xxx; option subnet-mask 255.255.252.0; option routers 85.148.xxx.xxx; option domain-name-servers 194.134.5.5,194.134.0.97; option domain-name "orange.nl"; option dhcp-lease-time 604800; option dhcp-message-type 5; option dhcp-server-identifier 10.49.1.4; renew 5 2007/3/9 00:53:22; rebind 0 2007/3/11 15:53:22; expire 1 2007/3/12 12:53:22; } Het getal 604800 is het aantal seconden dat de lease gegeven is, en dat is precies zeven dagen. Zie ook de 'renew', 'rebind' en 'expire' timers. Misschien heeft dit weer niets te maken met het expireren van een MAC adres -- geen idee. Als veel mensen van MAC adres veranderen op een subnetwerk die redelijk vol zit qua uitgegeven IP adressen, dan zou ik me kunnen voorstellen dat er op enig moment geen IP adressen meer beschikbaar zijn, gezien het feit dat de adressen voor een week worden uitgegeven! Ik ben ook wel benieuwd of je nu een nieuw IP adres toegewezen gekregen hebt, of dat je het oude hebt kunnen behouden. Misschien dat er ergens een statische koppeling tussen MAC en IP adres is geconfigureerd door Orange. Indien niet, dan zou bij het uitzetten van de modem voor meer dan een week het risico bestaan dat je een nieuw IP adres krijgt. Optimist


Optimist	#48 Geplaatst op 05 maart 2007, 17:44
Donateur » Diemen - The Netherlands Berichten: 376 Lid sinds: 11 dec 2006	Ook wel grappig is het RFC1918 adres dat Orange gebruikt voor de DHCP server: option dhcp-server-identifier 10.49.1.4; Als ik een traceroute doe naar dat adres, dan blijkt het gewoon bereikbaar vanuit een Orange DSL aansluiting (dat zal wel moeten, want anders werken de DHCP servers niet): traceroute to 10.49.1.4 (10.49.1.4), 30 hops max, 40 byte packets 1 gw-2-3 (192.168.3.254) 0.871 ms 0.444 ms 0.554 ms 2 epia (192.168.2.254) 0.757 ms 0.740 ms 0.708 ms 3 s12345678.adsl.wanadoo.nl (85.148.xxx.1) 20.757 ms 21.782 ms 20.387 ms 4 V520.dr3-asd5.nl.euro.net (194.134.152.13) 24.719 ms 23.679 ms 24.591 ms 5 GX-X.cr2-asd4.nl.euro.net (194.134.162.21) 24.918 ms 24.442 ms 24.634 ms 6 G3-2.cr2-asd2.nl.euro.net (194.134.162.194) 23.455 ms 24.661 ms 24.312 ms 7 G2-2.dr1-asd2.nl.euro.net (194.134.162.118) 24.497 ms 24.659 ms 24.361 ms 8 10.49.1.4 (10.49.1.4) 25.238 ms 24.633 ms 24.338 ms Vreemd, want je ziet zelden dan RFC1918 adressen via publieke IP adressen bereikbaar zijn! Optimist


Richard	#49 Geplaatst op 05 maart 2007, 21:09
Activiteit » Maastricht Berichten: 2179 Lid sinds: 03 apr 2006	Lijkt me ook eigenlijk logisch 10.49.1.4 is een private ip range. Ik zou me kunnen voorstellen dat dit een soort VPN verbinding is die dan alleen een tunnel bouwt tussen Orange en de Livebox zelf, daar kom je met je pc dan ook niet bij. Het is maar een idee, maar wel een mogelijkheid. Ik weet niet of dat in jouw geval met die bridge naar de Linux ook zo is want dan zou je eigenlijk stellen dat hij dat met die linuxmachine zou moeten doen. Maar daar kun je me vast wel verdere uitleg over geven en ook vertellen of mijn idee over dat 10.x adres een correcte gedachtengang kan zijn. Greetings, Richard.


Optimist	#50 Geplaatst op 05 maart 2007, 22:28
Donateur » Diemen - The Netherlands Berichten: 376 Lid sinds: 11 dec 2006	Eigenlijk zou je niet verwachten dat er een RFC1918 adres wordt gebruikt, omdat deze adresranges eigenlijk alleen in privé netwerken worden gebruikt die onder controle staan van een enkele autoriteit of beheerder. Iedereen mag gebruik maken van deze privé adressen, en daardoor kan je vreemde effecten bereiken indien deze IP adressen ook via het Internet gerouteerd worden, ook als dit alleen een enkele ISP betreft. Stel je eens voor dat ik zelf ook gebruik maak van hetzelfde IP adres in mijn privé netwerk -- dan kan je vreemde effecten krijgen! Immers, de firewall kent waarschijnlijk dan alleen de route naar het door mij geconfigureerde subnet, omdat de DHCP server alleen een default gateway bekend maakt. Alle expliciet gerouteerde netwerkadressen vallen daar niet onder en dus kan de door Orange gebruikte DHCP server ineens niet meer routeerbaar zijn. In dit specifieke geval zou het niet eens een probleem zijn, want er wordt gewerkt met broadcasts om DHCP requests te beantwoorden. De RFC1918 adressen zijn gewoon gerouteerd, dus zonder een speciale tunnel of zoiets. Optimist


Deze website gebruikt Awin affiliate links en Google advertenties, om deze service voor iedereen gratis te houden.