| Age | Commit message (Collapse) | Author |
|---|
|
To upgrade a connection to TLS or not, that is the question. It
is possible for us to send a CER offering both NO_INBAND_SECURITY
and TLS and for the peer to answer likewise: RFC 3588 doesn't make
clear that a CEA should be unambiguous about the choice of security.
Thus, if TLS is offered then assume the server is prepared to
for a handshake. Similarly, when receiving a CER, choose TLS if
it's offered and be unambiguous about our choice in CEA. There is
no ssl:maybe_accept that would let us receive a handshake if it
comes or another message if it doesn't.
The choice of TLS should probably be made into a callback so that
an application can decide based on the peer's Origin-Realm for
example. Such a callback could also be used to reject a CER/CEA.
Handle Inband-Security-Id values other than NO_INBAND_SECURITY and
TLS by assuming that they require no intervention by the transport
module, treating them like NO_INBAND_SECURITY. Whether or not this
is reasonable (or useful) is unclear. There may be a need for more
sychronization than we have on offer. (Having to do something before
taking the connection up for example.)
Note that diameter_peer_fsm must be upgraded before diameter_capx
because of the new return value from diameter_capx:recv_CEA/2.
|
|
Conflicts:
lib/diameter/src/app/Makefile
|
|
|
|
|
|
|
|
|
|
* anders/diameter/send_anything/OTP-9581:
Fix sending of messages of arbitrary form
|
|
* anders/diameter/relay_behaviour/OTP-9583:
Fix and clarify relay behaviour
|
|
* anders/diameter/peer_filters/OTP-9580:
Fix and clarify semantics of peer filters
|
|
* anders/diameter/logging/OTP-9579:
Makefile dependency fix
Remove duplicate info from error report at encode failure
Use single format for error_logger reports
Fix improper use of error_logger:info_report/2
|
|
* anders/diameter/header_folding_error/OTP-9577:
Fix header folding bug
|
|
3001 (DIAMETER_COMMAND_UNSUPPORTED) was not sent since the decode
placed the AVP list in the errors field rather than the avps field
of the diameter_packet, causing the subsequent encode to fail.
Session-Id was also set improperly, causing encode to fail even
in this case.
|
|
Leave it up to a handle_request callback to decide whether or
not to filter the peer from which the incoming request was sent.
Reply with 3002 (DIAMETER_UNABLE_TO_DELIVER) on anything but an
answer from the peer.
|
|
Dependency of generated dictionary modules on diameter.hrl
and diameter_gen.hrl was missed.
|
|
|
|
diameter:call/4 can be passed anything, as long as the subsequent
prepare_request callback returns a term that can be encoded.
|
|
An eval filter returning a non-true value caused the call process
to fail and the doc was vague on how an exception was treated.
Clarify that the non-tuple host/realm filters assume messages of
a certain form. Various minor corrections to align code and doc.
|
|
Function doesn't take a format string and arguments as we called it.
Instead use error_logger:info_report/1 and use the same report format
as used for warning and error reports.
|
|
A prepare_request callback from diameter can return a diameter_header
record with in order to set values in the header of an outgoing
request. The fault in diameter_lib:fold_tuple/3 caused encode of
the outgoing request to fail.
|
|
|
|
|
|
plus an example fix.
|
|
|
|
The application provides an implementation of the Diameter protocol
as defined in RFC 3588.
|
