| Age | Commit message (Collapse) | Author |
|---|
|
That is, don't use a key constructed from an incoming Diameter header
unless the message is known to the dictionary in question. Otherwise
there are 2^32 application ids, 2^24 command codes, and 2 R-bits for an
ill-willed peer to choose from, each resulting in new keys in the
counter table (diameter_stats).
The usual {ApplicationId, CommandCode, Rbit} in a key is replaced by the
atom 'unknown' if the message in question is unknown to the decoding
dictionary.
Counters for messages sent and received by a relay are (still) not
implemented.
|
|
The former were a little over-enthusiastic and could cause a node to be
logged to death if a peer Diameter node was sufficiently ill-willed.
The function calls are to diameter_lib:log/4, the arguments of which
identify the happening in question, and which does nothing but provide a
function to trace on. Many existing log calls have been shrunk.
The only remaining traffic-related report (hopefully) is that resulting
from {answer_errors, report} config, and this has been slimmed.
|
|
* anders/diameter/rc_counters/OTP-11937:
Count encode errors in outgoing messages
Count decode errors in incoming requests
Count decode errors independently of result codes
|
|
* anders/diameter/rc_counters/OTP-11891:
Count result codes in CEA/DWA/DPA
|
|
Only decode errors were counted previously. Keys are of the form
{Id, send, error}, where Id is:
{ApplicationId, CommandCode, Rbit} | unknown
The latter will be the case if not even a #diameter_header{} can be
constructed.
|
|
Errors were only counted in incoming answers. Counters are keyed on
tuples of the same form:
{{ApplicationId, CommandCode, Rbit}, recv, error}
|
|
Since the former doesn't exclude the latter.
Counter values are returned by diameter:service_info/2. They can
currently only be retrieved for a service, not for individual transports
or peer connections.
|
|
Corresponding counters for other answer messages have been counted
previously, but those for CEA, DWA, and DPA have been missing since
diameter itself sends these messages and the implementation is as bit
more separate than it might be. The counters are keyed on values of the
following form.
{{ApplicationId, CommandCode, 0 = Rbit}, send|recv, {'Result-Code', RC}}
|
|
No longer needed to update code in runtime since the emulator is
restarted at a major release.
|
|
* anders/diameter/release/R16B01/OTP-11120:
vsn -> 1.4.2
Update appup for R16B01
Trailing whitespace and copyright fixes
Minor macro simplification
Move app/appsrc from src/base into src
|
|
That is, for the process that's spawned for each incoming Diameter
request message.
|
|
|
|
RFC 6733 says that certain 5xxx result codes must be accompanied by
Failed-AVP, and decode populates #diameter_packet.errors with
Result-Code/AVP pairs for errors it detects. However, Failed-AVP was not
set in the outgoing answer if the handle_request callback returned
{answer_message, 5xxx}. It is now set with the AVP from the first pair
with the specified Result-Code, if found.
Note that {answer_message, 5xxx} doesn't handle all cases in which a
5xxx answer is required, only that in which the setting above is
appropriate. If it isn't then handle_request should construct its answer
and return {reply, Ans}.
|
|
When setting these from an #diameter_packet.errors list, select one
Result-Code or {Result-Code, Failed-AVP}, instead of accumulating all
AVP's from the 2-tuples in the list. This is more in keeping with RFC
6733:
7.5. Failed-AVP AVP
The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides
debugging information in cases where a request is rejected or not
fully processed due to erroneous information in a specific AVP. The
value of the Result-Code AVP will provide information on the reason
for the Failed-AVP AVP. A Diameter answer message SHOULD contain an
instance of the Failed-AVP AVP that corresponds to the error
indicated by the Result-Code AVP. For practical purposes, this
Failed-AVP would typically refer to the first AVP processing error
that a Diameter node encounters.
The text of RFC 3588 was less specific, not including the last two
sentences.
Note that an improper AVP Length will result in both 5014 and 5005 being
detected for the same AVP. Without this commit, Failed-AVP would be
populated with two AVP's for the same error.
|
|
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.
|
|
When setting Failed-AVP in a message record, it was never tested that
the field was actually present. RFC 6733 says it should be, 3588 says
MAY.
|
|
This is the functionality that allows transports to be shared between
identically-named services on different nodes, which has been neither
documented nor tested (until now).
|
|
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.
|
|
In particular, don't put an error tuple in the errors field of
a #diameter_packet{} when Result-Code and the E-bit are in conflict, put
{integer(), #diameter_avp{}}.
|
|
When receiving a request for which errors have been detected during
decode, diameter previously used the errors list in the decoded
diameter_packet record to unconditionally set Result-Code and Failed-AVP
in the outgoing answer. It wasn't particularly delicate in doing so
however and would happily set a 5xxx Result-Code even if a
handle_request callback returned an answer-message, leading to an encode
error. This behaviour became even less endearing as of commit ac452e28,
which made it possible to handle_request to take place even for protocol
errors. (ie. When a callback typically should return an answer-message.)
This commit fixes the behaviour by only setting a value that's
appropriate for the answer in question, either a 3xxx or a 5xxx,
depending on if the answer's an answer-message or not. It also allows
handle_request to prevent diameter from setting anything by setting
errors = false in a returned diameter_packet. Ideally it should have
been errors = [] but the empty list is the default value for the errors
field and changing the default (ideally there shouldn't have been one)
would require recompilation of all modules including diameter.hrl:
choose the less attractive 'false' to avoid such backwards
incompatibility.
The request reception is also refactored somewhat to shorten some call
chains.
|
|
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.
|
|
The value determines whether or not an unexpected message length in the
header of an incoming messages causes the peer process to exit, the
message to be discarded or handled as usual. The latter may only be
appropriate for message-oriented transport (eg. SCTP) since
stream-oriented transport (eg. TCP) may not be able to recover the
message boundary once a length error has occurred.
|
|
|
|
Traffic handling is connected to the service implementation through the
pick_peer callback and failover but diameter_service was getting
unwieldy as home to both the service process and traffic handling.
|
