[erlang-questions] erlang-questions Digest, Vol 378, Issue 6

[anders.gs.svensson@REDACTED]

rveyland2@REDACTED 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