Synology-Forum.nl
Synology Router => Synology Router => Topic gestart door: GfS op 04 april 2017, 11:05:42
-
Ik heb een aantal clients in de reservation list staan, en die staan onder de client list als onbeperkte leasetijd (zoals het hoort)
Maar als ik een IP nummer in die lijst aan een nieuw apparaat toe wil kennen, verwijder ik de client met dat IP nummer uit de reservation list, en dan veranderd de leasetijd in de client list naar 24 uur, en gaat hij terugtellen.
Is er een mogelijkheid om die client uit de lijst te verwijderen, en ik het IP nummer meteen kan gebruiken voor dat nieuwe apparaat, zonder dat ik moet wachten tot de Leasetijd op 0 staat (24 uur dus), zodat het IP nummer automatisch vrijkomt ??
Het enige dat ik kan vinden is de leasetijd bij Lokaal Netwerk veranderen in bv 1 uur, maar niet verwijderen
-
Waarom wil je kiezen welk IP een host krijgt? Daar is dhcp nu net voor.
Gewoon de ongebruikte reservering eruit gooien en dhcp zn ding laten doen
Sent from my iPhone using Tapatalk
-
Ik vind het wel fijn om met vaste IP adressen via DHCP reservation te werken.
Zo weet ik namelijk altijd welke poort ik naar welk IP moet forwarden (FTP en Webserver), of naar welk IP ik moet printen.
Of via FTP mijn Humax decoder/recorder moet benaderen, of via IP mijn Soundbridge moet instellen.
Zonder allemaal Hostnamen te moeten onthouden (Nu is het via reservation, altijd hetzelfde IP nummer).
En dat vind ik nu eenmaal makkelijk, en doe ik al jaren zo.
Dus.....zou het fijn zijn als iemand een antwoord op mijn vraag weet !! (ipv te vragen, waarom ik het zo wil)
Excuses als ik nu iemand beledig, maar ik lees, ook in andere fora, steeds vaker de vraag "why would you want that"
-
Je hoeft je niet te verdedigen hoor, dhcp reserveringen gebruiken veel forumleden hier toch echt wel!
Ik ook en al vele vele jaren. Ideaal voor NASsen, printers mediaspelers en dat soort "vaste" apparaten.
Maar kan je bij de Synology router deze niet gewoon meteen verwijderen?
Ik heb een oud Linksys routertje (E4200) en daar kan ik een entry direct verwijderen.
En dus ook direct uitgeven voor een ander apparaat.
-
Is het apparaat dat vroeger het betreffende IP gebruikte nog aangesloten? Dan blijft dat IP in gebruik zolang dat apparaat zijn DHCP blijft vernieuwen.
Wat gebeurt er als je het IP handmatig toekent aan het nieuwe apparaat? Staat de router dat niet toe?
-
@Robert Koopman: Nee....denk het niet, zodra ik een reservering verwijder, veranderd de staus in de DHCP client list van Onbeperkt naar de standaard leasetijd (86400 seconden) en gaat terugtellen.
Ik krijg die client dan niet verwijderd tot hij automatisch verdwijnt na het einde van de leasetijd.
Bij mijn oude D-Link Dir-655, kon ik gewoon die client verwijderen, en was het IP nummer weer vrij
-
@Hofstede: Nee, lukt niet.
Had pasgeleden een nieuwe printer aangeschaft, en wilde die hetzelfde IP geven als de oude.
Printer uit reservation gehaald, handmatig de nieuwe printer toegevoegd met nieuw MAC adres op oude IP, maar kreeg steeds de melding fat het IP al in gebruik was, heb toen de nieuwe printer een nieuw statisch IP gegeven, en pas 24 uur later de nieuwe printer eerst statisch en toen via "Aan adresreservering toevoegen" in de lijst weer het oude IP kunnen geven.
-
Wat onhandig.
Zou Synology vragen om dit aan te passen in een volgende firmware update.
Is toch raar dat je 24 uur moet wachten om een ip adres opnieuw te kunnen gebruiken.
-
Ik heb nu de leasetijd naar een uur gezet, en dat is nog te doen, want als dat IP naar de reservations gaat, wordt het "onbeperkt".
En Synology vragen om een bug te verwijderen kost al een behoorlijke tijd, er zijn nu bijvoorbeeld gebruikers waar clients die niet aktief zijn op dit moment, maar wel aktief zijn geweest sinds de verandering naar zomertijd.......Wel als aktief in de Verkeerbeheerlijst blijven staan.
Hierdoor werkt bv ook WOL niet.
De bug is bekend bij Synology, maar wordt hoogstwaarschijnlijk pas in SRM 1.1.5 opgelost, en heeeeeeeel misschien in SRM 1.1.4, deze bug was er ook al vorig jaar, bij de verandering naar wintertijd (Maar toen was er een workaround)
Hier is de thread op het Amerikaanse forum, voor wiw er ook last van heeft. (https://forum.synology.com/enu/viewtopic.php?f=265&t=123359)
Ik zeg zeker niet dat de RT1900 een slechte Router is, maar ze hebben er naar mijn mening teveel "features" bijgestopt, sinds de release, die de router instabieler en de GUI trager maken.
Ook de CPU gaat nu regelmatig naar de 100%, wat de eerste paar maanden niet het geval was
-
Zie de draad nu pas (bij toeval).
Is er een mogelijkheid om die client uit de lijst te verwijderen, en ik het IP nummer meteen kan gebruiken voor dat nieuwe apparaat, zonder dat ik moet wachten tot de Leasetijd op 0 staat (24 uur dus), zodat het IP nummer automatisch vrijkomt ??
Ja dat kan. (Vergeet verder voorgestelde opties dat firmware zou moeten worden aangepast).
Gewoon de router een keer rebooten zodat oude IP-adressen met geldende leasetijden worden vrij gegeven, en erna een nieuwe lease wordt gegeven op de nieuw gekozen IP-adressen. Evt. ook de aangesloten apparaten een keer rebooten. (Zie ook < HIER > (https://www.synology-forum.nl/synology-router/dhcp-reserverings-probleem/msg198354/#msg198354) ).
Is feitelijk de basis standaard procedure bij veranderingen van IP-adressen om apparaten een keer te herstarten.
-
Het is geen kwestie van moeten verdedigen idd. Maar je komt heel vaak tegen dat iemand vraagt "hoe doe ik dit en dat", terwijl dan bij even doorvragen naar t doel, er zomaar een veel simpeler oplossing is. Vandaar dat ik (en vele anderen met mij) die vraag altijd even stel.
Overigens lees ik in t relaas eigenlijk twee doelen. Njet helder is welke je precies nastreeft
1) wil je gewoon een vast IP voor sommige apparaten? (Snap ik), of
2) wil je een specifiek vast ip kiezen voor sommige apparaten (snap ik niet - welk probleem los je ermee op?)
Sent from my iPhone using Tapatalk
-
2) Ik snap dat wel.
Bij mijn eigen situatie met die Synology router, kies ik bewust een bepaalde volgorde, waarbij zowel de eigen Hostnaam van die apparaten alsook de IP-adressen volgens een bepaalde chronologische volgorde wordt vastgelegd. In eerste instantie bij DHCP zonder dat nog een DHCP reservering is vastgelegd, is er van die chronologische volgorde nog geen sprake. Niet voor IP-adres, niet voor de Host naamgeving.
Om makkelijker een lijst van vastgelegde apparaten te overzien wat daarin is opgenomen, kan men de weergave van de lijst sorteren op:
- MAC-adres
- IP-adres
- Hostnaam
Zowel oplopend als aflopend. Door bovenaan bij het betreffende menu even op de kolomnaam van de verschillende onderdelen te klikken.
-
Misschien een beetje mosterd na de maaltijd, maar misschien is het een idee om het toekennen van vaste IP adressen
te gaan regelen aan client zijde. Dat is even werk (je moet immers elke client afgelopen), maar op deze wijze ben je van dit soort problemen verlost.
Ik heb al mijn clients een IP gegeven onder de 50 (192.x.x.2-50) en de DHCP pool laten starten vanaf 51(tot 254).
Als er dan een client tussenuit moet qua vast -ip heeft de router daar geen bemoeienis meer mee.
Nadeel: Ik moet wel even een (handmatige) administratie bijhouden voor alle IP's onder de 50...
Peter
-
...misschien is het een idee om het toekennen van vaste IP adressen te gaan regelen aan client zijde.
Dat is doorgaans een erg slecht idee. Wissel je toevallig een keer van router met een andere IP-range, koppelen je Clients niet meer.
Handig is het ook niet als overzicht met wat er aan apparaten wordt vastgelegd. Jij moet handmatig een administratie bijhouden.
In de router zitten al die tools al voor je ingebakken om dat optimaal uit te voeren. Waarom moeilijk doen als het makkelijk kan?
-
Het risico van een nieuwe DHCPserver (of router) is erg klein en als het mocht gebeuren, dan ben je daar natuurlijk zelf bij.
Het is dan een simpele klus om de router weer in de vorige (oude) range te zetten en de DHCP weer qua pool goed te zetten.
Er is denk ik geen beste manier; het is maar net wat je prettig vind en het is denk ik ook afhankelijk van hoeveel clients je gebruikt (overzicht).
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.
Bovendien levert deze werkwijze voordelen bij het vervangen van bv printers. 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.
Bovendien zullen juist de DHCP reserveringen weg zijn als je de router/DHCPserver vervangt. Die informatie zit immers in je oude server/router. Dus die moet je dan ook weer aanbrengen.
BIj vastlegging op client niveau ligt de IP informatie in de client en zullen bijvoorbeeld de printers hier ook bij een nieuwe DHCP server (of router) altijd weer op het dezelfde IP terug komen.(zolang ik maar eenmalig de range in de server goed zet).
Ieder natuurlijk het zijne.
Maar volgens mij raken we een beetje off-topic ;-)
Peter
-
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.
[attach=1]
Gesorteerd op Hostnaam:
[attach=2]
-
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
-
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 > (https://forum.synology.com/enu/viewtopic.php?f=265&t=130551&p=481457#p481457), 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.
-
Laten we er geen wellus/nietus discussie van maken.
Daar is de topic-starter niet mee geholpen.
Ik lees verder mee.
Thanks,
Peter
-
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)
-
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
-
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 (https://www.synology-forum.nl/synology-router/dhcp-clients-verwijderen/msg221200/#msg221200), 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 > (https://www.synology-forum.nl/synology-router/dhcp-clients-verwijderen/msg221232/#msg221232) 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:
[attach=1]
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.
[attach=2]
En........
Op dezelfde manier weer terug naar het oorspronkelijke vaste IP-adres 192.168.10.24 :
[attach=3]
En........
Vanuit hetzelfde uitgangspunt aangaande het IP-adres van mijn mobiele telefoon, normaal vast IP-adres 192.168.10.27 :
[attach=4]
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:
[attach=5]
-
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 (https://forum.synology.com/enu/viewtopic.php?f=265&t=123359) op het Internationale forum)
-
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.
-
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.
-
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 (https://www.synology-forum.nl/synology-router/firmware-update-srm-1-1-4-6509/msg221497) (uitgeprobeerd en het is nog hetzelfde als wat hiervoor in de draad beschreven).
-
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
-
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.
-
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.
-
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.
-
Het is mij bekend dat "vroeger" Synology Support enkele specifieke IP-adressen opgaf in hun reacties, waarbij je die toegang zou moeten verschaffen.
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 omdat ze dat tegenwoordig er niet bijzetten, had ik het vermoeden dat men inmiddels meerdere IP-adressen gebruikt, en het vooraf moeilijker te bepalen is welke afdeling contact legt.
In ieder geval zijn het "NIET" die IP-adressen uit 2014 die jij noemt. Maar wel in hetzelfde domein:
Information System 2017/05/12 05:14:10 admin System successfully started [SSH service].
Information System 2017/05/12 05:11:02 admin User [admin] logged in from [118.163.127.250]
Information System 2017/05/12 03:52:57 admin User [admin] logged in from [125.227.147.112]
Met de Firewall regel zou je de inlog dan nog wel kunnen beperken door bereiken van IP-nummers op te geven.
Zie nu overigens dat er nu twee Firewall regels extra bijstaan die me eerder onbekend waren.
De eerste regel is me duidelijk vanuit Support oogpunt gezien.
Die DNLA / UPnP die er bij staat, zou misschien kunnen dat die erbij is gekomen nadat ik een paar dagen terug mijn media-server opnieuw heb geïnstalleerd.
[attach=1]
-
Maar omdat ze dat tegenwoordig er niet bijzetten
Bij mij wel, afgelopen maandag:
Synology WAN IPs are 118.163.127.250, 125.227.147.112 and 125.227.250.76
-
Dat 2e adres is in ieder geval een ander IP-adres als gebruikt bij mij.
-
Blijkbaar zijn de doorgegeven adressen toch niet zo vast als ik altijd dacht. Misschien per afdeling anders. Dan toch heel Taiwan toelaten. Of het geheel van de drie gebruikte adresblokken, die elk een half miljoen groot zijn. (Altijd nog minder dan heel Taiwan :P)
-
Naar aanleiding van de fix die voor mijn router reeds is doorgevoerd (https://www.synology-forum.nl/synology-router/dhcp-clients-verwijderen/msg222630/#msg222630) en de vraag of het bij andere gebruikers ook ter beschikking komt:
Dear Customer,
Thank you for the good news.
According to our developers, this has been identified as a known issue.
Regarding this resolution, we release it in the future DSM version.
Please kindly stay tuned for the update, and in the meantime, we apologize for any inconvenience caused.
Please feel free to contact us again if you have further questions or suggestions.