From rullfig at uic.edu Thu Dec 5 18:33:57 2019 From: rullfig at uic.edu (Ullfig, Roberto Alfredo) Date: Thu, 5 Dec 2019 18:33:57 +0000 Subject: [RADIATOR] Radiator and AuthLog SQL on Centos 7 Message-ID: We're converting our servers from Centos 6 to Centos 7. We do some logging with: DBSource dbi:mysql... but the connection keeps failing: MySQL server has gone away We have the mysql odbc connector installed: mysql-connector-odbc-5.2.5-8.el7.x86_64 and up to date with mysql/mariadb: mariadb-5.5.64-1.el7.x86_64 mariadb-libs-5.5.64-1.el7.x86_64 Any ideas? --- Roberto Ullfig - rullfig at uic.edu Systems Administrator Enterprise Architecture and Development | ACCC University of Illinois - Chicago -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvn at open.com.au Mon Dec 9 16:40:40 2019 From: hvn at open.com.au (Heikki Vatiainen) Date: Mon, 9 Dec 2019 18:40:40 +0200 Subject: [RADIATOR] Radiator Version 4.24 released - new features, enhancements and bug fixes Message-ID: <0f8e768c-ffe8-b525-6242-aa43fd43ebfd@open.com.au> We are pleased to announce the release of Radiator version 4.24 This version contains new features, enhancements and bug fixes. See below for the details. As usual, the new version is available to current licensees and evaluators from: https://www.open.com.au/radiator/downloads.html Licensees with expired access contracts can renew at: https://radiatorsoftware.com/renewal-order/ An extract from the history file https://www.open.com.au/radiator/history.html is below: ----------------------------- Revision 4.24 (2019-12-09) new features, enhancements and bug fixes Selected compatibility notes, enhancements and fixes Added configuration parameters TLS_SecurityLevel and EAPTLS_SecurityLevel and calls to set accepted TLS version ranges. This allows for Radiator module level control of desired TLS settings without modifications of system defaults. ClientListSQL configuration can now be simplified with ClientColumnDef parameters. AuthBy SQLHOTP and SQLTOTP SQL query parameter support was added. Dynamically updated Diameter RealmTable for request routing and forwarding is now available for advanced Diameter applications. Added a new configuration flag parameter IgnoreIfMissing. Added a new check item ExistsInRequest for matching requests by attribute presence. Useful for Handlers. Added new AuthBy REST, which is built on a new class called HTTPClient. Packages are now available for Red Hat Enterprise Linux 8 and CentOS 8 and Debian 10 (Buster). Added configuration guide and samples for SecureW2 integration. Known caveats and other notes TLSv1.3 remains disabled by default for TLS based EAP methods and Stream based classes, such as RadSec. EAP-FAST functionality is reported to vary between TLS versions, TLS library security level settings and client implementations. Detailed changes AuthBy SIP2 sometimes parsed ACS server responses incorrectly causing incorrect authentication rejects. Stream modules that use TLS, such as RadSec, now log the negotiated TLS version and cipher similar to what TLS based EAP methods already do. Short inner EAP messages received by EAP-TTLS and PEAP are now caught earlier instead of generic EAP module. Added new configuration parameters TLS_SecurityLevel and EAPTLS_SecurityLevel to control TLS library's security level settings. See OpenSSL manual for SSL_CTX_set_security_level() for more about security levels. When TLS_Protocols or EAPTLS_Protocols is configured to set the desired TLS versions, TLS library's Net::SSLeay::CTX_set_min_proto_version and its 'max' counterpart are automatically called. The security level and TLS version settings may be needed on systems with strict defaults. For example, Debian 10 sets the default minimum TLS version to 1.2 and security level to 2. This may be too restrictive with older EAP clients or Diameter and RadSec peers. Support for min/max_proto functions was added in Net::SSLeay 1.83. Updated Lancom and Aerohive attributes in the default dictionary. Aerohive products appear to use attribute 1 for different purposes. For this reason the newly added Aerohive-User-Vlan is an alias for the existing AH-HM-Admin-Group-Id. Both names are usable as reply attributes but incoming attributes are remain named as AH-HM-Admin-Group-Id. Thanks to Stefan Winter for the updated information. Added two new modules that allow temporarily denying logins for users that were rejected because of repetitive bad passwords. These are intial versions AuthBy FAILUREPOLICY and AuthBy SQLFAILUREPOLICY with more enhancements done in subsequent Radiator releases. See failurepolicy.cfg in goodies for a sample configuration. Added radiator-instances.service to goodies. This is a systemd unit configuration file for a virtual service for managing all Radiator instances. It works in conjunction with with radiator at .service unit file. Added 25 VSAs in the default dictionary for VENDOR 12356 Fortinet. Updated sample certificates to expire on November 10 2021. ClientListSQL now supports new configuration parameter ClientColumnDef. This allows for more simple and flexible configuration. Updated ClientList modules based on perlcritic reports. Updated AuthBy SQLHOTP and SQLTOTP to support SQL query parameters. Enhanced the configuration for the both to refuse token lengths shorter than 4 and clarified documentation of Require2Factor and SQL token active field. Other minor updates to SQL schema, sample configurations and code based on perlcritic. ClientListSQL and ClientListLDAP can now fetch TACACSPLUSKey parameter. This allows Clients to have separate values for RADIUS shared secret and TACACS+ key. Check items with regular expression values now use s modifier by default. This allows dot to also match newline. An instance of RealmTable is now dynamically updated for Diameter peerings used by Radiator 3GPPP AAA Server and other advanced Diameter applications. This RealmTable is available for Diameter request routing and forwarding for those Diameter peers that are configured with DiaPeerDef clauses supported by Radiator Carrier Pack. Added RealmTable.pm for genric support for realm routing tables. This can be used with Radius and Diameter to dynamically or statically build routing tables that support quick lookups from a large number of destinations. Aggregates and regexp based lookups are supported. See realmtable.pl in goodies for a sample application. Minor fixes: enhance Radius::SCTP support detection and address messages triggered by recently enabled warnings pragma. Radiator's Radius::UtilXS package now provides interface to DES functions in OpenSSL and LibreSSL. These alternative functions are automatically used with Radius::UtilXS is available. Radius::UtilXS package is available from Radiator downloads. Digest::MD4 is no longer strictly required with MSCHAP related authentication methods. An alternative MD4 digest implementation is now provided by Radiator's Radius::UtilXS package. This package is available from Radiator downloads. Added new configuration parameter LeavePassword. LeavePassword is similar to ConsumePassword but leaves beginning of password unchanged and extracts a portion of password from the end. Added integration guide and configuration files for configuring Radiator Software's RADIUS Server for EAP-TLS using SecureW2 PKI. Added Win32-Lsa module for 64bit Strawberry Perl 5.30.1. Updated Radiator MSI package to use Strawberry Perl 5.30.1.1. Added new configuration flag parameter IgnoreIfMissing. This parameter is somewhat similar to the previously existing parameter AcceptIfMissing. If the user is not present in the user database, this parameter causes the enclosing AuthBy to return ignore instead of reject. When multiple AuthBys are configured, this allows lookups to continue until the user is found while accept or reject is returned immediately. Suggested by Christian Meutes and Alexander Hartmaier. When PacketTrace is set for a proxied request, the corresponding reply from a proxy now inherits the trace setting and is logged with trace level 5. With RadSec, the proxied request is now also logged with trace level 5. Updated vendor Ruckus attributes in dictionary. Contributed by Michael Newton. Added new check item ExistsInRequest. This is mostly used in Handlers to help matching requests based on attribute presence irrespective of their content. For example, selects all EAP requests. Simple alternation is also supported: matches requests that have one or both of the attributes. RADIUS attribute names are now cheked for uncommon characters. Unexpected names are accepted and a warning is logged when dictionary is loaded. Locked Radiator distribution now honours Windows Service Control Manager state changes when expiry date or other limits have been reached. Previously Locked Radiator service became unstoppable when limits were reached. Added new class called HTTPClient which implements a flexible and asynchronous HTTP and HTTPS client. Added new HTTPClient based AuthBy REST for sending authentication and accounting request over a REST interface. Added support for using different back ends for random generation. The currently preferred source is Net::SSLeay with the default being Perl core rand. AuthDN in AuthBy LDAP2 now supports %0 special. This is replaced with DN escaped value of currently authenticated username. Added special formatters %{LDAPDN:...} and %{LDAPFilter:...} for escaping values with LDAP DN and filter rules. Fixed ServerChecksPassword error logging to be correct about failure reason when no result was received from server because of, for example, unexpected disconnection. Similar changes, and return value unification, was done to function checkPassword for custom code uses. Trailing NUL octets are no longer stripped from attributes received from LDAP. Addressed results reported by Perl::Critic. Multiple LDAP enhancements were added. LDAP modules now support new configuration parameters SSLCAClientKeyPassword and SSLExpectedServerName. SSLCAClientKeyPassword sets the passphrase to decrypt client private key when mutual certificate based LDAP authentication is required. SSLExpectedServerName sets the name the server certificate must match during verification. Misconfigured values for SSLCAFile and other related files are now logged and handled and no longer cause Radiator to exit without logging. Unknown values for SSLVerify are now logged and map to the default value require. SNMPAgent and Monitor with FarmSize configuration no longer require a FarmChildHook to re-open their listen sockets. Their listen sockets are now created after forking the instances. FarmChildHook sample in hooks.txt goodies file was updated to point to an example in farmchildhook.txt goodies file. Updated Ldap.pm and SNMPAgent to better log and refuse incorrect Port configuration values. Minor fix to SNMPAgent to also return SNMPv2-MIB system group values when queried with snmpwalk. Too large port numbers in configuration file for TCP, UDP and SCTP are now more clearly logged and refused. Fixed a memory leak caused by a StatsLog clause and ClientListSQL or ClientListLDAP being enabled in the same configuration. Leak affects Radiator versions 4.17 up to 4.23. Minor updates to IP address packing and resolution functions in Util.pm. Similar updates to old Socket6 module based functions. This makes IPv6 support with Socket6 more similar to what Perl core provides. Minor updates to BigInt functions and fixes to recent quota calculation related utility functions. Addressed a number of perlcritic reports. Unified Radiator internal JSON support. Modules, hooks and other code should now use Radius::JSON which chooses a JSON backend during startup and provides an interface for querying JSON status. The JSON backend and its version, or lack of backend, is logged when Radiator starts. Updated AuthBy DUO to use Radius::JSON instead JSON.pm. Messages logged to global LogFile and by LogFILE, LogSYSLOG and Monitor clauses now support adding farm instance to log messages. This is enabled by new LogFarmInstance configuration flag parameter. Addressed results reported by Perl::Critic. Updated diapwtst and ServerDIAMETER to include Acct-Application-Id in Accounting-Request (ACR) and Accounting-Answer (ACA) commands. Changed diapwtst to use Diameter base accounting in Command Code header field. AuthBy LSA now checks that Win32::NetAdmin is available when the configuration is loaded. This prevents radiusd from starting if the module is not installed. Previously the check happened when group membership check was first done causing radiusd to exit. The local address of AuthBy LDAP2 and other LDAP client connections, configured with BindAddress parameter, now supports formatting characters. Improved logging of LocalAddress for Stream based classes when LocalAddress uses formatting characters. Added VENDOR 14823 Aruba attributes Aruba-Captive-Portal-URL and Aruba-MPSK-Passphrase to dictionary. When global DupCache parameter was set to a non-default value, only duplicates for replied messages were correctly detected. Fixed a related memory leak and addressed Perl::Critic reports. -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory, EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc. From hvn at open.com.au Tue Dec 10 12:33:40 2019 From: hvn at open.com.au (Heikki Vatiainen) Date: Tue, 10 Dec 2019 14:33:40 +0200 Subject: [RADIATOR] Radiator and AuthLog SQL on Centos 7 In-Reply-To: References: Message-ID: On 05/12/2019 20.33, Ullfig, Roberto Alfredo wrote: > We're converting our servers from Centos 6 to Centos 7. We do some > logging with: > > ? ? ? ? > ? ? ? ? ? ? ? ? DBSource ? ? ? ?dbi:mysql... > > but the connection keeps failing: > > MySQL server has gone away MySQL and Radiator's DB connections should work fine with CentOS 7 too. The message you indicates the DB server, or possibly a firewall between Radiator and the server, has closed or forced the connection to close. In this case Radiator should retry opening the connection and running the query again. If it fails even after retries, it will log something like this: Tue Dec 10 14:05:25 2019: ERR: Could not connect to any SQL database. Request is ignored. Backing off for 600 seconds I'm not saying what you see is normal, but it might be worth checking if it successful after it detects the problem. I think I've seen the above message in cases where the SQL connection is seldom uses and the DB server side is keen to remove idle connections. Sometimes a firewall between Radiator and DB has done something similar. > We have the mysql odbc connector installed: > > mysql-connector-odbc-5.2.5-8.el7.x86_64 I think this is not used because you have not configured dbi:odbc:... Your config snippet indicates it uses DBD::mysql which links directly to MySQL client libraries and uses SQL native, not ODBC, interface. dbi:mysql:... is commonly used, and I think it should be stable and work well > and up to date with mysql/mariadb: > > mariadb-5.5.64-1.el7.x86_64 > mariadb-libs-5.5.64-1.el7.x86_64 > > Any ideas? I would check the server side to see if it logs about why it closes connections. Radiator tries to keep a connection open to DB once it's established. Therefore there might be a mismatch in what Radiator does and what the server expects from the connections. Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory, EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc. From rullfig at uic.edu Tue Dec 10 13:36:53 2019 From: rullfig at uic.edu (Ullfig, Roberto Alfredo) Date: Tue, 10 Dec 2019 13:36:53 +0000 Subject: [RADIATOR] Radiator and AuthLog SQL on Centos 7 In-Reply-To: References: , Message-ID: Ah yes, I also suspect an issue with a seldom used connection being closed by the mysql server. The radiator server is to be put into production in January so I'm expecting the issue to go away once it gets a full load of authentication requests. Thanks! --- Roberto Ullfig - rullfig at uic.edu Systems Administrator Enterprise Architecture and Development | ACCC University of Illinois - Chicago ________________________________ From: radiator on behalf of Heikki Vatiainen Sent: Tuesday, December 10, 2019 6:33 AM To: radiator at lists.open.com.au Subject: Re: [RADIATOR] Radiator and AuthLog SQL on Centos 7 On 05/12/2019 20.33, Ullfig, Roberto Alfredo wrote: > We're converting our servers from Centos 6 to Centos 7. We do some > logging with: > > > DBSource dbi:mysql... > > but the connection keeps failing: > > MySQL server has gone away MySQL and Radiator's DB connections should work fine with CentOS 7 too. The message you indicates the DB server, or possibly a firewall between Radiator and the server, has closed or forced the connection to close. In this case Radiator should retry opening the connection and running the query again. If it fails even after retries, it will log something like this: Tue Dec 10 14:05:25 2019: ERR: Could not connect to any SQL database. Request is ignored. Backing off for 600 seconds I'm not saying what you see is normal, but it might be worth checking if it successful after it detects the problem. I think I've seen the above message in cases where the SQL connection is seldom uses and the DB server side is keen to remove idle connections. Sometimes a firewall between Radiator and DB has done something similar. > We have the mysql odbc connector installed: > > mysql-connector-odbc-5.2.5-8.el7.x86_64 I think this is not used because you have not configured dbi:odbc:... Your config snippet indicates it uses DBD::mysql which links directly to MySQL client libraries and uses SQL native, not ODBC, interface. dbi:mysql:... is commonly used, and I think it should be stable and work well > and up to date with mysql/mariadb: > > mariadb-5.5.64-1.el7.x86_64 > mariadb-libs-5.5.64-1.el7.x86_64 > > Any ideas? I would check the server side to see if it logs about why it closes connections. Radiator tries to keep a connection open to DB once it's established. Therefore there might be a mismatch in what Radiator does and what the server expects from the connections. Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory, EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc. _______________________________________________ radiator mailing list radiator at lists.open.com.au https://lists.open.com.au/mailman/listinfo/radiator -------------- next part -------------- An HTML attachment was scrubbed... URL: From csinankoca at gmail.com Tue Dec 10 13:52:40 2019 From: csinankoca at gmail.com (cihangir sinan koca) Date: Tue, 10 Dec 2019 16:52:40 +0300 Subject: [RADIATOR] What TPS are you getitng on your radiator Message-ID: Hello, We have 2 radiator for redundancy, they are connecting to same oracle DB cluster. Its a new setup. What we are facing is, servers are unable to process more packet than 50-60 TPS. After i while its not writing the problem in logs, its not answering to any packet. Is it expected ? Or are we doing something wrong ? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpenezic at srce.hr Wed Dec 11 07:37:14 2019 From: dpenezic at srce.hr (Dubravko Penezic) Date: Wed, 11 Dec 2019 08:37:14 +0100 Subject: [RADIATOR] Radiator and AuthLog SQL on Centos 7 In-Reply-To: References:

