| Age | Commit message (Collapse) | Author |
|---|
|
Introduced in commit ed6395a6. The {stream, Id} transport_data set upon
reception is passed back to us by default when receiving the answer to a
request message, so even capabilities exchange failed.
|
|
OTP-10229 (commit c4592b69) added these function to give access to all
addresses on a multihomed endpoint, their singular siblings not
returning anything useful in this case.
This fixes {accept, Match} config, which matches peer addresses against
configured addresses or regexps to decide whether or not a newly
established association should be retained. The functionality was added
in OTP-10893 (commit 9bbf27eb) but predated OTP-10229 by a few months.
It also fixes the addresses shown for SCTP associations in
diameter:service_info/2 output.
|
|
* anders/diameter/17.0_release/OTP-11605:
vsn -> 1.6
Remove upgrade-related code
Update appup for 17.0
Avoid type gen_sctp:open_option() until it actually exists
|
|
No longer needed to update code in runtime since the emulator is
restarted at a major release.
|
|
The type's existence is the subject of OTP-11139, which has been
gathering dust since R16B.
http://erlang.org/pipermail/erlang-bugs/2013-September/003765.html
|
|
The module uses the transport_data field of record diameter_packet to
communicate the stream on which the an incoming message is received and
on which an outgoing message should be sent, the previous interface
being that both are communicated as a tuple of the form {stream, Id}.
However, since diameter retains the value of an incoming request's
transport_data unless the corresponding answer message specifies
otherwise, the behaviour in this case is to send an answer on the
outbound stream with the same identifier as the that of the inbound
stream on which the request was received. If the inbound stream id is
greater than or equal to the number of outbound streams then this is
guaranteed to fail, causing the transport process in question to
terminate. There is no relationship between inbound and outbound stream
identifiers so diameter_sctp's imposition of one is simply wrong.
Outbound stream ids are now communicated with a different tuple:
{outstream, Id}, interpreted modulo the number of outbound streams.
Thus, retention of an inbound request's transport_data has no effect on
the selection of an outbound stream.
The change in interface is not strictly backwards compatible because of
the new atom for the outbound stream. However, as there is currently no
documented way of obtaining the available number of outbound streams for
a peer connection, there is no way for a client to have known the range
of ids from which it could reliably have chosen with the previous
interface, so any setting of the outbound stream has probably been
unintentional. Not explicitly specifying an outbound stream now results
in a round-robin selection.
|
|
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.
|
|
The third argument to start/3 was just wrong.
|
|
|
|
Use the default address address (as selected by gen_tcp) if none is
configured, passing it in the new 'connected' message introduced by the
previous commit.
The corresponding update to diameter_sctp has to wait until problems
with inet:sockname/1 are resolved: the function currently only returns
one address, and sometimes {0,0,0,0}. See OTP-11018.
|
|
|
|
Don't start a new timer with each incoming message. Instead, start a
timer at timeout and flush after two successive timeouts with no message
reception.
|
|
|
|
Which will be the case in R16B.
|
|
|
|
Which will be the case with R16B in this case.
|
|
|
|
|
|
* anders/diameter/R15B02_release:
Dialyzer spec fix
Learn to keep time in diameter_gen_sctp_SUITE
Update command line test for changed ct:run_test/1 return value
OTP-10243
|
|
|
|
* anders/diameter/sctp_peeloff/OTP-9611:
Use gen_sctp:peeloff/2 to transfer association ownership
|
|
To be used by diameter_service in constructing service_info.
|
|
The transport process is now controlling process even in the
accept case.
|
|
Module contains a transport start function that calls an a
specified function, and more.
|
|
It isn't always the case. The information isn't currently used in
any case.
|
|
Simpler, no duplication of similar makefiles and makes for
better dependencies. (Aka, recursive make considered harmful.)
|
|
|
|
|
|
This is the method added in draft-ietf-dime-rfc3588bis, whereby
a TLS handshake immediately follows connection establishment and
CER/CEA is sent over the secured connection.
|
|
RFC 3588 requires that a Diameter server support TLS but in
practise this seems to mean TLS over SCTP since there are limitations
with running over SCTP: see RFC 6083 (DTLS over SCTP), which is a
response to RFC 3436 (TLS over SCTP). The current RFC 3588 draft
acknowledges this by equating the Inband-Security-Id value TLS
with TLS/TCP and DTLS/SCTP but underlying support for DTLS is
still thin on the ground.
|
|
If TLS has been configured on Inband-Security-Id then the transport
process receives a message from the peer_fsm process indicating
whether or not to upgrade to TLS.
The current draft of RFC 3588 deprecates (but retains for backwards
compatibility) the use of Inband-Security-Id for negotiating TLS,
adding the possibility of TLS having be negotiated before capabilities
exchange. This commit handles the deprecated case.
|
|
When an initial message is received and TLS is a possibility, must
wait for a message from the peer process before either commencing
a handshake or receiving more messages.
|
|
The events are enabled by default but diameter_sctp neither disabled
nor dealt with them. Reception of such an event caused a transport
process to crash.
|
|
|
|
The application provides an implementation of the Diameter protocol
as defined in RFC 3588.
|
