Дмитрий

Этот процессор был очень пограничным для полной поддержки аппаратной виртуализации. Как минимум он ещё не поддерживает аппаратный SLAT, а это прямо ощутимые тормоза.
Вполне возможно там что-то глючило, и решили вырубить поддержку в микрокоде.
Плата тоже может ограничено уметь в виртуализацию, т. к. в то время она только развивалась и поддержка вполне могла быть экспериментальной.

Есть пара способов:
Обновить прошивку платы.
Обновить микрокод процессора.

Если ни один из них не поможет, то вряд ли уже что-то поможет. Слишком экспериментальной ещё была виртуализация в те времена.

Первая же ссылка в гугле по запросу "RTL8821AU Linux" говорит о том, что Realtek забил болт на всех, и исходники драйвера для этого чипа никогда не публиковались, соответственно, их не может быть в ядре изначально.

Единственный вариант -- это собрать среверсенный драйвер через dkms или установить с пользовательского репозитория уже собранный модуль.

Для Федоры: https://copr.fedorainfracloud.org/coprs/sunwire/dk...
Для Арча: https://aur.archlinux.org/packages/rtl8821au-dkms-git
Для Убунты не припомню собранного актуального модуля.

Для самостоятельной сборки: https://github.com/morrownr/8821au-20210708

UPD: От себя добавлю, что драйвер очень глючит, что под Линуксами, что под Виндой. Если используется не для кулхацкинга и режима монитора, то лучше купить что-то понадёжнее.

Так поменяйте местами us,ru на ru,us.

darkk.net.ru/redsocks

--block-outside-dns

Раньше перепробовал все популярные дистрибутивы с дистровотч.
Пока не дошёл по списку до Арча. Пользуюсь уже лет 8, никаких проблем не было за это время. Всегда свежайший актуальный софт, все существующие пакеты есть в пользовательских репо. Заводится на любом железе: стоит на 3-х ПК, одном ноуте, 2 серверах и Малине. Пересадил брата с мерзкого OpenSUSE, брат жив. Если делать всё адекватно и понимать, что делаешь, читать официальные новости/вики, в которых пишут, если есть какая-то особенность обновлений и т. п., то проблем не будет.

Конечно, знаний нужно побольше, чем мышкой возить в бубунте, но оно того стоит. Например, rolling release — штука довольно непонятная для большинства. Здесь нужны понимания, что такое версии SO-библиотек, как от них зависят исполнимые файлы, как их безболезненно обновлять и т.д. Ну, это если в бою использовать.
А если на домашнем компе, который можно перегрузить свободно, то просто, нужно усвоить правило: не устанавливать новые пакеты без обновления старых, с каждым апдейтом желательно перегружаться, и проблем не будет.

man xsel

ESTAB значит ESTABLISHED, т.е. установленное, а не зависшее и тем более, искусственно. Если оно установлено, значит по нему кто-то ожидает принять данные и оно ему нужно.

Потому что, когда винда уходит в гибернацию, она создаёт на NTFS-разделе страницу, которую помечает как start speedup cache. В этой странице находится кеш метаданных для быстрого старта, чтобы потом не читать их заново на старте и не тупить.
Вот этот кеш для линуксов не имеет никакого смысла. Мало того, раздел при монтировании видится как битый, потому что он помечается кучей своих флагов. Современные версии NTFS-3g предупреждают об этом и просят загрузиться снова в винду, чтобы она восстановила этот кеш. Ядерный же драйвер ntfs вообще пока не знает об этом, и может молча что-то записать поверх, и тогда ваша винда уже не загрузится.

Это что касается NTFS.

Ещё есть вероятность поломать EFI-раздел. Тут уж я не знаю, что делает с ним винда, но в момент гибернации, она тоже что-то оставляет не нём в неконсистентном состоянии, и при дальнейшем монтировании в линуксе, этот раздел видится битым. Если в этот момент на него что-то записать или попытаться "исправить", то уже все ваши операционные системы не смогут загрузиться.

На самом деле, можно и не отключать этот фастбут. Просто нужно постоянно помнить: не выключился ли у вас случайно комп, когда был в виндовой гибернации. Типа там, свет моргнул, или уборщица сетевой фильтр шваброй обработала, либо вы сами накосячили.

Ну, так, а вы почитайте про разницу UDP и TCP и всё станет понятно.

В UDP нет понятия подключения или потока байт. Там есть понятия датаграмм. Это атомарные сущности, которые принимаются точно так же, как и отсылаются, абсолютно в том же виде.

Каналы в джаве созданы просто для унификации, для некого подобия псевдо-стримминга для удобной обработки. На самом же деле, никакого канала и потока нет. Есть отдельные датаграммы определённого размера, которые вы должны принимать.
Каждый клиент идентифицируется по его паре адрес:порт, с которого пришли данные через функцию recvfrom. Других вариантов нет.

Это, если нужна синхронная обработка. Для асинхронного варианта, как уже ответил dummyman, удобнее использовать Asio.

Поставьте на виртуалку и не парьтесь.

Забейте. Это в каждом ядре то добавляют, то ломают, то обратно чинят. Ни на что оно не влияет.
Просто обновите биос для уверенности и, если не пропадёт, забейте.

Для таких случаев пишут systemd сервис.

А зачем вам тогда epoll? Чем он, в вашем случае, будет отличаться от обычного блокирующего сокета в отдельном потоке?
Его смысл как раз в асинхронности и неблокируемости, а вы эти плюшки сводите на нет, вводите тормозящие мьютексы, очереди.
Раз уж пишете на плюсах асинхронно, то возьмите библиотеку для этого, тот же Asio.