Hi zusammen:
Beim automatischen Upgrade hat es irgendwie an der freeradius-Konfiguration was zerschossen, so dass bei uns niemand mehr ins Internet kam.
Packages with configuration changes:
-freeradius-config 3.2.3-1 amd64
+freeradius-config 3.2.4-1 amd64
Ich hätte auch ein diff, kann aber keine problematische Änderung an der Config erkennen.
Server reboot (auf dem auch der freeradius läuft ) hat nicht geholfen.
Rumgespielt mit der Config und die Restriktion --require-membership-of=LINUXMUSTER\wifi
nur in /etc/freeradius/3.2/mods-available/mschap entfernt. Neu starten des Dienstes. Dann tat es wieder.
Ist aber immer noch unklar, ob das wirklich die Ursache ist.
Hallo Tobias,
normalerweise spuckt doch freeradius -X oder notfalls auch freeradius -XX ziemlich detailliert aus, wo es gerade hakt, oder? Hast Du das ausprobiert?
Hallo Tobias,
ich habe heute im Zuge des 7.2 Upgrades damit gekämpft, bei mir war es so, dass ich in require-membership zwei mal das Backslash zwischen Domain und Gruppe eintippen musste, damit es einmal ankommt. Ich hatte sowas in den Logs gesehen, dass er die Domain nicht auflösen/trennen konnte. Ich habe das auch beim Eintrag im eap Modul gemacht…
ich habe immer mit
service freeradius debug
getestet
LG
Max
Ihr seid ja Schatzis…
Das wäre ja ein Zufall, wenn es wirklich daran läge: \\ statt \ im require-membership und du das zufällig heute feststellst.
Es kann bei mir eigentlich nur am Update von gestern abend liegen, dass ich unschuldig am Server angeschmissen hatte.
Murphys Law: Deutsch Fortbildung im Haus, die dann weder WLAN noch Apple-TV-Zugriff hatte, weil unsere Apple-TVs über Radius am Netz hängen.
Wenn jemand noch einen Befehl „übrig“ hätte, mit dem man den Wifi-Zugang testen könnte? radtest hat bei mir nicht funktioniert (also per Wifi komme ich rein, während radtest fehlschlägt).
Ich weiß, dass ich schonmal eine einfach CLI-Möglichkeit hatte, eine WIFI-Anmeldung per Radius zuverlässig nachzustellen, statt immer tatsächlich vor Ort mich ins WLAN zu verbinden.
(Fehlt noch, dass ich einen Laptop in den Serverraum stelle, der per LAN angebunden ist, den ich remote dann versuche zusätzlich mit dem WIFI zu verkuppeln… Oder noch besser: der server kriegt eine WIFI-Karte+Antenne und das ganze wird in einer VM simuliert … hi hi hi klingt wie zu Unizeiten, wo man jeden Scheiß ausprobiert hat.)
verstehe ich nicht, ich habe das nicht im eap-Modul.
Das ist bei mir nur configured insofern, als dass unter peap { ... default_eap_type = mschapv2 .... virtual_server = inner-tunnel ... } verwendet und unter mschapv2 { ... } nichts mehr wichtiges steht.
Erst in ntlm_auth steht wieder die ntlm_auth = ... Zeile wie in der Doku.
Die ist erst relevant, wenn ich „PAP“ statt „EAP/mschap“ teste…
Hier zur Vollständigkeit noch meine CLI-debug-kommandos:
PAP authentification mit relevanter config in freeradius/3.2/mods-enabled/ntlm_auth. Hier wird definitiv das Passwort im Klartext übermittelt:
EAP-MSCHAPv2 authentification mit relevanter config in freeradius/3.2/mods-enabled/mschap, hier scheint das clear-text-pw nicht beim Server anzukommen.
Ich benutze die Pakete von networkradius.com, die ihre Konfigurationsdateien bei /etc/freeradius ablegen. Version dort: 3.2.4-1
Debian/Ubuntu-Pakete legen ihre Konfiguration in /etc/freeradius/3.0 ab. Version in ubuntu-jammy: 3.0.26.
Meine Befehle oben enthalten noch /etc/freeradius/3.2/ aus historischen Gründen, sollte eigentlich nicht so sein … ist also nicht so gut, das so hinzubiegen, wie ich das mal gemacht habe. Ich sollte eher dem Paketstandard folgen.
ich hab die Woche meinen Dockerserver auf ubuntu 22.04 und dann auf 24.04 upgegraded: wie zu erwarten: ohne irgendwelche Probleme (ja, sorry: der war noch 18.04 … hab ich nicht bemerkt ).
Und in einem Anflug von „in Sicherheit wiegen“ und weil es ja auch sonst selten zu Problemen kommt, hab ich auch noch den lmn server upgegraded (nicht von 7.1 auf 7.2 oder so, sondern ein normales dist-upgrade).
… auch keien Probleme … dachte ich … aber war nicht so.
Heute schrieb man mir dann, dass das GastWLAN funktionierte, aber das „reguläre“ (also mit WPA2 Enterprise) nciht: keiner komme rein.
Klar: ich sitze in einer GLK und kann kaum was machen. Zuhause hab ich dann diesen Thread gefunden: Danke euch allen!
Ich hab in /etc/freeradius/3.2/mods-enabled/ die beiden Dateien
mschap und
ntlm_auth
das zusätzliche Backslash eingefügt, freeradius neugestartet und voila: tut wieder.
Die sind schon lustig bei freeradius: dass sie innerhalb einer Version die Interpretation der configfiles ändern (wer Sarkasmus findet, der war aufmerksam…).
Ich habe von freeradius 3.2.3 auf 3.2.6 upgedatet und schon tuts nicht mehr …
Jetzt werde ich bei einer anderen Einrichtung testen, ob 3.2.3 schon mit dem zweiten slash zurecht kommt: dann fahre ich da nicht in einigen Wochen ins selbe Problem.
Nur nochmal, um hier auf Nummer sicher zu gehen:
Du hast den v7-Server aber nicht mit einem do-release-upgrade von 22.04 auf 24.04 angehoben, richtig?
Ich frage deshalb, weil ich nicht sicher bin, woher Du unter v7.2 „bereits“ freeRADIUS 3.2.x
hast. Hier läuft v7.2 mit freeRADIUS 3.0.26~dfsg~git20220223.1.
Hast Du bei Dir die sources.list angepasst, damit Du explizit freeRADIUS 3.2 verwenden kannst? Und falls ja: Warum?
In diesem Zshg.: Ich habe neulich eine andere VM von 22.04 auf 24.04 gebracht. Dabei ist mir aufgefallen, dass die apt-sources nun ganz anders aufgebaut sind.
Es ist übersichtlicher geworden aber sieht jetzt dafür auch anders aus – z.B. so:
/etc/apt/sources.list.d # cat ubuntu.sources
Types: deb
URIs: http://archive.ubuntu.com/ubuntu
Suites: noble noble-updates noble-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg
ich hab nur ein apt dist-upgrade gemacht (genau so, wie ich es im ersten Post geschrieben habe "…nicht von 7.1 auf 7.2 oder so, sondern ein normales dist-upgrade).
Ja, ich habe für freeradius eine eigene sources-Datei in /etc/apt/sources.list.d/ mit dem Inhalt:
deb [arch=amd64 signed-by=/etc/apt/keyrings/packages.networkradius.com.asc] http://packages.networkradius.com/freeradius-3.2/ubuntu/jammy jammy main
aus dem wurde (damals) freeradius 3.2.3 installiert und da lag nun 3.2.6, welches aber config Dateien anders interpretiert, wie Tobias und jetzt ich, feststellen mußten.
) hat nicht geholfen.
