On 26.3.2015 14.45, Kaspar Jasper wrote: > My Diameter peer sometimes complains about Diameter timeouts, which is 5 > seconds. Debugging leads me to the interesting detail - Diameter > messages sometimes are processing with delays in Radiator. > > For instance, Radiator's server Wireshark capture: > No. Time Source Destination Protocol Length Info > 231521 09:00:58.997242000 xxx.xxx.xx.xx xxx.xxx.xx.xx DIAMETER 1622 > cmd=Accounting Request(271) flags=RP-- appl=Diameter Base Accounting(3) > h2h=253e8654 e2e=253e8654 > > But in the Radiator this request appears 5.2 second later: > Thu Mar 26 09:01:04 2015 029052: DEBUG: StateMachine::event event
Most likely you see this request as delayed because there is already a queue in the OS receive buffer. That is, the previous messages have taken longer than than usually. I would take a look at the request processing flow and consider what external lookups radiusd is doing. For example, DNS lookups, SQL DB queries and so on. Some functions in Radius/Util.pm may do DNS lookups. This can happen if they are given a name instead of IP address. Thanks, Heikki -- Heikki Vatiainen <[email protected]> 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 etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. _______________________________________________ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