Message-ID: Hi Roberto, I run few very busy RADIUS servers, and all use MySQL/MariaDB with RADIATOR DB connector on Centos 7 without any issue. Regards, Dubravko On 12/10/19 2:36 PM, Ullfig, Roberto Alfredo wrote: > Ah yes, I also suspect an issue with a seldom used connection being > closed by the mysql server. The radiator server is to be put into > production in January so I'm expecting the issue to go away once it gets > a full load of authentication requests. Thanks! > > --- > Roberto Ullfig - rullfig at uic.edu > Systems Administrator > Enterprise Architecture and Development | ACCC > University of Illinois - Chicago > ------------------------------------------------------------------------ > *From:* radiator on behalf of > Heikki Vatiainen > *Sent:* Tuesday, December 10, 2019 6:33 AM > *To:* radiator at lists.open.com.au > *Subject:* Re: [RADIATOR] Radiator and AuthLog SQL on Centos 7 > ? > On 05/12/2019 20.33, Ullfig, Roberto Alfredo wrote: >> We're converting our servers from Centos 6 to Centos 7. We do some >> logging with: >> >>? ? ? ? ? >>? ? ? ? ? ? ? ? ? DBSource ? ? ? ?dbi:mysql... >> >> but the connection keeps failing: >> >> MySQL server has gone away > > MySQL and Radiator's DB connections should work fine with CentOS 7 too. > The message you indicates the DB server, or possibly a firewall between > Radiator and the server, has closed or forced the connection to close. > In this case Radiator should retry opening the connection and running > the query again. > > If it fails even after retries, it will log something like this: > > Tue Dec 10 14:05:25 2019: ERR: Could not connect to any SQL database. > Request is ignored. Backing off for 600 seconds > > I'm not saying what you see is normal, but it might be worth checking if > it successful after it detects the problem. > > I think I've seen the above message in cases where the SQL connection is > seldom uses and the DB server side is keen to remove idle connections. > Sometimes a firewall between Radiator and DB has done something similar. > >> We have the mysql odbc connector installed: >> >> mysql-connector-odbc-5.2.5-8.el7.x86_64 > > I think this is not used because you have not configured dbi:odbc:... > Your config snippet indicates it uses DBD::mysql which links directly to > MySQL client libraries and uses SQL native, not ODBC, interface. > > dbi:mysql:... is commonly used, and I think it should be stable and work > well > >> and up to date with mysql/mariadb: >> >> mariadb-5.5.64-1.el7.x86_64 >> mariadb-libs-5.5.64-1.el7.x86_64 >> >> Any ideas? > > I would check the server side to see if it logs about why it closes > connections. Radiator tries to keep a connection open to DB once it's > established. Therefore there might be a mismatch in what Radiator does > and what the server expects from the connections. > > Thanks, > Heikki > > -- > Heikki Vatiainen > > Radiator: the most portable, flexible and configurable RADIUS server > anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory, > EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP, > DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc. > _______________________________________________ > radiator mailing list > radiator at lists.open.com.au > https://lists.open.com.au/mailman/listinfo/radiator > > _______________________________________________ > radiator mailing list > radiator at lists.open.com.au > https://lists.open.com.au/mailman/listinfo/radiator > -- Dubravko Penezic Information Systems and Applications Department SRCE - University of Zagreb University Computing Centre, www.srce.unizg.hr Dubravko.Penezic at srce.hr, tel: +385 1 616 5555, fax: +385 1 616 5559 From sintezwh1te at gmail.com Fri Dec 13 07:40:27 2019 From: sintezwh1te at gmail.com (SinTeZ Wh1te) Date: Fri, 13 Dec 2019 10:40:27 +0300 Subject: [RADIATOR] Proxy does not catch the Request Message-ID: Hello! We have a problem with some RADIUS packets. Radiator don't catch these packets. But other packets with same host, same values - Radiator sees and forwarding to another host. It is not a routing/networking issue since i see on Radiator server (using tcpdump) that the requests arrives correctly on 1821 port. But nothing gets logged (using Trace 4). There are a lot of ignored packets, and i can't understand what wrong with our configuration. radius-accounting.cfg ---------------- Identifier Client-DEFAULT Secret ----- DupInterval 0 Identifier Proxy1 Host 192.168.144.3 Secret ----- AuthPort AcctPort 1821 ReplyHook file:"/etc/radiator/proxy.pl" UseExtendedIds IgnoreReplySignature Identifier Proxy2 Host 192.168.144.18 Secret ----- AuthPort AcctPort 1821 ReplyHook file:"/etc/radiator/proxy2.pl" AddToReply Class=Proxy2 UseExtendedIds IgnoreReplySignature Identifier ForwardToProxy2 HandlerId Proxy2 AuthBy Proxy2 Identifier Proxy1 RejectHasReason AuthBy Proxy1 Identifier Proxy2 RejectHasReason AuthBy Proxy2 ---------------- Accounting-Request which not logged and forwarded from tcpdump ---------------- Frame 446: 497 bytes on wire (3976 bits), 497 bytes captured (3976 bits) on interface 0 Interface id: 0 (eth0.144) Interface name: eth0.144 Encapsulation type: Ethernet (1) Arrival Time: Dec 12, 2019 23:20:28.338266344 RTZ 2 [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1576182028.338266344 seconds [Time delta from previous captured frame: 0.000001241 seconds] [Time delta from previous displayed frame: 0.000000000 seconds] [Time since reference or first frame: 4.433944841 seconds] Frame Number: 446 Frame Length: 497 bytes (3976 bits) Capture Length: 497 bytes (3976 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ip:udp:radius] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: LucentTe_d6:fc:c0 (00:05:86:d6:fc:c0), Dst: Vmware_9d:fd:74 (00:50:56:9d:fd:74) Destination: Vmware_9d:fd:74 (00:50:56:9d:fd:74) Address: Vmware_9d:fd:74 (00:50:56:9d:fd:74) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Source: LucentTe_d6:fc:c0 (00:05:86:d6:fc:c0) Address: LucentTe_d6:fc:c0 (00:05:86:d6:fc:c0) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IPv4 (0x0800) Internet Protocol Version 4, Src: 192.168.144.22, Dst: 192.168.144.8 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes (5) Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) 0000 00.. = Differentiated Services Codepoint: Default (0) .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0) Total Length: 483 Identification: 0x4e2e (20014) Flags: 0x0000 0... .... .... .... = Reserved bit: Not set .0.. .... .... .... = Don't fragment: Not set ..0. .... .... .... = More fragments: Not set ...0 0000 0000 0000 = Fragment offset: 0 Time to live: 64 Protocol: UDP (17) Header checksum: 0x896c [validation disabled] [Header checksum status: Unverified] Source: 192.168.144.22 Destination: 192.168.144.8 User Datagram Protocol, Src Port: 56812, Dst Port: 1821 Source Port: 56812 Destination Port: 1821 Length: 463 Checksum: 0x2e0b [unverified] [Checksum Status: Unverified] [Stream index: 16] [Timestamps] [Time since first frame: 0.009830951 seconds] [Time since previous frame: 0.000601348 seconds] RADIUS Protocol Code: Accounting-Request (4) Packet identifier: 0xcc (204) Length: 455 Authenticator: 37c7c07c413bcb782f2c1574e375ed0f Attribute Value Pairs AVP: t=User-Name(1) l=11 val=101179610 AVP: t=Acct-Status-Type(40) l=6 val=Interim-Update(3) AVP: t=Acct-Session-Id(44) l=11 val=352027268 AVP: t=Event-Timestamp(55) l=6 val=Jul 12, 2017 23:19:30.000000000 RTZ 2 AVP: t=Acct-Input-Octets(42) l=6 val=1127113955 AVP: t=Acct-Output-Octets(43) l=6 val=728225336 AVP: t=Acct-Session-Time(46) l=6 val=451796 AVP: t=Acct-Input-Packets(47) l=6 val=8962801 AVP: t=Acct-Output-Packets(48) l=6 val=35607540 AVP: t=Acct-Delay-Time(41) l=6 val=0 AVP: t=Service-Type(6) l=6 val=Framed(2) AVP: t=Framed-Protocol(7) l=6 val=PPP(1) AVP: t=Vendor-Specific(26) l=29 vnd=Juniper Networks/Unisphere(4874) AVP: t=Acct-Authentic(45) l=6 val=RADIUS(1) AVP: t=Vendor-Specific(26) l=22 vnd=Juniper Networks/Unisphere(4874) AVP: t=Framed-IP-Address(8) l=6 val=172.26.93.174 AVP: t=Framed-IP-Netmask(9) l=6 val=255.255.255.255 AVP: t=Vendor-Specific(26) l=12 vnd=Juniper Networks/Unisphere(4874) AVP: t=Acct-Input-Gigawords(52) l=6 val=0 AVP: t=NAS-Identifier(32) l=9 val=RUrban3 AVP: t=NAS-Port(5) l=6 val=3028 AVP: t=NAS-Port-Id(87) l=32 val=ae0.demux0.3222168877:812-3028 AVP: t=NAS-Port-Type(61) l=6 val=Ethernet(15) AVP: t=Vendor-Specific(26) l=12 vnd=Juniper Networks/Unisphere(4874) AVP: t=Acct-Output-Gigawords(53) l=6 val=11 AVP: t=Vendor-Specific(26) l=12 vnd=Juniper Networks/Unisphere(4874) AVP: t=Vendor-Specific(26) l=12 vnd=Juniper Networks/Unisphere(4874) AVP: t=Vendor-Specific(26) l=12 vnd=Juniper Networks/Unisphere(4874) AVP: t=Vendor-Specific(26) l=12 vnd=Juniper Networks/Unisphere(4874) AVP: t=Vendor-Specific(26) l=12 vnd=Juniper Networks/Unisphere(4874) AVP: t=Vendor-Specific(26) l=12 vnd=Juniper Networks/Unisphere(4874) AVP: t=Vendor-Specific(26) l=23 vnd=Juniper Networks/Unisphere(4874) AVP: t=Vendor-Specific(26) l=31 vnd=Juniper Networks/Unisphere(4874) AVP: t=Vendor-Specific(26) l=63 vnd=The Broadband Forum(3561) AVP: t=NAS-IP-Address(4) l=6 val=192.168.144.22 ---------------- after 5 second another incoming packet was catched and logged (and has mark [The response to this request is in frame 2187]) ---------------- Frame 2076: 497 bytes on wire (3976 bits), 497 bytes captured (3976 bits) on interface 0 Interface id: 0 (eth0.144) Interface name: eth0.144 Encapsulation type: Ethernet (1) Arrival Time: Dec 12, 2019 23:20:33.338291848 RTZ 2 [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1576182033.338291848 seconds [Time delta from previous captured frame: 0.000005672 seconds] [Time delta from previous displayed frame: 5.000025504 seconds] [Time since reference or first frame: 9.433970345 seconds] Frame Number: 2076 Frame Length: 497 bytes (3976 bits) Capture Length: 497 bytes (3976 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ip:udp:radius] [Coloring Rule Name: UDP] [Coloring Rule String: udp] Ethernet II, Src: LucentTe_d6:fc:c0 (00:05:86:d6:fc:c0), Dst: Vmware_9d:fd:74 (00:50:56:9d:fd:74) Destination: Vmware_9d:fd:74 (00:50:56:9d:fd:74) Address: Vmware_9d:fd:74 (00:50:56:9d:fd:74) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Source: LucentTe_d6:fc:c0 (00:05:86:d6:fc:c0) Address: LucentTe_d6:fc:c0 (00:05:86:d6:fc:c0) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IPv4 (0x0800) Internet Protocol Version 4, Src: 192.168.144.22, Dst: 192.168.144.8 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes (5) Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) 0000 00.. = Differentiated Services Codepoint: Default (0) .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0) Total Length: 483 Identification: 0x6b14 (27412) Flags: 0x0000 0... .... .... .... = Reserved bit: Not set .0.. .... .... .... = Don't fragment: Not set ..0. .... .... .... = More fragments: Not set ...0 0000 0000 0000 = Fragment offset: 0 Time to live: 64 Protocol: UDP (17) Header checksum: 0x6c86 [validation disabled] [Header checksum status: Unverified] Source: 192.168.144.22 Destination: 192.168.144.8 User Datagram Protocol, Src Port: 49785, Dst Port: 1821 Source Port: 49785 Destination Port: 1821 Length: 463 Checksum: 0x4a48 [unverified] [Checksum Status: Unverified] [Stream index: 17] [Timestamps] [Time since first frame: 5.009851203 seconds] [Time since previous frame: 0.000005672 seconds] RADIUS Protocol Code: Accounting-Request (4) Packet identifier: 0x7f (127) Length: 455 Authenticator: 881201108d944ad51622c1b9e14bfee7 [The response to this request is in frame 2187] Attribute Value Pairs AVP: t=User-Name(1) l=11 val=101179610 AVP: t=Acct-Status-Type(40) l=6 val=Interim-Update(3) AVP: t=Acct-Session-Id(44) l=11 val=352027268 AVP: t=Event-Timestamp(55) l=6 val=Jul 12, 2017 23:19:30.000000000 RTZ 2 AVP: t=Acct-Input-Octets(42) l=6 val=1127113955 AVP: t=Acct-Output-Octets(43) l=6 val=728225336 AVP: t=Acct-Session-Time(46) l=6 val=451796 AVP: t=Acct-Input-Packets(47) l=6 val=8962801 AVP: t=Acct-Output-Packets(48) l=6 val=35607540 AVP: t=Acct-Delay-Time(41) l=6 val=5 AVP: t=Service-Type(6) l=6 val=Framed(2) AVP: t=Framed-Protocol(7) l=6 val=PPP(1) AVP: t=Vendor-Specific(26) l=29 vnd=Juniper Networks/Unisphere(4874) AVP: t=Acct-Authentic(45) l=6 val=RADIUS(1) AVP: t=Vendor-Specific(26) l=22 vnd=Juniper Networks/Unisphere(4874) AVP: t=Framed-IP-Address(8) l=6 val=172.26.93.174 AVP: t=Framed-IP-Netmask(9) l=6 val=255.255.255.255 AVP: t=Vendor-Specific(26) l=12 vnd=Juniper Networks/Unisphere(4874) AVP: t=Acct-Input-Gigawords(52) l=6 val=0 AVP: t=NAS-Identifier(32) l=9 val=RUrban3 AVP: t=NAS-Port(5) l=6 val=3028 AVP: t=NAS-Port-Id(87) l=32 val=ae0.demux0.3222168877:812-3028 AVP: t=NAS-Port-Type(61) l=6 val=Ethernet(15) AVP: t=Vendor-Specific(26) l=12 vnd=Juniper Networks/Unisphere(4874) AVP: t=Acct-Output-Gigawords(53) l=6 val=11 AVP: t=Vendor-Specific(26) l=12 vnd=Juniper Networks/Unisphere(4874) AVP: t=Vendor-Specific(26) l=12 vnd=Juniper Networks/Unisphere(4874) AVP: t=Vendor-Specific(26) l=12 vnd=Juniper Networks/Unisphere(4874) AVP: t=Vendor-Specific(26) l=12 vnd=Juniper Networks/Unisphere(4874) AVP: t=Vendor-Specific(26) l=12 vnd=Juniper Networks/Unisphere(4874) AVP: t=Vendor-Specific(26) l=12 vnd=Juniper Networks/Unisphere(4874) AVP: t=Vendor-Specific(26) l=23 vnd=Juniper Networks/Unisphere(4874) AVP: t=Vendor-Specific(26) l=31 vnd=Juniper Networks/Unisphere(4874) AVP: t=Vendor-Specific(26) l=63 vnd=The Broadband Forum(3561) AVP: t=NAS-IP-Address(4) l=6 val=192.168.144.22 ---------------- Only second packet was logged ---------------- Thu Dec 12 23:20:33 2019: DEBUG: Packet dump: *** Received from 192.168.144.22 port 49785 .... Code: Accounting-Request Identifier: 127 Authentic: <136><18><1><16><141><148>J<213><22>"<193><185><225>K<254><231> Attributes: User-Name = "101179610" Acct-Status-Type = Alive Acct-Session-Id = "352027268" Event-Timestamp = 1499890770 Acct-Input-Octets = 1127113955 Acct-Output-Octets = 728225336 Acct-Session-Time = 451796 Acct-Input-Packets = 8962801 Acct-Output-Packets = 35607540 Acct-Delay-Time = 5 Service-Type = Framed-User Framed-Protocol = PPP Unknown-4874-177 = Port speed: 30000000k Acct-Authentic = RADIUS Unisphere-Dhcp-Mac-Addr = "c0a5.dd11.6d13" Framed-IP-Address = 172.26.93.174 Framed-IP-Netmask = 255.255.255.255 Unisphere-Input-Gigapkts = 0 Acct-Input-Gigawords = 0 NAS-Identifier = "RUrban3" NAS-Port = 3028 NAS-Port-Id = "ae0.demux0.3222168877:812-3028" NAS-Port-Type = Ethernet Unisphere-Ouput-Gigapkts = 0 Acct-Output-Gigawords = 11 Unisphere-Ipv6-Acct-Input-Octets = 0 Unisphere-Ipv6-Acct-Output-Octets = 0 Unisphere-Ipv6-Acct-Output-Octets = 0 Unisphere-Ipv6-Acct-Output-Packets = 0 Unisphere-Ipv6-Acct-Input-Gigawords = 0 Unisphere-Ipv6-Acct-Output-Gigawords = 0 Unisphere-Virtual-Router = "default:default" Unisphere-Pppoe-Description = "pppoe c0:a5:dd:11:6d:13" DSLForum-Agent-Circuit-Id = DSLForum-Agent-Remote-Id = NAS-IP-Address = 192.168.144.22 ---------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvn at open.com.au Fri Dec 13 13:22:27 2019 From: hvn at open.com.au (Heikki Vatiainen) Date: Fri, 13 Dec 2019 15:22:27 +0200 Subject: [RADIATOR] Proxy does not catch the Request In-Reply-To: References: Message-ID: <7c23232e-fc74-c3a8-073f-dbd1fc473186@open.com.au> On 13/12/2019 9.40, SinTeZ Wh1te wrote: > We have a problem with some RADIUS packets. > Radiator don't catch these packets. But other packets with same host, > same values - Radiator sees and forwarding to another host. > It is not a routing/networking issue since i see on Radiator server > (using tcpdump) that the requests arrives correctly on 1821 port. > But nothing gets logged (using Trace 4). > > There are a lot of ignored packets, and i can't understand what wrong > with our configuration. I would start by looking at log messages from radiusd start. If there are problems with configuration parameters and loading the configuration, this is where you can see them. When radiusd is running, do you see any log messages that could correspond to the problems? You should also check CPU utilisation with top or similar utility. Do you see radiusd processing using a lot of CPU? When UDP messages are received from the network, the kernel needs to queue them for the processes. To see if there are queue overflows, use for example netstat: % netstat --udp --statistics ... Udp: 340652 packets received 0 packets to unknown port received. 0 packet receive errors 340682 packets sent 0 receive buffer errors 0 send buffer errors ... If you see receive buffer errors and the number is increasing, it might be caused by more UDP mesages being received than radiusd can handle. The buffer in kernel is limited and messages are are discarded when the buffer space runs out. These buffers can be increased to handle sudden spikes but in the long run it will always overflow if the process emptying the buffer can't keep up with incoming rate. Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory, EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc. From hvn at open.com.au Fri Dec 13 13:36:52 2019 From: hvn at open.com.au (Heikki Vatiainen) Date: Fri, 13 Dec 2019 15:36:52 +0200 Subject: [RADIATOR] What TPS are you getitng on your radiator In-Reply-To: References: Message-ID: <3791211b-469f-e194-41b9-8806675d7a00@open.com.au> On 10/12/2019 15.52, cihangir sinan koca wrote: > What we are facing is, servers are unable to process more packet than > 50-60 TPS. After i while its not writing the problem in logs, its not > answering to any packet. > > Is it expected ? Or are we doing something wrong ? I'd say it's possible and possibly not, respectively :) Database access is synchronous. If DB takes a long time to respond, it will lower TPS rate for a single Radiator instance. To fix this, you take a look at FarmSize parameter to increase the number of instances to make processing parallel. FarmSize works with protocols such as PAP, MSCHAP and its derivatives and RADIUS accounting. With EAP you need to do more because it uses multiple messages for each authentication and the related messages must be processed by the same instance. To summarise: there can be many reasons why TPS rate is low. Sometimes indexing on the DB side helps a lot, sometimes there are DNS requests for each query or it may be a number of different things such as a complex configuration that consults 3 databases for each request. You should also check that you are not using debug logging while trying to test performance. I would look at DB indexing and logs on the DB side and Radiator configuration log level and complexity on Radiator side. Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory, EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc. From hvn at open.com.au Mon Dec 16 09:37:05 2019 From: hvn at open.com.au (Heikki Vatiainen) Date: Mon, 16 Dec 2019 11:37:05 +0200 Subject: [RADIATOR] memory leaks In-Reply-To: <55a7d3d8-1959-133f-095c-cac716e809ec@tomasek.cz> References: <55a7d3d8-1959-133f-095c-cac716e809ec@tomasek.cz> Message-ID: On 29/11/2019 11.57, Jan Tomasek wrote: > after I started using FarmSize = 3 I've noted that Radiator is quite > badly leaking memory, see: > http://tomasek.cz/stuff/memusage_radiusd-day.png > > I'm not sure that the problem comes with FarmSize. The system has 32GB > RAM and with 3 workers it becomes visible. I wasn't monitoring memory > consumption before. There are some things that are shared between processes, such as listen socket for incoming RadSec connections, but otherwise the processes are independent. I'd say this is not a FarmSize issues, but I would not rule it out yet. You mentioned you did not monitor memory consumption before: Did you restart processes daily already then? > The automatic restart is scheduled at 6:59. That is the lowest value in > the graph (3.18GB), later every 2nd hour in 25minute memory consumption > jumps by ~1.5GB, detail: > http://tomasek.cz/stuff/memusage_radiusd-day.png > > I do not think it is related to user activity as the graph seems to jump > by constant step every 2h. CPU load graphs: > http://tomasek.cz/stuff/cpuload_radiusd.png > top user activity is at 12. How do you refresh CRL files? Would this be something that happens every 2 hours? > I'm running Radiator as Czech eduroam proxy. I've about 450 peer RADIUS > servers, mostly (400+) using RadSec. I'm using CRL checking, which is > the main reason for its initial memory footprint but can hardly explain > memory leaks. It might be useful to see if, for example, CRL files are refreshed on the file system periodically and this corresponds to process size growth. > I'm logging with trace 4 and rotating logs every one hour: > That is only periodical activity configured - but it happens every hour. This should not matter. > I'm running version 4.23.43 on Debian Stretch. > Total memory usage of the system: > http://tomasek.cz/stuff/total-memory.png > does not show growth so clearly as only isolated Radiator. There is some > periodicity at 40minute of every hour? Any periodic events that happen are relative to each radiusd start time. This may be configurable at some time in the future, but now things that happen periodically within a radiusd are relative. For example, if Client list is refreshed from SQL every 50 minutes, the first refresh happens when radiusd has been running for 50 minutes. > I will start monitoring also Resident Set Size, I guess it will not show > steps like Virtual, but fact that radiator is leaking memory remains. How does it look? Anything periodic looking happening there? Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory, EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc. From csinankoca at gmail.com Tue Dec 17 07:29:34 2019 From: csinankoca at gmail.com (cihangir sinan koca) Date: Tue, 17 Dec 2019 10:29:34 +0300 Subject: [RADIATOR] What TPS are you getitng on your radiator In-Reply-To: <3791211b-469f-e194-41b9-8806675d7a00@open.com.au> References: <3791211b-469f-e194-41b9-8806675d7a00@open.com.au> Message-ID: Hi Heikki, Thanks for your answer. Due to a routing issue on network, one database query was taking 100ms for each Radiator (we got 2) After we fix the issue, now a query takes 2 ms for the first one, for second one its 20ms. So TPS is much better now. For the second one, which is taking 20ms, we will consider to use Farmsize command. Thanks Best Regards Heikki Vatiainen , 13 Ara 2019 Cum, 16:36 tarihinde ?unu yazd?: > On 10/12/2019 15.52, cihangir sinan koca wrote: > > > What we are facing is, servers are unable to process more packet than > > 50-60 TPS. After i while its not writing the problem in logs, its not > > answering to any packet. > > > > Is it expected ? Or are we doing something wrong ? > > I'd say it's possible and possibly not, respectively :) > > Database access is synchronous. If DB takes a long time to respond, it > will lower TPS rate for a single Radiator instance. To fix this, you > take a look at FarmSize parameter to increase the number of instances to > make processing parallel. > > FarmSize works with protocols such as PAP, MSCHAP and its derivatives > and RADIUS accounting. With EAP you need to do more because it uses > multiple messages for each authentication and the related messages must > be processed by the same instance. > > To summarise: there can be many reasons why TPS rate is low. Sometimes > indexing on the DB side helps a lot, sometimes there are DNS requests > for each query or it may be a number of different things such as a > complex configuration that consults 3 databases for each request. You > should also check that you are not using debug logging while trying to > test performance. > > I would look at DB indexing and logs on the DB side and Radiator > configuration log level and complexity on Radiator side. > > Thanks, > Heikki > > -- > Heikki Vatiainen > > Radiator: the most portable, flexible and configurable RADIUS server > anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory, > EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP, > DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc. > _______________________________________________ > radiator mailing list > radiator at lists.open.com.au > https://lists.open.com.au/mailman/listinfo/radiator > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvn at open.com.au Tue Dec 17 12:23:34 2019 From: hvn at open.com.au (Heikki Vatiainen) Date: Tue, 17 Dec 2019 14:23:34 +0200 Subject: [RADIATOR] What TPS are you getitng on your radiator In-Reply-To: References: <3791211b-469f-e194-41b9-8806675d7a00@open.com.au> Message-ID: <8e676c6c-65f2-cd34-35ff-6df8e00d4876@open.com.au> On 17/12/2019 9.29, cihangir sinan koca wrote: > For the second one, which is taking 20ms, we will consider to use > Farmsize command. I'll clarify Radiator reference manual to include FarmSize where DB indexing and other performance ideas and checks are discussed. There's no reason to not include it there. Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory, EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc. From hvn at open.com.au Wed Dec 18 08:33:59 2019 From: hvn at open.com.au (Heikki Vatiainen) Date: Wed, 18 Dec 2019 10:33:59 +0200 Subject: [RADIATOR] memory leaks In-Reply-To: References: <55a7d3d8-1959-133f-095c-cac716e809ec@tomasek.cz> Message-ID: On 16/12/2019 11.37, Heikki Vatiainen wrote: > On 29/11/2019 11.57, Jan Tomasek wrote: >> I'm running Radiator as Czech eduroam proxy. I've about 450 peer RADIUS >> servers, mostly (400+) using RadSec. I'm using CRL checking, which is >> the main reason for its initial memory footprint but can hardly explain >> memory leaks. > > It might be useful to see if, for example, CRL files are refreshed on > the file system periodically and this corresponds to process size growth. I took a closer look at CRL loading and noticed that with a very large CRL file that is refreshed frequently, time stamp change is enough, radiusd process size grows quickly. This turned out to be caused by resources allocated by OpenSSL API not being freed by Radiator once the CRL file had been processed. Please go to https://www.open.com.au/radiator/downloads.html and proceed to downloads. At the bottom of page listing the release packages for 4.24, there is a link to 4.24 patches. The fix to free resources is in 4.24-3. The fix requires Net::SSLeay 1.46 which covers the most of current distributions. Notably RHEL/CentOS 6 does unfortunately have Net::SSLeay::X509_CRL_free() and on those systems the problem remains and call to the said functions is not attempted. Please see how it goes and let us know. Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory, EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc. From jan at tomasek.cz Thu Dec 19 08:25:56 2019 From: jan at tomasek.cz (Jan Tomasek) Date: Thu, 19 Dec 2019 09:25:56 +0100 Subject: [RADIATOR] memory leaks In-Reply-To: References: <55a7d3d8-1959-133f-095c-cac716e809ec@tomasek.cz>

