aboutsummaryrefslogtreecommitdiffstats
path: root/lib/diameter/src/base/diameter_traffic.erl
AgeCommit message (Collapse)Author
2015-03-05Merge branch 'anders/diameter/retransmission/OTP-12415' into maintAnders Svensson
* anders/diameter/retransmission/OTP-12415: Fix retransmission of messages sent as header/avps list
2015-02-25Don't discard outgoing answers with Result-Code/E-bit errorsAnders Svensson
Outgoing answers missing a Result-Code AVP or setting an E-bit inappropriately were discarded, but there's no particular reason for doing so if the answer can be encoded, and the sender has no way of knowing that their answer has been discarded. It's also inappropriate that the message be discarded in the relay case. Answers are now sent, and an error counter incremented.
2015-01-19Fix retransmission of messages sent as header/avps listAnders Svensson
Extracting the End-to-End and Hop-by-Hop identifiers resulted in a function clause error, causing the send to fail.
2014-12-01Merge branch 'anders/diameter/3xxx/OTP-12233' into maintAnders Svensson
* anders/diameter/3xxx/OTP-12233: Fix handling of 3xxx Result-Code without E-bit
2014-10-10Fix handling of 3xxx Result-Code without E-bitAnders Svensson
Commit 00584303 broke the population of the errors field of the diameter_packet record when an incoming request with an E-bit/Result-Code mismatch was decoded. Instead of the intended {5004, #diameter_avp{value = integer()}}, the value was a 4-tuple containing the integer Result-Code.
2014-09-25Fix remote diameter_request table leakAnders Svensson
An outgoing request whose pick_peer callback selected a transport on another node resulted in an orphaned diameter_request entry on that node.
2014-09-08Fix best effort decode of Failed-AVPAnders Svensson
Commit c2c00fdd didn't get it quite right: it only decoded failed AVPs in the common dictionary since it's this dictionary an answer-message is decoded in. An extra dictionary isn't something that's easily passed through the decode without rewriting dictionary compilation however, and that's no small job, so continue with the use/abuse of the process dictionary by storing the dictionary module for the decode to retrieve. This is one step worse than previous uses since the dictionary is put in one module (diameter_codec) and got in another (the dictionary module), but it's the lesser of two evils.
2014-09-08Fix counters for answer-messageAnders Svensson
An answer message that sets the E-bit is encoded/decoded with Diameter common dictionary, using the answer-message grammar specified in the RFC. However, the dictionary of the application in question is the one that knows the command code of the message. Commit df19c272 didn't make this distinction when incrementing counters for an answer-message, using the common dictionary for both purposes, causing the message to be counted as unknown. This commit remedies that.
2014-08-05Count relayed messages on {relay, Rbit}Anders Svensson
Instead of grouping them with 'unknown'. These messages were keyed on {ApplicationId, CommandCode, Rbit} prior to commit df19c272, but distinguishing between the relay application and others is probably more useful. The only reason for not including the R-bit in the unknown key is that the key is also used elsewhere, and relay is an expected case while unknown isn't.
2014-08-05Count request retransmissionsAnders Svensson
As mentioned in the parent commit. The {Id, send, retransmission} key is of the same form as the {Id, send|recv, error} key used for encode/decode errors.
2014-08-05Fix counting of outgoing requestsAnders Svensson
Commit df19c272 broke this in avoiding counting on arbitrary keys. It didn't break it sufficiently for the only counters usage in the test suites to fail however: watchdog counters worked as intended, but no others, not even CER and DPR. More testcases are needed. This commit does change/fix the previous semantics somewhat: - Retransmissions are no longer counted. This previously made it impossible to distinguish between these and unanswered requests, since both counted as an outgoing request. There should probably be a retransmission counter but it should be distinct from the sent request counter. - The counting is always on the node from which diameter:call/4 is invoked, not the node on which the transport resides, as was previously the case. (Although they're typically one and the same.) Note that none of these semantics are documented as yet, so we're not changing a documented interface.
2014-05-26Don't count messages on arbitrary keysAnders Svensson
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.
2014-05-26Replace traffic-related log reports with no-op function callsAnders Svensson
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.
2014-05-25Merge branch 'anders/diameter/rc_counters/OTP-11937' into maintAnders Svensson
* 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
2014-05-25Merge branch 'anders/diameter/rc_counters/OTP-11891' into maintAnders Svensson
* anders/diameter/rc_counters/OTP-11891: Count result codes in CEA/DWA/DPA
2014-05-23Count encode errors in outgoing messagesAnders Svensson
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.
2014-05-22Count decode errors in incoming requestsAnders Svensson
Errors were only counted in incoming answers. Counters are keyed on tuples of the same form: {{ApplicationId, CommandCode, Rbit}, recv, error}
2014-05-22Count decode errors independently of result codesAnders Svensson
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.
2014-05-21Count result codes in CEA/DWA/DPAAnders Svensson
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}}
2014-01-27Remove upgrade-related codeAnders Svensson
No longer needed to update code in runtime since the emulator is restarted at a major release.
2013-06-11Merge branch 'anders/diameter/release/R16B01/OTP-11120' into maintAnders Svensson
* 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
2013-06-10Make spawn options for request processes configurableAnders Svensson
That is, for the process that's spawned for each incoming Diameter request message.
2013-06-10Trailing whitespace and copyright fixesAnders Svensson
2013-06-02Fix setting of Failed-AVP on {answer_message, 5xxx} from handle_requestAnders Svensson
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}.
2013-05-17Adapt Failed-AVP setting to RFC 6733Anders Svensson
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.
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-05-03Ensure setting Failed-AVP is appropriateAnders Svensson
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.
2013-03-17Distribution fixesAnders Svensson
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).
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-16Comments and minor Result-Code fixAnders Svensson
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{}}.
2013-02-16Be less brutal in setting Result-Code/Failed-AVPAnders Svensson
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.
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-11Add transport_opt() length_errorsAnders Svensson
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.
2013-02-08Remove trailing whitespaceAnders Svensson
2013-02-08Split message handling in diameter_service into diameter_trafficAnders Svensson
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.