Age | Commit message (Collapse) | Author |
|
The decode of an incoming request in a non-relay application results in
a deep list of diameter_avp records. Encoding such a list resulted in a
function_clause error in diameter_codec:pack_avp/1, which expected a
flat list. The list is only flat in the relay case, or in the absence of
AVPs of type Grouped.
This is also related to code that exists but isn't documented. It's
documented that a diameter_app(3) handle_request callback can return
{relay, Opts} to relay a request received in the relay application.
What's not documented is that it can also return {proxy|resend, Opts} in
a non-relay application, but this leads to encode failure when there are
Grouped AVPs. This shouldn't be interpreted as meaning that proxy|resend
are now supported: they aren't. The two extra terms are a historical
relic that should probably be removed. Neither are generally usable
since, for example, a proxy agent may want to modify a request before
resending it. A specific handle_request return is not needed to
implement a proxy agent. Even {relay, Opts} isn't strictly necessary.
|
|
|
|
The decode of a Grouped AVP ignored the case that extracting component
AVPs with diameter_codec:collect_avps/1 returned a tuple, in the case of
a truncated AVP header.
|
|
The AVPs of an incoming Diameter message diameter_codec:decode/2,3 are
decoded into a diameter_packet record in two ways: as a message-specific
record in the 'msg' field and as a deep list of diameter_avp records in
the 'avps' field. The record decode came first; the diameter_avp decode
came later to support the Diameter relay application, but can also be
convenient for non-relay applications. The diameter_avp representation
can be used with outgoing messages, but what exactly is supported for
isn't clearly documented.
In the diameter_avp list representation, it's AVPs of type Grouped that
lead to nesting: instead of a diameter_avp record, a Grouped AVP is
represented by a diameter_avp list whose head is the Grouped AVP itself,
and whose tail is the list of component AVPs.
The diameter_avp decode was broken in the case of decode errors: the
Grouped AVP was represented as a bare diameter_avp, and the component
records were lost. The decode now produces the intended list. Note that
component AVPs that could not be decoded will have 'undefined' in their
data field.
|
|
Decode can span multiple codec modules, so written entries cannot be
tagged on ?MODULE.
|
|
|
|
|
|
OTP-12196 remote request table leak
OTP-12233 3xxx result code without E-bit
OTP-12281 ignored connect_timer
OTP-12308 filter ordering
|
|
* anders/diameter/filters/OTP-12308:
Order peers in pick_peer callbacks
|
|
* anders/diameter/connect_timer/OTP-12281:
Tweak reason in closed event
Fix ignored connect timer
Check {connect,watchdog}_timer distinction in event testcases
Rename reconnect_timer to connect_timer in examples and suites
|
|
* anders/diameter/3xxx/OTP-12233:
Fix handling of 3xxx Result-Code without E-bit
|
|
The order of peers presented to a diameter_app(3) pick_peer callback has
previously not been documented, but there are use cases that are
simplified by an ordering. For example, consider preferring a direct
connection to a specified Destination-Host/Realm to any host in the
realm. The implementation previously treated this as a special case by
placing matching hosts at the head of the peers list, but the
documentation made no guarantees. Now present peers in match-order, so
that the desired sorting is the result of the following filter.
{any, [{all, [host, realm]}, realm]}
The implementation is not backwards compatible in the sense that a realm
filter alone is no longer equivalent in this case. However, as stated,
the documentation never made any guarantees regarding the sorting.
|
|
From {error, Reason} to {no_connection, Reason} when a connection can't
be established. The exit reason of a diameter_peer_fsm process is turned
into a message from the corresponding diameter_watchdog process to the
relevant diameter_service process, the latter sending a 'closed' event
including the reason to any subscribers. Reason = [] when none of the
configured transport modules succeeds in establishing a connection,
which admittedly isn't terribly descriptive. (The lists is of error
reasons from transport start functions, which is empty as long as
transport processes start successfully.)
Note that this form of the closed event is undocumented, aside from the
documentation saying that one should expect undocumented events. The
explicitly documented forms are currently specific to CER/CEA failures.
|
|
There are two timers governing the establishment of peer connections:
connect_timer and watchdog_timer. The former is the RFC 6733 Tc timer
and is used by diameter_service to establish an initial connection. The
latter is RFC 3539 TwInit and is used by diameter_watchdog for
connection reestablishment after the watchdog leaves state INITIAL. A
connecting transport ignored the connect timer since the watchdog
process never died, regardless of the watchdog state, causing the
watchdog timer to handle reconnection.
This seems to have been broken for some time.
|
|
The connect timer is currently ignored by a connecting transport,
so the check causes one testcase to fail.
|
|
The timer was renamed in commit abea7186.
|
|
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.
|
|
An outgoing request whose pick_peer callback selected a transport on
another node resulted in an orphaned diameter_request entry on that
node.
|
|
|
|
* anders/diameter/17.3_release/OTP-12093:
Add recompilation admonition to 17.2 release notes
|
|
* anders/diameter/Failed-AVP/OTP-12094:
Fix ?MODULE in preprocessed dictionary forms
|
|
That dictionaries need to be recompiled, which is the case whenever
diameter_gen.hrl is modified.
|
|
By replacing literal diameter_gen_relay atoms in forms extracted from
that module by the name of the module in question. This has been wrong
for some time, but only became noticable when the parent commit started
using ?MODULE as more than a process dictionary key or tag to match on.
In particular, the function dict/1 in diameter_gen.hrl (included by
every dictionary module) can now return ?MODULE, which is (not
surprisingly) expected to be the name of the dictionary module in
question. It wasn't in the case of a module compiled from forms: it was
diameter_gen_relay, since that's the module the forms were extracted
from.
The fix only affects dictionaries compiled from forms, as returned by
diameter_make:codec/2. In particular, dictionaries compiled from Erlang
source returned by this function, or by diameterc(1), are unaffected.
|
|
* anders/diameter/17.3_release/OTP-12093:
vsn -> 1.7.1
Update appup for OTP-12094
Update appup for OTP-12080
Update appup for OTP-12069
|
|
* anders/diameter/5014/OTP-12074:
Don't leave extra bit in decoded AVP data
|
|
* anders/diameter/Failed-AVP/OTP-12094:
Fix best effort decode of Failed-AVP
Fix decode of Failed-AVP in RFC 3588 answer-message
|
|
* anders/diameter/counters/OTP-12080:
Fix counters for answer-message
Count relayed messages on {relay, Rbit}
Count request retransmissions
Fix counting of outgoing requests
|
|
The bit is added in diameter_codec to induce a decode error in the case
of 5014 errors, but was not removed before returning the decoded result.
Code examining the binary data in a diameter_avp record would then see
the extra bit.
|
|
|
|
diameter_codec must be loaded before diameter_traffic.
|
|
|
|
|
|
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.
|
|
Commit 066544fa had the unintended consequence of breaking the decode of
Failed-AVP in answer-message as defined in the RFC 3588, since the
grammar doesn't list Failed-AVP as an explicit component AVP, in
contrast to the RFC 6733 grammar, which does. Handle this case
explicitly, as an exception, just as with Failed-AVP as parent AVP.
|
|
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.
|
|
That is, instead of including the list in a diameter:service_info/2 info
tuple, only include the number of references and the number of bytes
referenced. The list itself can be quite large and typically isn't that
interesting, at least not to a diameter user.
|
|
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.
|
|
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.
|
|
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.
|
|
To extract only process info from connections info, which can be useful
to reduce the amount of information returned.
Choose 'info' for the item since process_info is more than one word: all
others are one. Don't choose memory since it's too specific: might want
to use it for more.
|
|
To show process_info of interest. This is not yet documented since it
may well change.
|
|
To return sizes of named ets tables.
|
|
|
|
|
|
|
|
* anders/diameter/dictionaries/OTP-11958:
Fix broken check for undefined AVPs in @codec and @custom_types
Add @codecs and @custom_types tests to compiler suite
|
|
Instead of detecting the error, code generation failed when attempting
to lookup the type of an undefined AVP.
|
|
Dictionary compilation fails to detect undefined AVPs in these sections.
|
|
* anders/diameter/17.1/OTP-11943:
Update appup for OTP-11946, OTP-11936: 5014, Failed-AVP decode
Update appup for OTP-11938: terminate watchdog after DPR reception
Update appup for OTP-11721: log and counter hardening
Update appup for OTP-11937: counters
Update appup for OTP-11901: diameter_sctp function_clause
Update appup for OTP-11934: watchdog process leak
Update appup for OTP-11893: request table leak
Update appup for OTP-11891: result code counters for CEA/DWA/DPA
vsn -> 1.7
Fix broken release note for diameter-1.4.4
|
|
* anders/diameter/hardening/OTP-11721:
Change answer_errors default from report to discard
|