Есть тупая железка, которая шлёт клиентские запросы NTPv1 на 20 байт длиннее (68 вместо 48, 20 байт в конце просто забиты нулями), из-за чего chronyd сносит башку (он думает, что это аутентифицированные пакеты, видит неправильный Key-MAC и дропает их).

Хочу этой тупой железке попробовать сделать обрезание таких UDP-пакетов. Пока что с NFQUEUE не заморачивался, хочу чего-то попроще.

Вопрос: как? Пробовал tc-pedit:

#!/usr/bin/env bash

LAN=enp3s2

case "$1" in
        start)
                tc qdisc add dev ${LAN} handle ffff: ingress
                tc filter add dev ${LAN} parent ffff: protocol ip flower src_ip 192.168.1.55 ip_proto udp dst_port 123 action pedit munge offset 2 u16 set 0x30 pipe csum ip and udp
                ;;
        stop)
                tc qdisc del dev ${LAN} handle ffff: ingress
                ;;
esac

но сломал мозг (то, что я написал выше, не работает).

Железка подключена через сеть за enp3s2, пакеты идут через линуксовый роутер, на котором, собственно, и нужно провернуть трюк.

mky vel

https://blog.centos.org/2020/12/future-is-centos-stream/

https://www.redhat.com/en/blog/centos-stream-building-innovative-future-enterprise-linux

Для неосиливших ссылки:

CentOS 8 с конца следующего года больше не будет развиваться Red Hat’ом, вместо неё будет CentOS Stream, эдакая вечная бета следующего RHEL’а. По ходу дела RH предложит бесплатную подписку на RHEL для некоторых community, которые завязаны на CentOS 8. Для CentOS 7 ничего не меняется, она будет жива до 2024-го.

Как дальше жить?

Смотрю на вот это вот чудо и хочу понять, будет ли оно работать как точка доступа в 5 ГГц диапазоне.

Есть такой зверь у кого? Поделитесь выводом iw list.

Ну и чтобы два раза не вставать — что вообще сейчас нужно брать и ставить в PCI-E, чтобы сделать как минимум 802.11ac (а ещё лучше ax)?

Поделитесь историей успеха.

Сейчас имею Asterisk 16 с настроенным WebRTC и sipML5 в качестве клиента. Аудиозвонки работают нормально во все стороны. Видео работает как попало: эхо-тест работает в Firefox и CSipSimple, а в Chromium'е тупо не показывает входящий видеопоток.

Карта в SDP одинакова что для Firefox'а, что для Chromium'а. Пробовал тасовать кодеки без результата. Пробовал врубать direct_media, тоже без результата. В логах Asterisk'а вижу, что когда работает Firefox, то Strict RTP лочится на два потока (видео и аудио, соответственно), а когда Chromium — только на один (аудио). Выглядит так, как будто Chromium просто игнорит факт наличия видео.

Куда копать? Вниз не предлагать, вдоль тоже.

Оно вообще должно работать? Есть истории успеха, или дело гиблое?

Хочу клавиатуру:

• островную (обязательно);
• низкопрофильную (обязательно);
• с полноразмерными клавишами (обязательно);
• без цифрового блока (желательно);
• беспроводную (желательно).

Понятное дело, что она не должна быть хлипкой. Ну и Apple не предлагать, хотя их вариант очень даже подошёл бы, используй я Мак.

Есть идеи?

А вот хочу я, допустим, в командной строке ядра одному кастомному параметру передать однострочную структурированную простыню, которую потом в юзерспейсе буду парсить на Сишечке.

Хочется что-то типа json'а, но без двойных кавычек. Желательно, чтобы кавычек и скобок вообще поменьше было. И чтобы можно было в одну строку всё написать. И ещё чтобы парсер на Си был без внешних зависимостей.

Ну например:

{ foo: [ bar1, 0.0 ], ololo: { boom: [ 1, 2, qwerty ] } }

Есть такое?

Opera 45.0.2552.812, распоследний Arch.

Сразу после запуска один из процессов Оперы начинает чем-то занимать CPU. Не полностью, но достаточно заметно, процентов на 15.

