dante   Frontpage - Dante - Download - Status - Support - Modules - Docs - Links - Survey - GDPR
 

Server logging

The Dante server has support for logging many different types of information, including traffic data, server status and debug information.

Server logging

The logging done by the server is controlled via keywords in the server configuration file.

Logfiles

Two logfile keywords are supported by Dante: logoutput and errorlog. The former controls how all syslog-type messages should be logged, regardless of severity, while the latter will only be used for logging warnings, errors, etc. If both are specified, warnings will be written to both files, while debug and information level messages are only written to the logoutput logfile.

Both keywords take the name of the file to which messages should be written, or one of the keywords syslog[/facility], stdout or stderr.

The following example shows how to enable general log output to a file and logging of warnings or errors to syslog:

errorlog: syslog
logoutput: /var/log/sockd.log

Debug logging

The debug keyword can be used to enable debug logging, and will cause a large amount of debug information to be written, as specified by the logoutput keyword:

debug: 1

The supported argument values are as follows:

  • debug: 0 - No debug logging.
  • debug: 1 - Some debug logging.
  • debug: 2 - Verbose debug logging.

Debug logging can also be enabled via the -d command line option when starting the Dante server. The command line option will override any value set in the configuration file.

Per-rule logging

Traffic related logging can be enabled on a per-rule basis, allowing different amounts of information to be logged for different types of traffic. The log keyword is used for this purpose and can be specified in any client or socks rule.

The following arguments can be given to the log keyword to enable logging of various types of information:

  • connect - Information about accepted client connections.
  • disconnect - Information about disconnecting clients.
  • ioop - Logging of each data transfer operation.
  • data - Logging of the actual data transferred.
  • tcpinfo - Logging of information obtained via the TCP_INFO socket option, on platforms where this information is available.

The default is for no logging to be done, unless debugging has been enabled, in which case several of the above types of data might be logged.

SIGINFO/SIGUSR1 based logging

Upon reception of a SIGINFO/SIGUSR1 signal, the Dante server will write various types of status information to the files specified by the logoutput keyword. This includes an overview of the server status, such as the number of handled clients, the number of running processes, etc., as well as a list of all currently active sessions.

UDP-based Dante latency testing

Dante also logs information about the latency of passed UDP traffic. If deliberate testing is done to measure the current latency of UDP traffic through the Dante server, it is recommended to follow the procedure outlined below.

To be guaranteed that the UDP latency information is available it is necessary to signal Dante while at least one of the UDP clients used for testing is still running. If Dante is signaled after the UDP clients have all exited, it is possible that the Dante I/O process(es) that were previously handling the UDP clients have exited. Because latency information is calculated and stored individually for each I/O process, the stored latency information will no longer be available after the I/O process handling the traffic has exited.

The following procedure can be used when measuring the current UDP latency through the Dante server, to ensure that this information is obtained reliably:

  1. Start at least one UDP client that sends and/or receives UDP packets through the Dante server.
  2. While at least one UDP client is still running, send the SIGINFO/SIGUSR1 signal to Dante.

If the UDP client terminates before the SIGINFO/SIGUSR1 signal is sent, the latency information might still be available, but this is not guaranteed.

The general statistics log output looks like this:

debug: read-only latency statistics based on last 50 packets:
       min/max/median/average/last/stddev: 100/159/138/137/133/15 (us)
debug: i/o latency statistics based on last 50 packets:
       min/max/median/average/last/stddev: 161/371/200/199/198/28 (us)
   

This information is provided by Dante on a per-process basis and consists of the observed min/max/median/avarage/last/stddev latency values observed by each Dante i/o process.

For the i/o latency statistics, Dante compares the timestamp of the received UDP packet to the current time, immediately after Dante has forwarded the packet, giving the total forwarding time.

For the read-only latency statistics, the values represent the difference between the kernel/NIC timestamp of the UDP packet, and the time when Dante read the packet, giving the processing delay before Dante is able to process the packet.

Note that in all cases, information is based on the most recently received packets.

Logging of traffic related failure warnings

Some types of network related problems can be reported by the system to the Dante server during forwarding of data traffic. This includes routing errors, connection refused errors and DNS failures.

When the Dante server is used to pass traffic from internal hosts to any external host on the Internet, these types of errors will typically be uninteresting, as connectivity to external hosts may come and go according to routing changes far away.

When Dante is instead used as a reverse proxy, forwarding traffic only to a small number of internal servers, or used as a gateway for internal hosts to a small number of high-quality target servers (e.g., servers for stock exchange information), the previously mentioned types of failures should generally never occur. If they do occur, it will likely indicate that there is a problem with the network between the Dante server and the target servers, or with the target servers themselves. By having support for logging of warnings in these situations, Dante can potentially warn the operator when the errors occur, assuming there is relevant client traffic passing through Dante.

Logging of routing failure related warnings (such as EHOSTUNREACH) can be enabled with the no-route keyword:

external.log.warning.error: no-route #enable warnings on external interface
internal.log.warning.error: no-route #enable warnings on internal interface

By default, the no-route warnings are not enabled, but the above lines can be set in the server configuration file to enable logging of the warnings for either of the internal or external sides of the Dante server (i.e., on the client side, server side, or both).

If a SOCKS client requests a connection to a target server by a hostname (rather than perhaps the more normal, by IP-address), and the DNS lookup for the target server requested fails, this is also an error that it might be useful to know about. Logging of this type of events can be enabled using the dns-any value, which will log any DNS-related errors.

These warnings will be logged in the following format:

warning: could not DNS-resolve "NOSUCHDNSNAME": Name or service not known

These warnings can be enabled as follows:

#enable warnings for traffic on the external interface
external.log.warning.error: dns-any

The no-route and dns-any are Dante-specific values that match multiple system errors.

It is also possible to specify the system error values directly, using the symbolic errno name for system calls, and the symbolic EAI_xxx error value for DNS-related errors.

For example, if a SOCKS client requests a connection to a target host that is currently reachable via the network, but where the target server application has crashed, the target host/kernel the target server is running on will normally return a TCP RST when Dante attempts to connect to the target server. Logging of this type of error can be enabled with the ECONNREFUSED keyword, corresponding to the errno value with the same name, giving the following type of log output:

warning: connect to host 10.0.0.1.80 failed: Connection refused

The following example shows how logging can be enabled when ECONNREFUSED is returned by the kernel or EAI_AGAIN is returned during DNS lookup:

#enable warnings for traffic on the external interface
external.log.warning.error: ECONNREFUSED EAI_AGAIN

For configurations where these types of warnings are useful, the traffic monitoring functionality in Dante might also provide tools that can usefully be used for detecting potential network problems.


Copyright © 1998-2024 Inferno Nettverk A/S