en:dpi:faq:troubleshooting:start [Документация VAS Experts]
Документация VAS Experts Документация VAS Experts-mobile
in

Settings

  • Show page
  • Old revisions
  • Export to PDF
  • Fold/unfold all
  • Backlinks
  • Show page
  • Old revisions
  • Export to PDF
  • Fold/unfold all
  • Backlinks

    • Differences

    This shows you the differences between two versions of the page.

    Link to this comparison view

    Both sides previous revisionPrevious revision
    Next revision    		Previous revision
    en:dpi:faq:troubleshooting:start [2019/10/25 13:37] – ↷ Page moved from en:dpi:dpi_options:base_functionality:opt_bras:bras_steps:troubleshooting:start to en:dpi:faq:troubleshooting:start lexx26en:dpi:faq:troubleshooting:start [2023/08/29 13:55] (current) – removed elena.krasnobryzh
    Line 1: Line 1:
    -====== 6 Troubleshooting ====== 
    -{{indexmenu_n>6}} 
    - 
    -== Authorization is not working == 
    -:!: Please check if authorization [[en:dpi:dpi_options:base_functionality:opt_bras:bras_steps:radius_auth_setup:start|is enabled]] in the fastdpi.conf settings   
    - 
    -:!: Is there local subscribers traffic? Let us recall that authorization is performed only when a packet from a local subscriber is received. 
    - 
    -:!: If fastDPI and fastPCRF are running on different servers, first of all check the firewall: whether the fastPCRF TCP port of fastDPI -> fastPCRF connection (default 29002) can be accessed from the fastDPI server. Similarly, ensure it works the other way round, i.e. that the fastDPI TCP control port (29000 by default) can be accessed from the fastPCRF server.  
    - 
    -:!: Check if there is a fastDPI -> fastPCRF connection. If the connection suddenly broken, then the following message will be written to the  [[en:dpi:dpi_options:base_functionality:opt_bras:bras_steps:radius_auth_fastpcrf_setup:fastpcrf_logs|fastdpi_ap0.log]]: 
    -<code> 
    -[INFO    ][2018/06/09-19:46:58:603824] auth_server::close_socket: client socket fd=27 closed 
    -</code> 
    -When a connection is established, the following message will be written to the log file: 
    -<code> 
    -[INFO    ][2018/06/09-19:45:46:843710] auth_server::accept: accepted client connection from 127.0.0.1:53498, fd=27, slot=1 
    -</code> 
    - 
    -:!: Check whether the connection to the Radius server is alive. If there are connection errors with the Radius server, the following messages in the [[en:dpi:dpi_options:base_functionality:opt_bras:bras_steps:radius_auth_fastpcrf_setup:fastpcrf_logs|fastdpi_ap2.log]] will indicate this situation: 
    -<code> 
    -[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 
    -</code> 
    -Also the connection errors might be indicated by a lot of records about the resending requests to the Radius server. 
    - 
    -When establishing connection to the Radius server, you will see something similar in the fastpcrf_ap2.log: 
    -<code> 
    -[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 
    -</code> 
    - 
    -:!: Check your Radius server: whether the requests from the fastPCRF reach the Radius server (if not, the possible reason is that the firewall blocks the Radius UDP ports), and whether the Radius secret is specified properly. 
    - 
    -:!: radius_unknown_user (unknown_user) – is a string, the user login, if the real login is unknown to the fastdpi. Default value: ''VasExperts.FastDPI.unknownUser''. This is the value of the Access-Request User-Name attribute in case the ''radius_user_name_ip = 0'' and the user login is unknown. It is assumed that the radius server will send in the Access-Accept response the real user login determined by its IP address being extracted from the Framed-IP-Address attribute and will send VasExperts.FastDPI.unknownUser; in the Wireshark you can see the "User-Name = ip", and in the logs: 
    -<code> 
    -[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 
    -</code> 
    - 
    -Starting from VAS Experts DPI version 7.4  the following more recent parameter has been introduced: ''radius_user_name_auth'', see the link [[https://wiki.vasexperts.ru/doku.php?id=en:dpi:dpi_options:base_functionality:opt_bras:bras_steps:radius_auth_server_integration:start&s[]=radius_user_name_auth|Integration with the Radius server]]. 
    -Hence the IP appears in the User-Name, if you specify it as ''radius_user_name_auth=login'', then when the login is not defined, the ''VasExperts.FastDPI.unknownUser'' will be used instead. This parameter should be used within the fastpcrf.conf file. 
    - 
    -== CoA requests are not accepted == 
    -:!: Check the firewall: whether the client sending the CoA request is granted the access to the fastPCRF server via the CoA port (this is the UDP port) 
    - 
    -== Other matters == 
    -:!: Please, consult me on issues relating to the manually authorization status management. Should the default_reject_whitelist be used if I set the following stuff manually: <code>fdpi_ctrl load --auth=0 --ip=192.168.10.1</code>? 
    - 
    -No, it should not be used. You should either explicitly run the corresponding command on the Radius, or to activate the 5th service for the subscriber.