Synology-Forum.nl
Packages => Officiële Packages => Radius Server => Topic gestart door: Briolet op 07 november 2014, 20:33:24
-
Onder de beta van dsm 5.1 werke de radius server nog wel. (Was zelfs een speciale 5.1 beta versie). Onder de 5.1 final stop het opstarten steeds met de melding dat poort 1812 al in gebruik is en het pakket stopt dan weer. (Hij staat wel op de dsm desktop, maar hij autentiseert niet meer. Dus al mijn draadloze apparaten werken plots niet meer. :(
Dan verwacht je toch dat van de beta naar de final geen problemen geeft. Ik het het pakket al ge-deïnstalleerd en ook de nas nog een extra reboot gegeven na alle pakket updates.
Balen, dat zal betekenen dat ik alle 4 wifi hosts en de vele cliënten tijdelijk een nieuwe SSID moet geven.
-
Ik heb radius ook draaien en bij mij draait het prima. Eindelijk hebben ze die auth bug gefixt.
Wel heb ik eerst de package geupdate van radius alvorens de DSM te updaten...
Zie je wellicht errors in de log ?
-
Ik log nu in via de Ziggo WifiSpot bij gebrek aan eigen WiFi toegang. Ik kan morgen pas weer bedraad bij de nas om te zien of er nog iets te doen is en om eventueel mijn wifi's op wpa2-psk in te stellen totdat de bug opgelost is.
Het log is als volgt:
RADIUS Server
Type Date & Time Event
Error 2014-11-07 20:27:16 /usr/local/synoradius/rad_listen[7]: Error binding to port for 10.0.1.30 port 1812
Error 2014-11-07 20:27:16 Failed binding to authentication address 10.0.1.30 port 1812: Address already in use
Info 2014-11-07 20:27:16 Loaded virtual server inner-tunnel
Info 2014-11-07 20:27:16 Loaded virtual server <default>
Error 2014-11-07 20:27:13 /usr/local/synoradius/rad_listen[7]: Error binding to port for 10.0.1.30 port 1812
Error 2014-11-07 20:27:13 Failed binding to authentication address 10.0.1.30 port 1812: Address already in use
Info 2014-11-07 20:27:13 Loaded virtual server inner-tunnel
Info 2014-11-07 20:27:13 Loaded virtual server <default>
Error 2014-11-07 20:27:09 /usr/local/synoradius/rad_listen[7]: Error binding to port for 10.0.1.30 port 1812
Error 2014-11-07 20:27:09 Failed binding to authentication address 10.0.1.30 port 1812: Address already in use
Info 2014-11-07 20:27:09 Loaded virtual server inner-tunnel
Info 2014-11-07 20:27:09 Loaded virtual server <default>
Dat is 3x hetzelfde en deze reeks herhaalt zich nog vele malen.
Vreemd is natuurlijk dat het pakket in pakket-centre aangemerkt is als 'gestopt' terwijl hij toch gewoon op de desktop staat en je de settings nog volledig kunt bedienen.
-
Nog steeds problemen met de Radius Server?
Ik gebruik deze ook en ga niet naar 5.1 voordat ik weet dat het blijft werken...
-
Het probleem is persistent. Ik heb het pakket nog eens verwijderd, dan de nas ge-restart en toen pas geïnstalleerd. Het resultaat blijft echter hetzelfde. In packet manager staat hij als 'gestopt'. Maar ondertussen is hij wel werkzaam en staat gewoon op de desktop. Opvallend is wel, dat elke keer als ik op DSM inlog, hij niet op de desktop staat en dan na 1 à 2 seconden het icoontje verschijnt.
Gezien mijn andere problemen met het interne netwerk, zal dit niet oplosbaar zijn, omdat hij natuurlijk data moet gaan uitwisselen met interne apparaten. Dus al zou hij wel goed actief worden, dan zal het op die andere bug vastlopen. (Behalve met 1 cliënt die in een ander subnet zit.)
Maar het zou me niet verbazen dat beide bugs een gezamenlijke oorzaak hebben.
-
Blijft duister....
Radius server is niet veel in gebruik bij anderen lijkt wel?
Ik vind het wel een handige toevoeging.
-
Een Radius server is inderdaad een handig iets als je regelmatig derden op je netwerk wilt toelaten.
Alleen jammer dat niet alle cliënten het enterprise protocol ondersteunen dat nodig is om te kunnen verbinden.
b.v. mijn Wifi Printer niet en ook mijn Humax hardeschijf recorder niet. Gelukkig wilde ik die toch al niet via Wifi gaan gebruiken, maar voor velen kan dit een drempel zijn om de radius server te gaan gebruiken.
Als noodoplossing heb ik nu dus de 2 belangrijkste accesspoints een ander SSID gegeven met PSK toegang. Een aantal reguliere bezoekers zal dat SSID deze week dus ook aan hun smartphone moeten toevoegen.
-
Klopt, mijn Epson printer kon er ook niet mee overweg.
Gelukkig stond deze al naast een vaste aansluiting.
Windows 7 machines is ook even wat meer werk.
-
Maar het zou me niet verbazen dat beide bugs een gezamenlijke oorzaak hebben.
Niet dus. De elders genoemde bug is opgelost, maar de Radius server werkt nog steeds niet.
-
Ik heb geen problemen en ik gebruik het heel veel tientallen clients no issues.. Dat error binding to port duidt erop dat er al iets draait (wat ook aansluit bij de melding IP in use).
Kan je met ps afx niet zien wat dat is ? Kan wellicht het probleem zijn dat je accespoint het verkeerde shared secret heeft ?
Of zet je nas eens uit en ping dan het adres (10.0.1.30) eens waarvan gemeld wordt dat het in use is. Is dat 10.0.1.30 je nas adres (hard) of een DHCP toegekend adres ?
-
Ik kreeg vanochtend om 8:45 de reactie:
As to RADIUS Server issue, it has been escalated to our engineers for their further analysis. I will update you upon any news.
en twee uur later om 10:45
Our developer has fixed this issue in your DiskStation manually and we have confirmed it as a bug (network setting issue) and will fix it in further DSM release. Please do feel free to contact us if you have further questions or problems.
Het log eindigde nu met "ready to process" maar het pakket stond nog steeds als gestopt te boek. Via de PackageManager kon ik hem nu wel starten en het log geeft geen fouten meer.
Mijn laptop geeft echter de melding dat hij geen verbinding met de radius server kan maken, dus ergens is er nog iets mis. Ik zal er vanavond nog eens naar kijken of ik overal wel weer de goede radius wachtwoorden gebruik.
Edit: ik zag dat de Synology medewerker de firewall regel voor de radius server gewist heeft. Na toestaan van de radiuspoort werkt het dus weer. :P
-
Dus als ik geen firewall regels heb voor de Radius server poort moet het gewoon werken?
-
Ik begrijp uit hun reactie dat het probleem niet in de server zat maar in het netwerk. Met het testen hebben ze waarschijnlijk mijn firewall regel om poort 1812 toe te staan even gewist. Het opstarten van de server werd volgens het log door een reeds bezette poort 1812 tegengehouden.
Maar als dat zo is, had ik de problemen waarschijnlijk ook met de oude radius server gehad en is het i.d.d. een bug in DSM 5.1 zelf.
-
Na de update naar 5.1 deed mijn Radius server het ook niet meer.
Maar het pakket moest nog gedaan worden, nu werkt het wel.
Zie alleen een vreemde boodschap in de log file staan: [mchap] invalid LM-Password.
Wat dat is weet ik nog niet?
-
Ik heb een soort van gast account aangemaakt speciaal voor deze radius server.
Op de NAS heeft deze gebruiker eigenlijk geen rechten.
Maar wel om in te kunnen loggen uiteraard.
Ik geef gasten deze gegevens, zij blij want internet werkt goed.
En regelmatig verander ik het wachtwoord zodat je er grip op houdt.
Ik denk dat er laatst met een doorlopende verjaardag een man of 15 tegelijk waren ingelogd.
-
Tnx Robert! Dat gaat werken! Ik vreesde al een uitgebreide userdatabase met systeembeheerdersnarigheden.
-
en die foutmelding gaat over ms chap, chap staat voor challenge handshake protocol, horend bij radius dacht ik. MS vrees ik voor....
-
Volgens mij moet je met 1 account op meerdere toestellen kunnen inloggen. Het enige wat de Wifi router doet, is aan de nas vragen of persoon x mag inloggen. Er wordt niet bijgehouden of je ook weer uitlogt. Ook als de nas down gaat, blijft de wifi verbinding staan.
Ik heb wel gemerkt dat de IP adressen soms onlogisch zijn. Door de huidige problemen waren mij settings gewist en moest ik ze opnieuw instellen. Ik heb 2 routers in mijn netwerk. Ubee --> airport --> nas. Voor de airport moet ik het WAN IP gebruiken en niet het IP van het interne netwerk, waar ook mijn andere Wifi accessoints in zitten.
Qua rechten kun je ook een speciale wifi-only groep aanmaken de verder geen rechten op de nas heeft en daar de gasten aan koppelen.
-
en die foutmelding gaat over ms chap, chap staat voor challenge handshake protocol, horend bij radius dacht ik. MS vrees ik voor....
Maar ik krijg dit pas sinds de update naar 5.1
En of MS voor Microsoft staat betwijfel ik, louter Apple draadloze apparatuur de er dagelijks gebruik van maken.
Elke verbinding die gemaakt wordt geeft deze melding.
-
MS staat wel degelijk voor MicroSoft. Ik gok dat MS dit protocol ontwikkeld heeft om op hun server te kunnen inloggen. Als je via een onbeveiligde verbinding inlogt, gaat het wachtwoord als platte tekst door de lucht. Bij een MS-Chapv2 inlog krijg je een complexe inlog challenge waarbij alleen een gehashte versie van het wachtwoord overgedragen wordt. Die hash kan nog steeds onderschept worden en met brute-force gekraakt worden. Volgens mij is wel al aangetoond dat dit mogelijk is, maar vereist toch nog erg krachtige computers.
Bij de nas kun je deze gehele inlog ook nog via het standaard servercertificaat beveiligen en dan is er zeker geen vuiltje aan de lucht. Echter gaan niet alle OS-en vriendelijk om met zulke certificaten. Bij de apple producten krijg je bij de eerste inlog de melding dat het certificaat onbekend is met de optie om het certificaat in toekomst te vertrouwen. Makkelijk dus.
Bij android en windows, moet je het certificaat handmatig installeren. Of kiezen om zonder certificaat te verbinden. Dan gaat je gehashte wachtwoord wel leesbaar door de lucht en zou ik voor de zekerheid nooit inloggen met een administrator account.
-
In de Radius Server kan je een basiscertificaat downloaden.
Maar hoe krijg ik dat certificaat op mijn iPhone?
Ik zal de bestaande verbinding eens verwijderen en opnieuw toevoegen.
-
In de apple producten zoals de iPhone is dat geen probleem. Bij de eerste inlog krijg je altijd de vraag of je het certificaat wilt accepteren. (Dat certificaat meesturen is een standaard onderdeel van het opbouwen van een SSL/TLS verbinding) En omdat dit radius certificaat hetzelfde certificaat is als voor een https inlog, is de kans groot dat hij er al instaat vanwege een eerdere toestemming bij een https inlog.
Toen ik met de radius server begon vond ik het heel onbevredigend om niet te zien hoe de inlog precies verliep en ik heb uiteindelijk Wireshark gepakt om zeker te zijn dat er werkelijk een certificaat gebruikt werd om de authenticatie te beveiligen.
Het proces is gelijk aan die van de Ziggo/UPC WifiSpots. Daar was het voor de meeste Windows/Android mensen te lastig om een certificaat te installeren, vanuit een lopende verbinding. Sinds een paar maand heeft Ziggo daar nu speciale apps die de installaties voor je doen. ;)
-
Verbinding vergeten, opnieuw aanmelden, certificaat accepteren en meteen in de logfile kijken.
Nog altijd dat foute wachtwoord...... Blijft vreemd.
-
Ik log nu in via de Ziggo WifiSpot bij gebrek aan eigen WiFi toegang.…
Het log is als volgt:
RADIUS Server
Type Date & Time Event
Error 2014-11-07 20:27:16 /usr/local/synoradius/rad_listen[7]: Error binding to port for 10.0.1.30 port 1812
Error 2014-11-07 20:27:16 Failed binding to authentication address 10.0.1.30 port 1812: Address already in use
Info 2014-11-07 20:27:16 Loaded virtual server inner-tunnel
Info 2014-11-07 20:27:16 Loaded virtual server <default>
Tja, alles herhaalt zich bij de installatie van DSM 5.1 update 2. Exact hetzelfde probleem en foutmelding. Dit keer heb ik geprobeerd of ik niet gewoon een andere poort kan gebruiken. Dus ik stel poort 1814 in, maar krijg dan gewoon dezelfde foutmelding, maar nu voor poort 1814.
Alle andere opties zoals nas resetten en Radius Server opnieuw installeren had ik vorige keer al geprobeerd en zal nu vast ook falen.
Tragisch omdat Synology al aangegeven had dat ze de fout gevonden hebben en dit in een volgende update zouden verbeteren. Nu heeft de update waarschijnlijk alle aanpassingen overschreven die de techneuten van Synology op mijn nas hadden gedaan om hem weer werkend te krijgen.
-
Hmmm...
Ik doe de update nog maar even niet denk ik.
-
Had net ook al onder ander bericht gezet dat de radius server bij mij nog steeds goed werkt na de laatste update.
-
Ga ik toch updaten dit weekeinde, kijken of het bij mij blijft werken.
-
Eigenlijk heb ik nog nooit issues gehad met de radius oplossing.
Anderen ook niet, dus moet het iets specifieks op mijn nas zijn. Het enige wat waarschijnlijk niet standaard is, is dat ik recent de Wifi-optie geactiveerd heb op mijn 212j nas. Die activering heeft de gehele netwerkomgeving aangepast, incl firewall. Dus ik vermoed dat dit een afwijkende configuratie update vraagt, waar ze mee de mist in gaan.
Ik heb alleen Synology pakketten in gebruik dus een onbekende aanpassing kan ik uitsluiten zodat het hun aanpassingen zijn die de boel in de war gooien. :|
-
Ik kreeg net een mailtje van Synology:
Dear customer ,
Thank you for contacting Synology support.
After discussed with our developers, we assumed it a side effect of a known issue at the moment
For workaround , please try to disable dhcp client with these command :
stop dhcp-client IFACE=eth0
It can be process with login with SSH/TELNET, as root account (password is same as admin)
See if the problem still happens.
Hope this helps.
Zijn suggestie gaf een error:
GedeeldeData> stop dhcp-client IFACE=eth0
stop: Unknown instance: eth0
Maar na inloggen bleek de radius server nu wel actief en volgens het log was hij al twee uur eerder actief geworden. Zij hebben dit dus al remote opgelost. Zijn idee was dus dat de bug samenhangt met de DHCP mode.
In elk geval doen alles het nu weer. En als het weer mis gaan, heb ik een idee in welke richting te zoeken.
-
Ik ben hier zojuist ook tegen aan gelopen.
Situatie. Als ik de firewall aanpas, hangt de radius server.
Oplossing: herstart de radius app en dus niet de hele server (dat lost het niet op).
Waarschijnlijk lost synology dit in een volgende release op. Heb het nog maar even gemeld aan synology.
-
Ik stop en start de radius server een keer per week denk ik.
Krijgen we in huis gewoon geen wifi verbinding meer, na de herstart meteen wel weer.
Geen vreemde dingen in de log waarom het even niet werkt.
-
Zie jij ook deze melding niet in je radius log ?
[ms-chap] invalid LM password
daar lijkt het bij op mis te gaan.
-
Die melding zie ik bij elke inlogpoging......
Loop ik van de begane grond naar de zolder, kom ik langs 3 routers/AP, zie ik die melding 3 keer.
Ik vroeg er laatst al eens om, schijnt een Microsoft gevalletje te zijn.
Vreemd want ik gebruik alleen Apple draadloze apparatuur, zit nergens Microsoft in de schakel.
Maar alle draadloze loggen wel gewoon in, waar dit LM password vandaan komt, geen idee?
-
Nooit gezien. Ik zie slechts 2 regels per inlog, ongeacht het device. Mij mij zijn het een i-Mac en diverse android toestellen die op het netwerk inloggen.
Misschien dat hij eerst een ander protocol probeert voor authenticatie?
-
Ook bij een android client zie ik deze melding.
Kan niet achterhalen waarom dit gebeurd.
-
Ik zie ook niets in de settings. Ik heb voor de aardigheid de config file bekeken. Daar kun je nog iets meer instellen dan via dsm:
GedeeldeData> cat radiusclient.conf
# General settings
# specify which authentication comes first respectively which
# authentication is used. possible values are: "radius" and "local".
# if you specify "radius,local" then the RADIUS server is asked
# first then the local one. if only one keyword is specified only
# this server is asked.
auth_order radius
# maximum login tries a user has (default 4)
login_tries 4
# timeout for all login tries (default 60)
# if this time is exceeded the user is kicked out
login_timeout 60
# name of the nologin file which when it exists disables logins.
# it may be extended by the ttyname which will result in
# a terminal specific lock (e.g. /etc/nologin.ttyS2 will disable
# logins on /dev/ttyS2) (default /etc/nologin)
nologin /etc/nologin
# name of the issue file. it's only display when no username is passed
# on the radlogin command line (default /etc/radiusclient/issue)
issue /etc/radiusclient/issue
# RADIUS settings
# RADIUS server to use for authentication requests. this config
# item can appear more then one time. if multiple servers are
# defined they are tried in a round robin fashion if one
# server is not answering.
# optionally you can specify a the port number on which is remote
# RADIUS listens separated by a colon from the hostname. if
# no port is specified /etc/services is consulted of the radius
# service. if this fails also a compiled in default is used.
authserver localhost:31067
# RADIUS server to use for accouting requests. All that I
# said for authserver applies, too.
#
acctserver localhost:31068
# file holding shared secrets used for the communication
# between the RADIUS client and server
servers /etc/radiusclient/servers
# dictionary of allowed attributes and values
# just like in the normal RADIUS distributions
dictionary /etc/radiusclient/dictionary
# program to call for a RADIUS authenticated login
# (default /usr/sbin/login.radius)
login_radius /usr/sbin/login.radius
# file which holds sequence number for communication with the
# RADIUS server
seqfile /var/run/radius.seq
# file which specifies mapping between ttyname and NAS-Port attribute
mapfile /etc/radiusclient/port-id-map
# default authentication realm to append to all usernames if no
# realm was explicitly specified by the user
# the radiusd directly form Livingston doesnt use any realms, so leave
# it blank then
default_realm
# time to wait for a reply from the RADIUS server
radius_timeout 10
# resend request this many times before trying the next server
radius_retries 3
# NAS-Identifier
#
# If supplied, this option will cause the client to send the given string
# as the contents of the NAS-Identifier attribute in RADIUS requests. No
# NAS-IP-Address attribute will be sent in this case.
#
# The default behavior is to send a NAS-IP-Address option and not send
# a NAS-Identifier. The value of the NAS-IP-Address option is chosen
# by resolving the system hostname.
# nas_identifier MyUniqueNASName
# LOCAL settings
# program to execute for local login
# it must support the -f flag for preauthenticated login
login_local /bin/login
-
Die melding zie ik bij elke inlogpoging......
Loop ik van de begane grond naar de zolder, kom ik langs 3 routers/AP, zie ik die melding 3 keer.
Ik vroeg er laatst al eens om, schijnt een Microsoft gevalletje te zijn.
Vreemd want ik gebruik alleen Apple draadloze apparatuur, zit nergens Microsoft in de schakel.
Maar alle draadloze loggen wel gewoon in, waar dit LM password vandaan komt, geen idee?
Bij mij is het ook mac online er is geen windows client te vinden in huis. Ik ben wel bezig met dit verder uit te zoeken. Kom het ook wel tegen bij de freeradius fora. Dus we zijn niet de enige en lijkt meer dan syno gerelateerd.
-
Kan het ook liggen aan de account instellingen van de cliënt? Of kun je daar op de iPhone niets instellen. Mijn iBook is zelf configurerend dus moet ik maar accepteren wat hij kiest. Ik kan alleen achteraf zien dat hij met ms-chapv2 authentseert.
Op Android moet je wel zelf alles configureren. Daarvan zijn er drie wekelijks op mijn netwerk, maar zie ik niets vreemds.
Per verbinding krijg ik twee regels in het log. Beide beginnen met de accountnaam van de inlogger.
Android heeft twee vakjes voor de identiteit. De eerste heet "identiteit" en dat is de inlognaam. Er is ook nog een vak "anonieme identiteit" (Wat is dat eigenlijk). Met de radius server van een jaar geleden kwam die naam terug als de inlognaam van de tweede log-regel. Ik vond het handig om daar de apparaat-naam in te vullen. Dan kon ik snel zien welk apparaat inlogde, i.p.v. naar het mac-adres te kijken. Tegenwoordig genereert het een error als dat "anonieme identiteit" veld niet leeg is.
-
Ik krijg net een update en mijn issues zijn gone :-)
-
Hier niet....
Per inlogactiviteit een invalid password.
-
Same here toch helaas. Ik dacht er vanaf te zijn maar ook ik zie ze nu weer in de logs opduiken..
-
Ik heb gisteren mijn zus met haar kinderen op bezoek gehad. Één van hen genereerde ook deze error in het log:
Thu Dec 25 16:28:48 2014 : Error: [mschap] Invalid LM-Password
Thu Dec 25 16:28:48 2014 : Auth: Login OK: [A.....] (from client Kantoor port 0 via TLS tunnel)
Thu Dec 25 16:28:48 2014 : Auth: Login OK: [A.....] (from client Kantoor port 0 cli BC-44-86-BA-CC-29)
Zij heeft zeker geen Apple product, maar een goedkoop Android toestel.
Overigens vind je het log in de nas op:
/volume1/@appstore/RadiusServer/var/log/radius/radius.log
Lekker verstopt dus, maar identiek aan het log in dsm. Alles wat in Volume1 staat kun je echter met een hardlink in een share zichtbaar maken, wat het weer lekker snel toegankelijk maakt (totdat er een logrotatie plaats heeft)
Mijn oude radiuslog is gisteren gewist met de update van het radius package. Bij een hardlink naar een share, blijft daar wel het oude log staan. :P
-
[ms-chap] invalid LM password
Gevaarlijk om dit soort info openbaar te maken. ;D
Ik denk dat ik de oorzaak nu gevonden heb: Als je wachtwoord een uppercase teken bevat, dan krijg je die foutcode. Bij een volledig lowercase wachtwoord, blijft die foutmelding weg.
Ik heb het nu bij 3 accounts geprobeerd waar ik het wachtwoord van ken. (Niet direct een onderzoek van grote getallen, maar anderen kunnen dit hopelijk bevestigen of juist ontkrachten)
Als ik op mijn laptop inlog met het ene account, is die melding er niet en met het andere account wel.
-
Gevaarlijke informatie maar geen hoofdletters in mijn wachtwoord.
Dus bij mij gaat deze theorie niet op.
-
Dan maar verder op zoek naar een andere reden. ;)
Als je op die error googled vind je vaak iets als:
[mschap] No Cleartext-Password configured. Cannot create LM-Password.
[mschap] No Cleartext-Password configured. Cannot create NT-Password.
[mschap] Told to do MS-CHAPv2 for john with NT-Password
[mschap] FAILED: No NT/LM-Password. Cannot perform authentication.
[mschap] FAILED: MS-CHAP2-Response is incorrect
Dus naast een "LM-Password" is er blijkbaar ook nog een "NT-Password". Pas als beide falen, faalt de connectie-opbouw. Ik heb echter nog niet kunnen vinden wat die beide wachtwoorden nu precies inhouden.
-
Het blijft duister.....
-
Eigenlijk moet je blij zijn met die foutmelding. Als ik de Wikipedia er bij haal: LM Hash (http://en.wikipedia.org/wiki/LM_hash), dan zie ik dat het genereren van een LM hash een minder veiliger methode is, waarvoor nu een beter protocol bestaat. Dat ww mag ook maximaal 14 tekens lang zijn. Een tip om die hashes te voorkomen is dan ook een ww van 15 tekens of langer te gebruiken.
Maar dit verklaart het gedrag nog niet. Mijn wachtwoord heeft > 14 tekens en genereert die melding niet. Maak ik een nieuw account aan met dat ww, dan genereert dat account wel weer die melding.
-
Nu heb ik een verdere test gedaan. Van mijn eigen account dat geen error geeft heb ik het wachtwoord opnieuw gedefinieerd met exact dezelfde inhoud. Nu genereert dat account ook die LM-error.
Als laatste test heb ik er nog een account bijgepakt dat al 2 jaar oud is, (met ww van <14 tekens) en die genereert niet die LM-error.
Dat suggereert bij mij dat Synology het opslaan van wachtwoorden aangepast heeft en deze error alleen bij nieuw ingestelde wachtwoorden genereert. Maar gezien dat de LM-hash zwak is, is deze error eigenlijk goed. :P
-
hebben jullie die nieuwe radius update gdaan van enkele dagen geleden? Tot die tijd moest ik ook ca wekelijks mijn radiusserver opnieuw opstarten. Ik hoop dat dit nu verholpen is
Die vage ms chapinvalid pwd melding lijkt bij mij ook iets met een wachtwoordformat te maken te hebben! Een account met een iets simpeler wachtwoord geeft wel de foutmelding, anderen niet. Daarmee nog maar eens aan de klungel. overigens beiden pwd van tusen de 10 en 15 karakters zonder hoofdletters (einde verstrekking privacyggevoelige informatie)
-
Onder de beta van dsm 5.1 werke de radius server nog wel. (Was zelfs een speciale 5.1 beta versie). Onder de 5.1 final stop het opstarten steeds met de melding dat poort 1812 al in gebruik is en het pakket stopt dan weer. (Hij staat wel op de dsm desktop, maar hij autentiseert niet meer. Dus al mijn draadloze apparaten werken plots niet meer. :(
Dit probleem is weer terug sinds de DSM 5.1 update van vandaag. De radius server stopt zichzelf na aanzetten met de melding dat de poort al in gebruik is. Synology heeft me de vorige keer een tip gegeven om de boel weer aan de praat te krijgen. Toen hadden ze het probleem al remote opgelost, maar ik heb die tip van 3 december 2014 er weer bijgepakt.
Dear customer ,
Thank you for contacting Synology support.
After discussed with our developers, we assumed it a side effect of a known issue at the moment
For workaround , please try to disable dhcp client with these command :
stop dhcp-client IFACE=eth0
It can be process with login with SSH/TELNET, as root account (password is same as admin)
Na invoeren van het commando kreeg ik de volgende terugmelding:
dhcp-client stop/waiting
Daarna via DSM inloggen en ik kon de radiusserver weer aanzetten.
----
Dit alles gedaan met een VPN verbinding via een Ziggo hotspot omdat ik niet meer op mijn eigen Wifi kon inloggen.
-
Zijn er meer mensen met dit probleem ?
Ik herken het niet ondanks dat ik radius gebruik
-
Ik herken het eerlijk gezegd ook niet.
Zie dat deze update 4 automatisch is geladen op mijn NAS waar de Radius Server op draait.
Niets van gemerkt en al mijn draadloze clients werken nog.
-
Ik denk dat het alleen onder specifieke omstandigheden optreed. Synology heeft het vorig jaar twee keer op afstand gefixed op mijn nas. Daarbij gaven ze aan dat het een "Known problem" is. Dat was alles vorig jaar dus verbaast het me dat de bug er nog steeds in zit.
Wat bij mij misschien minder voorkomend is, is dat mijn nas zijn IP via DHCP krijgt. De fix die Synology was om de 'dhcp-client' via de terminal uit te zetten. Het gros van de mensen definieert de vaste IP in de nas zelf en niet via dhcp.
Een ander verschil zou kunnen zijn dat ik een Wifi accesspoint gebruik die intern aan "eth0" gekoppeld is.
Ik heb twee week geleden mijn NAS vervangen door een nieuwe met geheel andere hardware. Hier speelt het probleem dus ook.
In elk geval zal ik vandaag nog een antwoord op het synology mailtje van 3 december formuleren om hun duidelijk te maken dat het probleem nog steeds speelt. Ik gebruik de nieuwe beta versie van de radius server.
-
Mijn NAS staat ook op DHCP.
Ik heb er geen WiFi accesspoint op, misschien toch daar de fout in zoeken?
-
Na de update naar 5.2 werkt de Radius server dus helemaal niet meer.
Pakket stoppen en opnieuw starten lukt ook niet meer.
Kijken of een complete herstart van mijn 1812+ helpt.
Na herstart is de status van de Radius server stopgezet, starten helpt niet.
Niet fijn!
-
Als jij in het radius log hebt staan dat de radiuspoort 1812 reeds in gebruik is, dan help mijn oplossing van een paar messages hierboven vast.
Overigens heb ik dat probleem met bezette poorten voor het laatst gehad met de laatste 5.1 update. Bij updaten naar de 5.2beta en naar de 5.2 release liep alles als een zonnetje.
-
Staat niets in de log.
Uit nood op mijn 712+ gezet en daar werkt het wel!
-
Mooi dat je een backup radius kunt creëren. :P
Op mijn Apple Airports kan ik een primaire en secundaire radius server opgeven. Dat is mooi om met dit soort storingen om te gaan.
Mijn Ziggo Ubee en ook de hotspot functie van de nas accepteren echter maar 1 radius server.
Heb je ook al geprobeerd het gehele pakket te deïnstalleren? Je ben je settings dan wel kwijt, maar dat zijn er maar een paar.
-
Nood Radius server werkt goed 8)
Morgen de oude situatie eens proberen te maken.
Pakket verwijderen en opnieuw installeren is niet zo ingewikkeld.
Ik gebruik drie draadloze routers hiervoor en dat instellen is zo klaar.
-
Er is vandaag weer een update uitgebracht. Versie 1.1-0094
Volgens de release notes alleen iets met toestaan van poorten onder de 1024, maar meestal zitten er meer fixes in dan de genoemde.
Wel is, zoals altijd, het log weg na een update. Wil je dat behouden, moet je die eerst even exporteren met de 'opslaan' button.
-
Ik gebruik de standaard poort, die ligt boven die waarde.
Maar de Radius Server draait nu prima op mijn 712+
Voor mijn gevoel zelfs beter dan voorheen op mijn 1812+
Ik denk dat ik het voorlopig zo laat.