aboutsummaryrefslogtreecommitdiffstats
path: root/lib/diameter/src/base/diameter_config.erl
AgeCommit message (Collapse)Author
2015-08-25Add service_opt() strict_mbitAnders Svensson
There are differing opinions on whether or not reception of an arbitrary AVP setting the M-bit is an error. 1.3.4 of RFC 6733 says this about how an existing Diameter application may be modified: o The M-bit allows the sender to indicate to the receiver whether or not understanding the semantics of an AVP and its content is mandatory. If the M-bit is set by the sender and the receiver does not understand the AVP or the values carried within that AVP, then a failure is generated (see Section 7). It is the decision of the protocol designer when to develop a new Diameter application rather than extending Diameter in other ways. However, a new Diameter application MUST be created when one or more of the following criteria are met: M-bit Setting An AVP with the M-bit in the MUST column of the AVP flag table is added to an existing Command/Application. An AVP with the M-bit in the MAY column of the AVP flag table is added to an existing Command/Application. The point here is presumably interoperability: that the command grammar should specify explicitly what mandatory AVPs much be understood, and that anything more is an error. On the other hand, 3.2 says thus about command grammars: avp-name = avp-spec / "AVP" ; The string "AVP" stands for *any* arbitrary AVP ; Name, not otherwise listed in that Command Code ; definition. The inclusion of this string ; is recommended for all CCFs to allow for ; extensibility. This renders 1.3.4 pointless unless "*any* AVP" is qualified by "not setting the M-bit", since the sender can effectively violate 1.3.4 without this necessitating an error at the receiver. If clients add arbitrary AVPs setting the M-bit then request handling becomes more implementation-dependent. The current interpretation in diameter is strict: if a command grammar doesn't explicitly allow an AVP setting the M-bit then reception of such an AVP is regarded as an error. The strict_mbit option now allows this behaviour to be changed, false turning all responsibility for the M-bit over to the user.
2015-08-05Simplify time manipulationAnders Svensson
By doing away with more wrapping that the parent commit started to remove.
2015-03-27Add service_opt() incoming_maxlenAnders Svensson
To bound the length of incoming messages that will be decoded. A message longer than the specified number of bytes is discarded. An incoming_maxlen_exceeded counter is incremented to make note of the occurrence. The motivation is to prevent a sufficiently malicious peer from generating significant load by sending long messages with many AVPs for diameter to decode. The 24-bit message length header accomodates (16#FFFFFF - 20) div 12 = 1398099 Unsigned32 AVPs for example, which the current record-valued decode is too slow with in practice. A bound of 16#FFFF bytes allows for 5461 small AVPs, which is probably more than enough for the majority of applications, but the default is the full 16#FFFFFF.
2015-03-26Add guard to reject {spawn_opt, false} as transport/service_opt()Anders Svensson
It was possible to configure the option, but doing so caused the service to fail when starting a watchdog process: {function_clause, [{diameter_service,'-spawn_opts/1-lc$^0/1-0-', [false], [{file,"base/diameter_service.erl"},{line,846}]}, {diameter_service,start,5, [{file,"base/diameter_service.erl"},{line,820}]}, {diameter_service,start,3, [{file,"base/diameter_service.erl"},{line,782}]}, {diameter_service,handle_call,3, [{file,"base/diameter_service.erl"},{line,385}]}, {gen_server,try_handle_call,4,[{file,"gen_server.erl"},{line,607}]}, {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,639}]}, {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,237}]}]} Tests for the option in the config suite were also missing. Bungled in commit 78b3dc6.
2015-03-24Merge branch 'anders/diameter/dpr/OTP-12609' into maintAnders Svensson
* anders/diameter/dpr/OTP-12609: Discard incoming/outgoing requests after incoming DPR Add transport_opt() dpr_timeout Be lenient with errors in incoming DPR
2015-03-24Merge branch 'anders/diameter/string_decode/OTP-11952' into maintAnders Svensson
* anders/diameter/string_decode/OTP-11952: Let examples override default service options Set {restrict_connections, false} in example server Set {string_decode, false} in examples Test {string_decode, false} in traffic suite Add service_opt() string_decode Strip potentially large terms when sending outgoing Diameter messages Improve language consistency in diameter(1)
2015-03-24Add service_opt() string_decodeAnders Svensson
To control whether stringish Diameter types are decoded to string or left as binary. The motivation is the same as in the parent commit: to avoid large strings being copied when incoming Diameter messages are passed between processes; or *if* in the case of messages destined for handle_request and handle_answer callbacks, since these are decoded in the dedicated processes that the callbacks take place in. It would be possible to do something about other messages without requiring an option, but disabling the decode is the most effective. The value is a boolean(), true being the default for backwards compatibility. Setting false causes both diameter_caps records and decoded messages to contain binary() in relevant places that previously had string(): diameter_app(3) callbacks need to be prepared for the change. The Diameter types affected are OctetString and the derived types that can contain arbitrarily large values: OctetString, UTF8String, DiameterIdentity, DiameterURI, IPFilterRule, and QoSFilterRule. Time and Address are unaffected. The DiameterURI decode has been redone using re(3), which both simplifies and does away with a vulnerability resulting from the conversion of arbitrary strings to atom. The solution continues the use and abuse of the process dictionary for encode/decode purposes, last seen in commit 0f9cdba.
2015-03-23Add transport_opt() dpr_timeoutAnders Svensson
To cause a peer connection to be closed following an outgoing DPA, in case the peer fails to do so. It is the recipient of DPA that should close the connection according to RFC 6733.
2015-03-23Merge branch 'anders/diameter/dpr/OTP-12542' into maintAnders Svensson
* anders/diameter/dpr/OTP-12542: Discard CER or DWR sent with diameter:call/4 Allow DPR to be sent with diameter:call/4 Add transport_opt() dpa_timeout Add testcase for sending DPR with diameter:call/4
2015-03-22Add transport_opt() dpa_timeoutAnders Svensson
To make the default DPA timeout configurable. The timeout say how many milliseconds to wait for DPA in response to an outgoing DPR before terminating the transport process regardless.
2015-02-20Use new time api in implementationAnders Svensson
In particular, deal with the deprecation of erlang:now/0 in OTP 18. Be backwards compatible with older releases: the new api is only used when available. The test suites have not been modified.
2015-02-20Add transport_opt() pool_sizeAnders Svensson
Transport processes are started by diameter one at a time. In the listening case, a transport process accepts a connection, tells the peer_fsm process, which tells its watchdog process, which tells its service process, which then starts a new watchdog, which starts a new peer_fsm, which starts a new transport process, which (finally) goes about accepting another connection. In other words, not particularly aggressive in accepting new connections. This behaviour doesn't do particularly well with a large number of concurrent connections: with TCP and 250 connecting peers we see connections being refused. This commit adds the possibilty of configuring a pool of accepting processes, by way of a new transport option, pool_size. Instead of diameter:add_transport/2 starting just a single process, it now starts the configured number, so that instead of a single process waiting for a connection there's now a pool. The option is even available for connecting processes, which provides an alternate to adding multiple transports when multiple connections to the same peer are required. In practice this also means configuring {restrict_connections, false}: this is not implicit. For backwards compatibility, the form of diameter:service_info(_,transport) differs in the connecting case, depending on whether or not pool_size is configured. Note that transport processes for the same transport_ref() can be started concurrently when pool_size > 1. This places additional requirements on diameter_{tcp,sctp}, that will be dealt with in a subsequent commit.
2014-05-27Change answer_errors default from report to discardAnders Svensson
In the same vein as commit 00584303, to avoid logging traffic-related happenings. Not that the value in diameter.hrl is just documentation: the value is set explicitly when diameter:start_service/2 creates diameter_app records.
2013-11-29Rename reconnect_timer -> connect_timerAnders Svensson
The former was misleading since the timer only applies to initial connection attempts, reconnection attempts being governed by watchdog_timer. The name is a historic remnant from a (dark, pre-OTP) time in which RFC 3539 was followed less slavishly than it is now, and the timer actually did apply to reconnection attempts. Note that connect_timer corresponds to RFC 6733 Tc, while watchdog_timer corresponds to RFC 3539 TwInit. The latter RFC makes clear that TwInit should apply to reconnection attempts. It's less clear if only RFC 6733 is read. Note also that reconnect_timer is still accepted for backwards compatibility. It would be possible to add an option to make reconnect_timer behave strictly as the name suggests (ie. ignore RFC 3539 and interpret RFC 6733 at face value; something that has some value for testing at least) but no such option is implemented in this commit.
2013-09-04Fix broken spawn_optAnders Svensson
The option was morphed into a boolean() and then ignored.
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-04-06Fix handling of unknown options to diameter:start_service/2Anders Svensson
{error, Reason} is now returned, instead of the options being ignored. Note that diameter:add_transport/2 purposely ignores unknown options and that the behaviour is documented. This is historic: some users depend on it in order to store their own options for identifying transport config, instead of using the reference returned by add_transport.
2013-03-26Fix faulty sequence validationAnders Svensson
The validation of {sequence, {H,N}} incorrectly checked that H was an N-bit integer, instead of the intended 32-N.
2013-03-26Move most transport_opt() validation into diameter_configAnders Svensson
Faulty configuration was previously passed directly on to watchdog and peer_fsm processes, diameter:add_transport/2 happily returning ok and the error resulting on failure of watchdog and/or peer_fsm processes. Now check for errors before getting this far, returning {error, Reason} from diameter:add_transport/2 when one is detected. There are still some errors that can only be detected after transport start (eg. a misbehaving callback) but most will be caught early.
2013-03-17More flexible distribution configAnders Svensson
Allow both share_peers and use_shared_peers to be a list of nodes, or a function that returns a list of nodes.
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-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-11-05Implement service_opt() restrict_connectionsAnders Svensson
2012-11-05Implement sequence masksAnders Svensson
Code should be loaded in this order: diameter_session (sequence/1) diameter_peer_fsm (calls to sequence/1) diameter_service (sequence config, mask in receive_message/3) diameter_watchdog (mask in peer start and receive_message/3) diameter_config (accept sequence config) Order of diameter and diameter_peer doesn't matter.
2012-09-25Fix matching in case of erroneous capabilities configAnders Svensson
{invalid, K, V} was never matched. Return full reason, not just an atom.
2012-08-28Merge branch 'anders/diameter/callback_isolation/OTP-10215' into maintAnders Svensson
* anders/diameter/callback_isolation/OTP-10215: Don't let peer_up/peer_down take down the service process Turn last field of #diameter_app{} into an options list
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.)
2012-08-24Statistics fixesAnders Svensson
Statistics are deleted as a consequence of diameter:remove_transport/2.
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-10-17One makefile for src build instead of recursionAnders Svensson
Simpler, no duplication of similar makefiles and makes for better dependencies. (Aka, recursive make considered harmful.)