Message-ID: <5f73a29d-d687-e07a-e8f1-13afa49a15d2@tomasek.cz> Hi Heikki, On 12/18/19 9:33 AM, Heikki Vatiainen wrote: > Please go to https://www.open.com.au/radiator/downloads.html and proceed > to downloads. At the bottom of page listing the release packages for > 4.24, there is a link to 4.24 patches. The fix to free resources is in > 4.24-3. > > The fix requires Net::SSLeay 1.46 which covers the most of current > distributions. Notably RHEL/CentOS 6 does unfortunately have > Net::SSLeay::X509_CRL_free() and on those systems the problem remains > and call to the said functions is not attempted. It didn't help, graph: http://www.tomasek.cz/stuff/memusage_radiusd-2019-12-19.png red dot shows moment of instaling the new version 4.24-3. root at radius1mng4:/usr/share/perl5# md5sum Radius/StreamTLS.pm Radius/TLS.pm c293a634495b5a775fa70c162627d980 Radius/StreamTLS.pm ecae687b1d22f6e6026ad0f31a5e8f95 Radius/TLS.pm root at radius1mng4:~# dpkg -l |grep -i ssleay ii libnet-ssleay-perl 1.80-1 amd64 Perl module for Secure Sockets Layer (SSL) -- ----------------------- Jan Tomasek aka Semik http://www.tomasek.cz/ From jan at tomasek.cz Thu Dec 19 08:26:03 2019 From: jan at tomasek.cz (Jan Tomasek) Date: Thu, 19 Dec 2019 09:26:03 +0100 Subject: [RADIATOR] memory leaks In-Reply-To: References: <55a7d3d8-1959-133f-095c-cac716e809ec@tomasek.cz> Message-ID: <115be093-4cff-9905-6d71-ca2ab20eec63@tomasek.cz> Hi Heikki, On 12/16/19 10:37 AM, Heikki Vatiainen wrote: > You mentioned you did not monitor memory consumption before: Did you > restart processes daily already then? No, I configured periodic restarts at 4. 12., But I'm not sure if I will notice Radiator crash because of Out of memory Kill. I'm running HA cluster and it will re-start it immediately. >> The automatic restart is scheduled at 6:59. That is the lowest value in >> the graph (3.18GB), later every 2nd hour in 25minute memory consumption >> jumps by ~1.5GB, detail: >> ???? http://tomasek.cz/stuff/memusage_radiusd-day.png >> >> I do not think it is related to user activity as the graph seems to jump >> by constant step every 2h. CPU load graphs: >> ???? http://tomasek.cz/stuff/cpuload_radiusd.png >> top user activity is at 12. > > How do you refresh CRL files? Would this be something that happens every > 2 hours? Yes, CRL refresh is done by script getcrls http://tools.cesnet-ca.cz/getcrl/ it's scheduled at 29 minute every second hour - I didn't realize this when I was writing the previous email. > How does it look? Anything periodic looking happening there? http://www.tomasek.cz/stuff/memusage_radiusd-2019-12-19.png it is same for VIRT/RES memory. My system is configured to check CRLs: 244b5494.0 -> DigiCert_High_Assurance_EV_Root_CA.pem 4d12be1d.0 -> CESNET_CA_3.pem 84c78b97.0 -> CESNET_CA_4.pem a580eeb3.0 -> eduroamCA.pem b1159c4c.0 -> DigiCert_Assured_ID_Root_CA.pem c158e258.0 -> eduPKI_CA_G_01.pem d919ffd0.0 -> TERENA_SSL_CA_3.pem dd5d4ea8.0 -> TERENA_SSL_High_Assurance_CA_3.pem e523eeaa.0 -> TERENA_eScience_SSL_CA_3.pem f4401b90.0 -> CESNET_CA_Root.pem Only two have significant size: -rw-r--r-- 1 root root 482162 Dec 19 08:29 d919ffd0.r0 -rw-r--r-- 1 root root 58276 Dec 19 08:29 dd5d4ea8.r0 They are http://crl3.digicert.com/TERENASSLCA3.crl and http://crl3.digicert.com/TERENASSLHighAssuranceCA3.crl Best regards -- ----------------------- Jan Tomasek aka Semik http://www.tomasek.cz/ From rullfig at uic.edu Thu Dec 19 15:03:31 2019 From: rullfig at uic.edu (Ullfig, Roberto Alfredo) Date: Thu, 19 Dec 2019 15:03:31 +0000 Subject: [RADIATOR] NTLM Auth / Samba Password Caching? Message-ID: Hello, one of my co-workers recently changed their AD password and it took a while for the new password to authenticate to Radiator. Does NTLM Auth have a password cache? Trying to determine where in the path the new password wasn't up to date... --- Roberto Ullfig - rullfig at uic.edu Systems Administrator Enterprise Architecture and Development | ACCC University of Illinois - Chicago -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvn at open.com.au Fri Dec 20 15:28:54 2019 From: hvn at open.com.au (Heikki Vatiainen) Date: Fri, 20 Dec 2019 17:28:54 +0200 Subject: [RADIATOR] NTLM Auth / Samba Password Caching? In-Reply-To: References: Message-ID: On 19/12/2019 17.03, Ullfig, Roberto Alfredo wrote: > Hello, one of my co-workers recently changed their AD password and it > took a while for the new password to authenticate to Radiator. Does NTLM > Auth have a password cache? Trying to determine where in the path the > new password wasn't up to date... Radiator's AuthBy NTLM does not cache, so the closest thing to Radiator would be parts of samba that ntlm_auth talks to. The AD environments I've used for testing have been simple and I do not recall noticing propagation delay. A quick web search indicates propagation delays after password resets between servers are not unheard-of. Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory, EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc. From hvn at open.com.au Fri Dec 20 15:53:09 2019 From: hvn at open.com.au (Heikki Vatiainen) Date: Fri, 20 Dec 2019 17:53:09 +0200 Subject: [RADIATOR] memory leaks In-Reply-To: <5f73a29d-d687-e07a-e8f1-13afa49a15d2@tomasek.cz> References: <55a7d3d8-1959-133f-095c-cac716e809ec@tomasek.cz>

