| Age | Commit message (Collapse) | Author |
|---|
|
* rickard/erts-print/17/OTP-13150:
Remove ERTS_PRINT_INVALID from erts_print()
|
|
ERTS_PRINT_INVALID prevented file descriptor 0 to be used which
could cause an empty crash dump.
|
|
|
|
|
|
* ia/ssl/maint-17/backport-of-18-fix:
ssl: Prepare for release
ssl: Do not crash on proprietary hash_sign algorithms
|
|
* raimo/inet-setopts-multi-raw/OTP-11482:
Update appup
Testcase for inet:setopts/2 multiple raw options
Fix inet:setopts/2 to take multiple raw options
Fix error propagate from setopts
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* sverk/trace-process_dump-matchstate-17/OTP-12968:
erts: Add testcase for tracing whith 'process_dump'
erts: Fix bug when tracing with 'process_dump'
|
|
* dgud/debugger/fix-case-clause/OTP-12911:
debugger: Fix broken debugger:quick/3 start
|
|
Commit 4f365c07 introduced the error on set_watchdog/2, as a consequence
of timeout/1 returning stop, which only happens with accepting
transports with {restrict_connections, false}.
|
|
of a process with a matchstate on the stack.
|
|
If the process stack contained a match state
the print function would crash the vm as it was not
recognized by tag_val_def().
Add new MATCHSTATE_DEF returned by tag_val_def().
All other callers either ignore it or has a default
clause to handle invalid terms.
|
|
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.
|
|
Too much code was removed in commit 560f73141af
|
|
|
|
|
|
* anders/diameter/17.5.6.3/OTP-12927:
vsn -> 1.9.2.1
Update appup for 17.5.6.3
|
|
* anders/diameter/17/time/OTP-12926:
Simplify time manipulation
Remove use of monotonic time in pre-18 code
Remove unnecessary redefinition of erlang:max/2
|
|
* anders/diameter/grouped_errors/OTP-12930:
Fix decode of Grouped AVPs containing errors
Simplify logic
Simplify logic
|
|
* anders/diameter/transport/OTP-12929:
Fix start order of alternate transports
Log discarded answers
|
|
* anders/diameter/lcnt/OTP-12912:
Make ets diameter_stats a set
Remove unnecessary sorting in stats suite
Set ets {write_concurrency, true} on diameter_stats
Don't start watchdog timers unnecessarily
Remove unnecessary erlang:monitor/2 qualification
Add missing watchdog suite clause
|
|
* anders/diameter/caseless/OTP-12902:
Match allowable peer addresses case insensitively
Replace calls to module inet_parse to equivalents in inet
|
|
* anders/diameter/grouped_decode/OTP-12879:
Fix relay encode of decoded diameter_avp lists
|
|
* anders/diameter/decode/OTP-12891:
Don't compute AVP list length unnecessarily at AVP decode
|
|
* anders/diameter/decode/OTP-12871:
Don't traverse errors list unnecessarily when detecting missing AVPs
Don't flag AVP as missing as a consequence of decode error
Correct inaccurate doc
Truncate potentially large terms passed to diameter_lib:log/4
|
|
There's no need for it to be ordered, and the ordering has been seen to
have an unexpectedly negative impact on performance in some cases. Order
when retrieving statistics instead, so as not to change the
presentation in diameter:service_info/2.
|
|
The ordering of (ets) diameter_stats (also unnecessary) ensures the
sorting.
|
|
By doing away with more wrapping that the parent commit started to
remove.
|
|
This has been seen to be a bottleneck at high load: each undef results
in a loop out to the code server.
Originally implemented as suggested in the erts user's guide, in commits
e6d19a18 and d4386254.
|
|
|
|
OTP-12871: 5005 decode
OTP-12791: decode performance
OTP-12879: grouped decode
OTP-12902: caseless address match
OTP-12912: fewer timers
OTP-12926: pre-18 time
diameter_lib must be loaded after modules calling its time-related
functions (that have been removed).
|
|
A transport configured with diameter:add_transport/2 can be passed
multiple transport_module/transport_config tuples in order to specify
alternate configuration, modules being attempted in order until one
succeeds. This is primarily for the connecting case, to allow a
transport to be configured to first attempt connection over SCTP, and
then TCP in case SCTP fails, with configuration like that documented:
{transport_module, diameter_sctp},
{transport_config, [...], 5000},
{transport_module, diameter_tcp},
{transport_config, [...]}
If the options are the same in both cases, another possibility would be
configuration like this, which attaches the same transport_config to
both modules:
{transport_module, diameter_sctp},
{transport_module, diameter_tcp},
{transport_config, [...], 5000},
However, in this case the start order was reversed relative to the
documented order: first tcp, then sctp. This commit restores the
intended order.
|
|
To diameter_lib:log/4, which was last motivated in commit 39acfdb0.
|
|
The function already operates on arbitrary terms.
|
|
Commit c74b593a fixed the problem that a decoded deep diameter_avp list
couldn't be encoded, but did so in the wrong way: there's no need to
reencode component AVPs since the Grouped AVP itself already contains
the encoded binary. The blunder caused diameter_codec:pack_avp/1 to fail
if the first element of the AVP list to be encoded was itself a list.
Thanks to Andrzej Trawiński for reporting the problem.
|
|
Both diameter_tcp and diameter_sctp can be configured with one or more
IP addresses from which connections should be accepted (an 'accept'
tuple), specified either as a tuple-valued address or as a regular
expression. In the latter case, peer addresses are mapped to string
using inet:ntoa/1 and the result matched against the regexp. Since
(ipv6) addresses are case insensitive, this should also be the case with
the match, but was not.
|
|
Commits b563c796 (R16B) and 0fad6449 (R16B02) added parse_address/1 and
ntoa/1 to module inet, providing documented alternatives to address/1
and ntoa/1 in the undocumented (save comments in inet(3)) inet_parse.
|
|
This has had a hugely negative impact on performance when decoding
messages containing many AVP: each decode of an AVP having variable
arity computed the length of the list of previously decoded AVPs when
checking that the allowed arity was not exceeded, even if the allowed
arity was infinite, making for O(n^2) cost. Here are some execution
times, for diameter_codec:decode/2 on a representative message with n
integer AVPs in the Common application (on the host at hand):
Before After
------- ---------
n = 1K 5 ms 2 ms
n = 10K 500 ms 25 ms
n = 100K 75 sec 225 ms
n = 1M 2.6 sec
Note the nearly linear increase following the change.
Remove the dire documentation warning for incoming_maxlen as a
consequence. It can still be useful to set, but not doing so won't have
the same consequences as previously.
|
|
Since the list can potentially be long.
|
|
The decode of an incoming Diameter message uses the record
representation to determine whether or not an AVP has been received with
the expected arity, the number of AVPs in each field following decode
being compared with the arity specified in the message grammar. The
problem with this is that decode failure isn't reflected in the record
representation, so that an AVP can be appended to the errors field of a
diameter_packet record despite an entry for the same AVP already
existing. This isn't a fault as much as a misleading error indication,
but now only append AVPs that aren't already represented.
|
|
The warning report was removed in commit 00584303.
|
|
Last visited in commit 00584303.
|
|
lcnt:inspect/1 recently showed this:
lock id #tries collisions [%] time [us]
----- --- ------- --------------- ----------
db_tab diameter_stats 932920 92.9326 330332554
|
|
TLS hash_sign algorithms may have proprietary values see
http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
We should add callbacks to let applications handle them.
But for now we do not want to crash if they are present and
let other algorithms be negotiated.
|
