| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Has to follow the release_targets include for make not to
think that a misspelled dictionary is up to date just because
the exprecs dependency is.
|
|
Generated files are unchanged but the separation will be
especially pleasant when more dictionary files are added
as examples. It is still only the rfc3588 and relay
dictionaries that are known to the diameter implementation.
|
|
|
|
The section simply results in generated macros and has nothing
specifically to do with result codes. It's still not documented,
and neither are the macros generated from @enum, since the generated
names are typically so long as to be impractical/unreadable in source.
Better to use numeric values with a comment or define your own
shorter macros as the need arises.
|
|
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.
|