<5f73a29d-d687-e07a-e8f1-13afa49a15d2@tomasek.cz> Message-ID: <6dc9255c-7fdf-a3ff-f9ba-09abc11c3984@open.com.au> On 19/12/2019 10.25, Jan Tomasek wrote: > It didn't help, graph: > http://www.tomasek.cz/stuff/memusage_radiusd-2019-12-19.png > red dot shows moment of instaling the new version 4.24-3. > > root at radius1mng4:/usr/share/perl5# md5sum Radius/StreamTLS.pm Radius/TLS.pm > c293a634495b5a775fa70c162627d980 Radius/StreamTLS.pm > ecae687b1d22f6e6026ad0f31a5e8f95 Radius/TLS.pm Seem to match. I checked against what I have. Do you think you could modify your certificate refresh so that it only copies the CRL file in place if it has changed? For example, if old and new files have different SHA checksums. That would verify that problem is with CRL file timestamps triggering refresh attempts. Or maybe stopping the refresh for a short while to see if it affects memory consumption. Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory, EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc. From rullfig at uic.edu Fri Dec 20 20:06:34 2019 From: rullfig at uic.edu (Ullfig, Roberto Alfredo) Date: Fri, 20 Dec 2019 20:06:34 +0000 Subject: [RADIATOR] Why the need for Radiator? Message-ID: I got into this project after it had all been designed. Why can't the Cisco WISMs talk directly to Active Directory for authentication? Why do we need Radiator in between? --- Roberto Ullfig - rullfig at uic.edu Systems Administrator Enterprise Architecture and Development | ACCC University of Illinois - Chicago -------------- next part -------------- An HTML attachment was scrubbed... URL: From hugh at open.com.au Sat Dec 21 06:39:00 2019 From: hugh at open.com.au (Hugh Irvine) Date: Sat, 21 Dec 2019 17:39:00 +1100 Subject: [RADIATOR] Why the need for Radiator? In-Reply-To: References: Message-ID: Hello Roberto - It depends on what else you are wanting/needing to do for authentication. Most Universities are members of Eduroam, and for that you will have authentication requests for people from other institutions that you will need to proxy via Eduroam. In general it is much easier to have Radiator deal with Eduroam users before you authenticate your local users. YMMV of course. regards Hugh > On 21 Dec 2019, at 07:06, Ullfig, Roberto Alfredo wrote: > > I got into this project after it had all been designed. Why can't the Cisco WISMs talk directly to Active Directory for authentication? Why do we need Radiator in between? > > --- > Roberto Ullfig - rullfig at uic.edu > Systems Administrator > Enterprise Architecture and Development | ACCC > University of Illinois - Chicago > _______________________________________________ > radiator mailing list > radiator at lists.open.com.au > https://lists.open.com.au/mailman/listinfo/radiator -- Hugh Irvine hugh at open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER, SIM, etc. Full source on Unix, Linux, Windows, macOS, Solaris, VMS, NetWare etc. From jan at tomasek.cz Sun Dec 22 17:12:24 2019 From: jan at tomasek.cz (Jan Tomasek) Date: Sun, 22 Dec 2019 18:12:24 +0100 Subject: [RADIATOR] memory leaks In-Reply-To: <6dc9255c-7fdf-a3ff-f9ba-09abc11c3984@open.com.au> References: <55a7d3d8-1959-133f-095c-cac716e809ec@tomasek.cz>

