• Check if authorization is enabled in fastdpi.conf settings
• Is there traffic from local subscribers? Remember that authorization takes place only after the packet from a local subscriber is received.
• If FastDPI and FastPCRF are installed on different servers, then you should first check the firewall settings: whether you have configured FastPCRF server to allow access from the FastDPI server to the TCP port for establishing fastDPI → fastPCRF connection (by default 29002). Similarly, in order to establish the opposite direction connection, the FastDPI server should be configured to allow access from the FastPCRF to the TCP management port (by default 29000).
• Check if there is a fastDPI → fastPCRF connection available. If the connection suddenly fails, then the following message will be written to the fastdpi_ap0.log log file:

[INFO ][2018/06/09-19:46:58:603824] auth_server::close_socket: client socket fd=27 closed

When a connection is established, the following message is logged:

[INFO ][2018/06/09-19:45:46:843710] auth_server::accept: accepted client connection from 127.0.0.1:53498, fd=27, slot=1

• Check if there is an active connection with the Radius server. The following messages in fastdpi_ap2.log indicate that there are problems with Radius server connection:

[ERROR ][2018/06/09-19:57:44:168053] rad_auth[0]::on_conn_error: fd=24, port=54189: errno=111 'Connection refused'
[INFO ][2018/06/09-19:57:44:168062] rad_auth[0]::close_connection: fd=24, port=54189, reqs=1

Also, problems can be indicated by multiple records about re-sending requests to the Radius server. When you establish a connection with the Radius server, you will see something like this in fastpcrf_ap2.log:

[INFO ][2018/06/09-20:01:44:190499] rad_auth[0]::init_connection: new connection to X.X.X.X%eth0:1812, fd=18, port=40510, connection count=1

• Check your Radius server: does it receive requests from the FastPCRF (possible reason is the firewall is configured to block connections to the Radius UDP ports), and is the Radius secret specified correctly.

The radius_unknown_user paremeter (unknown_user) is a string, user login, in case the real login is unknown to the fastdpi. The default value is ‘VasExperts.FastDPI.unknownUser’. It corresponds to the value of the User-Name attribute within the Access-Request request in case the radius_user_name_ip equals to 0 and the user login is unknown. It is assumed that the Radius server will pass in the Access-Accept the real user login, determined by its IP address extracted from the Framed-IP-Address attribute and will send VasExperts.FastDPI.unknownUser. The packages having been analyzed by Wireshark show that the User-Name = ip (in log files):

[TRACE ][2018/07/04-15:10:34:011126] auth_server::process: auth request: user IP=10.12.0.146, login='<n/a>', vlan-count=0

Since the VAS Experts DPI 7.4, a more recent parameter is used: radius_user_name_auth (see the hyperlink Integration with Radius Server). So IP address is used in the User-Name out there. If you specify radius_user_name_auth = login, then without a login being specified, the VasExperts.FastDPI.unknownUser will be used instead. It is the fastpcrf.conf parameter.