DHCP clients verwijderen

[Babylonia]

Voor mij is dit de ultieme manier om vaste / gemeenschappelijke entiteiten administratief 'vast' te zetten en zo te scheiden van alles
wat (eventueel) dynamisch wordt afgewerkt.

Dat is niet anders als dat je dat in de router vast zet.

Iedereen hier weet dat de printers in range 40-49 zitten en dat een nieuwe printer altijd op de IP plek van de oude komt te zitten.
....
Maar volgens mij raken we een beetje off-topic ;-)

Welnee, zie het IP-adres van mijn printer wat ik heb vastgelegd in onderstaande lijst.

Off topic is die keuze om IP-adressen in de router vast te leggen beslist niet. Dat is volgens mij precies datgene wat de topic starter voorstaat.
Hij stelt er juist vragen over hoe dat het beste te doen. 


Gesorteerd op IP-adres.  Let op de "open stukken" (voor extra toevoegingen) in het bereik tussen  x.x.x.15  en  x.x.x.20
En de aparte vastlegging van het gast IP-adres van de smartphone van de "buurvrouw" in een ander IP-adres bereik.

Lekker handig voor je als jij IP-adressen allemaal in de "Client" vast zou willen leggen in smartphones, iPad's e.d.




Gesorteerd op Hostnaam:

[pvkan]

Dat jouw printer een ander IP-adres als die hier, is natuurlijk logisch.
Geen enkele printer (of device) heeft overal hetzelfde IP adres.
Die vrijheid heb je nl helemaal zelf en neem je die vrijheid niet, dan regelt de DHCP dat voor je.
Die range 40-49 is dus niet gekozen door de router of de printer, dat is een plekje die wij vanuit beheer zelf hebben gekozen
en waarop we hier alle printers op instellen.

Wij kiezen er echter voor de printers in de range 40-49 vast te zetten op client niveau en daarmee gaan we voorbij aan de DHCP server.
Dit doen we om beheers-administratieve redenen.
Niets meer en niets minder ;-)
Op deze wijze kunnen we bv ook bepaalde IP ranges afschermen voor niet toegestane activiteiten. Dat wordt met DHCP een
ondoenlijke zaak (je IPranges lopen dan immers dwars door elkaar).
Er is een groot verschil om 10 devices in de hand te houden (meestal thuis situatie) of meer dan 500...
Ik kan mij voorstellen dat je in een prive situatie hele andere (beheers)redenen naleeft dan zakelijke omgevingen.

Ofwel zoals een bekend voetballer ooit zei: Elk voordeel heeft zijn nadeel... ;-))

Peter

[Babylonia]

IP-ranges kan ik hier net zo goed beheren.

En er zijn nog wel meer redenen om de Clients in de router vast te leggen.
Zie een reactie < die ik elders heb geplaatst >, waar dat naadloos aansluit op de functies van de router zelf.

Verder hebben we het hier expliciet over een Synology router (model RT1900ac in het geval van de topic starter) afgestemd op de soho markt.
Bij organisaties met circa 500 Clients zal er echt absoluut een ander type router worden gekozen met een full time systeembeheerder om alles binnen de organisatie draaiende te houden.  Dat is een heel andere opzet en functionaliteit. Dat is hier allemaal niet aan de orde.
Verwar die praktijk niet met simpel datgene wat de topic starter voorstaat en waar het hier in dit topic over gaat.

[pvkan]

Laten we er geen wellus/nietus discussie van maken.
Daar is de topic-starter niet mee geholpen.

Ik lees verder mee.

Thanks,
Peter

[GfS]

Bedankt voor alle reacties, maar zoals ik al in een eerdere post heb neergezet, heb ik de lease tijd gewoon op een uur gezet, als ik nu een device uit de reserveringslijst haal, wordt het IP na een uur vrijgegeven.

Alleen werkt dat momenteel niet, omdat er in de huidige FW een bug zit sinds de overgang naar DST, die apparaten constant als aktief blijft zien, ook al zijn ze bv al een week niet op het netwerk geweest (Zoals bv de Tablet van een vriend, die een week geleden op visite was), Synology weet al meer dan een maand (ehm....Nee 6 maanden van de bug), maar zegt dat de fix misschien in FW 1.1.4 verwerkt word.

Ik ben dus momenteel helemaal niet blij met Synology, en ben er ook sterk over na aan het denken om de RT1900 de deur uit te doen. (BTW de RT2600 heeft er ook last van) 

[mchp92]

Weten van een bug en vervolgens een fix globaal uitrollen zijn geen dingen die je op een zondagmiddag doet. Los nog van de relatieve prioriteit die ze eraan geven...
Wat ga je kopen dat gegarandeerd beter is?


Sent from my iPhone using Tapatalk

[Babylonia]

