| Age | Commit message (Collapse) | Author |
|---|
|
* anders/diameter/answer-message_decode/OTP-14596:
Exercise answer-message/AVP decode in traffic suite
Exercise answer-message/Failed-AVP decode in traffic suite
|
|
* anders/diameter/DOIC/OTP-14588:
Exercise avp_dictionaries in traffic suite
Let generic AVPs be encoded/decoded in alternate dictionaries
Rename field in codec map: dictionary -> app_dictionary
Add RFC 7683 Diameter Overload Indicator Conveyance text and dictionary
Fix decode undef
Fix dictionary compilation error message
|
|
OTP-14520
|
|
to include new defined properties in OTP-20
regarding comparison and serialization.
|
|
* rickard/statistics-time-fixes/OTP-14597/ERL-465:
Bug fixes of statistics(wall_clock) and statistics(runtime)
Conflicts:
erts/emulator/beam/erl_time_sup.c
|
|
|
|
|
|
|
|
|
|
If printable range is set to 'unicode', the simple error logger will now
recognize code points > 255 and print lists containing these as strings.
|
|
Check if standard_io can handle Unicode, and if so add the 't'
modifier to format strings.
|
|
This is both for error logger events and debug events. It can be done
because error log and debug log are both opened with encoding utf8 since
OTP-20.0
|
|
This is now ok since sys opens the debug file with encoding utf8.
Conflicts:
lib/stdlib/src/gen_server.erl
|
|
This can now be explicitly set by the 'sasl_error_logger'
configuration parameter, but if not set, the default encoding is now
utf8. When printing to this log, the Unicode translation modifier, t,
might be used in the format string.
|
|
Since error_logger_file_h now opens its log file with encoding utf8,
it is ok to print with the 't' modifier in format strings.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The updates of xref_base:analysis() are cosmetic (the strings are
parsed by the Erlang scanner only).
|
|
It's not clear to me if the receiving file always can handle
characters codes greater than 255.
|
|
|
|
|
|
|
|
|
|
|
|
There is more to do.
|
|
|
|
|
|
Commit 58091992 discarded a new monitor reference, so didn't avoid
multiple monitors as was the intention. The blunder was harmless since
all but the first DOWN message resulted in notifications.
|
|
|
|
In particular, that arbitrary application AVPs are decoded in an answer
setting the E-bit.
|
|
In particular, that application AVPs in Failed-AVP are decoded in an
answer setting the E-bit.
|
|
As introduced in the parent commit.
|
|
To support specifications like RFC 7683 DOIC, that only define AVPs, not
applications. AVPs that aren't known to the application dictionary in
question could previously not be decoded. Configuring alternate
dictionaries with the new transport/service option avp_dictionaries
changes this, so that AVPs like DOIC's Grouped OC-OLR can presented in
their fully decoded glory. Encode is also extended, allowing things like
the following to be encoded in an outgoing message:
'AVP' => [{'OC-OLR', #{'OC-Sequence-Number' => 1,
'OC-Report-Type' => 0,
'OC-Reduction-Percentage' => [25]}}]
A diameter_gen_doic_rfc7683 dictionary is installed, but
avp_dictionaries isn't specific to DOIC.
This commit also solves the problem demonstrated a few commits back,
that application AVPs aren't decoded in answers setting the E-bit. Test
coverage will come in a subsequent commit.
|
|
To better reflect what the field is: field 'module' is the dictionary
module that's calling diameter_gen to decode a list of AVP, while field
'app_dictionary' is the dictionary module defining the message being
decoded.
|
|
Which motivates the avp_dictionaries config that will be added in
a subsequent commit.
|
|
|
|
Function avp/5 isn't exported from dictionary modules. Not necessarily
intentional, but don't just export it since that requires recompilation
of all dictionary modules, since the function is in diameter_gen.hrl.
Not having to recompile was the main motivation for moving most of the
included code to module diameter_gen in commit 205521d3.
This reveals a weakness in the decode of answers setting the E-bit: any
AVP that isn't defined by the common application won't be decoded; the
diameter_avp records that these are packed into (in the 'AVP' field of a
message record, or equivalent) will have value = undefined. This is
nothing new (same in OTP 19), but the values should be decoded. Fix it
(and the lack of test coverage) in a subsequent commit that will add
avp_dictionaries config.
|
|
Adding a second {Vendor-Id} to the common CER definition results in
this error:
** AVP CER at line 85 already referenced at line 84
That is, the error incorrectly refers to the message name (CER) where the
AVP name (Vendor-Id) is expected.
|
|
* ingela/ssl/session-cache-max/OTP-14556:
ssl: Mend Max session handling
|
|
The commit 256e01ce80b3aadd63f303b9bda5722ad313220f was a misunderstanding
that actually broke the implementation.
It is not so important to keep specific max, rather max is a threshold
when the table should be shrinked as to not grow indefinitely.
New sessions are created when the id is created and may be short lived
it they are not registered for reuse due to handshake failure.
|
|
* ingela/ssl/error-msg-enhancment:
ssl: Add the role (server or client) to the alert message
Addition to 972f9121311efcfb50db727ab3e930ebc95ab314 solved in OTP-14236
|
|
* anders/diameter/decode_format/OTP-14511:
Map less in traffic suite
Fix decode_format doc oversights
Rename decode_format false to none
Tweak {decode_format, false} semantics
Fix dialyzer spec
|
|
* anders/diameter/config_consistency/OTP-14555:
Fix strict_arities blunder
Fix minor error-handling blunder
|