<5f73a29d-d687-e07a-e8f1-13afa49a15d2@tomasek.cz> <6dc9255c-7fdf-a3ff-f9ba-09abc11c3984@open.com.au> Message-ID: <25009d51-ea40-f435-8dc1-6f2b5b47d938@tomasek.cz> Hi Heikki, On 12/20/19 4:53 PM, Heikki Vatiainen wrote: > Do you think you could modify your certificate refresh so that it only > copies the CRL file in place if it has changed? For example, if old and > new files have different SHA checksums. > > That would verify that problem is with CRL file timestamps triggering > refresh attempts. Or maybe stopping the refresh for a short while to see > if it affects memory consumption. I disabled CRL downloading for two days and it is clearly visible that memory leak is related to CRL reloading: http://tomasek.cz/stuff/memusage_radiusd-20191222.png Best regards -- ----------------------- Jan Tomasek aka Semik http://www.tomasek.cz/ From michael.filz at zv-extern.fraunhofer.de Mon Dec 23 08:14:15 2019 From: michael.filz at zv-extern.fraunhofer.de (michael.filz at zv-extern.fraunhofer.de) Date: Mon, 23 Dec 2019 08:14:15 +0000 Subject: [RADIATOR] Why the need for Radiator? In-Reply-To: References:

Message-ID: To be fair, for proxying Eduroam you are probably better off using radsecproxy which is pretty much made for that. Although Radiator is quite a bit easier to deal with than Cisco. On Sat, 2019-12-21 at 17:39 +1100, Hugh Irvine wrote: > Hello Roberto - > > It depends on what else you are wanting/needing to do for > authentication. > > Most Universities are members of Eduroam, and for that you will have > authentication requests for people from other institutions that you > will need to proxy via Eduroam. > > In general it is much easier to have Radiator deal with Eduroam users > before you authenticate your local users. > > YMMV of course. > > regards > > Hugh > > > > On 21 Dec 2019, at 07:06, Ullfig, Roberto Alfredo > > wrote: > > > > I got into this project after it had all been designed. Why can't > > the Cisco WISMs talk directly to Active Directory for > > authentication? Why do we need Radiator in between? > > > > --- > > Roberto Ullfig - rullfig at uic.edu > > Systems Administrator > > Enterprise Architecture and Development | ACCC > > University of Illinois - Chicago > > _______________________________________________ > > radiator mailing list > > radiator at lists.open.com.au > > https://lists.open.com.au/mailman/listinfo/radiator > > -- > > Hugh Irvine > hugh at open.com.au > > Radiator: the most portable, flexible and configurable RADIUS server > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, > Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, > TLS, > TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, > DIAMETER, SIM, etc. > Full source on Unix, Linux, Windows, macOS, Solaris, VMS, NetWare > etc. > > _______________________________________________ > radiator mailing list > radiator at lists.open.com.au > https://lists.open.com.au/mailman/listinfo/radiator From hvn at open.com.au Mon Dec 23 11:23:58 2019 From: hvn at open.com.au (Heikki Vatiainen) Date: Mon, 23 Dec 2019 13:23:58 +0200 Subject: [RADIATOR] memory leaks In-Reply-To: <25009d51-ea40-f435-8dc1-6f2b5b47d938@tomasek.cz> References: <55a7d3d8-1959-133f-095c-cac716e809ec@tomasek.cz>

