[erlang-questions] [OTP 19.3] [Diameter 1.12.2] Handle_request with error: reply not taken into account

[Chandru]

Hi René,

On 21 June 2018 at 15:31, René Veyland Mobile <rveyland2@REDACTED> wrote:

> Dear Erlang Community,
>
>
>
> I’m a beginner in Erlang, and i have a question on diameter stack behavior.
>
>
>
> I ‘m working on a sw acting as diameter peer server with a S6A app.
>
>
>
> I have noticed that when an diameter request is received with an error
> (for example an additional AVP not supported by dict), even if the packet
> provided in return value of the handle_request call back contains a valid
> answer with an AVP result-code=Success and header with errors=[] and
> is_error=false, the diameter stack return to client peer a diameter packet
> with an error 5001 (unsupported_avp) which is corresponding to the initial
> error found on request decoding (and not the answer sent in {reply, Reply}.
>
>
>
> If the initial diameter request is valid verus dict, then the answer
> provided by callback is sent back to client peer as expected.
>
>
>
> I would like to confirm that it is due to a bug from my sw (most probably
> ☹ )
>
>
>
> So I have some questions :
>
>    - Is it a normal of diameter stack behavior
>       -  if yes how to avoid/bypass it ? (how to send a valid answer even
>       if request is seen in error)
>
>
This code works for me in the handle_request/3 callback:

handle_request(#diameter_packet{msg = Req, transport_data = TD}, _SvcName,
{_, Caps})
  when is_record(Req, 'diameter_gx_CCR') ->

    #diameter_caps{origin_host = {OH,_},
                   origin_realm = {OR,_}}                = Caps,

    #'diameter_gx_CCR'{'Session-Id'          = Id,
                       'Auth-Application-Id' = AuthAppId,
                       'CC-Request-Type'     = ReqType,
                       'CC-Request-Number'   = ReqNum}  = Req,

    PolicyMap = get_policy(Req),

    CCA   = #'diameter_gx_CCA'{'Result-Code'                      = 2001,
                               'Auth-Application-Id'              =
AuthAppId,
                               'Origin-Host'                      = OH,
                               'Origin-Realm'                     = OR,
                               'Session-Id'                       = Id,
                               'CC-Request-Type'                  = ReqType,
                               'CC-Request-Number'                = ReqNum,
                               'Supported-Features'               =
get_supported_features(),
                               'QoS-Information'                  =
get_qos(PolicyMap),
                               'Charging-Rule-Install'            =
get_crbn(PolicyMap)
                              },
    ReplyPacket = #diameter_packet{msg = CCA,
                                   header = #diameter_header{},
                                   errors = false,
                                   transport_data = TD},
    {reply, ReplyPacket};

Also, when initialising the service, I tend to use the {strict_mbit, false}
option this is a frequent annoyance.


>    - More globally: What is the simplest way to debug diameter stack in
>       order to verify that data sent back by callback handler are « as
>       expected » ?
>
> I've also found debugging diameter applications to be quite hard. I've had
to resort to using dbg to trace calls in the diameter_codec module to
figure out what was going wrong.

regards,
Chandru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180621/dd869487/attachment.htm>