aboutsummaryrefslogtreecommitdiffstats
path: root/lib/diameter
AgeCommit message (Collapse)Author
2014-05-26Do best-effort decode of Failed-AVPAnders Svensson
Commit 4ce2d3a6 (diameter-1.4.2, OTP-11007) disabled the decode of values in Failed-AVP components since any error caused the decode of Failed-AVP itself to fail. This is less than useful since (1) we should be able to decode it given that we've sent it (modulo mangling on the way to the peer and back), and (2) it's not unheard of to examine Failed-AVP to see what the peer objected to. This commits adds a best-effort decode: decode if possible, otherwise not, using the same abuse of the process dictionary as commit bbdb027c.
2014-05-26Add a testcase that expects a decoded value in Failed-AVPAnders Svensson
This isn't currently the case, but soon will be.
2014-05-26Fix handling of AVP length errors (5014) in unknown AVPsAnders Svensson
Commit 4ce2d3a6 added the insertion of a single bit into binary AVP data to induce an encode error in the case of a header length that pointed past the available bytes: a 5014 = DIAMETER_INVALID_AVP_LENGTH error. Commit 838856b fixed this for stringish Diameter types, but both commits neglected the case in which the offending AVP isn't known to the dictionary in question. Unless the AVP was regarded as erroneous for other reasons (eg. an M-bit resulting in 5001) it would be happily be packed into an 'AVP' field. If it was regarded as an error, the record could be passed back to diameter_codec:pack_avp/1, and if the record contained header data then there was no clause to deal with the unpleasantry. Deal with it by having the dictionary module strip the extra bit and flag the AVP as 5014, and by having diameter_codec handle any extra bit coming from an dictionary compiled against an old diameter_gen. An old dictionary won't detect 5014 however, so dictionaries should be recompiled. Change most of the guards in diameter_codec from is_bitstring/1 to is_binary/1. What's being passed to the decode functions are binaries received other the network. The only case in which a non-binary bitstring is when we've placed an extra bit there ourselves. (Modulo someone doing something they shouldn't.)
2014-05-26Add testcases that send unknown AVPs with a bad AVP LengthAnders Svensson
In particular, a length that points past the end of the message. This goes undetected there is some other problem with the AVP (eg. M-bit), which is a problem we're about to fix.
2014-05-26Simplify example serverAnders Svensson
In particular, remove the unnecessary list-or-record answer.
2014-05-26Make example server answer unsupported requests with 3001Anders Svensson
As it should. The previous discard (surely) pre-dated being able to return {answer_message, 3001} from a handle_request callback.
2014-05-26Make example code quietAnders Svensson
The output could make it impossible to use the shell. Counters returned diameter:service_info/2 can be used to check for expected happenings.
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-25Merge branch 'anders/diameter/watchdog_leak/OTP-11934' into maintAnders Svensson
* anders/diameter/watchdog_leak/OTP-11934: Simplify sending of 'close' to watchdog Fix watchdog table leak
2014-05-25Merge branch 'anders/diameter/request_leak/OTP-11893' into maintAnders Svensson
* anders/diameter/request_leak/OTP-11893: Fix leaking request table Add check that request table is empty to failover suite Comment fix
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-05-20Simplify sending of 'close' to watchdogAnders Svensson
There's no need to send the message immediately if there's no transport configuration since that in itself means the service process will tell the watchdogs to die.
2014-05-20Fix watchdog table leakAnders Svensson
Commit ef5fddcb (diameter-1.4.1, R16B) caused the leak in the case of an accepting watchdog with restrict_connections = false. It (correctly) ensured the state remained at INITIAL but a subsequent 'close' message to terminate the process was ignored since the state was not DOWN. In fact, no 'close' was sent since there was no state transition or previous connection: the former triggers the message from diameter_service, the latter from diameter_watchdog. The message is now sent to self() from the watchdog itself. Send 'close' in the same way when multiple connections to the same peer are allowed, to avoid waiting for a watchdog timer expiry for the process to terminate in this case.
2014-05-18Fix leaking request tableAnders Svensson
A new connection writes the pid to the table diameter_request. The normal handling is that loss of a connection leads to a watchdog state change in the service process, which removes the entry, but this usually won't happen in the case of diameter:stop_service/1 since the service process is terminated without waiting for watchdog transitions. The request table should really be service-specific, so that the table is deleted when the service is stopped, which requires passing the table identifier into request processes and handling that the table may not exist. Just clear out the service-specific entries at service process termination for now.
2014-05-18Add check that request table is empty to failover suiteAnders Svensson
The way in which this suite causes transport connections to be broken - by stopping the service - makes it prone to orphaning entries in the request table, which is a bug we're about to fix.
2014-05-18Comment fixAnders Svensson
2014-04-07Update release notesErlang/OTP
2014-04-07Merge branch 'anders/diameter/17.0_release/OTP-11605'Anders Svensson
* anders/diameter/17.0_release/OTP-11605: Fix diameter.hrl comment typos
2014-04-07Fix diameter.hrl comment typosAnders Svensson
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.
2014-04-03Merge branch 'anders/diameter/17.0_release/OTP-11605'Anders Svensson
* anders/diameter/17.0_release/OTP-11605: Bring diameter_dbg into the present
2014-04-02Bring diameter_dbg into the presentAnders Svensson
The module is just a collection of functions for retrieving or printing information for the purpose of debugging. Various changes over several releases had broken the table-listing functions diameter_peer/0 and diameter_service/0. Add some minor tidying as well.
2014-04-01Merge branch 'anders/diameter/17.0_release/OTP-11825'Anders Svensson
* anders/diameter/17.0_release/OTP-11825: Simplify xref tests in app suite Add app suite test for app file runtime_dependencies Generate runtime_dependencies in app file Remove syntax_tools and runtime_tools from app file
2014-03-31Simplify xref tests in app suiteAnders Svensson
By examining which modules *use* runtime and compiler modules instead of which modules compiler modules call. Note that the semantics are changed somewhat: we will now fail if diameter modules are called from an application which diameter.app lists as a start dependency, which wasn't the case previously.
2014-03-31Add app suite test for app file runtime_dependenciesAnders Svensson
In particular, that modules listed in the 'modules' tuple only call modules in other applications listed in the 'runtime_dependencies' tuple.
2014-03-31Generate runtime_dependencies in app fileAnders Svensson
To avoid having to specify applications more than once.
2014-03-31Merge branch 'anders/diameter/unicode_path/OTP-11655'Anders Svensson
* anders/diameter/unicode_path/OTP-11655: Fix unicode path failure in diameter_make:codec/2
2014-03-31Merge branch 'anders/diameter/unicode/OTP-11686'Anders Svensson
* anders/diameter/unicode/OTP-11686: Use fun encoding to erl_parse:abstract/2 Adapt dictionary compilation to new default encoding
2014-03-31Merge branch 'anders/diameter/pick_peer/OTP-11789'Anders Svensson
* anders/diameter/pick_peer/OTP-11789: Fix pick_peer case clause failure
2014-03-30Remove syntax_tools and runtime_tools from app fileAnders Svensson
The former is used by the dictionary compiler, the latter by some unfinished code in diameter_dbg. None of the corresponding modules are included in the app file since they typically aren't needed/wanted on a target system.
2014-03-30Merge branch 'anders/diameter/17.0_release/OTP-11605'Anders Svensson
* anders/diameter/17.0_release/OTP-11605: Move info modules into own subdirectory Include compiler and info modules in app file Remove unused diameter_dbg:log/4 Remove case expecting a pre-R16B return value from os:type/1 Fix doc typo: required -> requires Remove release note unrelated to functionality
2014-03-29Move info modules into own subdirectoryAnders Svensson
Possibly overkill for two modules but it mirrors their different treatment by the makefile.
2014-03-29Include compiler and info modules in app fileAnders Svensson
Albeit as comments. This is just to make it more obvious that these aren't include in the modules list, since they typically aren't needed/wanted on a target system. Also add comments for the corresponding dependencies on syntax_tools and runtime_tools, as well as the optional runtime dependency on ssl.
2014-03-29Remove unused diameter_dbg:log/4Anders Svensson
It was intended to replace diameter_lib:log/4 at some point but that was a bad idea since diameter_dbg isn't included in the app file.
2014-03-29Remove case expecting a pre-R16B return value from os:type/1Anders Svensson
The documented return value changed in commit c37a9761.
2014-03-29Fix doc typo: required -> requiresAnders Svensson
2014-03-29Remove release note unrelated to functionalityAnders Svensson
2014-03-25Use fun encoding to erl_parse:abstract/2Anders Svensson
This is an encoding that didn't exist at the time of the previous commit, but which was added in commit 83b6daef. Use it to restrict stringification to lists containing printable ascii.
2014-03-21Adapt dictionary compilation to new default encodingAnders Svensson
The problem is that the change in default encoding to utf8 in 17.0, in commit 00e42967, changes the behaviour of erl_parse:abstract/1, which is used by the dictionary compiler to turn terms into abstract code. In particular, it transforms the orddict representation of a parsed dictionary to contruct the return value of a dictionary module's dict/0 function. This orddict contains various lists, one of which is a list of tuples of the form {Name, Code, [VendorId], [Avp]} where Name is an ASCII string and VendorId is a non-negative integer. Using erl_parse:abstract/2 instead allows a string encoding to be specified but regardless of what encoding is used, the result of transforming our tuple might not be what we really want, which is for Name to always be represented as a string form and [VendorId] to always be represented as a cons form: the [VendorId] will always end up as a string form if the integers are small enough. The only way around this is to transform the tuple bit by bit, but modifying the code to do this is quite a lot of work, for not much gain: it would be nice to produce more readable output but nothing stops working without it. This commit restores the pre-17.0 conversion by explicilty specifying latin1 as the string encoding to erl_parse:abstract/2. The utf8 encoding broke the compilation of some dictionares since unicode strings aren't expected when writing the generated code to file. Note that the latin1 encoding does reasonably well in practice, although it mangles the Ericsson Vendor Id list [193] into a "LATIN CAPITAL LETTER A WITH ACUTE". The utf8 encoding does worse, mangling the 3GPP Vendor Id 10415 into "DESERET CAPITAL LETTER CHEE". An ascii encoding would do better than latin1 but doesn't yet exist. (Encoding isn't really what the option is. It's a string predicate: if the predicate is true then represent as a string form, otherwise a cons form.)
2014-03-20Fix unicode path failure in diameter_make:codec/2Anders Svensson
A dictionary path containing a unicode codepoint > 255 caused the function to fail when iolist_to_binary/1 was applied to the path.
2014-03-20Fix pick_peer case clause failureAnders Svensson
In the case of {call_mutates_state, true} configuration on the service in question, any peer selection that failed to select a peer resulted in a case clause failure in diameter_service:pick_peer/5, when the call to the service process returned false. This was noticed in the case of a peer failover in which an alternate peer wasn't available. The explicit matching is intentional, to match exactly what's expected.
2014-03-20Introduce runtime_dependencies in .app filesRickard Green
Most dependencies introduced are exactly the dependencies to other applications found by xref. That is, there might be real dependencies missing. There might also be pure debug dependencies listed that probably should be removed. Each application has to be manually inspected in order to ensure that all real dependencies are listed. All dependencies introduced are to application versions used in OTP 17.0. This since the previously used version scheme wasn't designed for this, and in order to minimize the work of introducing the dependencies.
2014-03-17Remove "coding: utf-8" from test filesSiri Hansen
UTF-8 is now the default encoding and should no longer be specified. These have probably been merged from maint earlier and the coding statement was missed. lib/dialyzer/test/opaque_SUITE_data/src/modules/opaque_erl_scan.erl lib/diameter/test/diameter_codec_test.erl lib/ssh/test/ssh_unicode_SUITE.erl
2014-02-24Merge branch 'anders/diameter/grouped_decode/OTP-11675'Anders Svensson
* anders/diameter/grouped_decode/OTP-11675: Be lenient with the M-bit in Grouped AVPs
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.