| Age | Commit message (Collapse) | Author |
|---|
|
* anders/diameter/17.0_release/OTP-11605:
Fix diameter.hrl comment typos
|
|
A Diameter Header Command Code is 24 bits, not 8, and an Application-ID
is 32 bits, not 24.
Thanks to Austin Aigbe for pointing it out.
|
|
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.
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
|
|
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).
|
|
|
|
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.)
|
|
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.
|
|
Should have been included in 5af64c7d57d83ce35bfd7b15ac3ce6ec7459fd73.
|
|
The message being encoded and dictionary module are included
by diameter_codec.erl so diameter_gen.hrl doing so was overkill.
|
|
|
|
The application provides an implementation of the Diameter protocol
as defined in RFC 3588.
|