<5f73a29d-d687-e07a-e8f1-13afa49a15d2@tomasek.cz> <6dc9255c-7fdf-a3ff-f9ba-09abc11c3984@open.com.au> <25009d51-ea40-f435-8dc1-6f2b5b47d938@tomasek.cz> Message-ID: <026a7921-7832-5022-bb5c-216d60dc5fce@open.com.au> On 22.12.2019 19.12, Jan Tomasek wrote: > I disabled CRL downloading for two days and it is clearly visible that > memory leak is related to CRL reloading: > http://tomasek.cz/stuff/memusage_radiusd-20191222.png Thanks for the verification. With 4.24-3, the growth rate seems to be similar (about 1.5GB) to what it was before the 4.24-3 version. Is that Debian 9 (Stretch) that you are using? It's likely something that is related to API usage, but I thought I'd make sure what library Net::SSLeay is linked against. Just to check: the .pm file checksums match so you have the updated files, but would there be any possibility that they are not in use? As you wrote, the CRL file sizes are not very large but if there are a lot of Handlers or other clauses that refer to them, then the cumulative size could be large. If so, I would expect that would be some visible change in memory usage but now it seems not. Because CRLs are loaded for each SSL context (SSL_CTX) I'll see if, for example, more work is needed to release resources in each SSL_CTX after CRL reload. Can you estimate how many clauses, and thus SSL_CTX instances, you have in your config? I noticed you have quite a few RadSec peers Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory, EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc. From hugh at open.com.au Mon Dec 23 22:59:35 2019 From: hugh at open.com.au (Hugh Irvine) Date: Tue, 24 Dec 2019 09:59:35 +1100 Subject: [RADIATOR] Why the need for Radiator? In-Reply-To: References:

