Re: 2.2.0 - Shared Secret is incorrect
Dear Arran, Sorry, about the typo with debug I looked at the invalid packet counters. Only shows the requests with wrong shared secrets in rejects-Counter ... Same thing.... stats client auth x.x.x.x requests 5 responses 5 accepts 1 rejects 4 challenges 0 dup 0 invalid 0 malformed 0 bad_signature 0 dropped 0 unknown_types 0 But thanks for the tipp.... I´m aware of that log "formats" change, but I couldn´t get A.L.M.s explanation, because of the unknown-Error appearing and the shared secret-Info not "because of DoS prevention". If you have a lot of radius-servers running and a lot of switches, you are glad to do some syslog-collection and an automated-search for any string or character in a log line showing that x.x.x.x has a wrong secret or is not known to radius, so the problem can be fixed immediatly. The only two types of "NAS-Misconfiguratin" I´m interested in are: - The client is unknown o the RADIUS-Server (which is still logged). - The shared secret is wrong (which is not in the log anymore). So, I think I´ll change the code. Thanks for your time...
On 19 Jul 2013, at 16:32, Anja Ruckdaeschel <Anja.Ruckdaeschel@rz.uni-regensburg.de> wrote:
Dear Arran,
Sorry, about the typo with debug
I looked at the invalid packet counters. Only shows the requests with wrong shared secrets in rejects-Counter ... Same thing....
The RADIUS server cannot determine whether the shared secret is correct for Access-Requests without the Message-Authenticator attribute. The User-Password field is decrypted incorrectly and so comparison with the REFERENCE password fails which is why they're seen as a reject. This isn't an issue with the server, it's an issue with the protocol. Accounting-Requests are validated using the Authenticator field and so you get the error message. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
participants (2)
-
Anja Ruckdaeschel -
Arran Cudbard-Bell