| Age | Commit message (Collapse) | Author |
|---|
|
* anders/diameter/dpr/OTP-11938:
Ensure watchdog dies with transport if DPA was sent
|
|
* anders/diameter/rc_counters/OTP-11937:
Count encode errors in outgoing messages
Count decode errors in incoming requests
Count decode errors independently of result codes
|
|
* anders/diameter/rc_counters/OTP-11891:
Count result codes in CEA/DWA/DPA
|
|
A DPR/DPA exchange should always cause the watchdog process in question
to die with the transport, so that a subsequent connection with the same
peer doesn't result in a 3 x DWR/DWA exchange. Commit 5903d6db saw to
this for the sending of DPR but neglected the corresponding problem for
DPA.
In the case of sending DPR (the aforementioned commit), note that
there's no distinction between receiving DPA as expected and not: the
watchdog dies with the transport regardless.
diameter_watchdog must be loaded first at upgrade.
|
|
Only decode errors were counted previously. Keys are of the form
{Id, send, error}, where Id is:
{ApplicationId, CommandCode, Rbit} | unknown
The latter will be the case if not even a #diameter_header{} can be
constructed.
|
|
Errors were only counted in incoming answers. Counters are keyed on
tuples of the same form:
{{ApplicationId, CommandCode, Rbit}, recv, error}
|
|
Corresponding counters for other answer messages have been counted
previously, but those for CEA, DWA, and DPA have been missing since
diameter itself sends these messages and the implementation is as bit
more separate than it might be. The counters are keyed on values of the
following form.
{{ApplicationId, CommandCode, 0 = Rbit}, send|recv, {'Result-Code', RC}}
|
|
No longer needed to update code in runtime since the emulator is
restarted at a major release.
|
|
* anders/diameter/failed_avp/OTP-11293:
Fix Failed-AVP construction for CEA/DWA/DPA
|
|
Send of Failed-AVP resulted in encode failure.
|
|
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.
|
|
* anders/diameter/one_failed_avp/OTP-11127:
Adapt CEA/DPA Failed-AVP to RFC 6733
|
|
* 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.
|
|
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.
|
|
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.
|
|
The value determines whether or not an unexpected message length in the
header of an incoming messages causes the peer process to exit, the
message to be discarded or handled as usual. The latter may only be
appropriate for message-oriented transport (eg. SCTP) since
stream-oriented transport (eg. TCP) may not be able to recover the
message boundary once a length error has occurred.
|
|
|
|
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).
|
|
There is no such transition in RFC 3539, the state remains in INITIAL.
|
|
This was the result of the watchdog process exiting as a consequence of
peer death in some casesi, causing a restarted transport to enter
INITIAL when it should enter REOPEN. The watchdog now remains alive as
long as peer shutdown isn't requested and a 'close' message to the
service process (instead of watchdog death) generates 'closed' events
from the service.
|
|
Service process informs the watchdog process which informs the peer
process. (Instead of going directly to the latter in one case.)
|
|
|
|
|
|
|
|
|
|
|
|
Long dead.
|
|
|
|
The guard is against a connection to a given peer already existing but
fails if diameter is not running on a remote node.
Note that the guard itself is to be made configurable in R15B03
(OTP-10493) to allow multiple connections per peer.
|
|
|
|
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.
|
|
* anders/diameter/statistics/OTP-9608:
Improve statistics test cases
Statistics fixes
|
|
* anders/diameter/capabilities_encode/OTP-10203:
Deal with the fact that capabilities config may be incomplete
|
|
|
|
|
|
Statistics are deleted as a consequence of diameter:remove_transport/2.
|
|
A transport can be configured before its service so handle
insufficient configuration instead of crashing at CER/CEA encode.
|
|
Transports are started one after the other if a connection is
not established with the timeout that can now be specified
with transport_config. For example, try an SCTP connect first,
a TCP connect if it doesn't succeed.
|
|
|
|
|
|
If a peer fsm process exits then the exit reason is received by
the service process in a 'DOWN' message. If the reason is the one
generated by diameter_peer_fsm:close/2, which is called to signal
a non-transport failure before the completion of capabilities exchange
(eg. receiving an unsuccessful CEA), then an event is sent to any
subscribers.
Also, tweak capabilities_cb return values for more informative
event data.
|
|
Value is a function that's applied to the transport reference
and capabilities record after capabilities exchange. If a callback
returns anything but 'ok' then the connection is closed. In the case
of an incoming CER, the callback can return a result code with which
to answer. Multiple callbacks can be specified and are applied until
either all return 'ok' or one doesn't.
Also, include Origin-State-Id in answers where it was previously
omitted.
|
|
We're already monitoring the transport process, no need to do
so again.
|
|
Simpler, no duplication of similar makefiles and makes for
better dependencies. (Aka, recursive make considered harmful.)
|
