On Sat, Nov 20, 2021 at 01:39:38PM +0400, Алексей Витальевич Коротков wrote:

Вложил ping.txt от команды
LANG=en_US.UTF-8 ping -c 1 192.168.1.1 > ping.txt 2>&1

Вот это

capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, NULL) = 0 capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=0, permitted=0, +inheritable=0}) = 0
capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, NULL) = 0 capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=0, permitted=0, +inheritable=0}) = 0
prctl(PR_SET_KEEPCAPS, 1) = 0
getuid() = 1000
setuid(1000) = 0
prctl(PR_SET_KEEPCAPS, 0) = 0
getuid() = 1000
...
socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP) = -1 EACCES (Permission denied) socket(AF_INET, SOCK_RAW, IPPROTO_ICMP) = -1 EPERM (Operation not permitted)

совершенно закономерно: видно, что "strace ping ..." запускается не от
рута, а под uid/gid=1000/1000), а в таком случае при запуске под strace
на применяются capabilities, соответственно capget не выдаёт, а capset
не ставят нужную CAP_NET_RAW, в результате не удаётся создать raw socket,
необходимый для пинга -- последний вызов socket() выдаёт EPERM.

Насколько я понимаю, ping без strace исправно работает под этим uid/gid,
хоть и ругается на ipv6.

Интересно, давно ли перезагружался компьютер. :)

И поскольку говорилось о наличии рядом другого компьютера с рабочей
системой, предлагаю сравнить diff-ом выдачу "sysctl -a" с этих компов.
Разумеется, отсекая всё что не относится к сети.
--
Eugene Berdnikov

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Nov 20, 2021 at 11:05:50PM +0400, Алексей Витальевич Коротков wrote:

После убирания отключения IPv6 старые проблемы ушли, но есть новые.
getmail получает почту со второго раза, в перый раз он выдаёт

operation error (error resolving name pop.gmail.com during connect
([Errno -2] Name or service not known))

Это явно проблема с DNS. Скорее всего запросы где-то дублируются на
разные серверы, и первым отвечает поломанный сервер, возвращая NxDomain
(имя не найдено). При повторном запросе тот сервер почему-то не отвечает,
и клиенту удаётся дождаться правильного ответа от другого сервера.

Почему так может происходить -- есть варианты, не вижу смысла их
вдаваться в их обсуждение. Проще и быстрее посмотреть дамп трафика,
как было здесь предложено, хотя бы на проблемном хосте.

Только я не знаю, где взять dumpcap... а tcpdump в Дебиане точно есть.
Запускать его под рутом, примерно так:

tcpdump -nlUv -i any -s0 port domain
--
Eugene Berdnikov

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Nov 21, 2021 at 02:45:35PM +0400, Алексей Витальевич Коротков wrote:

На компьютерах у меня в /etc/resolv.conf стоит nameserver 192.168.1.1

А на Кинетике (который 192.168.1.1) серверы DNS такие
77.88.8.8
77.88.8.1
77.88.8.88
77.88.8.2
77.88.8.7
77.88.8.3
8.8.8.8
192.168.8.1
(именно в таком порядке).

192.168.8.1 это адрес модема.

В такой толпе серверов неудивительно распостранение глюков и багов,
особенно во время пандемии... :) Без дампа трафика гадать тут можно
бесконечно, подозревая и косяки Кинетика (в котором может быть зашит
dnsmasq прошлого века), и модем, а в качестве безумной фантастики
ещё iproute2 и версию ядра.
--
Eugene Berdnikov

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)