Alleen werkt dat momenteel niet, omdat er in de huidige FW een bug zit sinds de overgang naar DST, die apparaten constant als aktief blijft zien, ook al zijn ze bv al een week niet op het netwerk geweest

Zoals eerder aangegeven, als je een IP-adres verandert blijft de oude lease nog in stand omdat de lease nog niet vrij is gegeven,
zolang een aangekoppeld apparaat nog aan staat.  Die lease was namelijk onbeperkt geldig (of andere tijdspanne die je in hebt gesteld).
Een nieuwe lease op een nieuw IP-adres komt tot stand, als je apparaten herstart (of netwerk adapters even uit- en weer inschakelt).

Zie mijn voorbeeld < eerder in de draad > het IP-adres voor de Denon-Receiver, die normaal vast staat op  192.168.10.24

Heb in de router dat vaste IP-adres even veranderd naar 192.168.10.44

Herstart van beide apparaten en ik krijg onder status:



Precies wat de bedoeling was.


Feitelijk is de herstart van de router niet eens nodig.  Alleen van het aangesloten apparaat is voldoende.
Nog eens het vaste IP-adres even veranderd naar 192.168.10.78
En alleen herstart van de Denon-Receiver  (Power stekker eruit en er weer in).
De nieuwe status.



En........
Op dezelfde manier weer terug naar het oorspronkelijke vaste IP-adres 192.168.10.24 :




En........
Vanuit hetzelfde uitgangspunt aangaande het IP-adres van mijn mobiele telefoon, normaal vast IP-adres 192.168.10.27 :



IP-adres in de router veranderen naar 192.168.10.88
De WiFi van de mobiele telefoon even uitschakelen, en weer opnieuw inschakelen, en ik krijg:

[GfS]

Ok, ik weet nu hoe dat ik een IP adres moet veranderen cq verwijderen.

Maar.... de bug die ik bedoel, is dat de apparaten die niet aan staan in de apparatenlijst en verkeerbeheer gewoon aktief blijven staan (Dus zwart blijven) terwijl ze inaktief (grijs) moeten worden, omdat ze in feite op dit moment niet aan staan.

Dus als ik voor de bug, mijn TV (Bedraad) of de WiFi van mijn telefoon aanzette, waren deze zwart (Aktief) te zien in de apparatenlijst en verkeerbeheer, en als ik ze uitzette, werden ze na een tiental seconden grijs (Inaktief), maar bleven ze wel in de lijst staan, omdat ze een onbeperkte lease hebben, maar nu blijven ze constant zwart, omdat de router niet meer "ziet" dat ze uitstaan.

Als je bij wijze van test even de tijdzone in regionale opties op +2-Amman zet, en dan in verkeerbeheer en de apparatenlijst kijkt staat alles weer zoals het zou moeten staan.
Vergeet daarna niet om de tijdzone weer op +1-Amsterdam te zetten, maar helaas is dit maar een tijdelijke oplossing (totdat het apparaat weer aaangezet wordt)

Ik wwet ook niet hoe ik het anders uit moet leggen.

Daarom werkt voor die clients ook de WOL niet. (Lees aub even door de thread op het Internationale forum)

[Babylonia]

Maar.... de bug die ik bedoel, is dat de apparaten die niet aan staan in de apparatenlijst en verkeerbeheer gewoon aktief blijven staan (Dus zwart blijven) terwijl ze inaktief (grijs) moeten worden, omdat ze in feite op dit moment niet aan staan.

Dat is inderdaad een "opnieuw terugkeerde bug".
Eerder was er al eens ooit melding van gemaakt, en herstelt. Bij weer een latere firmware update is de bug opnieuw weer terug gekomen.

Maar het onterecht "te lang" als actief in de statuslijst blijven "plakken", staat verder los van vaste IP-adressen toekennen aan Clients en veranderingen die je aanbrengt in die IP-adressen. Zo gauw een apparaat daadwerkelijk opnieuw connectie legt met de router, wordt de status aangepast aan het geldend nieuw uitgegeven IP-adres.

