| Age | Commit message (Collapse) | Author |
|---|
|
This was supposed to already be the case (in what passes for my memory),
and detects that commit ed6395a6 is horrifically broken: diameter is
unable to send CEA over SCTP.
|
|
* anders/diameter/17.0_release/OTP-11825:
Simplify xref tests in app suite
Add app suite test for app file runtime_dependencies
Generate runtime_dependencies in app file
Remove syntax_tools and runtime_tools from app file
|
|
By examining which modules *use* runtime and compiler modules instead of
which modules compiler modules call. Note that the semantics are changed
somewhat: we will now fail if diameter modules are called from an
application which diameter.app lists as a start dependency, which wasn't
the case previously.
|
|
In particular, that modules listed in the 'modules' tuple only call
modules in other applications listed in the 'runtime_dependencies'
tuple.
|
|
* anders/diameter/unicode/OTP-11686:
Use fun encoding to erl_parse:abstract/2
Adapt dictionary compilation to new default encoding
|
|
The problem is that the change in default encoding to utf8 in 17.0, in
commit 00e42967, changes the behaviour of erl_parse:abstract/1, which is
used by the dictionary compiler to turn terms into abstract code. In
particular, it transforms the orddict representation of a parsed
dictionary to contruct the return value of a dictionary module's dict/0
function. This orddict contains various lists, one of which is a list of
tuples of the form
{Name, Code, [VendorId], [Avp]}
where Name is an ASCII string and VendorId is a non-negative integer.
Using erl_parse:abstract/2 instead allows a string encoding to be
specified but regardless of what encoding is used, the result of
transforming our tuple might not be what we really want, which is for
Name to always be represented as a string form and [VendorId] to always
be represented as a cons form: the [VendorId] will always end up as a
string form if the integers are small enough. The only way around this
is to transform the tuple bit by bit, but modifying the code to do this
is quite a lot of work, for not much gain: it would be nice to produce
more readable output but nothing stops working without it.
This commit restores the pre-17.0 conversion by explicilty specifying
latin1 as the string encoding to erl_parse:abstract/2. The utf8 encoding
broke the compilation of some dictionares since unicode strings aren't
expected when writing the generated code to file.
Note that the latin1 encoding does reasonably well in practice, although
it mangles the Ericsson Vendor Id list [193] into a "LATIN CAPITAL
LETTER A WITH ACUTE". The utf8 encoding does worse, mangling the 3GPP
Vendor Id 10415 into "DESERET CAPITAL LETTER CHEE". An ascii encoding
would do better than latin1 but doesn't yet exist. (Encoding isn't
really what the option is. It's a string predicate: if the predicate is
true then represent as a string form, otherwise a cons form.)
|
|
UTF-8 is now the default encoding and should no longer be
specified. These have probably been merged from maint earlier and the
coding statement was missed.
lib/dialyzer/test/opaque_SUITE_data/src/modules/opaque_erl_scan.erl
lib/diameter/test/diameter_codec_test.erl
lib/ssh/test/ssh_unicode_SUITE.erl
|
|
* anders/diameter/undefined_group/OTP-11561:
Ensure that Grouped AVP's are fully defined in dictionaries
Don't format diameter_make:codec/2 errors
Compiler suite fix
|
|
The case in which an AVP was defined as having type Grouped in
@avp_types without a corresponding specification in @grouped was
missing.
|
|
Instead, add diameter_make:format_error/1 to allow the caller to format
if desired, which is what applications like compiler and yecc do. Use
this to check that the expected error is the one actually generated in
the compiler suite.
|
|
An error when expecting success wasn't regarded as failure when
compiling dictionaries.
|
|
|
|
* anders/diameter/R16B03_release/OTP-11499:
vsn -> 1.5
Update appup for OTP-11168
Update appup for OTP-11361
Add makefile to build example dictionaries
Add recent Diameter-related RFCs
Generate diameterc.1, not diameter_compile.1
Fix documentation typos
Fix appup blunder
|
|
That is, preprocessed forms that can be passed to compile:forms/1,2.
|
|
To set @avp_vendor_id, @codecs and @custom_types as required for
imported avps.
|
|
In particular, make codec/2 flexible as to what's generated, the formats
(erl, hrl, parse, forms and beam) being passed in the options list and
defaulting to [erl, hrl]. The 'parse' format is the internal format to
which dictionaries are parsed, which can be manipulated by flatten/1
before being passed back to codec/2 or format/1.
Remove the (undocumented) dict/1,2 since codec/2 now subsumes it with
the 'parse' option.
|
|
|
|
It was originally written before this interface existed.
|
|
|
|
|
|
|
|
By using binary comprehensions. Add string-valued addresses to codec
suite.
|
|
To accept any nested list of codepoints and binaries. A list containing
a binary was previously misinterpreted and the documentation was
incomplete.
Also, rework codec suite slightly to be able to specify values for which
decode o encode is the identity map, for which encode should succeed,
and for which encode should fail.
|
|
|
|
|
|
|
|
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/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
|
|
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.
|
|
|
|
|
|
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/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.
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
|
|
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.
|
