aboutsummaryrefslogtreecommitdiffstats
path: root/lib/diameter/include
AgeCommit message (Collapse)Author
2014-02-24Be lenient with the M-bit in Grouped AVPsAnders Svensson
RFC 6733 says this, in 4.4: Receivers of a Grouped AVP that does not have the 'M' (mandatory) bit set and one or more of the encapsulated AVPs within the group has the 'M' (mandatory) bit set MAY simply be ignored if the Grouped AVP itself is unrecognized. The rule applies even if the encapsulated AVP with its 'M' (mandatory) bit set is further encapsulated within other sub-groups, i.e., other Grouped AVPs embedded within the Grouped AVP. The first sentence is mangled but take it to mean this: An unrecognized AVP of type Grouped that does not set the 'M' bit MAY be ignored even if one of its encapsulated AVPs sets the 'M' bit. This is a bit of a non-statement since if the AVP is unrecognized then its type is unknown. We therefore don't know that its data bytes contain encapsulated AVPs, so can't but ignore any of those that set the M-bit. Doing anything else when the type *is* known would be inconsistent. OTP-11087 (commit 066544fa) caused the M-bit on any unrecognized AVP to be regarded as an error, unrecognized being taken to mean "not explicitly defined as a member of its container". (That is, an AVP that can't be packed into a dedicated record field, which is slightly stronger than "not defined".) This fixed the original intention for top-level AVPs but broke the required leniency for Grouped AVPs whose type is known. This commit restores the leniency. Note that dictionary files need to be recompiled for the commit to have effect. Thanks to Rory McKeown for reporting the problem.
2013-05-29Fix recognition of 5001 on mandatory AVP'sAnders Svensson
An AVP setting the M-bit was not regarded as erroneous if it was defined in the dictionary in question and its container (message or Grouped AVP) had an 'AVP' field. It's now regarded as a 5001 error (AVP_UNSUPPORTED), as in the case that the AVP is not defined.
2013-05-17Detect all 5005 (MISSING_AVP) errors and don't reverse errorsAnders Svensson
The previous commit ensures that only one will be reported in an answer message when diameter itself sets Result-Code/Failed-AVP. The order of errors in #diameter_packet.errors is that in which they're detected, not the reverse as previously.
2013-05-17Add spec to diameter_genAnders Svensson
2013-05-17Fix recognition of 5014 (INVALID_AVP_LENGTH) errorsAnders Svensson
Invalid lengths come in two flavours: ones that correctly point at the end of an AVP's payload but don't agree with its type, and ones that point elsewhere. The former are relatively harmless but the latter leave no way to recover AVP boundaries, which typically results in failure to decode subsequent AVP's in the message in question. In the case that AVP Length points past the end of the message, diameter incorrectly regarded the error as 5009, INVALID_AVP_BITS: not right since the error has nothing to do with AVP Flags. Ditto if the length was less than 8, a minimal header length. Only in the remaining case was the detected error 5014, INVALID_AVP_LENGTH. However, in this case it slavishly followed RFC 3588 in suggesting the undecodable AVP as Failed-AVP, thereby passing the woeful payload back to the sender to have equal difficulty decoding. Now follow RFC 6733 and suggest an AVP with a zero-filled payload.
2013-02-17Answer 5xxx errors with application_opt() request_errors = answerAnders Svensson
RFC 3588 allowed only 3xxx result codes in an answer-message (that is, an answer that sets the E-bit) while RFC 6733 also allows 5xxx result codes. Setting request_errors = answer tells diameter to answer 5xxx errors itself. Returning {answer_message, integer()} from a handle_request callback allows both 3xxx and 5xxx result codes to be set. {protocol_error, integer()} is retained for 3xxx result codes.
2013-02-16Add application_opt() request_errorsAnders Svensson
Configuring the value 'callback' all errors detected in incoming requests to result in a handle_request callback. The default value 'answer_3xxx' is the previous behaviour in which diameter answers protocol errors without a callback.
2013-02-08Remove trailing whitespaceAnders Svensson
2013-02-08Don't hardcode common dictionaryAnders Svensson
Instead, use whatever dictionary a transport has configured as supporting application id 0. This is to support the updated RFC 6733 dictionaries (which bring with them updated records) and also to be able to transparently support any changed semantics (eg. 5xxx in answer-message).
2012-08-31Update copyright yearsBjörn-Egil Dahlberg
2012-08-26Turn last field of #diameter_app{} into an options listAnders Svensson
To make for easier adding of future options. The record is only passed into transport modules so the only compatibility issue is with these. (No issue for diameter_{tcp,sctp} and unlikely but theoretically possible for any other implementations, which probably don't exist at this point.)
2011-12-06Smarter diameter_callbackAnders Svensson
The module was originally just intended as a minimal callback implementation that could be used as a template. Being able to order just a subset of callbacks (with reasonable defaults) makes for simpler code in many cases however so ready support for this can be useful.
2011-11-10diameter_dbg:log -> diameter_lib:logAnders Svensson
Should have been included in 5af64c7d57d83ce35bfd7b15ac3ce6ec7459fd73.
2011-09-26Remove duplicate info from error report at encode failureAnders Svensson
The message being encoded and dictionary module are included by diameter_codec.erl so diameter_gen.hrl doing so was overkill.
2011-05-20Remove undocumented interface functions plus comment fix.Anders Svensson
2011-05-18Initial commit of the diameter application.Anders Svensson
The application provides an implementation of the Diameter protocol as defined in RFC 3588.