Re: erlang-questions Digest, Vol 378, Issue 6

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: erlang-questions Digest, Vol 378, Issue 6

anders.gs.svensson-2
[hidden email] writes:
>
> 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}.

The diameter application can indeed modify your answer, but you can
tell it not to. Here's the doc for the handle_request callback in
diameter_app(3):

  The errors field specifies any results codes identifying errors
  found while decoding the request. This is used to set Result-Code
  and/or Failed-AVP in a returned answer unless the callback returns a
  #diameter_packet{} whose errors field is set to either a non-empty
  list of its own, in which case this list is used instead, or the
  atom false to disable any setting of Result-Code and Failed-AVP.
  Note that the errors detected by diameter are of the 3xxx and 5xxx
  series, Protocol Errors and Permanent Failures respectively. The
  errors list is empty if the request has been received in the relay
  application.

That is set the errors field to false instead of [] and you should get
what you're expecting. (As Chandru did in his example.)

> 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

Yes. Far enough back in time this was the only possible behaviour, but
in more recent times you can ...

> o  if yes how to avoid/bypass it?? (how to send a valid answer even if request is seen in error)

... set errors = false, as above.

> o If not?: on which criteria a predefined answer is sent back to the transport layer instead of the application?s callback one??
> - 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????

Like Chandru said, tracing on diameter_codec lets you see what is
actually sent. Something like the following will do in this case.

dbg:tracer().
dbg:p(all, c).
dbg:tp(diameter_codec, encode, x).

Or [] instead of x if you only want to see what's encoded.

/Anders, Erlang/OTP


>
> Thx a lot by advance for your support.
>
> BR
>
> Ren? Veyland
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: erlang-questions Digest, Vol 378, Issue 6

René Veyland Mobile

Hi Anders

 

I will try with error=false instead of [] as it was coded.

 

I wrongly understood the text. I understood that the stack returns an error excepted if error field was set to [] or false. My fault.

 

Thx for feedback.

 

Br

René

Provenance : Courrier pour Windows 10

 

De : [hidden email]
Envoyé le :lundi 25 juin 2018 10:01
À : [hidden email]
Cc : [hidden email]; [hidden email]
Objet :Re: erlang-questions Digest, Vol 378, Issue 6

 

[hidden email] writes:

>

> 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}.

 

The diameter application can indeed modify your answer, but you can

tell it not to. Here's the doc for the handle_request callback in

diameter_app(3):

 

  The errors field specifies any results codes identifying errors

  found while decoding the request. This is used to set Result-Code

  and/or Failed-AVP in a returned answer unless the callback returns a

  #diameter_packet{} whose errors field is set to either a non-empty

  list of its own, in which case this list is used instead, or the

  atom false to disable any setting of Result-Code and Failed-AVP.

  Note that the errors detected by diameter are of the 3xxx and 5xxx

  series, Protocol Errors and Permanent Failures respectively. The

  errors list is empty if the request has been received in the relay

  application.

 

That is set the errors field to false instead of [] and you should get

what you're expecting. (As Chandru did in his example.)

 

> 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

 

Yes. Far enough back in time this was the only possible behaviour, but

in more recent times you can ...

 

> o  if yes how to avoid/bypass it?? (how to send a valid answer even if request is seen in error)

 

... set errors = false, as above.

 

> o If not?: on which criteria a predefined answer is sent back to the transport layer instead of the application?s callback one??

> - 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????

 

Like Chandru said, tracing on diameter_codec lets you see what is

actually sent. Something like the following will do in this case.

 

dbg:tracer().

dbg:p(all, c).

dbg:tp(diameter_codec, encode, x).

 

Or [] instead of x if you only want to see what's encoded.

 

/Anders, Erlang/OTP

 

 

>

> Thx a lot by advance for your support.

>

> BR

>

> Ren? Veyland

 


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions