| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* egil/maps/refactor-tagscheme/OTP-12585:
erts: Refactor Map - use multiple values ESTACK_PUSHN
erts: GC needs the size even if the frag is not referenced
Revert "hipe: Handle separate hashmap tag correctly"
erts: Combine flat and hash maps under one unifying tag
|
|
|
|
* peppe/common_test/failing_telnet_tests:
Add documentation and make get_data behaviour backwards compatible
Introduce polling feature in ct_telnet
Fix problem with invalid timeouts because of truncated floats
OTP-12627
|
|
|
|
* bjorn/doc:
cerl_trees: Fix incorrect EDoc reference to the cerl module
cerl: Correct incorrect EDoc references
|
|
* erland/OTP18/inets/time_api/OTP-12441:
inets: Add new module inets_time_compat with new time API The new module is backwards compatible.
|
|
* erland/ssh/OTP18/time_api/OTP-12444:
ssh: Use new time API
|
|
This reverts commit 4dc5f194b0a5a6f052763bb7494b0458f98d96ca.
|
|
|
|
The new module is backwards compatible.
|
|
|
|
|
|
|
|
Required load order by ticket.
- OTP-11492, answer messages discarded
- OTP-12415, retransmission failure
- OTP-12475, grouped AVP decode
- OTP-12543, no requests after DPR
none
- OTP-12412, shutdown issues
diameter_lib
diameter_service
- OTP-12428, transport_opt() pool_size
diameter_lib
diameter_service
diameter, diameter_config
diameter_{tcp,sctp}
diameter, diameter_config
- OTP-12439, new time api in Erlang/OTP 18
diameter_lib
diameter_{config,peer,reg,service,session,stats,sync,watchdog,sctp}
- OTP-11952, service_opt() decode_string
- OTP-12589, DiameterURI encode/decode
diameter_{capx,codec,peer}
diameter_types
diameter_traffic
diameter_{service,peer_fsm}
diameter_watchdog
diameter, diameter_config
- OTP-12542, DPR with diameter:call/4
diameter_{peer_fsm,watchdog}
diameter, diameter_config
- OTP-12609, transport_opt() dpr_timeout
diameter_peer_fsm
diameter, diameter_config
|
|
|
|
|
|
* anders/diameter/dpr/OTP-12609:
Discard incoming/outgoing requests after incoming DPR
Add transport_opt() dpr_timeout
Be lenient with errors in incoming DPR
|
|
Despite claims of full backwards compatibility, the text of RFC 6733
changes the interpretation of unspecified values in a DiameterURI. In
particular, 3588 says that the default port and transport are 3868 and
sctp respectively, while 6733 says it's either 3868/tcp (aaa) or
5658/tcp (aaas). The 3588 defaults were used regardless, but now use
them only if the common dictionary is diameter_gen_base_rfc3588. The
6733 defaults are used otherwise.
This kind of change in the standard can lead to interop problems, since
a node has to know which RFC its peer is following to know that it will
properly interpret missing URI components. Encode of a URI includes all
components to avoid such confusion.
That said, note that the defaults in the diameter_uri record have *not*
been changed. This avoids breaking code that depends on them, but the
risk is that such code sends inappropriate values. The record defaults
may be changed in a future release, to force values to be explicitly
specified.
|
|
Both RFC 3588 and 6733 disallow the combination. Make its encode fail.
|
|
* anders/diameter/string_decode/OTP-11952:
Let examples override default service options
Set {restrict_connections, false} in example server
Set {string_decode, false} in examples
Test {string_decode, false} in traffic suite
Add service_opt() string_decode
Strip potentially large terms when sending outgoing Diameter messages
Improve language consistency in diameter(1)
|
|
* anders/diameter/route_record/OTP-12551:
Fix ordering of AVPs in relayed messages
|
|
To make them a bit more flexible. Can now do things like this:
server:start([{'Product-Name', "Bob"}]),
server:listen({tcp, [{capx_timeout, 2000}]})
Beware that the latter is completely different from this:
server:listen(tcp, [{capx_timeout, 2000}])
|
|
Since there's no reason to reject a client that wants to establish
multiple connections, given that diameter can handle it.
|
|
So as to do what's now recommended in diameter(1), in the grandparent
commit.
|
|
By adding string decode or not in the server or client as another
combination. Run all traffic cases in parallel: remove the sequential
tests. Common test seems unable to deal with {group, X, [parallel]}
within a group.
|
|
To control whether stringish Diameter types are decoded to string or
left as binary. The motivation is the same as in the parent commit: to
avoid large strings being copied when incoming Diameter messages are
passed between processes; or *if* in the case of messages destined for
handle_request and handle_answer callbacks, since these are decoded in
the dedicated processes that the callbacks take place in. It would be
possible to do something about other messages without requiring an
option, but disabling the decode is the most effective.
The value is a boolean(), true being the default for backwards
compatibility. Setting false causes both diameter_caps records and
decoded messages to contain binary() in relevant places that previously
had string(): diameter_app(3) callbacks need to be prepared for the
change.
The Diameter types affected are OctetString and the derived types that
can contain arbitrarily large values: OctetString, UTF8String,
DiameterIdentity, DiameterURI, IPFilterRule, and QoSFilterRule. Time and
Address are unaffected.
The DiameterURI decode has been redone using re(3), which both
simplifies and does away with a vulnerability resulting from the
conversion of arbitrary strings to atom.
The solution continues the use and abuse of the process dictionary for
encode/decode purposes, last seen in commit 0f9cdba.
|
|
|
|
|
|
Both incoming and outgoing Diameter messages pass through two or three
processes, depending on whether they're incoming or outgoing: the
transport process and corresponding peer_fsm process and (for incoming)
watchdog processes. Since terms other than binary are copied when
passing process boundaries, large terms lead to copying that can be
problematic, if frequent enough. Since only the bin and transport_data
fields of a diameter_packet record are needed by the transport process,
discard others when sending outgoing messages.
Strictly speaking, the statement that only the aforementioned fields are
needed by the transport process depends on the transport process. It's
true of those implemented by diameter (in diameter_tcp and
diameter_sctp), but an implementation that makes use of other fields is
assuming more than the documentation in diameter_transport(3) promises.
|
|
|
|
Conflicts:
lib/ssh/test/ssh_basic_SUITE.erl
|
|
With the same motivation as in commits 5bd2d72 and b1fd629.
As in the latter, incoming DPR is the only exception.
|
|
To cause a peer connection to be closed following an outgoing DPA, in
case the peer fails to do so. It is the recipient of DPA that should
close the connection according to RFC 6733.
|
|
To avoid having the peer interpret the error as meaning the connection
shouldn't be closed, which probably does more harm than ignoring
syntactic errors in the DPR.
Note that RFC 6733 says this about incoming DPR, in 5.4 Disconnecting
Peer Connections:
Upon receipt of the message, the Disconnect-Peer-Answer message is
returned, which SHOULD contain an error if messages have recently been
forwarded, and are likely in flight, which would otherwise cause a race
condition.
The race here is presumably between answers to forwarded requests and
the outgoing DPA, but we have no handling for this: whether or not there
are pending answers is irrelevant to how DPR is answered. It's
questionable that a peer should be able to prevent disconnection in any
case: it has to be the node sending DPR that decides if it's approriate,
and the peer should take it as an indication of what's coming.
Incoming DPA is already treated leniently: the only error that's not
ignored is mismatching End-to-End and Hop-by-Hop Identifiers, since
there's no distinguishing an erroneous value from an unsolicited DPA.
This mismatch could also be ignored, which is the case for DWA for
example, but this problem is already dealt with by dpa_timeout, which
causes a connection to be closed even when the expected DPA isn't
received.
|
|
* anders/diameter/dpr/OTP-12542:
Discard CER or DWR sent with diameter:call/4
Allow DPR to be sent with diameter:call/4
Add transport_opt() dpa_timeout
Add testcase for sending DPR with diameter:call/4
|
|
* anders/diameter/dpr/OTP-12543:
Discard incoming requests after outgoing DPR
Discard outgoing requests after outgoing DPR
|
|
* erland/revert_time/OTP-12444:
Revert "Use new time API and be back-compatible in ssh"
|
|
* ia/ssl/dialyzer/alpn-and-crl:
ssl: Dialyzer fixes
|
|
|
|
6.1.9 of RFC 6733 states this:
A relay or proxy agent MUST append a Route-Record AVP to all requests
forwarded.
The AVP was inserted as the head of the AVP list, not appended, since
the entire AVP list was reversed relative to the received order.
Thanks to Andrzej Trawiński.
|
|
These are requests that diameter itself sends. It's previously been
possible to send them, but answers timed out at the caller since they
were discarded in diameter_watchdog. Answers will still timeout, but now
the requests are discarded before being sent.
|
|
DPR is sent by diameter at application shutdown, service stop, or
transport removal. It has been possible to send the request with
diameter:call/4, but the answer was discarded, instead of the transport
process being terminated. This commit causes DPR to be handled in the
same way regardless of whether it's sent by diameter or by
diameter:call/4.
Note that the behaviour subsequent to DPA is unchanged. In particular,
in the connecting case, the closed connection will be reestablished
after a connect_timer expiry unless the transport is removed. The more
probable use case is the listening case, to disconnect a single peer
associated with a listening transport.
|
|
To make the default DPA timeout configurable. The timeout say how many
milliseconds to wait for DPA in response to an outgoing DPR before
terminating the transport process regardless.
|
|
That currently fails when the resulting DPA is regarded as unsolicited
in diameter_peer_fsm, causing the request to timeout at the caller.
|
|
Since there's a race between an answer being sent and the connection
being closed upon the reception of DPA that's likely to be lost, and
because of the questionability of sending messages after DPR, as
discussed in the parent commit. An exception is made for DPR so that
simultaneous DPR in both directions doesn't result in it being discarded
on both ends.
|
|
RFC 6733 isn't terribly clear about what should happen to incoming or
outgoing messages once DPR is sent and the Peer State Machine
transitions into state Closing. There's no event for this in section
5.6, Peer State Machine, and no clarification in section 5.4,
Disconnecting Peer Connections. There is a little bit of discussion in
2.1.1, SCTP Guidelines, in relation to unordered message delivery, but
the tone there is that messages might be received after DPR because of
unordered delivery, not because they were actually sent after DPR.
Discarding outgoing answers may do more harm than good, but requests are
more likely to be unexpected, as has been seen to be the case with DWR
following DPR. DPR indicates a desire to close the connection: discard
any subsequent outgoing requests.
|
|
|
|
* anders/diameter/17/time/OTP-12439:
Adapt app suite to changes in time api
|
|
* anders/diameter/time/OTP-12439:
Adapt to changes in time api
|
