Sad smo došli do toga da ti meni pokušavaš da objasniš ono što sam ja prvobitno tebi naveo kao primer.
Pričao si ti svašta, premda potpuno bespotrebno, jer je sve to bilo u cilju dokazivanja neostvarljivosti ili komplikovanosti implementacije takve politike dodeljivanja adresa.
Uređaj ima pravo da je koristi onoliko dugo koliko god mu je DHCP inicijalno dozvolio. DHCP može samo da čeka istek ovog vremena kako bi onda pri sledećoj dodeli dodelio drugu adresu.
Sa čim se slažem... Al' si posle rekao:
U regularnim uslovima, ako je klijent stalno upaljen i ne postoji problem u komunikaciji sa DHCP serverom, "liza" se obnavlja na polovini vremena isteka. U tim uslovima, "liza" se stalno produžava i ne može da istekne.
Znači, nikada neće moći da mu promeni adresu? Skačeš sam sebi u usta.
Podrazumevano ponašanje DHCP servera je jedno, ali kod ISP-a DHCP ne radi izolovano - sam za sebe - već u koordinaciji sa drugim elementima sistema (RADIUS) i primenjuje politiku dodeljivanja adresa koju nametne provajder svojom poslovnom politikom.
Brisanjem "najma" iz baze DHCP servera tera se DHCP server da "nakuje" (o bože izraza, a meni nešto kažeš) klijente.
Izraz "nak-ovati" se koristi među kolegama i to je glagol koji je izveden iz engleskog glagola "to NAK".