Натравил strace: [1]

Показывает что-то похожее на event loop, с poll() и recvmsg(). Всегда вижу два дескриптора, в данном случае 110 и 117. recvmsg() очень много и очень быстро возвращает EAGAIN.

Смотрю стектрейсы для recvmsg: [2]

Вижу, что оно, похоже, вызывается в каком-то коде, завязанном на обработку событий от Иксов.

Смотрю на эти дескрипторы: [3]

Полезного ничего не вижу.

Если приаттачиться через gdb и сделать close() дескрипторам, Опера выпадает с SIGSEGV.

Воспроизводится на чистом профиле без расширений.

Репорт разрабам отправил, хочу теперь узнать, есть ли тут те, кто видел похожее и знает, как с этим бороться.

MidDaily Commander - форк форк файлового менеджера mc

Можно много спорить о том, какого качества темы на ЛОРе в последнее время, но Development обычно — это либо серьёзные темы по существу, либо весёлые споры с царём о сишечке. А вот это вот — ни в какие ворота.

Прошу либо снести, либо (если хочется оставить) перенести в толксы, либо забанить автора за постоянный и унылый тупняк, либо создать отдельный раздел «Цирк» по типу существующего клуба и плодить похожее говно именно там.

Developmentʼу эта тема не к лицу совсем.

http://git.kernel.dk/cgit/linux-block/commit/?h=for-4.12/block&id=aee69d7...

Ура.

Играюсь тут с libuv. Вот код. По замыслу это пока просто ехо-сервер по UDP — на всё, что ему шлешь, отвечает «hello».

С приёмом всё ОК.

С отправкой не ОК.

Допустим, в строках 84, 85 и 86 аллоцируется память для буфера перед отправкой. В строке 94 этот буфер отправляется, после отправки вызывается коллбек, который начинается со строки 42.

А теперь внимание, вопросы: почему в том хендле, который отдаётся коллбеку, указатель на буфер NULL (строка 46 и 47)? И почему в то же время количество этих буферов в том же хендле ненулевое? Как я должен освобождать память буфера, если мне не дают на него указатель? Какой смысл тогда в коллбеке on_send? И почему тогда тот же трюк для on_read работает нормально?

Похоже, утекло.

https://github.com/prestocore/browser

Странно, что тут ещё не обсуждают. Видимо, новость о клиенте Телеграма завлекла всех хомячков. Так вот вам ещё корм.

!Ъ: https://geektimes.ru/post/284530/ и http://www.theverge.com/2017/1/12/14251546/opera-neon-concept-web-browser-rel...

К редизайну и обновлению UX и UI специалисты Opera Software подошли основательно. Вот некоторые особенности Neon на фоне классических браузеров:

• Новая стартовая страница, которая использует в качестве фона обои рабочего стола.
• Левая боковая панель со своим собственным видеоплеером, менеджером закачек и просмотра изображений.
• Вертикальная панель вкладок с правой стороны окна браузера, что позволяет легче различать их с вкладками.
• Интеллектуальная система управления вкладками. Часто используемые вкладки будут перемещаться вверх, когда как менее используемые «оседать» вниз.
• Совершенно новый омнибокс, поддерживающий как основные, так и менее популярные поисковики.
• Режим разделенного экрана для просмотра двух вкладок одновременно.

Чтоделать, кудабежать.

а был (модератор). Где драма, Shaman007?

