| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
* anders/diameter/one_failed_avp/OTP-11127:
Adapt CEA/DPA Failed-AVP to RFC 6733
|
|
* anders/diameter/5xxx_failed_avp/OTP-11092:
Fix setting of Failed-AVP on {answer_message, 5xxx} from handle_request
|
|
RFC 6733 says that certain 5xxx result codes must be accompanied by
Failed-AVP, and decode populates #diameter_packet.errors with
Result-Code/AVP pairs for errors it detects. However, Failed-AVP was not
set in the outgoing answer if the handle_request callback returned
{answer_message, 5xxx}. It is now set with the AVP from the first pair
with the specified Result-Code, if found.
Note that {answer_message, 5xxx} doesn't handle all cases in which a
5xxx answer is required, only that in which the setting above is
appropriate. If it isn't then handle_request should construct its answer
and return {reply, Ans}.
|
|
* 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.
|
|
* anders/diameter/watchdog_function_clause/OTP-11115:
Fix watchdog function_clause
|
|
* anders/diameter/missed_5001/OTP-11087:
Remove redundant integer type specifiers from binaries
Fix recognition of 5001 on mandatory AVP's
|
|
* anders/diameter/avp_decode/OTP-11007:
Detect all 5005 (MISSING_AVP) errors and don't reverse errors
Adapt Failed-AVP setting to RFC 6733
Add spec to diameter_codec
Add spec to diameter_gen
Fix recognition of 5014 (INVALID_AVP_LENGTH) errors
Ensure setting Failed-AVP is appropriate
Correct AVP Length error testcases
|
|
* anders/diameter/avp_length_failure/OTP-11026:
Fix decode failure when AVP Length < 8
|
|
|
|
An AVP setting the M-bit was not regarded as erroneous if it was defined
in the dictionary in question and its container (message or Grouped AVP)
had an 'AVP' field. It's now regarded as a 5001 error (AVP_UNSUPPORTED),
as in the case that the AVP is not defined.
|
|
* anders/diameter/timetraps/OTP-10914:
Add examples testcase to help identify timetrap failures
Minor traffic suite fix
Add gen_tcp suite
Lighten up on suite timetraps
Add more information to traffic suite timeout failures
|
|
Commit 0b7c87dc caused diameter_watchdog:restart/2 to start returning
'stop', so that a watchdog process for a listening transport that
allowed multiple connections to the same peer would die one watchdog
timeout after losing a connection. The new return value was supposed to
be passed up to transition/2, but was instead passed to set_watchdog/1,
resulting in a function_clause error. The resulting crash was harmless
but unseemly.
Not detected by dialyzer.
Thanks to Aleksander Nycz.
|
|
The previous commit ensures that only one will be reported in an answer
message when diameter itself sets Result-Code/Failed-AVP.
The order of errors in #diameter_packet.errors is that in which they're
detected, not the reverse as previously.
|
|
When setting these from an #diameter_packet.errors list, select one
Result-Code or {Result-Code, Failed-AVP}, instead of accumulating all
AVP's from the 2-tuples in the list. This is more in keeping with RFC
6733:
7.5. Failed-AVP AVP
The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides
debugging information in cases where a request is rejected or not
fully processed due to erroneous information in a specific AVP. The
value of the Result-Code AVP will provide information on the reason
for the Failed-AVP AVP. A Diameter answer message SHOULD contain an
instance of the Failed-AVP AVP that corresponds to the error
indicated by the Result-Code AVP. For practical purposes, this
Failed-AVP would typically refer to the first AVP processing error
that a Diameter node encounters.
The text of RFC 3588 was less specific, not including the last two
sentences.
Note that an improper AVP Length will result in both 5014 and 5005 being
detected for the same AVP. Without this commit, Failed-AVP would be
populated with two AVP's for the same error.
|
|
|
|
|
|
Invalid lengths come in two flavours: ones that correctly point at the
end of an AVP's payload but don't agree with its type, and ones that
point elsewhere. The former are relatively harmless but the latter leave
no way to recover AVP boundaries, which typically results in failure to
decode subsequent AVP's in the message in question.
In the case that AVP Length points past the end of the message, diameter
incorrectly regarded the error as 5009, INVALID_AVP_BITS: not right
since the error has nothing to do with AVP Flags. Ditto if the length
was less than 8, a minimal header length. Only in the remaining case was
the detected error 5014, INVALID_AVP_LENGTH. However, in this case it
slavishly followed RFC 3588 in suggesting the undecodable AVP as
Failed-AVP, thereby passing the woeful payload back to the sender to
have equal difficulty decoding. Now follow RFC 6733 and suggest an AVP
with a zero-filled payload.
|
|
When setting Failed-AVP in a message record, it was never tested that
the field was actually present. RFC 6733 says it should be, 3588 says
MAY.
|
|
To return what RFC 6733 says. 3588 says less so follow 6733, even
though the extra specification of 6733 means that it isn't strictly
backwards compatible. In particular, 6733 says to send a zero'd payload
or none at all while 3588 says to send the offending AVP, despite the
fact that the peer will likely have equal difficulty in decoding it.
The testcases now fail, which will be remedied in subsequent commits.
|
|
There are still enslave/1 failures on some hosts despite a 2 minute
timetrap.
|
|
Such a length caused decode of a message with valid (24-bit) length to
fail. Note that the error detected is wrong: it should be 5014
(INVALID_AVP_LENGTH), not 3009 (INVALID_AVP_BITS). This will be dealt
with by OTP-11007.
|
|
Creating examples/code and examples/dict in parallel can fail when
examples doesn't exists. This has been seen on FreeBSD.
|
|
Point was to test that Session-Id was not undefined. Instead, test case
send_error just returned false.
|
|
This is initially to identify the source of some flakiness on Windows.
|
|
Due to sporadic timeouts one some (slow) hosts.
|
|
In particular, have the resulting badmatch contain the starting and
ending time. There are still sporadic failures on slow hosts.
|
|
* anders/diameter/watchdog_leak/OTP-11019:
Minor doc fix
Add testcase to exercise reconnect behaviour
Fix watchdog table leak
|
|
|
|
|
|
|
|
In particular, remove timing dependence by using diameter_reg:wait/1 to
wait on the term registered by diameter_{tcp,sctp} when opening a
listening socket.
|
|
Note that the semantics of client:connect/1 have changed slightly: the
second element in an argument 3-tuple is a remote address, the local
address being the transport module's default. Previously it was
interpreted as a common local/remote address.
|
|
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.
|
|
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.
|
|
A service process maintains a table keyed on watchdog process pids. When
a watchdog process dies the corresponding entry should be removed but
this was broken in commit f115a9f7, causing entries with watchdog state
DOWN to accumulate.
Watchdog processes die as a result of diameter:remove_transport/2, or
when a peer reestablishes a connection in the listening case. Neither is
typically a frequent occurrence.
The fault manifests itself in the return value of
diameter:service_info(SvcName, transport), which displays entries for
watchdog processes that are no longer alive.
|
|
* anders/diameter/service_config/OTP-11017:
Fix handling of unknown options to diameter:start_service/2
|
|
Diameter = the protocol
diameter = the Erlang application
|
|
{error, Reason} is now returned, instead of the options being ignored.
Note that diameter:add_transport/2 purposely ignores unknown options and
that the behaviour is documented. This is historic: some users depend on
it in order to store their own options for identifying transport config,
instead of using the reference returned by add_transport.
|
|
* anders/diameter/app_not_configured/OTP-10972:
Fix faulty sequence validation
Add config suite
Deal with config errors detected at transport start less brutally
Move most transport_opt() validation into diameter_config
Minor doc/spec fix
Minor diameter_lib cleanup
|
|
The validation of {sequence, {H,N}} incorrectly checked that H was an
N-bit integer, instead of the intended 32-N.
|
|
To verify return values from diameter:start_service/2 and
diameter:add_transport/2 when passing various config.
|
|
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.
|
|
'infinity' is a valid transport_config timeout.
|
