SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
RFC 8684 section 3.7 describes several opportunities for a MPTCP
connection to "fall back" to regular TCP early in the connection
process, before it has been confirmed that MPTCP options can be
successfully propagated on all SYN, SYN/ACK, and data packets. If a peer
acknowledges the first received data packet with a regular TCP header
(no MPTCP options), fallback is allowed.
If the recipient of that first data packet finds a MPTCP DSS checksum
error, this provides an opportunity to fail gracefully with a TCP
fallback rather than resetting the connection (as might happen if a
checksum failure were detected later).
This commit modifies the checksum failure code to attempt fallback on
the initial subflow of a MPTCP connection, only if it's a failure in the
first data mapping. In cases where the peer initiates the connection,
requests checksums, is the first to send data, and the peer is sending
incorrect checksums (see https://github.com/multipath-tcp/mpt...ext/issues/275), this allows
the connection to proceed as TCP rather than reset.
Fixes: dd8bcd1768ff ("mptcp: validate the data checksum")
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,167
Original Poster
Rep:
FWIW: Yesterday I built and installed the 5.18.0 kernel and it has been running perfectly with the
NVIDIA-Linux-x86_64-470.129.06.run driver and VirtualBox-6.1.35-151573-Linux_amd64.run (so far ).
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,167
Original Poster
Rep:
Year 2022, Round 32.
Another batch of updates has been scheduled for release on Sunday, 29 May 2022, at approximately 08:00, GMT. If no problems are found while testing the release candidates, they might be available sometime on Saturday (depending on your time zone).
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,167
Original Poster
Rep:
Quote:
Originally Posted by cwizardone
After being down for another 8 days, The Linux-Kernel Archive By Thread message board came back to life at 00:15:01 EST, this morning 24 April 2022.
Obviously, no one is minding the store.
Where are the adults?
Quote:
Originally Posted by cwizardone
......And, The Linux-Kernel Archive By Thread message board is down, yet, again! It hasn't been updated since Saturday, May 07, 2022 at 23:03:38 EST (US).
After being down for 20 straight days, "The Linux-Kernel Archive By Thread" message board came back from the dead this morning, Saturday, May 28, 2022, @ 00:15:45 EST (US). It would appear a human being was involved as the previous twenty days of messages have been restored as if nothing happened.
We'll see......
Last edited by cwizardone; 05-28-2022 at 06:41 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
).
