| Age | Commit message (Collapse) | Author |
|---|
|
* anders/diameter/capx_dictionary/OTP-11361:
Don't hardcode diameter_base @prefix on common dictionary
|
|
|
|
anders/diameter/patch_release/OTP-11459
* anders/diameter/5014_failure/OTP-11395:
Fix handling of 5014, DIAMETER_INVALID_AVP_LENGTH
|
|
The error was detected as 5004 (DIAMETER_INVALID_AVP_VALUE) for
stringish Diameter types, in which case an AVP length that pointed past
the end of a message resulted in encode failure of the suggested
Failed-AVP.
Should have been fixed in commit 4ce2d3a6.
|
|
Commit e762d7d1 broke outgoing DWA by setting new Hop-by-Hop and
End-to-End identifiers instead of those of the incoming DWR.
|
|
* anders/diameter/spawn_opt/OTP-11299:
Fix broken spawn_opt
|
|
* anders/diameter/failed_avp/OTP-11293:
Fix Failed-AVP construction for CEA/DWA/DPA
|
|
Send of Failed-AVP resulted in encode failure.
|
|
The option was morphed into a boolean() and then ignored.
|
|
By using binary comprehensions. Add string-valued addresses to codec
suite.
|
|
The original code predates that module but there's no reason not to use
it now.
|
|
To accept any nested list of codepoints and binaries. A list containing
a binary was previously misinterpreted and the documentation was
incomplete.
Also, rework codec suite slightly to be able to specify values for which
decode o encode is the identity map, for which encode should succeed,
and for which encode should fail.
|
|
Having the peer_fsm process answer DWR meant that watchdog timer expiry
could result in an outgoing DWR despite the fact that an incoming DWR
was just answered. Having the watchdog process answer avoids this.
diameter_peer_fsm must be loaded before diameter_watchdog. It's
possible for one incoming DWR to go unanswered but a subsequent DWR will
be answered so no harm is done.
|
|
Commit f0a36c79 broke the handling of such configuration, resulting in a
function clause error in diameter_capx if the list was not of length 3,
and faulty extraction of application id's otherwise. Only record-valued
config was properly interpreted.
|
|
* anders/diameter/release/R16B01/OTP-11120:
vsn -> 1.4.2
Update appup for R16B01
Trailing whitespace and copyright fixes
Minor macro simplification
Move app/appsrc from src/base into src
|
|
* anders/diameter/request_spawn/OTP-11060:
Make spawn options for request processes configurable
|
|
That is, for the process that's spawned for each incoming Diameter
request message.
|
|
Option 'accept' allows remote addresses to be configured as tuples or
regular expressions. The remote addresses for any incoming (aka
accepted) connection/association are matched against the configured
values, any non-matching address causing the connection/association to
be aborted.
|
|
|
|
|
|
|
|
* anders/diameter/one_failed_avp/OTP-11127:
Adapt CEA/DPA Failed-AVP to RFC 6733
|
|
* anders/diameter/5xxx_failed_avp/OTP-11092:
Fix setting of Failed-AVP on {answer_message, 5xxx} from handle_request
|
|
RFC 6733 says that certain 5xxx result codes must be accompanied by
Failed-AVP, and decode populates #diameter_packet.errors with
Result-Code/AVP pairs for errors it detects. However, Failed-AVP was not
set in the outgoing answer if the handle_request callback returned
{answer_message, 5xxx}. It is now set with the AVP from the first pair
with the specified Result-Code, if found.
Note that {answer_message, 5xxx} doesn't handle all cases in which a
5xxx answer is required, only that in which the setting above is
appropriate. If it isn't then handle_request should construct its answer
and return {reply, Ans}.
|
|
* anders/diameter/host_ip_address/OTP-11045:
Respect Host-IP-Address configuration
|
|
Addresses returned from a transport module were always used to populate
Host-IP-Address AVP's in an outgoing CER/CEA, which precluded the
sending of a VIP address. Transport addresses are now only used if
Host-IP-Address is unspecified.
In other words, respect any configured Host-IP-Address, regardless of
the physical addresses returned by the transport. To use the physical
addresses, don't configure Host-IP-Address.
|
|
By setting only one, not many. The handling for other messages (except
DWA, which is forgiving of errors) was dealt with in commit f7ec93e3.
|
|
RFC 6733 recommends against the use of Inband-Security-Id, so only send
a value that differs from the default.
|
|
* anders/diameter/watchdog_function_clause/OTP-11115:
Fix watchdog function_clause
|
|
Commit 0b7c87dc caused diameter_watchdog:restart/2 to start returning
'stop', so that a watchdog process for a listening transport that
allowed multiple connections to the same peer would die one watchdog
timeout after losing a connection. The new return value was supposed to
be passed up to transition/2, but was instead passed to set_watchdog/1,
resulting in a function_clause error. The resulting crash was harmless
but unseemly.
Not detected by dialyzer.
Thanks to Aleksander Nycz.
|
|
When setting these from an #diameter_packet.errors list, select one
Result-Code or {Result-Code, Failed-AVP}, instead of accumulating all
AVP's from the 2-tuples in the list. This is more in keeping with RFC
6733:
7.5. Failed-AVP AVP
The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides
debugging information in cases where a request is rejected or not
fully processed due to erroneous information in a specific AVP. The
value of the Result-Code AVP will provide information on the reason
for the Failed-AVP AVP. A Diameter answer message SHOULD contain an
instance of the Failed-AVP AVP that corresponds to the error
indicated by the Result-Code AVP. For practical purposes, this
Failed-AVP would typically refer to the first AVP processing error
that a Diameter node encounters.
The text of RFC 3588 was less specific, not including the last two
sentences.
Note that an improper AVP Length will result in both 5014 and 5005 being
detected for the same AVP. Without this commit, Failed-AVP would be
populated with two AVP's for the same error.
|
|
|
|
Invalid lengths come in two flavours: ones that correctly point at the
end of an AVP's payload but don't agree with its type, and ones that
point elsewhere. The former are relatively harmless but the latter leave
no way to recover AVP boundaries, which typically results in failure to
decode subsequent AVP's in the message in question.
In the case that AVP Length points past the end of the message, diameter
incorrectly regarded the error as 5009, INVALID_AVP_BITS: not right
since the error has nothing to do with AVP Flags. Ditto if the length
was less than 8, a minimal header length. Only in the remaining case was
the detected error 5014, INVALID_AVP_LENGTH. However, in this case it
slavishly followed RFC 3588 in suggesting the undecodable AVP as
Failed-AVP, thereby passing the woeful payload back to the sender to
have equal difficulty decoding. Now follow RFC 6733 and suggest an AVP
with a zero-filled payload.
|
|
When setting Failed-AVP in a message record, it was never tested that
the field was actually present. RFC 6733 says it should be, 3588 says
MAY.
|
|
Such a length caused decode of a message with valid (24-bit) length to
fail. Note that the error detected is wrong: it should be 5014
(INVALID_AVP_LENGTH), not 3009 (INVALID_AVP_BITS). This will be dealt
with by OTP-11007.
|
|
* anders/diameter/watchdog_leak/OTP-11019:
Minor doc fix
Add testcase to exercise reconnect behaviour
Fix watchdog table leak
|
|
A transport module can return a local address list from its start/3
function in order to specify addresses to be used as Host-IP-Address
during capabilities exchange. Now allow addresses to be communicated in
a 'connected' message in the case of a connecting transport, so that
diameter_tcp (in particular) can make local address configuration
optional, communicating the gen_tcp default after connection
establishment instead.
|
|
A service process maintains a table keyed on watchdog process pids. When
a watchdog process dies the corresponding entry should be removed but
this was broken in commit f115a9f7, causing entries with watchdog state
DOWN to accumulate.
Watchdog processes die as a result of diameter:remove_transport/2, or
when a peer reestablishes a connection in the listening case. Neither is
typically a frequent occurrence.
The fault manifests itself in the return value of
diameter:service_info(SvcName, transport), which displays entries for
watchdog processes that are no longer alive.
|
|
{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.
|
|
The validation of {sequence, {H,N}} incorrectly checked that H was an
N-bit integer, instead of the intended 32-N.
|
|
Crashing watchdog and peer_fsm processes was somewhat unseemly. Emit an
error report and die silently instead.
|
|
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.
|
|
'infinity' is a valid transport_config timeout.
|
|
Remove unused functions, add dialyzer specs, make wait/1 less fallible.
|
|
|
|
|
|
RFC 6733 has changed the arity of Vendor-Id in this Grouped AVP, from 1*
in RFC 3588 to 1 in RFC 6773. This impacts the generated dictionary
modules: Vendor-Id is expected to be list-valued in the 3588 dictionary,
integer-valued in the 6733 dictionary. This, in turn, breaks the
independence of capabilities configuration on a service or transport
from the dictionary that will be used to encode an outgoing CER or CEA.
This commit fixes this by massaging any Vendor-Specific-Application-Id
config as appropriate when constructing CER or CEA for a given
dictionary.
|
|
|
|
Allow both share_peers and use_shared_peers to be a list of nodes, or a
function that returns a list of nodes.
|
|
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).
|
