Am 18.08.22 um 16:39 schrieb Heiko Hund:
Patch and thus series doesn't apply anymore, in addition to eventual changes
also please rebase.
On Freitag, 20. Mai 2022 23:32:47 CEST Arne Schwabe wrote:
+ If both server and client support sending this message using the control
+ channel, the
Am 18.08.22 um 16:38 schrieb Heiko Hund:
On Freitag, 1. Juli 2022 00:42:55 CEST Arne Schwabe wrote:
Basically if I had been a bit more forwarding looking we would now have
protocol-flags ekm cc-exit instead of key-derivation ekm and
protocol-flags cc-exit
Then maybe also add support for
Patch and thus series doesn't apply anymore, in addition to eventual changes
also please rebase.
On Freitag, 20. Mai 2022 23:32:47 CEST Arne Schwabe wrote:
> + If both server and client support sending this message using the control
> + channel, the message will be sent as control-channel
On Freitag, 1. Juli 2022 00:42:55 CEST Arne Schwabe wrote:
> Basically if I had been a bit more forwarding looking we would now have
> protocol-flags ekm cc-exit instead of key-derivation ekm and
> protocol-flags cc-exit
Then maybe also add support for handling ekm via --protocol-flags and
Am 30.06.2022 um 22:25 schrieb David Sommerseth:
On 20/05/2022 23:32, Arne Schwabe wrote:
Current exit notification relies on data channel messages with specific
prefix. Adding these to new data channel modules (DCO) adds unncessary
complexity for the data for messages that from their idea
On 20/05/2022 23:32, Arne Schwabe wrote:
Current exit notification relies on data channel messages with specific
prefix. Adding these to new data channel modules (DCO) adds unncessary
complexity for the data for messages that from their idea belong to the
control channel anyway.
This patch adds
Current exit notification relies on data channel messages with specific
prefix. Adding these to new data channel modules (DCO) adds unncessary
complexity for the data for messages that from their idea belong to the
control channel anyway.
This patch adds announcing support for control channel and
