| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Having the peer_fsm process answer DWR meant that watchdog timer expiry
could result in an outgoing DWR despite the fact that an incoming DWR
was just answered. Having the watchdog process answer avoids this.
diameter_peer_fsm must be loaded before diameter_watchdog. It's
possible for one incoming DWR to go unanswered but a subsequent DWR will
be answered so no harm is done.
|
|
|
|
The R16B01 release
Conflicts:
lib/sasl/vsn.mk
|
|
|
|
|
|
Commit f0a36c79 broke the handling of such configuration, resulting in a
function clause error in diameter_capx if the list was not of length 3,
and faulty extraction of application id's otherwise. Only record-valued
config was properly interpreted.
|
|
|
|
* anders/diameter/request_spawn/OTP-11060:
Minor doc fix
|
|
|
|
|
|
* anders/diameter/release/R16B01/OTP-11120:
vsn -> 1.4.2
Update appup for R16B01
Trailing whitespace and copyright fixes
Minor macro simplification
Move app/appsrc from src/base into src
|
|
* anders/diameter/request_spawn/OTP-11060:
Make spawn options for request processes configurable
|
|
|
|
Tickets and corresponding runtime modules, in order merged:
OTP-9610 (distribution)
diameter
diameter_config
diameter_peer
diameter_service
diameter_traffic
diameter_service must precede diameter_peer.
OTP-10972 (app_not_configured)
diameter
diameter_config
diameter_lib
diameter_peer_fsm
diameter_watchdog
Load order is unimportant.
OTP-11017 (service_config)
diameter_config
OTP-10986 (address_config)
diameter_peer
diameter_peer_fsm
diameter_tcp
diameter_tcp must follow the others.
OTP-11019 (watchdog_leak)
diameter_service
OTP-11026 (avp_length_failure)
diameter_codec
OTP-11007 (avp_decode)
diameter_gen.hrl => diameter_gen_*
diameter_codec
diameter_traffic
diameter_traffic must precede diameter_gen_*.
OTP-11087 (missed_5001)
diameter_gen.hrl => diameter_gen_*
OTP-11115 (watchdog_function_clause)
diameter_watchdog
OTP-11050 (inband_security)
diameter_peer_fsm
diameter_capx
This order is required.
OTP-11045 (host_ip_address)
diameter_peer_fsm
OTP-11092 (5xxx_failed_avp)
diameter_traffic
OTP-11127 (one_failed_avp)
diameter_peer_fsm
OTP-10893 (peer_address_config)
diameter_peer
diameter_tcp
diameter_sctp
diameter_peer must precede the others.
OTP-11060 (request_spawn)
diameter_service
diameter_traffic
diameter_config
diameter
diameter_traffic should precede diameter_service, diameter_config
should follow.
Tickets without code:
OTP-10903 (examples_suite)
OTP-11014 (release_notes)
OTP-11051 (mkdir_race)
OTP-10914 (timetraps)
|
|
That is, for the process that's spawned for each incoming Diameter
request message.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
* 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.
|
