Good morning, everyone! I'm having a challenge understanding why we're seeing the error: authenticate { (660) Fri Jul 26 09:20:17 2019: WARNING: mschap: No Cleartext-Password configured. Cannot create NT-Password (660) Fri Jul 26 09:20:17 2019: WARNING: mschap: No Cleartext-Password configured. Cannot create LM-Password (660) Fri Jul 26 09:20:17 2019: Debug: mschap: Creating challenge hash with username: 54-72-4F-69-14-B1 (660) Fri Jul 26 09:20:17 2019: Debug: mschap: Client is using MS-CHAPv2 (660) Fri Jul 26 09:20:17 2019: ERROR: mschap: FAILED: No NT/LM-Password. Cannot perform authentication (660) Fri Jul 26 09:20:17 2019: ERROR: mschap: MS-CHAP2-Response is incorrect (660) Fri Jul 26 09:20:17 2019: Debug: [mschap] = reject (660) Fri Jul 26 09:20:17 2019: Debug: } # authenticate = reject We've just started providing radius services (3.0.18 on CentOS 7) to a new client, and all 14 of their properties have exhibited this behavior, to the tune of nearly 300,000 so far this month, with only about 80,000 successful auths. In the authenticate debug above, it states that there is no Cleartext-Password, but I personally checked for this specific user, and the attribute is set in radcheck (I've checked a random sample of some others, as well, with the same result). Still, however, we see that error, and for the life of me, although I believe I know *what* the error is, I'm unable to determine why. We've done packet captures to ensure that the site's gateway (Nomadix) is sent the correct credential data (it is), but somehow, on arrival at the FR server, the password appears to be missing. If someone can point me in the right direction (I'm thinking the NAS is the root of this), I would be most appreciative, as I don't want to lose any more hair! I've included the gzip'd output from raddebug, as this is a production server. I've had to include it as an attachment, because in raw form, it exceeded the message size limit for the list (and I apologize to the list maintainers for that error). Many thanks! -- Jim
On Jul 26, 2019, at 12:38 PM, J Kephart <jkephart@safetynetaccess.com> wrote:
Good morning, everyone! I'm having a challenge understanding why we're seeing the error:
authenticate { (660) Fri Jul 26 09:20:17 2019: WARNING: mschap: No Cleartext-Password configured. Cannot create NT-Password (660) Fri Jul 26 09:20:17 2019: WARNING: mschap: No Cleartext-Password configured. Cannot create LM-Password
That's pretty clear.
(660) Fri Jul 26 09:20:17 2019: Debug: mschap: Creating challenge hash with username: 54-72-4F-69-14-B1 (660) Fri Jul 26 09:20:17 2019: Debug: mschap: Client is using MS-CHAPv2 (660) Fri Jul 26 09:20:17 2019: ERROR: mschap: FAILED: No NT/LM-Password. Cannot perform authentication (660) Fri Jul 26 09:20:17 2019: ERROR: mschap: MS-CHAP2-Response is incorrect (660) Fri Jul 26 09:20:17 2019: Debug: [mschap] = reject (660) Fri Jul 26 09:20:17 2019: Debug: } # authenticate = reject
We've just started providing radius services (3.0.18 on CentOS 7) to a new client, and all 14 of their properties have exhibited this behavior, to the tune of nearly 300,000 so far this month, with only about 80,000 successful auths.
In the authenticate debug above, it states that there is no Cleartext-Password, but I personally checked for this specific user, and the attribute is set in radcheck (I've checked a random sample of some others, as well, with the same result). Still, however, we see that error, and for the life of me, although I believe I know *what* the error is, I'm unable to determine why.
Read the debug output to see. For ONE user.
We've done packet captures to ensure that the site's gateway (Nomadix) is sent the correct credential data (it is), but somehow, on arrival at the FR server, the password appears to be missing.
If someone can point me in the right direction (I'm thinking the NAS is the root of this), I would be most appreciative, as I don't want to lose any more hair! I've included the gzip'd output from raddebug, as this is a production server. I've had to include it as an attachment, because in raw form, it exceeded the message size limit for the list (and I apologize to the list maintainers for that error).
There's no need to post a debug output with 600+ packets. We're just not going to read all of that. And the list doesn't allow large messages. Zipping the debug output doesn't help. Post the debug output for *one* user. Yes, you can edit a large debug output before posting to the list. Alan DeKok.
Got it. Simple and concise. On 7/26/19 2:51 PM, Alan DeKok wrote:
On Jul 26, 2019, at 12:38 PM, J Kephart <jkephart@safetynetaccess.com> wrote:
authenticate { (660) Fri Jul 26 09:20:17 2019: WARNING: mschap: No Cleartext-Password configured. Cannot create NT-Password (660) Fri Jul 26 09:20:17 2019: WARNING: mschap: No Cleartext-Password configured. Cannot create LM-Password That's pretty clear.
Yes, it is, but if I'm reading this correctly, it seems to be telling me that there's no such attribute in radcheck. Am I interpreting it correctly, because if so, I can confirm that the Cleartext-Attribute for the user does exist in radcheck.
Read the debug output to see. For ONE user.
Output for one user: (660) Fri Jul 26 09:20:17 2019: Debug: Received Access-Request Id 60 from 67.135.207.161:2414 to 162.220.133.70:1812 length 255 (660) Fri Jul 26 09:20:17 2019: Debug: User-Name = "54-72-4F-69-14-B1" (660) Fri Jul 26 09:20:17 2019: Debug: NAS-IP-Address = 67.135.207.161 (660) Fri Jul 26 09:20:17 2019: Debug: NAS-Port = 1000 (660) Fri Jul 26 09:20:17 2019: Debug: Service-Type = Login-User (660) Fri Jul 26 09:20:17 2019: Debug: Acct-Session-Id = "07001C1F" (660) Fri Jul 26 09:20:17 2019: Debug: Called-Station-Id = "00-50-E8-03-82-6C" (660) Fri Jul 26 09:20:17 2019: Debug: Calling-Station-Id = "54-72-4F-69-14-B1" (660) Fri Jul 26 09:20:17 2019: Debug: Nomadix-Logoff-URL = "http://2.2.2.3" (660) Fri Jul 26 09:20:17 2019: Debug: WISPr-Location-ID = "isocc=,cc=,ac=,network=" (660) Fri Jul 26 09:20:17 2019: Debug: NAS-Identifier = "1000019" (660) Fri Jul 26 09:20:17 2019: Debug: Framed-IP-Address = 172.20.2.32 (660) Fri Jul 26 09:20:17 2019: Debug: MS-CHAP-Challenge = 0x795b0000883100003c760000721e0000 (660) Fri Jul 26 09:20:17 2019: Debug: MS-CHAP2-Response = 0x3700cb4e00005c030000971b0000f33900000000000000000000f3a9415e3205ea7d4a79fdb31489fab0fce1181a95c6584b (660) Fri Jul 26 09:20:17 2019: Debug: # Executing section authorize from file /etc/raddb/sites-enabled/default (660) Fri Jul 26 09:20:17 2019: Debug: authorize { (660) Fri Jul 26 09:20:17 2019: Debug: policy filter_username { (660) Fri Jul 26 09:20:17 2019: Debug: if (&User-Name) { (660) Fri Jul 26 09:20:17 2019: Debug: if (&User-Name) -> TRUE (660) Fri Jul 26 09:20:17 2019: Debug: if (&User-Name) { (660) Fri Jul 26 09:20:17 2019: Debug: if (&User-Name =~ / /) { (660) Fri Jul 26 09:20:17 2019: Debug: if (&User-Name =~ / /) -> FALSE (660) Fri Jul 26 09:20:17 2019: Debug: if (&User-Name =~ /@[^@]*@/ ) { (660) Fri Jul 26 09:20:17 2019: Debug: if (&User-Name =~ /@[^@]*@/ ) -> FALSE (660) Fri Jul 26 09:20:17 2019: Debug: if (&User-Name =~ /\.\./ ) { (660) Fri Jul 26 09:20:17 2019: Debug: if (&User-Name =~ /\.\./ ) -> FALSE (660) Fri Jul 26 09:20:17 2019: Debug: if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) { (660) Fri Jul 26 09:20:17 2019: Debug: if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) -> FALSE (660) Fri Jul 26 09:20:17 2019: Debug: if (&User-Name =~ /\.$/) { (660) Fri Jul 26 09:20:17 2019: Debug: if (&User-Name =~ /\.$/) -> FALSE (660) Fri Jul 26 09:20:17 2019: Debug: if (&User-Name =~ /@\./) { (660) Fri Jul 26 09:20:17 2019: Debug: if (&User-Name =~ /@\./) -> FALSE (660) Fri Jul 26 09:20:17 2019: Debug: } # if (&User-Name) = notfound (660) Fri Jul 26 09:20:17 2019: Debug: } # policy filter_username = notfound (660) Fri Jul 26 09:20:17 2019: Debug: [preprocess] = ok (660) Fri Jul 26 09:20:17 2019: Debug: [chap] = noop (660) Fri Jul 26 09:20:17 2019: Debug: mschap: Found MS-CHAP attributes. Setting 'Auth-Type = mschap' (660) Fri Jul 26 09:20:17 2019: Debug: [mschap] = ok (660) Fri Jul 26 09:20:17 2019: Debug: [digest] = noop (660) Fri Jul 26 09:20:17 2019: Debug: suffix: Checking for suffix after "@" (660) Fri Jul 26 09:20:17 2019: Debug: suffix: No '@' in User-Name = "54-72-4F-69-14-B1", looking up realm NULL (660) Fri Jul 26 09:20:17 2019: Debug: suffix: No such realm "NULL" (660) Fri Jul 26 09:20:17 2019: Debug: [suffix] = noop (660) Fri Jul 26 09:20:17 2019: Debug: eap: No EAP-Message, not doing EAP (660) Fri Jul 26 09:20:17 2019: Debug: [eap] = noop (660) Fri Jul 26 09:20:17 2019: Debug: [files] = noop (660) Fri Jul 26 09:20:17 2019: Debug: sql: EXPAND %{User-Name} (660) Fri Jul 26 09:20:17 2019: Debug: sql: --> 54-72-4F-69-14-B1 (660) Fri Jul 26 09:20:17 2019: Debug: sql: SQL-User-Name set to '54-72-4F-69-14-B1' (660) Fri Jul 26 09:20:17 2019: Debug: sql: EXPAND SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id (660) Fri Jul 26 09:20:17 2019: Debug: sql: --> SELECT id, username, attribute, value, op FROM radcheck WHERE username = '54-72-4F-69-14-B1' ORDER BY id (660) Fri Jul 26 09:20:17 2019: Debug: sql: Executing select query: SELECT id, username, attribute, value, op FROM radcheck WHERE username = '54-72-4F-69-14-B1' ORDER BY id (660) Fri Jul 26 09:20:17 2019: Debug: sql: EXPAND SELECT groupname FROM radusergroup WHERE username = '%{SQL-User-Name}' ORDER BY priority (660) Fri Jul 26 09:20:17 2019: Debug: sql: --> SELECT groupname FROM radusergroup WHERE username = '54-72-4F-69-14-B1' ORDER BY priority (660) Fri Jul 26 09:20:17 2019: Debug: sql: Executing select query: SELECT groupname FROM radusergroup WHERE username = '54-72-4F-69-14-B1' ORDER BY priority (660) Fri Jul 26 09:20:17 2019: Debug: sql: User not found in any groups (660) Fri Jul 26 09:20:17 2019: Debug: [sql] = notfound (660) Fri Jul 26 09:20:17 2019: Debug: [expiration] = noop (660) Fri Jul 26 09:20:17 2019: Debug: [logintime] = noop (660) Fri Jul 26 09:20:17 2019: Debug: [pap] = noop (660) Fri Jul 26 09:20:17 2019: Debug: } # authorize = ok (660) Fri Jul 26 09:20:17 2019: Debug: Found Auth-Type = mschap (660) Fri Jul 26 09:20:17 2019: Debug: # Executing group from file /etc/raddb/sites-enabled/default (660) Fri Jul 26 09:20:17 2019: Debug: authenticate { (660) Fri Jul 26 09:20:17 2019: WARNING: mschap: No Cleartext-Password configured. Cannot create NT-Password (660) Fri Jul 26 09:20:17 2019: WARNING: mschap: No Cleartext-Password configured. Cannot create LM-Password (660) Fri Jul 26 09:20:17 2019: Debug: mschap: Creating challenge hash with username: 54-72-4F-69-14-B1 (660) Fri Jul 26 09:20:17 2019: Debug: mschap: Client is using MS-CHAPv2 (660) Fri Jul 26 09:20:17 2019: ERROR: mschap: FAILED: No NT/LM-Password. Cannot perform authentication (660) Fri Jul 26 09:20:17 2019: ERROR: mschap: MS-CHAP2-Response is incorrect (660) Fri Jul 26 09:20:17 2019: Debug: [mschap] = reject (660) Fri Jul 26 09:20:17 2019: Debug: } # authenticate = reject (660) Fri Jul 26 09:20:17 2019: Debug: Failed to authenticate the user (660) Fri Jul 26 09:20:17 2019: Debug: Using Post-Auth-Type Reject (660) Fri Jul 26 09:20:17 2019: Debug: # Executing group from file /etc/raddb/sites-enabled/default (660) Fri Jul 26 09:20:17 2019: Debug: Post-Auth-Type REJECT { (660) Fri Jul 26 09:20:17 2019: Debug: sql: EXPAND .query (660) Fri Jul 26 09:20:17 2019: Debug: sql: --> .query (660) Fri Jul 26 09:20:17 2019: Debug: sql: Using query template 'query' (660) Fri Jul 26 09:20:17 2019: Debug: sql: EXPAND %{User-Name} (660) Fri Jul 26 09:20:17 2019: Debug: sql: --> 54-72-4F-69-14-B1 (660) Fri Jul 26 09:20:17 2019: Debug: sql: SQL-User-Name set to '54-72-4F-69-14-B1' (660) Fri Jul 26 09:20:17 2019: Debug: sql: EXPAND INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( '%{SQL-User-Name}', '%{%{User-Password}:-%{Chap-Password}}', '%{reply:Packet-Type}', '%S') (660) Fri Jul 26 09:20:17 2019: Debug: sql: --> INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( '54-72-4F-69-14-B1', '', 'Access-Reject', '2019-07-26 09:20:17') (660) Fri Jul 26 09:20:17 2019: Debug: sql: Executing query: INSERT INTO radpostauth (username, pass, reply, authdate) VALUES ( '54-72-4F-69-14-B1', '', 'Access-Reject', '2019-07-26 09:20:17') (660) Fri Jul 26 09:20:17 2019: Debug: sql: SQL query returned: success (660) Fri Jul 26 09:20:17 2019: Debug: sql: 1 record(s) updated (660) Fri Jul 26 09:20:17 2019: Debug: [sql] = ok (660) Fri Jul 26 09:20:17 2019: Debug: attr_filter.access_reject: EXPAND %{User-Name} (660) Fri Jul 26 09:20:17 2019: Debug: attr_filter.access_reject: --> 54-72-4F-69-14-B1 (660) Fri Jul 26 09:20:17 2019: Debug: attr_filter.access_reject: Matched entry DEFAULT at line 11 (660) Fri Jul 26 09:20:17 2019: Debug: [attr_filter.access_reject] = updated (660) Fri Jul 26 09:20:17 2019: Debug: [eap] = noop (660) Fri Jul 26 09:20:17 2019: Debug: policy remove_reply_message_if_eap { (660) Fri Jul 26 09:20:17 2019: Debug: if (&reply:EAP-Message && &reply:Reply-Message) { (660) Fri Jul 26 09:20:17 2019: Debug: if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (660) Fri Jul 26 09:20:17 2019: Debug: else { (660) Fri Jul 26 09:20:17 2019: Debug: [noop] = noop (660) Fri Jul 26 09:20:17 2019: Debug: } # else = noop (660) Fri Jul 26 09:20:17 2019: Debug: } # policy remove_reply_message_if_eap = noop (660) Fri Jul 26 09:20:17 2019: Debug: } # Post-Auth-Type REJECT = updated (660) Fri Jul 26 09:20:17 2019: Debug: EXPAND %{NAS-IP-Address} %{NAS-Identifier} (660) Fri Jul 26 09:20:17 2019: Debug: --> 67.135.207.161 1000019 Let me see if I can be a little more clear. I'm pretty sure that, reading the debug output, the problem is that the user password is not present in the packet that FR receives from the NAS. We know that the instruction we send to the NAS to auth a device is correct, and does include both the username and the correct password. We know that the NAS receives it, but when it tries the auth with FR, it appears to "lose" the password, resulting in a reject response. In short, I believe the problem is in the data sent by the NAS. Thus, I simply want to confirm that my understanding of what I've read is correct, that FR is not the problem (and I really don't think it is), and that the NAS is the actual source of the problem. Having confirmed that, I will then hand it to the NAS vendor and tell them to find/fix what's broken in their devices. Ultimately, I just need a second set of eyes (from someone who is far better at this than I) so I can move in the proper direction. Thank you, Alan. -- Jim
On 26.07.19 21:34, J Kephart wrote:
Let me see if I can be a little more clear. I'm pretty sure that, reading the debug output, the problem is that the user password is not present in the packet that FR receives from the NAS.
MSCHAP is a Challenge-Response protcol, there is *no* password coming from the NAS. Everything the protocol does is contained in MS-CHAP-Challenge and MS-CHAP2-Response. Both the client and the server need the cleartext-password (or the NT/LM-Hash for MSCHAP) to be able to do the math for the handshake. The server complains it has no Cleartext-Password or NT-Hash or LM-Hash in the data it got from the database and thus rejects the client, because there is nothing more it can do. Solution: You need to have the users cleartext-password in your database. And just in case the question comes up: no, it can't be hashed or encrypted. If you want to do *any* challenge-response protocol like MSCHAP, the server needs the cleartext-password, there is no mathematical way around this. Grüße, Sven.
On Jul 26, 2019, at 3:34 PM, J Kephart <jkephart@safetynetaccess.com> wrote:
Yes, it is, but if I'm reading this correctly, it seems to be telling me that there's no such attribute in radcheck. Am I interpreting it correctly, because if so, I can confirm that the Cleartext-Attribute for the user does exist in radcheck.
Nope.
(660) Fri Jul 26 09:20:17 2019: Debug: sql: EXPAND %{User-Name} (660) Fri Jul 26 09:20:17 2019: Debug: sql: --> 54-72-4F-69-14-B1 (660) Fri Jul 26 09:20:17 2019: Debug: sql: SQL-User-Name set to '54-72-4F-69-14-B1' (660) Fri Jul 26 09:20:17 2019: Debug: sql: EXPAND SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id (660) Fri Jul 26 09:20:17 2019: Debug: sql: --> SELECT id, username, attribute, value, op FROM radcheck WHERE username = '54-72-4F-69-14-B1' ORDER BY id (660) Fri Jul 26 09:20:17 2019: Debug: sql: Executing select query: SELECT id, username, attribute, value, op FROM radcheck WHERE username = '54-72-4F-69-14-B1' ORDER BY id (660) Fri Jul 26 09:20:17 2019: Debug: sql: EXPAND SELECT groupname FROM radusergroup WHERE username = '%{SQL-User-Name}' ORDER BY priority (660) Fri Jul 26 09:20:17 2019: Debug: sql: --> SELECT groupname FROM radusergroup WHERE username = '54-72-4F-69-14-B1' ORDER BY priority (660) Fri Jul 26 09:20:17 2019: Debug: sql: Executing select query: SELECT groupname FROM radusergroup WHERE username = '54-72-4F-69-14-B1' ORDER BY priority (660) Fri Jul 26 09:20:17 2019: Debug: sql: User not found in any groups (660) Fri Jul 26 09:20:17 2019: Debug: [sql] = notfound
"notfound" means that the user wasn't found in SQL. Try running the SQL query manually. That's why it's printed out in debug mode: so you can cut & paste it into an SQL command-line tool.
Let me see if I can be a little more clear. I'm pretty sure that, reading the debug output, the problem is that the user password is not present in the packet that FR receives from the NAS.
No.
We know that the instruction we send to the NAS to auth a device is correct, and does include both the username and the correct password. We know that the NAS receives it, but when it tries the auth with FR, it appears to "lose" the password, resulting in a reject response.
No.
In short, I believe the problem is in the data sent by the NAS.
No. Sven's explanation is correct here.
Thus, I simply want to confirm that my understanding of what I've read is correct, that FR is not the problem (and I really don't think it is), and that the NAS is the actual source of the problem. Having confirmed that, I will then hand it to the NAS vendor and tell them to find/fix what's broken in their devices. Ultimately, I just need a second set of eyes (from someone who is far better at this than I) so I can move in the proper direction.
The debug log is clear: the user is not found in SQL. I suspect what's happening is that SQL contains the user name as "54:72:4F:69:14:B1", and not as "54-72-4F-69-14-B1'". Alan DeKok.
On 27.07.19 01:20, Alan DeKok wrote:
I suspect what's happening is that SQL contains the user name as "54:72:4F:69:14:B1", and not as "54-72-4F-69-14-B1'".
And to spare Jim countless hours of debugging: It is *not* a good idea to use unlang to change the User-Name attribute when using MSCHAP, because it will (again) cause the handshake to fail. The better way (in my experience) is to use an unlang policy to rewrite the User-Name into a new internal attribute and use that in your SQL queries. Since you seem to be dealing with MAC addresses as User-Name, you can use the existing rewrite_calling_station_id policy as inspiration. Grüße, Sven.
On 7/27/19 1:03 PM, Sven Hartge wrote:
On 27.07.19 01:20, Alan DeKok wrote:
I suspect what's happening is that SQL contains the user name as "54:72:4F:69:14:B1", and not as "54-72-4F-69-14-B1'".
Sven and Alan, Yes, we're using MACs in a lab scenario to test what the client is reporting. What's strange about this is that FR reports that no cleartest-password can be found, yet when we run the radcheck query from the debug output, we get the following: SELECT id, username, attribute, value, op FROM radcheck WHERE username = '54-72-4F-69-14-B1' ORDER BY id; +-------+-------------------+--------------------+-------------------+----+ | id | username | attribute | value | op | +-------+-------------------+--------------------+-------------------+----+ | 13758 | 54-72-4F-69-14-B1 | Cleartext-Password | 54-72-4F-69-14-B1 | := | +-------+-------------------+--------------------+-------------------+----+ As you can see, the password is there, as is the username, in hyphenated form. We do no manipulation of the username at all, simply accepting what we receive. So, if we can run the query and get the expected results, why is FR giving us the error? Or, what are we doing wrong on the DB side? In my company, our radius team is a team of one -- me -- and I am truly trying the learn and understand as I much as I can, so I can fix this, and be able to recognize and diagnose any future recurrences. I thank you both for your time. -- Jim
On Jul 29, 2019, at 11:23 AM, J Kephart <jkephart@safetynetaccess.com> wrote:
Yes, we're using MACs in a lab scenario to test what the client is reporting. What's strange about this is that FR reports that no cleartest-password can be found, yet when we run the radcheck query from the debug output, we get the following:
SELECT id, username, attribute, value, op FROM radcheck WHERE username = '54-72-4F-69-14-B1' ORDER BY id; +-------+-------------------+--------------------+-------------------+----+ | id | username | attribute | value | op | +-------+-------------------+--------------------+-------------------+----+ | 13758 | 54-72-4F-69-14-B1 | Cleartext-Password | 54-72-4F-69-14-B1 | := | +-------+-------------------+--------------------+-------------------+----+
As you can see, the password is there, as is the username, in hyphenated form. We do no manipulation of the username at all, simply accepting what we receive.
Then something else is going wrong.
So, if we can run the query and get the expected results, why is FR giving us the error? Or, what are we doing wrong on the DB side? In my company, our radius team is a team of one -- me -- and I am truly trying the learn and understand as I much as I can, so I can fix this, and be able to recognize and diagnose any future recurrences.
FreeRADIUS just does SQL queries using the admin user/password you supply. Are you sure that you're using the same admin user above? Alan DeKok.
FreeRADIUS just does SQL queries using the admin user/password you supply. Are you sure that you're using the same admin user above?
Alan DeKok.
Yes, sir, we are. That's the MAC that was sent in the failed access-request debug output. And that is what I am desperately trying to figure out -- what that "something else" could be. -- Jim
On Jul 29, 2019, at 2:12 PM, J Kephart <jkephart@safetynetaccess.com> wrote:
Yes, sir, we are. That's the MAC that was sent in the failed access-request debug output. And that is what I am desperately trying to figure out -- what that "something else" could be.
Did you try using different users? i.e. creating a "test' user in the DB, and sending test packets via radclient? Unfortunately we don't have access to your systems, so we can't give detailed advice. The default configuration works, the default SQL queries work, etc. Maybe try spinning up a test system from scratch, and trying that. It may be that your current system is broken, but a new system will work. As with most computer issues, just poking at one thing won't help. You have to do experiments to see what works and what doesn't. That will help you narrow down the scope of the problem. Alan DeKok.
On 7/29/19 2:32 PM, Alan DeKok wrote:
Did you try using different users? i.e. creating a "test' user in the DB, and sending test packets via radclient?
Actually, yes, and the results were largely the same. Oddly, though, *some* transactions do succeed, with nothing we can see that's really different -- except that FR can get data from the DB.
Unfortunately we don't have access to your systems, so we can't give detailed advice. The default configuration works, the default SQL queries work, etc.
I know we went through a similar exercise on a previous -- **really old**--version we were running. Will you please send me, off the list--the details of cost/hour to give you that level access? Perhaps that might help, and move this along a tad faster.
Maybe try spinning up a test system from scratch, and trying that. It may be that your current system is broken, but a new system will work.
We looked into that, but our IT guys have re-purposed our lab server due to another high-visibility issue, and I simply don't have the resources available to create a new instance right now.
As with most computer issues, just poking at one thing won't help. You have to do experiments to see what works and what doesn't. That will help you narrow down the scope of the problem.
Concur. I am having the client disable a setting in the NAS that, I believe, caused a similar problem on v2.2.8. I hope it gives me a path forward. -- Jim
Am 29.07.2019 um 20:12 schrieb J Kephart:
FreeRADIUS just does SQL queries using the admin user/password you supply. Are you sure that you're using the same admin user above?
Alan DeKok.
Yes, sir, we are. That's the MAC that was sent in the failed access-request debug output. And that is what I am desperately trying to figure out -- what that "something else" could be.
seems simple, but do you have set the correct value for radius_db in your config? I once had a problem with multiple sql modules sharing the same connection pool, but different radius_db settings. It worked sometimes, depending which module created the connection. Greetings, Daniel Finger
On 7/30/19 6:58 AM, Daniel Finger wrote:
seems simple, but do you have set the correct value for radius_db in your config?
I once had a problem with multiple sql modules sharing the same connection pool, but different radius_db settings. It worked sometimes, depending which module created the connection.
Yes, the correct value is set.
participants (4)
-
Alan DeKok -
Daniel Finger -
J Kephart -
Sven Hartge