Het probleem wat er speelt is dus enkel dat met die status, uitgestuurde WOL pakketten (opstarten vanuit de menufunctie binnen DSM onder "Netwerkhulpmiddelen", niet werkt als de status van die apparaten nog als "actief" worden aangemerkt.


Met je tip om de tijdzone een keer anders in te stellen, heb ik dat hier ook uitgeprobeerd.
De statuslijst van apparaten wordt daarmee aangepast aan de actuele situatie.
(Apparaten die uit staan of geen connectie hebben, staan niet meer in de lijst).
Weer terug naar de Amsterdamse tijd, blijft bij mij in ieder geval de status correct aangegeven.
En kan ik alsnog via de menufunctie binnen DSM onder "Netwerkhulpmiddelen" mijn NAS opstarten die eerder uit stond.
(Het enige apparaat hier wat ik heb ingesteld om via WOL op te kunnen starten).

Ik zal het nog eens Bij Synology met een ticket onder de aandacht brengen.

[GfS]

Zoals jij het beschrijft klopt het precies.

Maar als je nu de NAS weer uitzet zul je zien dat die niet "grijs" meer wordt en WOL ook niet meer werkt op de NAS, dus het +2 +1 trucje zet alleen alles in de juiste stand van DAT moment.

Ook kun je in verkeerbeheer een apparaat dat onterecht aktief (zwart) staat niet verwijderen bij "instellingen verwijderen", maar een apparaat dat Inactief "grijs" staat wel !!

Dit geld ook voor een vast IP via reservering.

[Babylonia]

als Synology zelf aangeeft dat de bug bekend is, en ze in versie 1.1.4 meenemen....

Potverdorie, niet meegenomen  in update 1.1.4  (uitgeprobeerd en het is nog hetzelfde als wat hiervoor in de draad beschreven).

[Babylonia]

Groot nieuws aangaande deze bug die nogal wat consequenties heeft.

Ik ben eruit !!!  Ook waarom Synology de bug tot nu toe niet goed heeft onderkend.

Reactie klaargemaakt op het internationale forum (om in het ticket een URL naar die reactie te laten verwijzen).
Lees hoe simpel de bug is te reproduceren,  en ook waarom het bij Synology niet gevonden kon worden.

https://forum.synology.com/enu/viewtopic.php?f=265&t=131298&p=484031

[Babylonia]

Aanvullend:

Om het probleem "binnen Nederland" met de juiste tijdtabel te kunnen gebruiken, waarbij je geen probleem hebt, kun je voorlopig totdat er een bug-fix is de tijdtabel nemen van   (GTM+2:00) Centraal Afrika   of   (GTM+2:00) Harara, Pretoria,  waarbij geen zomertijd / wintertijd geldig is.
Die tijdtabellen werken zonder bug.  (Naar aanleiding van mijn uitzoekerij, terugkoppeling met @GfS  kwam hij aanvullend met dit idee).

Deze tijdtabel komt overeen met de  Amsterdam GTM+1:00 tijd  + 1 uur zomertijd verschuiving.

[Babylonia]

UPDATE:

Met het openen van een Support Ticket had Synology mij toestemming gevraagd om in mijn router te kunnen inloggen.

"Dear Customer,

Thank you for your patience and the detail information.
This case has been passed to our developers and we've found the resolution that we have to change the binary for you.
Please allow us your permission to connect to your router and follow the steps below and provide us with the information so we can access your system......"


Afgelopen nacht is men vanuit Taiwan ingelogd geweest.  Kon ik zien omdat de lijst van actieve apparaten nu was aangepast.
Tevens te zien binnen mijn log-bestanden, waarbij ik 2 vreemde IP-nummers zag,  opgezocht, en die bleken vanuit Tampei  / Taiwan te komen + SSL sessie.
(In de firewall had ik de regio voor toegang tot SRM met Taiwan uitgebreid).

Het probleem bij mij is nu opgelost   
De status van actieve apparaten wordt binnen 45 sec. - 1 minuut 45 sec aangepast (afhankelijk van de tijd van afsluiten van een apparaat).
De tijdzone stond bij mij op Amsterdam.   (Die tijdzone had ik voor Synology Support gekozen, met een "ongeldige" status van apparaten.
Zodat ze het verschil konden zien als men de tijdzone zou veranderen).
Heb het nu nog eens speciaal getest met een tijdzone zonder zomer en wintertijd verandering, en dat werkte ook !

Hoop dat de fix tevens ook snel voor iedereen ter beschikking komt in een volgende algemene firmware update.

[Briolet]

UPDATE:…waarbij ik 2 vreemde IP-nummers zag…

In 2014 stond de volgende regel in hun standaard mailtjes:

Note: our static external IPs are from 118.163.30.16 and 125.227.152.103 in case you would like to set up a firewall rule to allow only our IPs to access the system.

Maar soms ook:

Note: our static external IPs are from 118.163.30.16, 125.227.152.103 and 59.120.41.39 in case you would like to set up a firewall rule to allow only our IPs to access the system.

Ik neem aan dat het de eerste twee nummers zijn die je ziet.  Die 3 heb ik standaard in mijn firewall staan, zodat ik de rest van Taiwan nog buiten de deur houdt. Waarom het nummer 59.120.41.39 er soms wel en dan weer niet bij stond, weet ik niet. Maar misschien liep die bug via een andere afdeling.

Ik elk geval mooi dat Synology dit zo snel oppakt. Uit eigen ervaring kan ik zeggen dat zo'n goed gedocumenteerde bug het ook wel aanmoedigt om dit direct op te lossen. Met jouw beschrijving moet het voor kenners van de code relatief simpel zijn om het probleemstuk in de code bepalen.