add X25519MLKEM768 to the start of the default ECDHE curves list, allowing
libtls clients to connect to servers which don't offer any other curves
(this has been seen in the wild with got, reported by stsp). ok tb@
depends on recent libssl changes (ssl_tlsext.c r1.161, t1_lib.c r1.209).
Correctly handle failure to buffer DTLS messages.
If we fail to buffer an outgoing DTLS message, we're not going to be able
to retransmit it. Correctly propagate the failure.
ok kenjiro@ tb@
Move DTLS change cipher spec handling to its own function.
When a TLSv1.2 change cipher spec message has been built, call a separate
function that can handle the DTLS specific processing rather than including
this in the TLS code.
ok kenjiro@ tb@
Move DTLS handshake message handling to its own function.
When a TLSv1.2 handshake message has been built, call a separate function
that can handle the DTLS specific processing rather than including this in
the TLS code.
ok kenjiro@ tb@
Remove ssl3_handshake_msg_hdr_len()
This function is only called in one location, which is always a DTLS
context - use DTLS1_HM_HEADER_LENGTH directly instead.
ok kenjiro@ tb@
libssl: don't break TLSv1.2 with X25519MLKEM768
If the list of 'groups' starts with X25519MLKEM768 for a TLSv1.2 server,
ssl3_send_server_kex_ecdhe() attempts to use NID_X25519MLKEM768, which
it receives from tls1_get_supported_groups(). This does not work because
it never received the peer's public keys, which causes an error return
from tls_key_share_server_generate_mlkem768x25519().
For a TLSv1.2-only client with custom supported group list we will
currently send ML-KEM if configured. We should not do this.
There is more to fix here: if a TLSv1.2 client is misconfigured with
only X25519MLKEM768, we should not send a supported groups extension
(with this commit we'll send an empty one, which is an RFC violation).
This commit simply filters X25519MLKEM768 out of the supported groups
list if we're configured to be TLSv1.2-only.
feedback/ok jsing kenjiro (on an earlier version)
Properly set up interrupts in multivec mode if we have multiple msix
vectors but only one queue, making the driver work in uniprocessor
kernels, including RAMDISK.
problem reported by Lexi Winter
ok dlg@
Fix mwx_mcu_send_mbuf() for both mt7925 and mt7921 and the next bit
of 7925 bringup.
mwx_mcu_send_mbuf() handling of the len field was not quite right. Also
implement the mt7925 bits for UNI commands. Fix an issue with the wakeup
of commands, register the command in sc_mcu_wait before enqueuing the
command into the tx queue. Cleanup on error as well.
Implement mt7925_mcu_get_nic_capability() and mt7925_mcu_fw_log_2_host()
with this mwx_mcu_init() is done.
In mwx_dma_txwi_enqueue() use the right len0 value (mt_desc is a pointer).
With this MT7925 prints the mac-address (mwx_mcu_init() succeeds) but
more is needed mwx_init_hardware() after that mwx_preinit() should pass
which is a big step.
For MT7921 it seems this fixes the TX issue I was trying to fix for
so long. Also with this the driver works like before with the new
[3 lines not shown]
Fix up DMA allocation, interrupt handling and early hw init up to
the firmware load sequence.
Rename most functions used in the hw_init and firmware loading path
from mt7921 to mwx since these functions work on all versions now.
This diff allows both 7921 and 7925 devices to load and start the firmware.
Untested are 7920 and 7922 (I lack those devices).
Lots of bits picked up from a diff by mlarkin@
libssl: const correct ssl_*version* API
None of these functions modifies the SSL pointer. An upcoming diff will
need to call one of them with a const pointer, so fix all of them.
ok jsing kenjiro
