FreeTDS errors after running perfectly fine for 30-60minutes.
Running Freeradius 3.2.3 (from freeradius rep) installed with: sudo apt install freeradius freeradius-utils freeradius-freetds After running for 30-60 minutes this happens on all servers (3) (Debian 12-latetst) Thu Dec 14 06:49:32 2023 : Error: rlm_sql_freetds: unable to send command (ct_send()) Thu Dec 14 06:49:32 2023 : ERROR: (571) ERROR: rlm_sql_freetds: Server msg from "mydbserver": severity(5701), number(0), origin(1), layer(1), procedure "none": Changed database context to 'mydb'. Thu Dec 14 06:49:32 2023 : ERROR: (571) ERROR: SQL query failed: server error Thu Dec 14 06:49:32 2023 : Auth: (571) Login incorrect (rlm_sql_freetds: Server msg from "mydbserver": severity(5701), number(0), origin(1), layer(1), procedure "none": Changed database context to 'mydblog'.): [327700051207842] (from client 192.168.3.161/32 port 0 cli 327700051207842) Thu Dec 14 06:49:32 2023 : Auth: (572) Login OK: [327700050547002] (from client 192.168.3.161/32 port 0 cli 327700050547002) Thu Dec 14 06:49:33 2023 : Auth: (573) Login OK: [327700050626183] (from client 192.168.3.161/32 port 0 cli 327700050626183) Thu Dec 14 06:49:33 2023 : Auth: (574) Login OK: [327700051319260] (from client 192.168.3.161/32 port 0 cli 327700051319260) Thu Dec 14 06:49:34 2023 : Auth: (575) Login OK: [327700051047968] (from client 192.168.3.161/32 port 0 cli 327700051047968) Thu Dec 14 06:49:35 2023 : Error: rlm_sql_freetds: unable to send command (ct_send()) etc etc And start repeating like this forever. Most successful, some not. Restarting freeradius solves it directly. At that exact same moment my old centos server CAN connect with no issues to that same db for years already. I'm clueless whats going on here. But im almost sure it must be something local. Changing start servers did not help. Issue stays. freetds.conf # A typical Microsoft Azure SQL [myserver] host = mydb.database.windows.net port = 1433 tds version = 7.3 database = mydb Note that 7.4 does not connect but 7.3 or lower connects. My Setup is a default as possible with 1 sql query that does accept for unit or not. freeradius-freetds seems to install: freetds-common/stable,now 1.3.17+ds-2 all [installed,automatic] Not sure what to do here to use latest from Freetds (1.4.1) Any suggestions? Thanks, Olaf
On Dec 14, 2023, at 4:56 AM, Olaf <siegson@gmail.com> wrote:
After running for 30-60 minutes this happens on all servers (3) (Debian 12-latetst)
Thu Dec 14 06:49:32 2023 : Error: rlm_sql_freetds: unable to send command (ct_send()) Thu Dec 14 06:49:32 2023 : ERROR: (571) ERROR: rlm_sql_freetds: Server msg from "mydbserver": severity(5701), number(0), origin(1), layer(1), procedure "none": Changed database context to 'mydb'. Thu Dec 14 06:49:32 2023 : ERROR: (571) ERROR: SQL query failed: server error
It sounds like a freetds error to me. Either the library, or the DB. All of the other DBs work fine with FreeRADIUS, so we know it's not that,
And start repeating like this forever. Most successful, some not. Restarting freeradius solves it directly.
Which also reloads the freetds library, and resets its internal contexts.
Not sure what to do here to use latest from Freetds (1.4.1) Any suggestions?
Maybe don't use freetds :( Alan DeKok.
It sounds like a freetds error to me. Either the library, or the DB.
Yes, i think so.
Maybe don't use freetds :(
Here is my problem again. Compile from source with unixodbc is a nightmare. And it seems there is documentation on networkradius.com how to....that is not accessible for me. No other options left ?!. Olaf
On 14/12/2023 18:42, Olaf wrote:
Maybe don't use freetds :(
Here is my problem again. Compile from source with unixodbc is a nightmare. And it seems there is documentation on networkradius.com how to....that is not accessible for me.
If you use the latest code on the 3.2 branch, "make deb" will now build the unixodbx FreeRADIUS package rather than iODBC. Make sure you have unixodbc-dev installed. unixodbc-dev and libiodbc2-dev are conflicting packages which is likely what caused your issues, however since iODBC appears to not be getting any attention in Debian packaging, it makes more sense to build the unixodbc version as that is being kept up to date. -- Nick Porter
participants (3)
-
Alan DeKok -
Nick Porter -
Olaf