Za "lizu" nikada nisam čuo u domaćoj literaturi, niti u slengu. Inače, imenica "lease", u engleskom jeziku predstavlja "ugovor o zakupu/najmu", pa je asocijacija jasna. U srpskom, "liza" ne bi bila podjednako intuitivna, mada bih ja prihvatio svaki termin oko koga postoji koncenzus, a čini mi se da je to za sada "najam".
Ono što uporno pokušavam da ti objasnim i ti uporno odbijaš da shvatiš je da je to najgori i najproblematičniji način da se postigne ono što ti želiš.
Najgori je ako sam treba da implementiraš (skriptuješ?) logiku koja će to da radi, a ukoliko ti je to već ponuđeno kao opcija u nekom postojećem sistemu (RADIUS) ili uređaju (Cisco)? Lepo sam ti rekao da se obara pppoe konekcija, a da je DHCP podešen da uvek daje drugu i jednim udarcem dve muve. Sve ovo o čemu mi razglabamo nema veze sa temom i predstavlja čistu patkometriju i češkanje prstića.
Odbijam da poverujem da su svi provajderi, osim Eunet-a, dovoljno glupi i mazohistički nastrojeni da primene takvo rešenje + da je takvo rešenje masovno primenjeno. Takvo rešenje zahteva poseban trud nedostojan nivou lenjosti domaćih provajdera.
Vidi, dobar drug mi je bio jedan od jačih internet provajdera u Srbiji. Pitao sam ga još ranije za sve ovo. On ne zna baš sve tehnikalije, ali se seća priče da su morali na (NAS) ruteru da ograniče trajanje PPPoE sesije, jer valjda nije bilo opcije da je drugačije prekinu. Inače, gotova hardverska rešenja se u takvim okruženjima uglavnom i koriste.
Da, kada sam pominjao brisanje "najmova", podrazumevao sam da DHCP server radi u autoritativnom režimu. To je jedini očekivan režim rada DHCP servera koji se koristi "u produkciji". Neautoritativni režim se koristi samo u slučaju postojanja više od jednog DHCP servera u lokalnoj mreži i za potrebe testiranja.
Nije tačno da je to podrazumevani režim rada u produkciji. U većim mrežama obično i postoji više DHCP servera.
Za brisanje "najmova" si rekao:
U slučaju brisanja lize, novu adresu uređaj/računar dobija nakon isteka regularnog trajanja lize jer uređaj/računar ima pravo da koristi adresu do regularnog isteka lize. Prevremeno brisanje liza može da dovede do kolizije IP adresa a o tome ne bih da detaljišem.
Ako po isteku T1 tajmera (50% trajanja najma) server odgovori klijentu sa DHCPNAK (da ne kažem nakuje ga

), jer ga recimo nema više u svojoj evidenciji, klijent će ući u INIT režim i uzeti novu adresu. Podrazumevano je da obrisanu adresu, iz baze najmova, moraš nekako da držiš rezervisanu, tj da je ne izdaš nekome drugome. Mehanizam za tako nešto nije predviđen DHCP-om jer to ne ispunjava ni jedan cilj koji je postavljen pred njim, ali DHCP takođe tako nešto ne zabranjuje.
BRAS, odnosno NAS, ruteri imaju raznorazne napredne funkcije i oni svakakve takve kerefeke rade prostim štriklanjem opcije u konfiguracionom meniju. Nije ni bitno kako, mučiš i mene i sebe bespotrebno tupeći oko toga. To jednostavno radi i nema tu nikakvih problema i "tehničkih poteškoća".
Al' vidi... Sve je to potpuno nebitno. Prepucavamo se oko gluposti. Ti si zapeo da mi dokažeš kako je to Eunetu tehnički teško da izvede, pa hvataš na volej sve što kažem u pokušaju da ti objasnim da to sigurno nije razlog. Tako i odosmo u pogrešnom pravcu iz čistog inata.
Samo što na tvoju žalost DHCP propisuje i mehanizam i politiku nad kojom nemaš punu kontrolu.
Nije tačno. Nigde ne propisuje razlog za neprodužavanja najma. Vidi opis pomenute komande u Cisco dokumentaciji:
Cisco IOS IP Addressing Services Command Reference je napisao(la):
In some usage scenarios, such as a wireless hotspot, where both DHCP and secure ARP are configured, a connected client device might go to sleep or suspend for a period of time. If the suspended time period is greater than the secure ARP timeout (default of 91 seconds), but less than the DHCP lease time, the client can awake with a valid lease, but the secure ARP timeout has caused the lease binding to be removed because the client has been inactive. When the client awakes, the client still has a lease on the client side but is blocked from sending traffic. The client will try to renew its IP address but the DHCP server will ignore the request because the DHCP server has no lease for the client. The client must wait for the lease to expire before being able to recover and send traffic again.
To remedy this situation, use the renew deny unknown command in DHCP pool configuration mode. This command forces the DHCP server to reject renewal requests from clients if the requested address is present at the server but is not leased. The DHCP server sends a DHCPNAK denial message to the client, which forces the client back to its initial state. The client can then negotiate for a new lease immediately, instead of waiting for its old lease to expire.
Evo ti primer gde uklanjanje najma ima veze sa nekim "spoljašnjim" eventom (istekom ARP tajmera) i da je DHCP protokol dizajniran tako da ovo onemogućava, ne bi bilo moguće koristiti ga u kombinaciji sa različitim mrežnim protokolima i u različitim scenarijima.
Hmmm. Za nekoga ko je najverovatnije stariji i iskusniji od mene (a ni ja nisam više mlad), mnogo se nezrelo ponašaš.
To mi je
default behaviour. :d
Mnogo se koristiš uvredama i osporavanjima mog znanja i moje stručnosti, tvrdeći da lažem, nazivajući me trolom, i hvalisanjem "da ti je veći"
Ajmo ovako... Nisam ISP, niti sam ikada radio kod nekog ISP-a. Ne bavim se nešto posebno mrežama, mada sam održavao manje Linux mreže, storedž sisteme i razne mrežne servise. Sa Ciskom i nisam baš najbolji drug, mada ih imam par komada i kod kuće.
Moje znanje u ISP oblasti je (prirodno) šuplje, ali ne koliko i tvoje. Zato mi je "zasmetalo" toliko tvoje insistiranje na tehnikalijama i tome kako je "to što ja hoću nemoguće". Da ne ponavljam više da svi drugi provajderi rade "onako", a ne "ovako", kao i da
ja samo hoću da provajderi budu iskreni po pitanju svoje politike dodele IP adresa. Ima li razloga da ne budu?
Rezervišeš za šta/koga? Kako tačno rezervišeš? Adresu moraš da izbaciš iz pool-a (privremeno) da ne bi rizikovao koliziju. O Bogo. Dinamičko manipulisanje pool-om. Čist mazohizam. I da, manipulisanje pool-om ne može preko OMAPI-ja.
Ne manipulišeš pulom, već pojedinačnim najmovima. Kako vidim, umesto menjanja statusa najma (koji se ni ne može obrisati preko OMAPI-a), dovoljno je promeniti vreme isteka najma u trenutno vreme.
IP Address Management je napisao(la):
The ISC DHCP server provides an application programming interface (API) to query and manipulate lease data while the server is running. The Object Management API (OMAPI) enables remote access via a TCP/IP connection. The OMAPI functions exposed by the ISC DHCP server utilize a thin wrapper over OMAPI called dhcpctl, which provides access to objects that correspond to actual DHCP server objects, including lease, host, group, control and failover-state objects as described below. OMAPI enables gets and sets of attribute values of server objects such as leases and updates them on the server.
Znači, ažuriraš vrednost polja "ends" sa trenutnim vremenom i najam je istekao. Ali kažem opet... sve je to nebitno. Ovo je čista patkometrija. Kod provajdera ionako sve ide preko BRAS-a i RADIUS servera. Lično nikada nisam konfigurisao, a siguran sam da nisi ni ti, ni jedan od pomenutih (mada sam ja mogao da pitam nekoga ko jeste), tako da ne znam zašto se uopšte oko toga prepucavamo?
S druge strane, ako ne izbrišeš "najam" a spustiš konekciju, opet će klijent/ruter dobiti istu adresu jer "najam" i dalje postoji, validan je, i DHCP server će dati klijentu adresu koju je već ranije dao. Nema razlog da je promeni. To što je klijent krenuo od INIT stanja ne pravi nikakvu razliku.
Čim padne PPPoE sesija, BRAS će da otkači/obriše najam sa DHCP servera. Klijent kada se ponovo pojavi može da traži šta hoće, dobiće neku rnd adresu i ćao. To tako radi.
Nisi čuo za "privacy extensions" kod IPv6? To je sveti gral za tebe koji ne postoji na IPv4. S obzirom koliko su "privacy extensions" dobra stvar po korisnike tvog tipa, čisto sumnjam da će ISP-ovi dozvoliti njihovo korišćenje kad IPv6 zaživi.
Ama dosta više sa glupostima! Kakav sveti gral? Kakav IPv6? Šta, bre, za mene? Skini mi se. Svim provajderima radi kao što sam ti objasnio, samo Eunet nešto izmišlja, a ti uzeo da ih braniš i meni dokazuješ kako je to užasno komplikovano izvesti. Smešno!
Svašta su mu rekli samo ne ono što si ti napisao. Evo šta su mu rekli:
Pogrešno tumačiš te komentare g-dina Simona Hobsona (ne poznajem čoveka). Ja bih, međutim, izdvojio ovo:
If you want the server to randomly move clients around every time they renew, ISC DHCP doesn't have facilities to do that.
DHCP nema, ali to ne znači da to ne može da se uradi eksternom logikom. DHCP samo omogućava komunikaciju sa klijentima. Ono što jesi citirao nisi dobro razumeo.
No, it's the opposite of required functionality according to the RFC.
If you look through the archives, you'll find it gets roughly the
same response whenever it's asked - it's against the rfc, it's bad
for the network AND for the internet, and no it isn't supported.
Ne produžavanje najmova po njihovom isteku nije protivno RFC-u, niti RFC definiše takve stvari. Čovek je to rekao u smislu da je
"bespotrebno cimanje korisnika koji, tehnički gledano, imaju legitimne konekcije", nije u saglasju sa osnovnom svrhom DHCP-a!
To je sve lepo, ali za takve ljude (Free Software) Linus Torvalds kaže da se sigurno drogiraju. :d Realnost kapitalizma i slobodnog tržišta je sasvim drugačija. Da li je to lepo? Ne. Da li se ja slažem sa tim? Načelno, ne. Da li će to nekoga sprečiti u tome? Ne.
Uostalom... sve je ovo patkometrija. Ne znam koji već put kažem da se to radi preko RADIUS servera, koji pak direktno ili posredno upravlja najmovima.
Inače, čovek koji je postavio pitanje je posle sam rekao:
Guess the traditional way of doing it for ISPs is using RADIUS and PPP auth since Radius tends to switch IPs but I was and still am against IP rotation - it destroys the notion of "always on" in the case of ISPs.
Na to mu je lik (Simon Hobson) koji je toliko bio napljuvao takvu ISP politiku (FSF mentalitet) na kraju rekao:
Giving out a different IP each time a user connects is not necessarily bad, the user cannot have any existing connections to break.
Upravo ono što sam i ja rekao. Idealno mi je "nova konekcija nova adresa" i skoro svi tako i rade, bez da forsirano obaraju konekciju posle nekog vremena, a ja ako hoću novu adresu mogu ili da uradim "relese & renew" ili da resetujem konekciju.
Drugo, oni kada su diskutovali o tome 2006. nisu mogli ni da pretpostave koliko će u nerednim godinama da naraste broj WiFi klijenata, koji se svaki čas pojavljuju i nestaju i ulaze u
deep sleep bez otpuštanja najma, što DHCP-u na hot-spotu pravi poseban problem, tako da su neke od tih "loših politika" praktično postali norma, ali iz sasvim drugih razloga.
Ne. Postoji samo način konfigurisanja.
Koji sve načini postije? DHCP konfigurisanje, ručno konfigurisanje i konfigurisanje preko neke skripte ili programa, pa otuda imamo: dinamičku adresu, manuelnu adresu i programsku adresu. A ako sam konfigurisao adresu kopiranjem .rc fajla koji sam preneo na flešu? Onda je fleš adresa?
Statično znači nepomično. Dinamično je nešto što je promenljivo, što je "živo". Nema ničega statičnog u manuelnom/ručnom unošenju "fiksne ip adrese" - prstići rade.
Kako DHCP, uz pomoć RADIUS-a, može da dodeljuje klijentu i fiksnu ip adresu (i to nezavisno od klijentove MAC adrese), ispada da je i ta adresa onda dinamička. Ili je radijalna, jer ju je dodelio RADIUS server? :d
Hmmm. Koja to visokoškolska ustanova obrazuje akademski profil "IT inženjer"?
Viša elektrotehnička, na kojoj završih dva smera (NRT i AVT), ali sam zvaničnu vokaciju skratio. (BTW, tom školom se ne ponosim, ali kako danas ima toliko priučenih "stručnjaka" lepo je pozvati se nekada i na formalno obrazovanje.)
Ako ćemo da se frljamo sa kvalifikacijama, ja sam "dipl. inž. elektr. i računar.", uskoro valjda i "mast. inž. elektr. i računar."
Opa! Fakultetski obrazovan. Lepo. Samo da nisi sa Megatrenda. :d Ili sa Više elektrotehničke. :S:
Što se tiče moje stručnosti, recimo da od početka ove rasprave namerno nisam konsultovao literaturu da bih video koliko me dobro sećanje služi. Sve sam pričao iz glave. Ti koliko vidim se ubi od kopanja po internetu.
Pa... svašta si ti tresnuo "iz glave".

