| Age | Commit message (Collapse) | Author |
|---|
|
After DPR, the intention is that outgoing answers are sent and outgoing
requests are discarded. This was the case when the DPR was outgoing, but
if it was incoming then a subsequent outgoing request resulted in a
function_clause, bringing down the diameter_peer_fsm gen_server
associated with the transport connection in question.
With diameter_tcp/sctp, the failure can result in the connection being
reset before the peer closes it in response to DPA, but is otherwise
harmless since DPR means that the connection is already on its way down.
|
|
|
|
|
|
* anders/diameter/20.3/OTP-14946:
vsn -> 2.1.4
Update appup for 20.3
Update service_info examples in doc
Fix inaccurate comment
|
|
* anders/diameter/terminate/ERIERL-124:
Fix handling of SUSPECT connections at service termination
|
|
A peer_fsm process can be started long before a connection is
established in the listening case. The time reported in a 'peer' tuple
in service_info is of connection establishment.
|
|
A peer connection in watchdog state SUSPECT is represented by a peer
table entry in diameter_service, but not by a request table entry in
diameter_peer, so diameter_service:terminate/2 could result in failures
like this:
exception error: no match of right hand side value []
in function diameter_traffic:peer_down/1 (base/diameter_traffic.erl, line 141)
in call from lists:foldl/3 (lists.erl, line 1263)
in call from ets:do_foldl/4 (ets.erl, line 611)
in call from ets:foldl/3 (ets.erl, line 600)
in call from diameter_service:terminate/2 (base/diameter_service.erl, line 557)
in call from gen_server:try_terminate/3 (gen_server.erl, line 648)
in call from gen_server:terminate/10 (gen_server.erl, line 833)
in call from gen_server:handle_msg/6 (gen_server.erl, line 679)
|
|
Commit fae8ca0c broke notification by removing table elements before
matching for them, causing diameter_tcp/sctp listening processes to
live on after diameter:remove_transport/2.
Commit 58091992 added diameter_reg:subscribe/2, and commit 5ca5fb71
started using it for listener exit.
|
|
The options map wasn't updated after the AVP was identified, with
the resulting consequences for M-bit interpretation.
|
|
Which may have been used in the past, but aren't now.
|
|
The wrong variable was passed into the decode recursion, causing the
options map to be contaminated by strict_mbit and failed_avp
modifications that should only apply to component AVPs in the Grouped
case. Decode errors and M-bits could be ignored as a result.
|
|
|
|
Commit fae8ca0c inadvertently removed the monitor at add/1 and
add_new/1. As a result, process death did not remove associations,
causing table diameter_reg to leak entries and stop/start of a service
to fail.
Add a testcase to detect the problem, which existing testcases miss.
|
|
* anders/diameter/performance/OTP-14521:
Fix append of Route-Record AVPs
|
|
Commit b3d9e0c0 did away with the reordering of diameter_avp lists, so
prepending the AVP to the list means prepending it in the message, which
is not what the RFC requires.
Appending to a list isn't ideal, but right now there's no better way.
|
|
* anders/diameter/grouped_decode/OTP-14607:
Fix diameter_packet.avps decode of Grouped AVP errors in Failed-AVP
|
|
* anders/diameter/DOIC/OTP-14588:
Fix avp_dictionaries decode with {decode_format, none}
|
|
The decode didn't respect the format as a list of diameter_avp records,
so information about faulty component AVPs was lost.
|
|
Decode is only a no-op when the AVP is Grouped, and then only on the
Grouped AVP itself, not its components.
|
|
* anders/diameter/config_consistency/OTP-14555:
Fix type spec
Fix strict_arities blunder
|
|
* anders/diameter/performance/OTP-14521:
Simplify implementation in diameter_reg (take 2)
|
|
Map key was not retained when the spec was added in commit 66bb5251.
|
|
The watchdog process retained the configuration, causing DWR/DWA encode
to fail on a string-valued Origin-Host/Realm if the encode arity was
relaxed.
Bungled in commit 5f3becad.
|
|
Simplify the simplification. The order of sending is changed, but the
order isn't significant.
|
|
* anders/diameter/performance/OTP-14521:
Simplify implementation in diameter_reg
Fix type spec
Fix minor monitor blunder in diameter_reg
|
|
Use maps instead of dict for traceability more than performance.
|
|
That dialyzer hasn't noticed is wrong.
|
|
* anders/diameter/DOIC/OTP-14588:
Exercise avp_dictionaries in traffic suite
Let generic AVPs be encoded/decoded in alternate dictionaries
Rename field in codec map: dictionary -> app_dictionary
Add RFC 7683 Diameter Overload Indicator Conveyance text and dictionary
Fix decode undef
Fix dictionary compilation error message
|
|
Commit 58091992 discarded a new monitor reference, so didn't avoid
multiple monitors as was the intention. The blunder was harmless since
all but the first DOWN message resulted in notifications.
|
|
To support specifications like RFC 7683 DOIC, that only define AVPs, not
applications. AVPs that aren't known to the application dictionary in
question could previously not be decoded. Configuring alternate
dictionaries with the new transport/service option avp_dictionaries
changes this, so that AVPs like DOIC's Grouped OC-OLR can presented in
their fully decoded glory. Encode is also extended, allowing things like
the following to be encoded in an outgoing message:
'AVP' => [{'OC-OLR', #{'OC-Sequence-Number' => 1,
'OC-Report-Type' => 0,
'OC-Reduction-Percentage' => [25]}}]
A diameter_gen_doic_rfc7683 dictionary is installed, but
avp_dictionaries isn't specific to DOIC.
This commit also solves the problem demonstrated a few commits back,
that application AVPs aren't decoded in answers setting the E-bit. Test
coverage will come in a subsequent commit.
|
|
To better reflect what the field is: field 'module' is the dictionary
module that's calling diameter_gen to decode a list of AVP, while field
'app_dictionary' is the dictionary module defining the message being
decoded.
|
|
Function avp/5 isn't exported from dictionary modules. Not necessarily
intentional, but don't just export it since that requires recompilation
of all dictionary modules, since the function is in diameter_gen.hrl.
Not having to recompile was the main motivation for moving most of the
included code to module diameter_gen in commit 205521d3.
This reveals a weakness in the decode of answers setting the E-bit: any
AVP that isn't defined by the common application won't be decoded; the
diameter_avp records that these are packed into (in the 'AVP' field of a
message record, or equivalent) will have value = undefined. This is
nothing new (same in OTP 19), but the values should be decoded. Fix it
(and the lack of test coverage) in a subsequent commit that will add
avp_dictionaries config.
|
|
* anders/diameter/decode_format/OTP-14511:
Map less in traffic suite
Fix decode_format doc oversights
Rename decode_format false to none
Tweak {decode_format, false} semantics
Fix dialyzer spec
|
|
* anders/diameter/config_consistency/OTP-14555:
Fix strict_arities blunder
Fix minor error-handling blunder
|
|
* anders/diameter/Proxy-Info/OTP-9869:
Fix handling of Proxy-Info in answers formulated by diameter
|
|
* anders/diameter/Experimental-Result/OTP-14511:
Fix extraction of Experimental-Result for counter keys
|
|
* anders/diameter/performance/OTP-14521:
Rename variable
Fix decode of too many generic AVPs
Enumerate AVPs in diameter_avp.index (again)
|
|
Which reads better and makes it easier to distinguish this false from
others.
|
|
Represent the decoded message by its atom-valued name in
diameter_packet.msg, which makes trace much more readable. A
diameter_avp.value is untouched (ie. undefined): the AVP name is already
in the name field.
|
|
Which dialyzer hasn't noticed.
|
|
anders/diameter/decode_format/OTP-14511
* anders/diameter/config_consistency/OTP-14555:
Fix strict_arities blunder
Fix minor error-handling blunder
Let strict_mbit and incoming_maxlen be configured per transport
Let a service configure default transport options
Rename type evaluable -> eval
Document transport_opt() strict_capx
Rename transport_opt() capx_strictness to strict_capx
|
|
Remove value from the merged map, not from the maps being merged.
Bundled in commit 5f3becad.
|
|
Leading to this admonition from dialyzer:
diameter_config.erl:670: The variable No can never match since previous
clauses completely covered the type 'ok'
The throw was caught, but resulted in an error return without the
intended information.
|
|
RFC 6733 says this:
6.2. Diameter Answer Processing
When a request is locally processed, the following procedures MUST be
applied to create the associated answer, in addition to any
additional procedures that MAY be discussed in the Diameter
application defining the command:
...
o Any Proxy-Info AVPs in the request MUST be added to the answer
message, in the same order they were present in the request.
This wasn't done when a handle_request callback returned a Result-Code
in an 'answer-message' or protocol_error tuple, causing diameter itself
to construct the answer message. This form of answer is just a
convenience, since the callback can always return an answer that it
constructs itself.
|
|
The introduction of decode_format in commit 722fa415 (and then 55e65b26)
meant the value was not necessarily the intended tuple.
|
|
It's no longer the AVP name as of the parent commit, but the name of
the field/member the value will be stored in. Typically the AVP name,
but possibly 'AVP'.
|
|
That is, when the arity of an 'AVP' field has an upper bound. This
shouldn't happen in practice, but if an AVP is known but its name not
explicit in the message grammar then its count was confused with that
of AVPs packed into the 'AVP' field.
|
|
Commit 96cd627a changed the way the index field was used, but the
enumeration is used in at least one known application (as a pointer from
elements of diameter_packet.errors to elements of diameter_packet.avps)
and the motivation for the change is questionable: the lookup that was
avoided was unnecessary given that it was already performed in
incrementing a counter. Revert to enumerating as before in the non-relay
case, but not in the relay case since there's no corresponding usecase.
|
|
* anders/diameter/config_consistency/OTP-14555:
Let strict_mbit and incoming_maxlen be configured per transport
Let a service configure default transport options
Rename type evaluable -> eval
|
|
* anders/diameter/upgrade/OTP-14552:
Fix compatibility of remote send
|