[~]$ mtr -wbrc3 linux.org.ru
Start: Mon Dec 12 19:27:55 2016
HOST: spock                                                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- xxx.xx.xx.x                                                    0.0%     3    1.7   1.7   1.7   1.9   0.0
  2.|-- xxx.xxx.xxx.x                                                  0.0%     3    2.4   2.3   2.2   2.4   0.0
  3.|-- cz-prg-asbr2-xe-4-1-1-vlan1900.dialtelecom.cz (88.208.100.17)  0.0%     3    6.7   6.6   6.5   6.7   0.0
  4.|-- xe-4-0-0.prg11.ip4.tinet.net (213.200.74.93)                   0.0%     3    7.5   9.5   5.8  15.3   5.0
  5.|-- xe-1-2-0.vie20.ip4.gtt.net (141.136.105.154)                   0.0%     3   11.9  11.9  11.8  11.9   0.0
  6.|-- as174.vie20.ip4.gtt.net (141.136.101.238)                      0.0%     3   13.1  12.7  12.3  13.1   0.0
  7.|-- be2974.ccr21.muc03.atlas.cogentco.com (154.54.58.5)            0.0%     3   24.6  24.5  24.3  24.7   0.0
  8.|-- be2959.ccr41.fra03.atlas.cogentco.com (154.54.36.53)           0.0%     3   24.9  24.9  24.8  25.1   0.0
  9.|-- be3119.agr21.fra03.atlas.cogentco.com (130.117.51.38)          0.0%     3   24.9  25.1  24.9  25.4   0.0
 10.|-- adacor-hosting.demarc.cogentco.com (149.6.140.130)             0.0%     3   25.3  25.4  24.6  26.4   0.7
 11.|-- ???                                                           100.0     3    0.0   0.0   0.0   0.0   0.0

Через TOR вот зашёл, а с этих наших европ не пускает.

Как всегда.

Анонс тут.

http://lkml.iu.edu/hypermail/linux/kernel/1612.0/02646.html

Это делается специально, чтобы наконец-то смержить BFQ. Ура.

Пруф: https://groups.google.com/d/msg/bfq-iosched/mOPpF1aUcrY/WS-xUyfsBQAJ

Разбираюсь с шейпером на таком простом примере:

# шейпим исходящий трафик, корневая дисциплина — HTB
tc qdisc add dev enp3s0 root handle 1: htb default 99 r2q 1000

# корневой класс на ~20-мегабитный линк
tc class add dev enp3s0 parent 1: classid 1:1 htb rate 18000kbit burst 10k

# дочерний класс, допустим, сюда мы хотим засунуть ICMP
tc class add dev enp3s0 parent 1:1 classid 1:11 htb rate 100kbit ceil 18000kbit prio 1 quantum 2000

# дочерний класс по умолчанию для неклассифицированного трафика
tc class add dev enp3s0 parent 1:1 classid 1:99 htb rate 100kbit ceil 18000kbit prio 2 quantum 2000              

# навешиваем fq_codel на дочерние классы
tc qdisc add dev enp3s0 parent 1:11 handle 11: fq_codel
tc qdisc add dev enp3s0 parent 1:99 handle 99: fq_codel

# собственно, фильтр для ICMP
tc filter add dev enp3s0 parent 1: bpf run bytecode "$(tcpdump -ienp3s0 -ddd 'ip proto 1' | tr '\n' ',')" flowid 1:11

Счётчики для 1:11 после такого лежат в нулях, весь трафик валит в 1:99. Если фильтр заменить на обычный u32, то всё ОК:

tc filter add dev enp3s0 parent 1: u32 match ip protocol 1 0xff flowid 1:11

Самое плохое то, что всё это на BPF раньше работало. Не могу понять, что поменялось или сломалось при очередном апгрейде.

Arch, ядро v4.7.6, стоковое.

cast vel, mky.

Есть вредная железка X, которую нужно мониторить по SNMP и которая в упор не отвечает на IP-пакеты с флагом DF (баг в прошивке, который неизвестно как, когда и кто пофиксит).

Есть софт, живущий в контейнере (systemd-nspawn), который опрашивает snmpget'ом разные железки, в том числе и железку X.

Проблема в том, что все пакеты от софта в контейнере шлются с установленным флагом DF. Если на гипервизоре выставить ip_no_pmtu_disc=1 и запустить софт прямо на том же гипервизоре, а не в контейнере, то всё работает. Однако ip_no_pmtu_disc=1 не влияет на софт в контейнере — пакеты всё равно шлются с флагом DF.

Как быть?

Проверялось на Arch'е, CentOS'е 7, Ubuntu в systemd-nspawn и docker'е — везде одно и то же.