Navalio si da se ubeđuješ kako je "to tehnički teško izvodljivo", ni ne znajući kako cela stvar zapravo funkcioniše, a pokušao si da prodaš priču kako si sistem administrator kod nekog ISP, što je sa tvojim nivoom znanja i poznavanja meterije ne može biti istinito.
Argument da je to teško izvodljivo ti jednostavno ne stoji, a zbog njega smo i otišli u ovoliku digresiju. Suština priče je da uopšte nije teško - stvar završava RADIUS server (upravljajući najmovima).
Zadnji put kada sam proverio, tema nije bila o gramatici srpskog jezika ali ti ne možeš da odoliš da me "osporavaš" i u tom pogledu.
Ne, nisam te ispravio da bih te ponižavao ili terao mak na konac, već zato što nepravilno korišćenje priloga "odnosno" zaista ume da bude zbunjujuće.
Koristim ADSL kod PTT-a i stojim iza svojih reči. Ponašanje varira i nekad i posle višestrukih restartovanja rutera i sl. ja i dalje dobijem istu adresu a nekad adresu menja svaki put.
Zanimljivo. A jesi li probao da odradiš na ruteru "release and renew"?
U tehničkoj podršci PTT-a su mi rekli da mogu da mi garantuju novu adresu svaka 24 sata, ali ne i pri svakoj novoj konekciji. I da se ogradim unapred - ne želim da ulazim u to kako to postižu.