Message-ID: <6E795BAF-A702-4A20-BEE4-C933B299ECE8@open.com.au> Hello Michael - Yes Mike developed this out of the work he did on Diameter. We realised that RADIUS needed a secure tunnel too. best of the season Hugh > On 23 Dec 2019, at 19:14, wrote: > > To be fair, for proxying Eduroam you are probably better off using > radsecproxy which is pretty much made for that. Although Radiator is > quite a bit easier to deal with than Cisco. > > On Sat, 2019-12-21 at 17:39 +1100, Hugh Irvine wrote: >> Hello Roberto - >> >> It depends on what else you are wanting/needing to do for >> authentication. >> >> Most Universities are members of Eduroam, and for that you will have >> authentication requests for people from other institutions that you >> will need to proxy via Eduroam. >> >> In general it is much easier to have Radiator deal with Eduroam users >> before you authenticate your local users. >> >> YMMV of course. >> >> regards >> >> Hugh >> >> >>> On 21 Dec 2019, at 07:06, Ullfig, Roberto Alfredo >>> wrote: >>> >>> I got into this project after it had all been designed. Why can't >>> the Cisco WISMs talk directly to Active Directory for >>> authentication? Why do we need Radiator in between? >>> >>> --- >>> Roberto Ullfig - rullfig at uic.edu >>> Systems Administrator >>> Enterprise Architecture and Development | ACCC >>> University of Illinois - Chicago >>> _______________________________________________ >>> radiator mailing list >>> radiator at lists.open.com.au >>> https://lists.open.com.au/mailman/listinfo/radiator >> >> -- >> >> Hugh Irvine >> hugh at open.com.au >> >> Radiator: the most portable, flexible and configurable RADIUS server >> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, >> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, >> TLS, >> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, >> DIAMETER, SIM, etc. >> Full source on Unix, Linux, Windows, macOS, Solaris, VMS, NetWare >> etc. >> >> _______________________________________________ >> radiator mailing list >> radiator at lists.open.com.au >> https://lists.open.com.au/mailman/listinfo/radiator > _______________________________________________ > radiator mailing list > radiator at lists.open.com.au > https://lists.open.com.au/mailman/listinfo/radiator -- Hugh Irvine hugh at open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER, SIM, etc. Full source on Unix, Linux, Windows, macOS, Solaris, VMS, NetWare etc. From tarko at lanparty.ee Sun Dec 29 13:16:52 2019 From: tarko at lanparty.ee (Tarko Tikan) Date: Sun, 29 Dec 2019 15:16:52 +0200 Subject: [RADIATOR] Prometheus statistics output Message-ID: <13f4563c-ffe9-1e5b-c3e3-932c63074f6f@lanparty.ee> Hey and happy holidays, Radiator SNMPAgent has served us really well over the years to get the server statistics to our monitoring system. We are now moving towards Prometheus and I'm looking into how to get Radiator metrics to Prometheus. I could definetly write my own exporter that queries Radiator via SNMP and outputs Prometheus metrics (I could even use snmp-exporter for that). Or I could write a script that converts SNMP or StatsLog into suitable textfile and expose it via node-exporter textfile exporter. But all this feels like a hack in 2020 :) Are there other Radiator users who would be interested in native Prometheus metrics support? This would be exactly like SNMPAgent - HTTP listener on user-defined port that exposes server statistics on /metrics using https://prometheus.io/docs/instrumenting/exposition_formats/#text-based-format format. That could be then collected directly by Prometheus. Looking at the code it'll not be too difficult to add and could be something that ends up in the goodies. Or perhaps it could be something that will be added officially as Prometheus is quickly becoming defacto metrics collection system in the cloud era? -- tarko From thomas at kccg.com Mon Dec 30 12:00:28 2019 From: thomas at kccg.com (Thomas Kurian) Date: Mon, 30 Dec 2019 15:00:28 +0300 Subject: [RADIATOR] Automated Reply : Thomas Kurian is out of station Message-ID: <11912301500.AA4128934428@kccg.com> ?Dear Sender, Thank you for your e-mail. Kindly be informed that I am currently on a short annual leave from office and will resume work on Thursday 9th January 2020. During this period, I'll have limited access to e-mails and no phone access. For matters requiring immediate attention, you are kindly requested to contact Mr. Hakim for both Sales and Technical support queries. Contact Details are as follows : Mr Hakim's Email ID : hakim at kccg.com Mobile number : +965 66562029 KCCG Office Phone No. : +965 22435566 -- Best Regards, Thomas Kurian IT Security Consultant|Key Account Manager| Technical Support Manager | Kuwaiti Canadian Consulting Group (www.kccg.com) T: +965 22435566 F: +965 22415149 E: thomas at kccg.com From hvn at open.com.au Tue Dec 31 15:03:03 2019 From: hvn at open.com.au (Heikki Vatiainen) Date: Tue, 31 Dec 2019 17:03:03 +0200 Subject: [RADIATOR] Prometheus statistics output In-Reply-To: <13f4563c-ffe9-1e5b-c3e3-932c63074f6f@lanparty.ee> References: <13f4563c-ffe9-1e5b-c3e3-932c63074f6f@lanparty.ee> Message-ID: <3799ae7b-b9f5-1c23-368a-15fae34d579e@open.com.au> On 29/12/2019 15.16, Tarko Tikan wrote: > I could definetly write my own exporter that queries Radiator via SNMP > and outputs Prometheus metrics (I could even use snmp-exporter for > that). Or I could write a script that converts SNMP or StatsLog into > suitable textfile and expose it via node-exporter textfile exporter. A quick question: Would exporting metrics be preferred over pushing metrics even when Radiator already supports StatsLog FILE with JSON output? It seems that JSON is not directly usable, but would require a separate exporter too. Builtin exporter is certainly possible, but I thought I'd check that you had noticed the already existing JSON support. I see that Prometheus docs advocate a built-in exporter, for example, for storing 'up' metric directly based on queried instance responses. We are open to any options and I'd be interested in helping you with this. Most likely the best option would be to include the support exporter directly in Radiator for easier use. Another/additional option would be to add an exporter in goodies for processing the existing StatsLog output. In either case configuration examples could go to goodies too. Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory, EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc. From tarko at lanparty.ee Tue Dec 31 15:46:56 2019 From: tarko at lanparty.ee (Tarko Tikan) Date: Tue, 31 Dec 2019 17:46:56 +0200 Subject: [RADIATOR] Prometheus statistics output In-Reply-To: <3799ae7b-b9f5-1c23-368a-15fae34d579e@open.com.au> References: <13f4563c-ffe9-1e5b-c3e3-932c63074f6f@lanparty.ee> <3799ae7b-b9f5-1c23-368a-15fae34d579e@open.com.au> Message-ID: <6f7447dd-b38e-9bfb-e3c3-5689d22e92aa@lanparty.ee> hey, > A quick question: Would exporting metrics be preferred over pushing > metrics even when Radiator already supports StatsLog FILE with JSON output? Correct. It's best to get up-to-date metrics at the time of the scrape, all other solutions like writing to files and scraping later time or using pushgateway are just hacks (but they do work if done correctly). > It seems that JSON is not directly usable, but would require a separate > exporter too. Builtin exporter is certainly possible, but I thought I'd > check that you had noticed the already existing JSON support. Correct, I mentioned it because JSON is directly parseable without any quirks. Separate exporter is still required. > I see that Prometheus docs advocate a built-in exporter, for example, > for storing 'up' metric directly based on queried instance responses. Yeah, builtin exporter is the best because up metric will then show if the actual scrape was successful. Other solutions will hide the actual state of the radiator process. One of course needs to keep in mind that successful scrape does not necessarily show the actual state of the service (radius with SQL backend is quite useless if the SQL is down but radiusd will keep working ofc). Even more important is that you get the metric values at the time of the scrape (as the builtin exporter will read directly from statistics data structures). This is ofc also true if out-of-process exporter queries radiator via SNMP or other means during the HTTP scrape request and then returns the metrics. HNY to everyone now and I'll return to this when I'm back at the office next week. It has been a while since I wrote real perl and I didn't find any stdlib HTTP servers now during quick search. As radiator today already requires you to have additional dependencies when you activate functionality, it should not be too big of a deal. -- tarko