subject:"странное..."

2021-11-20 Пенетрантность Алексей Витальевич Коротков

сб, 20 нояб. 2021 г. в 22:31, Алексей Витальевич Коротков <
a.v.korot...@gmail.com>:

> On Sat, 20 Nov 2021 21:59:39 +0300
> Maksim Dmitrichenko wrote:
>
> MD> Верните строчку и пришлите strace из-под root'а или из-под sudo,
> MD> если вы хотите, чтобы вам помогли с диагностикой.
>
> В текущем виде проблем с пингами нет.

Коллега, тот факт, что у вас проблема решилась путем убирания параметра,
отключающего IPv6, может говорить не о том, что дело было в этом, а о том,
что проблема осталась, но оказалась в тени другой фичи.

> Есть с аптом и getmail, а также с
> частью страниц в браузере. Работает только со второй попытки. Вероятно,
> с другими сетевыми приложениями тоже возможна такая же ерунда, пока не
> пробовал. Что именно стрейсить? Пинги, наверно, нет смысла.
>

Ну strace apt'а, например. Только нужен strace не когда оно работает, а
когда оно не работает. А лучше всего оба. А то в случае с curl'ом вы
приложили именно работающий strace.

Ну и параллельно, я бы сдампил на всякий случай трафик с помощью dumpcap,
если таковой будет. Причем интересно не только сами попытки приконнектиться
к нужному адресу, но всё, что этому предшествует - ARP, DNS и вот это всё.

-- 
With best regards
  Maksim Dmitrichenko

Re: Что-то странное произошло с сетью

On Sat, 20 Nov 2021 21:59:39 +0300
Maksim Dmitrichenko wrote:

MD> Верните строчку и пришлите strace из-под root'а или из-под sudo,
MD> если вы хотите, чтобы вам помогли с диагностикой.

В текущем виде проблем с пингами нет. Есть с аптом и getmail, а также с
частью страниц в браузере. Работает только со второй попытки. Вероятно,
с другими сетевыми приложениями тоже возможна такая же ерунда, пока не
пробовал. Что именно стрейсить? Пинги, наверно, нет смысла.

Re: Что-то странное произошло с сетью

2021-11-20 Пенетрантность Алексей Витальевич Коротков

On Sat, 20 Nov 2021 22:01:49 +0300
Maksim Dmitrichenko wrote:

MD> Маловероятно вообще. Тем более, что команда ping к пакету iproute2
MD> не имеет никакого отношения

Вообще. Всё пинговалось, всё обновлялось, всё грузилось с первого раза.

Проблема не с пингами конкретно, а вообще сеть криво работает.

Re: Что-то странное произошло с сетью

2021-11-20 Пенетрантность Алексей Витальевич Коротков

On Sat, 20 Nov 2021 21:20:35 +0300
Eugene Berdnikov wrote:

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

С час назад.

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

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

Гляну.

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

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

Пакетная база обновляется не со всех сторонних репо. С CRAN, например,
не работает.

Re: Что-то странное произошло с сетью

сб, 20 нояб. 2021 г. в 21:38, Алексей Витальевич Коротков <
a.v.korot...@gmail.com>:

> Основной гипотезой у меня сейчас новый iproute2 + старое ядро. Потому
> что до вчерашнего дня проблем с сетью не было вообще.
>

Маловероятно вообще. Тем более, что команда ping к пакету iproute2 не имеет
никакого отношения


-- 
With best regards
  Maksim Dmitrichenko

Re: Что-то странное произошло с сетью

2021-11-20 Пенетрантность Алексей Витальевич Коротков

сб, 20 нояб. 2021 г. в 21:38, Алексей Витальевич Коротков <
a.v.korot...@gmail.com>:

On Sat, 20 Nov 2021 20:55:25 +0300
> Maksim Dmitrichenko wrote:
>
> MD> Я дико извиняюсь, но то, что в ядре отключено IPv6 вовсе не мешает
> MD> ping пропобовать открывать сокет семейства протоколов IPv6, что у
> MD> вас, судя по strace и происходит.
>
> Убрал ту строчку из груба. Сейчас с пингами всё нормально.
>

Верните строчку и пришлите strace из-под root'а или из-под sudo, если вы
хотите, чтобы вам помогли с диагностикой.


> MD> ЗЫ: А может вы (или какая-то программа хулиганская) сбросила
> MD> SUID-бит у ping?
>
> Его нет нигде: ни на десктопе, ни на домашнем сервере, ни на VPS с
> таким же Дебьяном.
>

Я второе письмо вдогонку послал с  разъяснением того, что ныне SUID-бит
заменяют capability.


-- 
With best regards
  Maksim Dmitrichenko

Re: Что-то странное произошло с сетью

On Sat, 20 Nov 2021 20:38:01 +0300
Dmitry Semyonov wrote:

DS> Что-то больно старое ядро... В stable и то новее, судя по
DS> https://packages.debian.org/search?keywords=linux-image-amd64.

Да, это из бастера.

Это другая проблема. Не грузятся новые ядра.

Причём после обновления 10 -> 11 новое ядро загружалось, но потом
перестало. Сейчас уже трудно сказать, после чего именно. Просто
загрузка останавливается. Хорошо, что сохранилось старое.

DS> Всё может быть. Вполне возможно, что новый iproute2 c Вашим ядром не
DS> до конца совместим. Также учитывая что IPv6 сейчас везде включают по
DS> умолчанию, нисколько не удивлюсь, если без него особо не проверяют
DS> работоспособность сетевых программ.

Убрал из GRUB, сделал в /etc/sysctl.d/. Проблема исчезла старая, но
вылезла новая:

$ LANG=en_US.UTF-8 ping -c 1 debian.org
ping: connect: Cannot assign requested address

Тогда убрал вообще. Сейчас пинги все без проблем работают.

Но почему-то в браузере некоторые страницы грузятся всё равно только со
второго раза.

DS> С другой стороны, разведение зоопарка из разных репозиториев
DS> пакетов - не очень хорошая идея, если нет чёткого понимания зачем
DS> это делается, и как они друг с другом уживаются. В Вашем случае, я
DS> бы посоветовал перейти на чистый stable

У меня и так stable, только с бэкпортами. Остальное - стороннее ПО
(Хром, например). В офрепо из него нет почти ничего, а что есть, не
должно влиять на мою ситуацию.

Основной гипотезой у меня сейчас новый iproute2 + старое ядро. Потому
что до вчерашнего дня проблем с сетью не было вообще.

Re: Что-то странное произошло с сетью

2021-11-20 Пенетрантность Алексей Витальевич Коротков

On Sat, 20 Nov 2021 20:55:25 +0300
Maksim Dmitrichenko wrote:

MD> Я дико извиняюсь, но то, что в ядре отключено IPv6 вовсе не мешает
MD> ping пропобовать открывать сокет семейства протоколов IPv6, что у
MD> вас, судя по strace и происходит.

Убрал ту строчку из груба. Сейчас с пингами всё нормально.

MD> ЗЫ: А может вы (или какая-то программа хулиганская) сбросила
MD> SUID-бит у ping?

Его нет нигде: ни на десктопе, ни на домашнем сервере, ни на VPS с
таким же Дебьяном.

Re: Что-то странное произошло с сетью

2021-11-20 Пенетрантность Eugene Berdnikov

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

Re: Что-то странное произошло с сетью

сб, 20 нояб. 2021 г. в 20:55, Maksim Dmitrichenko :

> ЗЫ: А может вы (или какая-то программа хулиганская) сбросила SUID-бит у
> ping?
>

Поправка. SUID-бит нычне не моден, теперь бинарю выставляются capabilities.
Впрочем запуск из-под strace также эффективно обнуляет эффект от
присвоенных капабилитей.
У меня вот так:
$ /sbin/getcap /usr/bin/ping
/usr/bin/ping = cap_net_raw+ep

-- 
With best regards
  Maksim Dmitrichenko

Re: Что-то странное произошло с сетью

сб, 20 нояб. 2021 г. в 18:28, Алексей Витальевич Коротков <
a.v.korot...@gmail.com>:

> DS> А так?
> DS> ping -4 ...
>
> $ ping -4 192.168.1.1
> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
> 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.326 ms
> 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.356 ms
> 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.292 ms
> 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.359 ms
> ^C
> --- 192.168.1.1 ping statistics ---
> 4 packets transmitted, 4 received, 0% packet loss, time 3074ms
> rtt min/avg/max/mdev = 0.292/0.333/0.359/0.027 ms
>
> Похоже, что угадали. Но тогда вопрос: почему до вчерашнего для всё было
> отлично? Обновление iproute2 повлияло?
>

Я дико извиняюсь, но то, что в ядре отключено IPv6 вовсе не мешает ping
пропобовать открывать сокет семейства протоколов IPv6, что у вас, судя по
strace и происходит.

Но вызывать ping из-под strace категорически нельзя, потому что strace не
дает запуститься ping с правами root (у него должен быть установлен бит
SUID). И это хорошо видно в вашем выводе strace, когда у него не получается
открыть socket семейства IPv4 (AF_INET)  для SOCK_DGRAM, PROTO_ICMP с
ошибкой EPERM. Собственно у вас ping и лезет к созданию сокета IPv6 просто
потому что у него обломалось создание сокета ICMPv4.

Приложите вывод strace пинга из-под root'а.

ЗЫ: А может вы (или какая-то программа хулиганская) сбросила SUID-бит у
ping?

-- 
With best regards
  Maksim Dmitrichenko

Re: Что-то странное произошло с сетью

2021-11-20 Пенетрантность Алексей Витальевич Коротков

On Sat, 20 Nov 2021 at 18:28, Алексей Витальевич Коротков wrote:

> BOOT_IMAGE=/boot/vmlinuz-5.5.0-0.bpo.2-amd64

Что-то больно старое ядро... В stable и то новее, судя по
https://packages.debian.org/search?keywords=linux-image-amd64.

> почему до вчерашнего дня всё было отлично? Обновление iproute2 повлияло?

Всё может быть. Вполне возможно, что новый iproute2 c Вашим ядром не
до конца совместим. Также учитывая что IPv6 сейчас везде включают по
умолчанию, нисколько не удивлюсь, если без него особо не проверяют
работоспособность сетевых программ.

С другой стороны, разведение зоопарка из разных репозиториев пакетов -
не очень хорошая идея, если нет чёткого понимания зачем это делается,
и как они друг с другом уживаются. В Вашем случае, я бы посоветовал
перейти на чистый stable, удалив/переустановив всё, что сейчас
установлено не оттуда (apt list --installed | grep -v /stable). Не так
уж много времени прошло со времени последнего релиза, чтобы пытаться
бежать впереди паровоза.

--
...Bye..Dmitry.

Re: Что-то странное произошло с сетью

On Sat, 20 Nov 2021 16:42:56 +0300
Dmitry Semyonov wrote:

DS> cat /proc/cmdline
DS> grep . /proc/sys/net/ipv6/conf/*/disable_ipv6

# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.5.0-0.bpo.2-amd64 
root=UUID=8a87c5eb-a97e-4f53-8f42-05e8d2700c5e ro ipv6.disable=1 quiet
# grep . /proc/sys/net/ipv6/conf/*/disable_ipv6
grep: /proc/sys/net/ipv6/conf/*/disable_ipv6: Нет такого файла или каталога

DS> А так?
DS> ping -4 ...

$ ping -4 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.326 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.356 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.292 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.359 ms
^C
--- 192.168.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3074ms
rtt min/avg/max/mdev = 0.292/0.333/0.359/0.027 ms

Похоже, что угадали. Но тогда вопрос: почему до вчерашнего для всё было
отлично? Обновление iproute2 повлияло?

Re: Что-то странное произошло с сетью

2021-11-20 Пенетрантность Алексей Витальевич Коротков

On Sat, 20 Nov 2021 14:28:15 +0200
Oleg Chernov wrote:

Добрый вечер,

OC> вот эта строчка из Вашего strace.txt наводит на мысль о SELinux
OC> (или файерволле)

SELinux не используется, файерволл не включен.

Re: Что-то странное произошло с сетью

2021-11-20 Пенетрантность Алексей Витальевич Коротков

On Sat, 20 Nov 2021 19:15:58 +0700
Max Nikulin wrote:

MN> У меня провайдер недавно чудил. Отдавал 2 DNS сервера, второй
MN> работал нормально, а первый с заметной долей с первого раза не мог
MN> отдать адрес. Если адрес уже был в кэше, то все работало. Может
MN> совпадение, но потом видел в новостях, про учения по изоляции
MN> рунета примерно в эти же дни.

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

MN> Попробуйте по нескольку раз команды с DNS серверами провайдера

У меня DNS от Яндекса и Гугла. 

MN> time dig @YOUR_DNS +tries=1 +retry=0 -t A SOME_HOST
MN> 
MN> Примерно такой командой я собирал статистику:
MN> time dig @YOUR_DNS +short +noanswer +tries=1 +retry=0 -t A
MN> SOME_HOST ; echo "Exit code $?"

Вот, например:
# time dig 77.88.8.8 +short +noanswer +tries=1 +retry=0 -t A
security.debian.org 151.101.66.132
151.101.194.132
151.101.2.132
151.101.130.132

real0m0,209s
user0m0,019s
sys 0m0,011s
# echo "Exit code $?"
Exit code 0

# time dig 77.88.8.8 +short +noanswer +tries=1 +retry=0 -t A
cloud.r-project.org ;; Warning: Client COOKIE mismatch
d3caqzu56oq2n9.cloudfront.net.
13.33.246.115
13.33.246.110
13.33.246.114
13.33.246.67

real0m0,228s
user0m0,010s
sys 0m0,016s
# echo "Exit code $?"
Exit code 0

MN> Подозрение, что
MN>  ping: socket: Семейство адресов не поддерживается протоколом
MN> это отдельная проблема, а на соседнем сервере проблема не так
MN> заметна, потому что там зоопарк репозиториев меньше.

Она появилась одновременно со всем остальным. Т.е. все сетевые
программы стали работать криво одновременно.

Re: Что-то странное произошло с сетью


On 20/11/2021 20:29, Dmitry Semyonov wrote:

On Sat, 20 Nov 2021 at 15:34, Oleg Chernov wrote:


socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP) = -1 EACCES (Permission
denied)

вот эта строчка из Вашего strace.txt наводит на мысль о SELinux (или
файерволле)


Или о том, что strace и "sudo strace -u $USER" ведут себя по-разному.


Я это сразу не заметил, но это подтверждение моей догадки, что ping.txt 
делался в одних условиях (ругнулся, но пакет отправил), а


LANG=en_US.UTF-8 strace -s64 ping -c 1 192.168.1.1 > strace.txt 2>&1

в других - ping не смог отправить пакет, потому что не дали открыть ни 
один сокет (ошибку он показал только для последней попытки, которая была 
по IPv6). У меня локально похожая команда отработала без проблем, 
поэтому начал подозревать, что по ошибке ее выполнили, скажем, из qemu, 
которому не дали серевой интерфейс, поэтому ему не хватает прав для icmp.

Re: Что-то странное произошло с сетью

On Sat, 20 Nov 2021 at 10:20, Алексей Витальевич Коротков wrote:

> У меня отключён IPv6 (через GRUB).

Точно?

cat /proc/cmdline
grep . /proc/sys/net/ipv6/conf/*/disable_ipv6
ip a | grep inet6

> И при обращении по IP, кстати, проблема та же.

А так?

ping -4 192.168.1.1

-- 
...Bye..Dmitry.

Re: Что-то странное произошло с сетью

On Sat, 20 Nov 2021 at 10:20, Алексей Витальевич Коротков wrote:

> У меня отключён IPv6 (через GRUB).

Точно?

cat /proc/cmdline
grep . /proc/sys/net/ipv6/conf/*/disable_ipv6

> И при обращении по IP, кстати, проблема та же.

А так?
ping -4 ...

-- 
...Bye..Dmitry.

Re: Что-то странное произошло с сетью

On Sat, 20 Nov 2021 at 15:34, Oleg Chernov wrote:

> socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP) = -1 EACCES (Permission
> denied)
>
> вот эта строчка из Вашего strace.txt наводит на мысль о SELinux (или
> файерволле)

Или о том, что strace и "sudo strace -u $USER" ведут себя по-разному.

-- 
...Bye..Dmitry.

Re: Что-то странное произошло с сетью

2021-11-20 Пенетрантность Oleg Chernov


Здравствуйте,

On 20-11-2021 11:39, Алексей Витальевич Коротков wrote:

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



socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP) = -1 EACCES (Permission 
denied)


вот эта строчка из Вашего strace.txt наводит на мысль о SELinux (или 
файерволле)




--
Best regards,
Oleg A. Chernov
OAC4-RIPE
WildPark ISP, Nikolaev, Ukraine
+380512 709555

Re: Что-то странное произошло с сетью

2021-11-20 Пенетрантность Алексей Витальевич Коротков


On 20/11/2021 18:36, Алексей Витальевич Коротков wrote:

* Could not resolve host: cloud.r-project.org
* Closing connection 0
curl: (6) Could not resolve host: cloud.r-project.org


У меня провайдер недавно чудил. Отдавал 2 DNS сервера, второй работал 
нормально, а первый с заметной долей с первого раза не мог отдать адрес. 
Если адрес уже был в кэше, то все работало. Может совпадение, но потом 
видел в новостях, про учения по изоляции рунета примерно в эти же дни.


Попробуйте по нескольку раз команды с DNS серверами провайдера и 
*разными* SOME_HOST, которые с малой вероятностью спрашивают другие 
пользователи (например, из списка зеркал debian)


time dig @YOUR_DNS +tries=1 +retry=0 -t A SOME_HOST

Примерно такой командой я собирал статистику:
time dig @YOUR_DNS +short +noanswer +tries=1 +retry=0 -t A SOME_HOST ; 
echo "Exit code $?"


Подозрение, что
ping: socket: Семейство адресов не поддерживается протоколом
это отдельная проблема, а на соседнем сервере проблема не так заметна, 
потому что там зоопарк репозиториев меньше.

Re: Что-то странное произошло с сетью

On Sat, 20 Nov 2021 17:04:44 +0700
Max Nikulin wrote:

MN> Кажется, ping не знает, что IPv6 отключен в grub

До вчерашнего дня знал. И настройки я не менял никакие.

MN> Можно еще почитать
MN> curl -v -I 
MN> http://cloud.r-project.org/bin/linux/debian/bullseye-cran40/InRelease
MN> ну и из-под strace уже без -v

$ curl -v -I
http://cloud.r-project.org/bin/linux/debian/bullseye-cran40/InRelease

С первой попытки не соединяется (curle.txt).

Со второй проходит (curlr.txt).

Со strace (curls.txt).

MN> Нет ли тут какого-нибудь proxy (например, для apt)?

Экспериментировал с proxy, но это было ещё в прошлом году, сейчас нет
его. Есть только переменная окружения no_proxy, но она не влияет, так
как proxy нет.

MN> ip address list
MN> ip link list
MN> ничего подозрительного не показывают?

Вроде, нет.
* Uses proxy env variable no_proxy == 'localhost,127.0.0.1,192.168.1.3'
* Could not resolve host: cloud.r-project.org
* Closing connection 0
curl: (6) Could not resolve host: cloud.r-project.org
* Uses proxy env variable no_proxy == 'localhost,127.0.0.1,192.168.1.3'
#=O#- # 
 
##O=#   #   
 
*   Trying 13.33.246.110:80...
* Connected to cloud.r-project.org (13.33.246.110) port 80 (#0)
> HEAD /bin/linux/debian/bullseye-cran40/InRelease HTTP/1.1
> Host: cloud.r-project.org
> User-Agent: curl/7.74.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Length: 4399
< Connection: keep-alive
< Server: Apache/2.4.39 (Unix)
< Last-Modified: Tue, 16 Nov 2021 11:50:10 GMT
< Accept-Ranges: bytes
< Date: Sat, 20 Nov 2021 11:01:31 GMT
< Expires: Sat, 20 Nov 2021 11:31:31 GMT
< Cache-Control: max-age=1800
< ETag: "112f-5d0e6870901bb"
< X-Cache: Hit from cloudfront
< Via: 1.1 71208833688838f959b0e70682af50b3.cloudfront.net (CloudFront)
< X-Amz-Cf-Pop: HEL50-C1
< X-Amz-Cf-Id: sViAQXuriD7890FHp-vPzFoL9PTMOy4LgL9FC_S2I6Pr2kxPGHuo6A==
< Age: 327
< 
* Connection #0 to host cloud.r-project.org left intact
HTTP/1.1 200 OK
Content-Length: 4399
Connection: keep-alive
Server: Apache/2.4.39 (Unix)
Last-Modified: Tue, 16 Nov 2021 11:50:10 GMT
Accept-Ranges: bytes
Date: Sat, 20 Nov 2021 11:01:31 GMT
Expires: Sat, 20 Nov 2021 11:31:31 GMT
Cache-Control: max-age=1800
ETag: "112f-5d0e6870901bb"
X-Cache: Hit from cloudfront
Via: 1.1 71208833688838f959b0e70682af50b3.cloudfront.net (CloudFront)
X-Amz-Cf-Pop: HEL50-C1
X-Amz-Cf-Id: sViAQXuriD7890FHp-vPzFoL9PTMOy4LgL9FC_S2I6Pr2kxPGHuo6A==
Age: 327


execve("/usr/bin/curl", ["curl", "-I", "http://cloud.r-project.org/bin/l";...], 
0x7fff3e5f5420 /* 84 vars */) = 0
brk(NULL)   = 0x5564e3622000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (ÐÐµÑ ÑÐ°ÐºÐ¾Ð³Ð¾ 
ÑÐ°Ð¹Ð»Ð° Ð¸Ð»Ð¸ ÐºÐ°ÑÐ°Ð»Ð¾Ð³Ð°)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=257901, ...}) = 0
mmap(NULL, 257901, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f811050
close(3)= 0
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libcurl.so.4", O_RDONLY|O_CLOEXEC) 
= 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\17\1\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=628232, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f81104fe000
mmap(NULL, 631416, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f8110463000
mmap(0x7f8110472000, 425984, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf000) = 0x7f8110472000
mmap(0x7f81104da000, 118784, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x77000) = 0x7f81104da000
mmap(0x7f81104f7000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x93000) = 0x7f81104f7000
mmap(0x7f81104fd000, 632, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f81104fd000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0203\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=113088, ...}) = 0
mmap(NULL, 115088, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f8110446000
mprotect(0x7f8110449000, 98304, PROT_NONE) = 0
mmap(0x7f8110449000, 69632, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f8110449000
mmap(0x7f811045a000, 24576, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x14000) = 0x7f811045a000
mmap(0x7f8110461000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a000) = 0x7f8110461000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 
3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 |\0\0\0\0\0\0"..., 832) 
= 832
fstat(3, {st_mode=S_IFREG|0755, st_size=149520, ...})

Re: Что-то странное произошло с сетью

2021-11-20 Пенетрантность Алексей Витальевич Коротков

On Sat, 20 Nov 2021 13:06:58 +0300
Tull Jethro wrote:

TJ> Чисто предположение: а то, что является роутером правильно
TJ> адреса/настройки через DHCP отдало?

Я не использую DHCP, адреса постоянные.

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

Кстати, письма не только получать, но и отправлять получается тоже
только со второй попытки.

Re: Что-то странное произошло с сетью

2021-11-20 Пенетрантность Tull Jethro

Чисто предположение: а то, что является роутером правильно
адреса/настройки через DHCP отдало?

сб, 20 нояб. 2021 г. в 12:42, Алексей Витальевич Коротков
:
>
> On Sat, 20 Nov 2021 15:32:37 +0700
> Max Nikulin wrote:
>
> MN> Подозрение, что где-то что-то отключили лишнего.
>
> Вряд ли. Ничего не трогал из настроек давно, и вплоть до вчерашнего дня
> всё работало идеально.
>
> MN> На английском проще будет сопоставить текст с кодом ошибки
> MN>
> MN> LANG=en_US.UTF-8 ping -с 1 192.168.1.1
>
> Вложил ping.txt от команды
> LANG=en_US.UTF-8 ping -c 1 192.168.1.1 > ping.txt 2>&1
>
> MN> А еще лучше то же самое из под strace (возможно, с -s64) чтобы
> MN> видно было системный вызов и с какими аргументами возникает ошибка.
>
> Вложил strace.txt от команды
> LANG=en_US.UTF-8 strace -s64 ping -c 1 192.168.1.1 > strace.txt 2>&1
>
> MN> Не уверен, что с debug или verbose ping расскажет про ошибку
> MN> больше. Еще можно попробовать другие команды, которые можно сделать
> MN> более разговорчивыми, например curl -v -I 192.168.1.1
>
> Вложил curl.txt от команды
> curl -v -I 192.168.1.1 > curl.txt 2>&1
>
> getmail вот такую ошибку выдаёт
> socket error ([Errno 97] Address family not supported by protocol)
> но со второго раза отрабатывает.
>
> ПС. Из вчерашнего обновления приехало iproute2:amd64 (5.14.0-1~bpo11+1,
> 5.15.0-1~bpo11+1).

Re: Что-то странное произошло с сетью

2021-11-20 Пенетрантность Алексей Витальевич Коротков


On 20/11/2021 16:39, Алексей Витальевич Коротков wrote:

У меня отключён IPv6 (через GRUB).



socket(AF_INET6, SOCK_DGRAM, IPPROTO_ICMPV6) = -1 EAFNOSUPPORT (Address family 
not supported by protocol)


Кажется, ping не знает, что IPv6 отключен в grub, и пытается его 
использовать. Меня правда немного настораживает, что в strace.txt я не 
вижу следов успешно принятого пакета.


curl, похоже, увидев IPv4 адрес, не пытался что-то делать с IPv6 и 
отрабатывает без ошибок.


Можно еще почитать
curl -v -I 
http://cloud.r-project.org/bin/linux/debian/bullseye-cran40/InRelease

ну и из-под strace уже без -v

Нет ли тут какого-нибудь proxy (например, для apt)?

ip address list
ip link list
ничего подозрительного не показывают?

Re: Что-то странное произошло с сетью

On Sat, 20 Nov 2021 15:32:37 +0700
Max Nikulin wrote:

MN> Подозрение, что где-то что-то отключили лишнего.

Вряд ли. Ничего не трогал из настроек давно, и вплоть до вчерашнего дня
всё работало идеально.

MN> На английском проще будет сопоставить текст с кодом ошибки
MN> 
MN> LANG=en_US.UTF-8 ping -с 1 192.168.1.1

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

MN> А еще лучше то же самое из под strace (возможно, с -s64) чтобы
MN> видно было системный вызов и с какими аргументами возникает ошибка.

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

MN> Не уверен, что с debug или verbose ping расскажет про ошибку
MN> больше. Еще можно попробовать другие команды, которые можно сделать
MN> более разговорчивыми, например curl -v -I 192.168.1.1

Вложил curl.txt от команды
curl -v -I 192.168.1.1 > curl.txt 2>&1

getmail вот такую ошибку выдаёт
socket error ([Errno 97] Address family not supported by protocol)
но со второго раза отрабатывает.

ПС. Из вчерашнего обновления приехало iproute2:amd64 (5.14.0-1~bpo11+1,
5.15.0-1~bpo11+1).
ping: socket: Address family not supported by protocol
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.270 ms

--- 192.168.1.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.270/0.270/0.270/0.000 ms
execve("/bin/ping", ["ping", "-c", "1", "192.168.1.1"], 0x7fffe9a2b7a0 /* 84 
vars */) = 0
access("/etc/suid-debug", F_OK) = -1 ENOENT (No such file or directory)
brk(NULL)   = 0x55bb6cb54000
fcntl(0, F_GETFD)   = 0
fcntl(1, F_GETFD)   = 0
fcntl(2, F_GETFD)   = 0
access("/etc/suid-debug", F_OK) = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=257901, ...}) = 0
mmap(NULL, 257901, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ffb6f4e3000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libcap.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\3203\0\0\0\0\0\0@\0\0\0\0\0\0\0P\221\0\0\0\0\0\0\0\0\0\0@\08\0\t\0@\0\32\0\31\0"...,
 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=38864, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7ffb6f4e1000
mmap(NULL, 41016, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ffb6f4d6000
mmap(0x7ffb6f4d9000, 16384, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7ffb6f4d9000
mmap(0x7ffb6f4dd000, 8192, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x7000) = 0x7ffb6f4dd000
mmap(0x7ffb6f4df000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8000) = 0x7ffb6f4df000
close(3)= 0
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libidn2.so.0", O_RDONLY|O_CLOEXEC) 
= 3
read(3, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\"\0\0\0\0\0\0@\0\0\0\0\0\0\\361\1\0\0\0\0\0\0\0\0\0@\08\0\t\0@\0\32\0\31\0"...,
 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=128944, ...}) = 0
mmap(NULL, 131096, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ffb6f4b5000
mmap(0x7ffb6f4b7000, 16384, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7ffb6f4b7000
mmap(0x7ffb6f4bb000, 102400, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x6000) = 0x7ffb6f4bb000
mmap(0x7ffb6f4d4000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e000) = 0x7ffb6f4d4000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libresolv.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, 
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260C\0\0\0\0\0\0@\0\0\0\0\0\0\0\310c\1\0\0\0\0\0\0\0\0\0@\08\0\t\0@\0\36\0\35\0"...,
 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=93000, ...}) = 0
mmap(NULL, 105088, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ffb6f49b000
mprotect(0x7ffb6f49f000, 73728, PROT_NONE) = 0
mmap(0x7ffb6f49f000, 57344, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0x7ffb6f49f000
mmap(0x7ffb6f4ad000, 12288, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x12000) = 0x7ffb6f4ad000
mmap(0x7ffb6f4b1000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = 0x7ffb6f4b1000
mmap(0x7ffb6f4b3000, 6784, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ffb6f4b3000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, 
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@n\2\0\0\0\0\0@\0\0\0\0\0\0\0p\2\34\0\0\0\0\0\0\0\0\0@\08\0\f\0@\0A\0@\0"...,
 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1839792, ...}) = 0
mmap(NULL, 1852680, P

Re: Что-то странное произошло с сетью

2021-11-19 Пенетрантность Алексей Витальевич Коротков


On 20/11/2021 14:19, Алексей Витальевич Коротков wrote:

У меня отключён IPv6 (через GRUB).


Подозрение, что где-то что-то отключили лишнего. Может, через sysctl


И при обращении по IP, кстати, проблема та же. Так что совет выше про
настройки /etc/resolv.conf в моей проблеме неактуален.

$ ping 192.168.1.1
ping: socket: Семейство адресов не поддерживается протоколом


На английском проще будет сопоставить текст с кодом ошибки

LANG=en_US.UTF-8 ping -с 1 192.168.1.1

А еще лучше то же самое из под strace (возможно, с -s64) чтобы видно 
было системный вызов и с какими аргументами возникает ошибка.


Не уверен, что с debug или verbose ping расскажет про ошибку больше. Еще 
можно попробовать другие команды, которые можно сделать более 
разговорчивыми, например curl -v -I 192.168.1.1

Re: Что-то странное произошло с сетью

On Sat, 20 Nov 2021 12:36:45 +0700
Max Nikulin wrote:

MN> Можно вот здесь подкрутить, но проблема где-то в другом месте. По 
MN> крайней мере, позволит работать, пока не станет понятно, что именно 
MN> сломалось.
MN> 
MN> /etc/gai.conf
MN> #For sites which prefer IPv4 connections change the last line to
MN> #
MN> # precedence :::0:0/96  100

У меня отключён IPv6 (через GRUB).

И при обращении по IP, кстати, проблема та же. Так что совет выше про
настройки /etc/resolv.conf в моей проблеме неактуален.

$ ping 192.168.1.1
ping: socket: Семейство адресов не поддерживается протоколом
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.324 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.417 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.309 ms
^C
--- 192.168.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2040ms
rtt min/avg/max/mdev = 0.309/0.350/0.417/0.047 ms

Re: Что-то странное произошло с сетью

2021-11-19 Пенетрантность Max Nikulin


On 19/11/2021 21:44, Алексей Витальевич Коротков wrote:

On Fri, 19 Nov 2021 17:04:43 +0300
Victor Wagner wrote:

VW> Такое впечатление что почему-то машина разучилась работать по
VW> протколоу IPv4, и хочет до всего достукиваться только по IPv6.

Где/что смотреть тогда?


Можно вот здесь подкрутить, но проблема где-то в другом месте. По 
крайней мере, позволит работать, пока не станет понятно, что именно 
сломалось.


/etc/gai.conf
#For sites which prefer IPv4 connections change the last line to
#
# precedence :::0:0/96  100

Re: Что-то странное произошло с сетью

2021-11-19 Пенетрантность Алексей Витальевич Коротков

On Fri, 19 Nov 2021 19:10:36 +0300
Andrey Jr. Melnikov wrote:

AJM> В /etc/resolv.conf для начала.

$ cat /etc/resolv.conf
nameserver 192.168.1.1
search desktop

Тот же nameserver на домашнем сервере (это адрес роутера), и там всё
работает без проблем.

Re: Что-то странное произошло с сетью

2021-11-19 Пенетрантность Andrey Jr. Melnikov

Алексей Витальевич Коротков  wrote:
> On Fri, 19 Nov 2021 17:04:43 +0300
> Victor Wagner wrote:

> VW> Такое впечатление что почему-то машина разучилась работать по
> VW> протколоу IPv4, и хочет до всего достукиваться только по IPv6.

> Где/что смотреть тогда?

В /etc/resolv.conf для начала.

Re: Что-то странное произошло с сетью

2021-11-19 Пенетрантность Алексей Витальевич Коротков

On Fri, 19 Nov 2021 17:04:43 +0300
Victor Wagner wrote:

VW> Такое впечатление что почему-то машина разучилась работать по
VW> протколоу IPv4, и хочет до всего достукиваться только по IPv6.

Где/что смотреть тогда?

Re: Что-то странное произошло с сетью

2021-11-19 Пенетрантность Victor Wagner

В Fri, 19 Nov 2021 17:21:42 +0400
Алексей Витальевич Коротков  пишет:

> Приветствую.
> 
> Какая-то непонятная бурда с сетью.
> 
> Произошло в точности не заметил когда, но в последние дни. Может,
> вчера.
> 
> Вот так примерно работают пинги (вложение ping.txt).
> 
> А вот так попытка обновить пакетную базу (вложение apt.txt).
> 
> В браузере веб-страницы открываются, но не все сразу, некоторые только
> со второй попытки.

Такое впечатление что почему-то машина разучилась работать по протколоу
IPv4, и хочет до всего достукиваться только по IPv6.
--

Что-то странное произошло с сетью

2021-11-19 Пенетрантность Алексей Витальевич Коротков

Приветствую.

Какая-то непонятная бурда с сетью.

Произошло в точности не заметил когда, но в последние дни. Может, вчера.

Вот так примерно работают пинги (вложение ping.txt).

А вот так попытка обновить пакетную базу (вложение apt.txt).

В браузере веб-страницы открываются, но не все сразу, некоторые только
со второй попытки.

Debian stable с бэкпортами.

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

Никакие настройки, связанные с сетью, в последнее время не трогал.

Куда копать?
$ ping google.com
ping: socket: Ð¡ÐµÐ¼ÐµÐ¹ÑÑÐ²Ð¾ Ð°Ð´ÑÐµÑÐ¾Ð² Ð½Ðµ 
Ð¿Ð¾Ð´Ð´ÐµÑÐ¶Ð¸Ð²Ð°ÐµÑÑÑ Ð¿ÑÐ¾ÑÐ¾ÐºÐ¾Ð»Ð¾Ð¼
ping: google.com: ÐÐµÐ¸Ð·Ð²ÐµÑÑÐ½Ð¾Ðµ Ð¸Ð¼Ñ Ð¸Ð»Ð¸ ÑÐ»ÑÐ¶Ð±Ð°
$ ping google.com
ping: socket: Ð¡ÐµÐ¼ÐµÐ¹ÑÑÐ²Ð¾ Ð°Ð´ÑÐµÑÐ¾Ð² Ð½Ðµ 
Ð¿Ð¾Ð´Ð´ÐµÑÐ¶Ð¸Ð²Ð°ÐµÑÑÑ Ð¿ÑÐ¾ÑÐ¾ÐºÐ¾Ð»Ð¾Ð¼
ping: google.com: ÐÐµÐ¸Ð·Ð²ÐµÑÑÐ½Ð¾Ðµ Ð¸Ð¼Ñ Ð¸Ð»Ð¸ ÑÐ»ÑÐ¶Ð±Ð°
$ ping google.com
ping: socket: Ð¡ÐµÐ¼ÐµÐ¹ÑÑÐ²Ð¾ Ð°Ð´ÑÐµÑÐ¾Ð² Ð½Ðµ 
Ð¿Ð¾Ð´Ð´ÐµÑÐ¶Ð¸Ð²Ð°ÐµÑÑÑ Ð¿ÑÐ¾ÑÐ¾ÐºÐ¾Ð»Ð¾Ð¼
PING google.com (173.194.222.113) 56(84) bytes of data.
64 bytes from lo-in-f113.1e100.net (173.194.222.113): icmp_seq=1 ttl=54 
time=80.0 ms
64 bytes from lo-in-f113.1e100.net (173.194.222.113): icmp_seq=2 ttl=54 
time=65.3 ms
64 bytes from lo-in-f113.1e100.net (173.194.222.113): icmp_seq=3 ttl=54 
time=78.7 ms
64 bytes from lo-in-f113.1e100.net (173.194.222.113): icmp_seq=4 ttl=54 
time=78.6 ms
^C
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 65.310/75.658/80.036/6.002 ms
root@desktop:~# aptitude -t bullseye-backports update 
ÐÑÐ¸Ð± https://download.sublimetext.com apt/stable/ InRelease
  Ð§ÑÐ¾-ÑÐ¾ ÑÑÑÐ°Ð½Ð½Ð¾Ðµ Ð¿ÑÐ¾Ð¸Ð·Ð¾ÑÐ»Ð¾ Ð¿ÑÐ¸ ÑÐ°Ð·ÑÐµÑÐµÐ½Ð¸Ð¸ 
Â«download.sublimetext.com:httpsÂ» (-5 - Ð¡ Ð¸Ð¼ÐµÐ½ÐµÐ¼ ÑÐ·Ð»Ð° Ð½Ðµ 
ÑÐ²ÑÐ·Ð°Ð½Ð¾ Ð½Ð¸ Ð¾Ð´Ð½Ð¾Ð³Ð¾ Ð°Ð´ÑÐµÑÐ°)
ÐÑÐ¸Ð± https://mkvtoolnix.download/debian bullseye InRelease  
  
  Ð§ÑÐ¾-ÑÐ¾ ÑÑÑÐ°Ð½Ð½Ð¾Ðµ Ð¿ÑÐ¾Ð¸Ð·Ð¾ÑÐ»Ð¾ Ð¿ÑÐ¸ ÑÐ°Ð·ÑÐµÑÐµÐ½Ð¸Ð¸ 
Â«mkvtoolnix.download:httpsÂ» (-5 - Ð¡ Ð¸Ð¼ÐµÐ½ÐµÐ¼ ÑÐ·Ð»Ð° Ð½Ðµ 
ÑÐ²ÑÐ·Ð°Ð½Ð¾ Ð½Ð¸ Ð¾Ð´Ð½Ð¾Ð³Ð¾ Ð°Ð´ÑÐµÑÐ°)
ÐÑÐ¸Ð± https://packages.microsoft.com/repos/vscode stable InRelease   
  
  Ð§ÑÐ¾-ÑÐ¾ ÑÑÑÐ°Ð½Ð½Ð¾Ðµ Ð¿ÑÐ¾Ð¸Ð·Ð¾ÑÐ»Ð¾ Ð¿ÑÐ¸ ÑÐ°Ð·ÑÐµÑÐµÐ½Ð¸Ð¸ 
Â«packages.microsoft.com:httpsÂ» (-5 - Ð¡ Ð¸Ð¼ÐµÐ½ÐµÐ¼ ÑÐ·Ð»Ð° Ð½Ðµ 
ÑÐ²ÑÐ·Ð°Ð½Ð¾ Ð½Ð¸ Ð¾Ð´Ð½Ð¾Ð³Ð¾ Ð°Ð´ÑÐµÑÐ°)
ÐÐ· ÐºÑÑÐ° http://mirror.yandex.ru/debian bullseye InRelease 

ÐÑÐ¸Ð± http://cloud.r-project.org/bin/linux/debian bullseye-cran40/ InRelease 
  
  Ð§ÑÐ¾-ÑÐ¾ ÑÑÑÐ°Ð½Ð½Ð¾Ðµ Ð¿ÑÐ¾Ð¸Ð·Ð¾ÑÐ»Ð¾ Ð¿ÑÐ¸ ÑÐ°Ð·ÑÐµÑÐµÐ½Ð¸Ð¸ 
Â«cloud.r-project.org:httpÂ» (-5 - Ð¡ Ð¸Ð¼ÐµÐ½ÐµÐ¼ ÑÐ·Ð»Ð° Ð½Ðµ ÑÐ²ÑÐ·Ð°Ð½Ð¾ 
Ð½Ð¸ Ð¾Ð´Ð½Ð¾Ð³Ð¾ Ð°Ð´ÑÐµÑÐ°)
ÐÑÐ¸Ð± https://download.virtualbox.org/virtualbox/debian bullseye InRelease
  Ð§ÑÐ¾-ÑÐ¾ ÑÑÑÐ°Ð½Ð½Ð¾Ðµ Ð¿ÑÐ¾Ð¸Ð·Ð¾ÑÐ»Ð¾ Ð¿ÑÐ¸ ÑÐ°Ð·ÑÐµÑÐµÐ½Ð¸Ð¸ 
Â«download.virtualbox.org:httpsÂ» (-5 - Ð¡ Ð¸Ð¼ÐµÐ½ÐµÐ¼ ÑÐ·Ð»Ð° Ð½Ðµ 
ÑÐ²ÑÐ·Ð°Ð½Ð¾ Ð½Ð¸ Ð¾Ð´Ð½Ð¾Ð³Ð¾ Ð°Ð´ÑÐµÑÐ°)
ÐÑÐ¸Ð± http://dl.google.com/linux/chrome/deb stable InRelease
  Ð§ÑÐ¾-ÑÐ¾ ÑÑÑÐ°Ð½Ð½Ð¾Ðµ Ð¿ÑÐ¾Ð¸Ð·Ð¾ÑÐ»Ð¾ Ð¿ÑÐ¸ ÑÐ°Ð·ÑÐµÑÐµÐ½Ð¸Ð¸ 
Â«dl.google.com:httpÂ» (-5 - Ð¡ Ð¸Ð¼ÐµÐ½ÐµÐ¼ ÑÐ·Ð»Ð° Ð½Ðµ ÑÐ²ÑÐ·Ð°Ð½Ð¾ Ð½Ð¸ 
Ð¾Ð´Ð½Ð¾Ð³Ð¾ Ð°Ð´ÑÐµÑÐ°)
ÐÑÐ¸Ð± https://desktop-download.mendeley.com/download/apt stable InRelease
  Ð§ÑÐ¾-ÑÐ¾ ÑÑÑÐ°Ð½Ð½Ð¾Ðµ Ð¿ÑÐ¾Ð¸Ð·Ð¾ÑÐ»Ð¾ Ð¿ÑÐ¸ ÑÐ°Ð·ÑÐµÑÐµÐ½Ð¸Ð¸ 
Â«desktop-download.mendeley.com:httpsÂ» (-5 - Ð¡ Ð¸Ð¼ÐµÐ½ÐµÐ¼ ÑÐ·Ð»Ð° Ð½Ðµ 
ÑÐ²ÑÐ·Ð°Ð½Ð¾ Ð½Ð¸ Ð¾Ð´Ð½Ð¾Ð³Ð¾ Ð°Ð´ÑÐµÑÐ°)
ÐÑÐ¸Ð± http://debian.neo4j.org/repo stable/ InRelease
  Ð§ÑÐ¾-ÑÐ¾ ÑÑÑÐ°Ð½Ð½Ð¾Ðµ Ð¿ÑÐ¾Ð¸Ð·Ð¾ÑÐ»Ð¾ Ð¿ÑÐ¸ ÑÐ°Ð·ÑÐµÑÐµÐ½Ð¸Ð¸ 
Â«debian.neo4j.org:httpÂ» (-5 - Ð¡ Ð¸Ð¼ÐµÐ½ÐµÐ¼ ÑÐ·Ð»Ð° Ð½Ðµ ÑÐ²ÑÐ·Ð°Ð½Ð¾ 
Ð½Ð¸ Ð¾Ð´Ð½Ð¾Ð³Ð¾ Ð°Ð´ÑÐµÑÐ°)
ÐÐ¾Ð»ÑÑÐ¸ÑÑ: 1 http://mirror.yandex.ru/debian bullseye-updates InRelease 
[39,4 kB]   
ÐÐ¾Ð»ÑÑÐ¸ÑÑ: 2 http://www.geogebra.net/linux stable InRelease [8â¯690 B]  

ÐÐ· ÐºÑÑÐ° http://packages.x2go.org/debian bullseye InRelease

ÐÑÐ¸Ð± http://apt.postgresql.org/pub/repos/apt bullseye-pgdg InRelease
  
  Ð§ÑÐ¾-ÑÐ¾ ÑÑÑÐ°Ð½Ð½Ð¾Ðµ Ð¿ÑÐ¾Ð¸Ð·Ð¾ÑÐ»Ð¾ Ð¿ÑÐ¸ ÑÐ°Ð·ÑÐµÑÐµÐ½Ð¸Ð¸ 
Â«apt.postgresql.org:httpÂ» (-5 - Ð¡ Ð¸Ð¼ÐµÐ½ÐµÐ¼ ÑÐ·Ð»Ð° Ð½Ðµ ÑÐ²ÑÐ·Ð°Ð½Ð¾ 
Ð½Ð¸ Ð¾Ð´Ð½Ð¾Ð³Ð¾ Ð°Ð´ÑÐµÑÐ°)
ÐÐ¾Ð»ÑÑÐ¸ÑÑ: 3 http://ftp.debian.org/debian bullseye-backports InRelease 
[43,7 kB]  
ÐÐ· ÐºÑÑÐ° http://repo.percona.com/percona/apt bullseye InRelease
  
ÐÐ· ÐºÑÑÐ° ht

Re: Странное поведение TCP

2015-10-17 Пенетрантность sergio


On 09/29/2015 09:00 AM, Max Dmitrichenko wrote:


согласно протокола


Предлог согласно в современном русском языке требует дательного падежа, 
правильно: согласно чему, не чего. Уже в XIX веке конструкция согласно 
чего, то есть с родительным падежом, расценивалась как характерная 
примета официально-деловой, канцелярской речи. А в современном русском 
языке она не является нормативной и для официально-делового стиля. 
Сейчас правильно только: согласно чему, то есть с дательным падежом.


http://new.gramota.ru/spravka/buro/hot10/


--
sergio

Re: Странное поведение TCP

2015-09-30 Пенетрантность Max Dmitrichenko

29 сентября 2015 г., 23:21 пользователь Andrey Melnikoff
 написал:
> Так запиши дамп без пайлоада. Нужны то только L2+L3 хидера.

Да разобрались уже, что железка виноватая. Спасибо всем за внимание.

--
With best regards
  Max Dmitrichenko

Re: Странное поведение TCP

2015-09-29 Пенетрантность Oleksandr Gavenko

On 2015-09-29, Max Dmitrichenko wrote:

>>  Если я правильно понял эту фразу, от сервера после RST идёт ожидаемый
>>  ответ приложения. Это свидетельствует о том, что RST посылает не ядро
>>  сервера, а некая посторонняя программа, прослушивающая трафик где-то
>>  между клиентом и сервером.
>
> Приходит не ответ приложения, а просто TCP-шный ACK, на посланные
> клиентом данные. Причем у него TTL тоже 125. Версия с вражеской
> железкой на пути меня давно посетила. Просто не понятно, для чего
> такая железка может применятся.

Работал я в одном банке программистом с обязанностями поддержки сопровождаемых
комплексов.

Когда постили тикет во внутреннем  Redmine со словом SELECT (пользователь
вставил содерж. диагностич. сообщения) - запрос не доходил до сервера.

Девопсы никак не смогли помочь, сетевики в силу забюрократизированости
недоступны рядовому разрабу. В общем мы перевели сервис на HTTPS ))

Далее была машинка, с которой иногда были RST, как у вас, но без какой либо
явной связи. И мучились мы пол года, девопсы полчали, достукавшись до
сетевиков - крестились что ничего нету, в общем раскидав красивые скриншоты от
wireshark со стрелочками и пояснениями бяки по "менедженту" нам в итоге
сказали что было установлены железки от DDos защиты (для внутрикорпоративного
трафика cis!). Спустя пару дней хост згорел, сервисы перенесли на другой хост
в другой сети и проблемы исчезли.

В обоих случаях пакостили безопасники, обладая большими полномочиями ни перед
кем не отчитываются + топология сети держится в секрете, в таких условиях нет
полной картины развертывания ПО и разбираться можно долго. 

-- 
Best regards!

Re: Странное поведение TCP

2015-09-29 Пенетрантность Andrey Melnikoff

Max Dmitrichenko  wrote:
> 29 сентября 2015 г., 10:17 пользователь Eugene Berdnikov
>  написал:
> >^M
> >  На дамп можно глянуть? Лучше всего в формате pcap.

> Протокол прориетарный, я его не знаю. Там скорее всего передаётся
> авторизация.  На сколько она криптована, хз, но скорее всего by
> obscurity. Но сервер более-менее публичный. Поэтому утечку допустить
> не хотелось бы.
Так запиши дамп без пайлоада. Нужны то только L2+L3 хидера.

Re: Странное поведение TCP

On Tue, Sep 29, 2015 at 12:09:21PM +0300, Max Dmitrichenko wrote:
> 29 сентября 2015 г., 11:08 пользователь Eugene Berdnikov
>  написал:
> >  Поскольку "чёрный ящик", в нём может жить некая сущность, рвущая
> >  коннекции по своему усмотрению. Типичные гадости такого рода делаются
> >  железками от Cisco, с их бредовыми inspect'ами и rate limit'ами.
> >  Опознаётся подлянка по id'ам, ttl'ам и прочим деталям, отличающим
> >  посторонние RST от тех, которые генерит ядро сервера.
> 
> Да, TTL действительно отличается. У SYN-ACK и других пакетов он 125, а
> у этого RST - 254.

 Вот и ответ. Вероятно, это циска, она рвёт коннекции пакетами с ttl=255.
 То есть между ней и тем местом, где снимался дамп, ровно один роутер.
 А сервер, подозреваю, под Windows, между ним и вредителем ещё 1 роутер.
-- 
 Eugene Berdnikov

Re: Странное поведение TCP

29 сентября 2015 г., 11:57 пользователь Eugene Berdnikov
 написал:
> If the incoming segment has an ACK field, the reset takes its
> sequence number from the ACK field of the segment, otherwise the
> reset has sequence number zero and the ACK field is set to the sum
> of the sequence number and segment length of the incoming segment.
>
>  Ref: RFC793 (этот текст встречается там в нескольких местах).

На странице 37 этой RFC есть требование того, что RST должно
"попадать" по sequnce. А ваша цитата похоже отностися к поведению
стэка, когда ему приходит вообще левый пакет на левый порт, но с
правильным IP-адресом назначения.

>> При этом, что самое смешное, после RST от сервера приходит ACK на
>> данные клиента.
>
>  Если я правильно понял эту фразу, от сервера после RST идёт ожидаемый
>  ответ приложения. Это свидетельствует о том, что RST посылает не ядро
>  сервера, а некая посторонняя программа, прослушивающая трафик где-то
>  между клиентом и сервером.

Приходит не ответ приложения, а просто TCP-шный ACK, на посланные
клиентом данные. Причем у него TTL тоже 125. Версия с вражеской
железкой на пути меня давно посетила. Просто не понятно, для чего
такая железка может применятся.

--
With best regards
  Max Dmitrichenko

Re: Странное поведение TCP

29 сентября 2015 г., 11:08 пользователь Eugene Berdnikov
 написал:
> On Tue, Sep 29, 2015 at 10:57:42AM +0300, Max Dmitrichenko wrote:
>> >  На дамп можно глянуть? Лучше всего в формате pcap.
>>
>> К сожалению в силу ряда причин нет (
>
>  Откуда тогда такие подробные сведения о механизме сбоя? Кто-то же
>  должен был смотреть дамп трафика, чтобы рассуждать о SYNах, RST...

У меня-то дамп есть. Просто я не уверен, что уполномочен им поделится с вами.

>  Поскольку "чёрный ящик", в нём может жить некая сущность, рвущая
>  коннекции по своему усмотрению. Типичные гадости такого рода делаются
>  железками от Cisco, с их бредовыми inspect'ами и rate limit'ами.
>  Опознаётся подлянка по id'ам, ttl'ам и прочим деталям, отличающим
>  посторонние RST от тех, которые генерит ядро сервера.

Да, TTL действительно отличается. У SYN-ACK и других пакетов он 125, а
у этого RST - 254.

--
With best regards
  Max Dmitrichenko

Re: Странное поведение TCP

  Вдогонку.

On Tue, Sep 29, 2015 at 09:00:26AM +0300, Max Dmitrichenko wrote:
> 3) Так вот, иногда бывает так, что сервер внезапно на первые
> присланные данные отвечает RST. Причем отвечает не сразу, а через
> время, которое на десятки миллисекунд превышает RTT. И всё бы хорошо,
> но у данного RST-пакета SEQ=0, а после SYN-ACK, он должен быть равен
> 1. Из-за этого, клиентский Linux игнорирует данный RST пакет и
> продолжает думать, что соединение живо.

If the incoming segment has an ACK field, the reset takes its
sequence number from the ACK field of the segment, otherwise the
reset has sequence number zero and the ACK field is set to the sum
of the sequence number and segment length of the incoming segment.

 Ref: RFC793 (этот текст встречается там в нескольких местах).

> При этом, что самое смешное, после RST от сервера приходит ACK на
> данные клиента.

 Если я правильно понял эту фразу, от сервера после RST идёт ожидаемый
 ответ приложения. Это свидетельствует о том, что RST посылает не ядро
 сервера, а некая посторонняя программа, прослушивающая трафик где-то
 между клиентом и сервером.
-- 
 Eugene Berdnikov

Re: Странное поведение TCP

On Tue, Sep 29, 2015 at 10:57:42AM +0300, Max Dmitrichenko wrote:
> >  На дамп можно глянуть? Лучше всего в формате pcap.
> 
> К сожалению в силу ряда причин нет (

 Откуда тогда такие подробные сведения о механизме сбоя? Кто-то же
 должен был смотреть дамп трафика, чтобы рассуждать о SYNах, RST...

 Поскольку "чёрный ящик", в нём может жить некая сущность, рвущая
 коннекции по своему усмотрению. Типичные гадости такого рода делаются
 железками от Cisco, с их бредовыми inspect'ами и rate limit'ами.
 Опознаётся подлянка по id'ам, ttl'ам и прочим деталям, отличающим
 посторонние RST от тех, которые генерит ядро сервера.
-- 
 Eugene Berdnikov

Re: Странное поведение TCP

29 сентября 2015 г., 10:17 пользователь Eugene Berdnikov
 написал:
>
>  На дамп можно глянуть? Лучше всего в формате pcap.

Протокол прориетарный, я его не знаю. Там скорее всего передаётся
авторизация.  На сколько она криптована, хз, но скорее всего by
obscurity. Но сервер более-менее публичный. Поэтому утечку допустить
не хотелось бы.

--
With best regards
  Max Dmitrichenko

Re: Странное поведение TCP

29 сентября 2015 г., 10:17 пользователь Mikhail A Antonov
 написал:
> 29.09.2015 09:00, Max Dmitrichenko пишет:
>> Добрый день, коллеги. Вопрос не совсем по Debian, но связан в
>> некоторой степени с администрированием.
>>
>> Есть некоторый сервер, к которому выполняется TCP-подключение.
>> 1) Во-время установления соединения происходит стандартный TCP-шный
>> handshake (SYN, SYN-ACK, ACK).
> Что за сервер?
> На сколько далеко клиент и сервер? В одной локальной сети?

Да в общем-то рядом. Это другой сегмент сети, но типичный RTT
составляет сотни микросекунд.

--
With best regards
  Max Dmitrichenko

Re: Странное поведение TCP

>  На дамп можно глянуть? Лучше всего в формате pcap.

К сожалению в силу ряда причин нет (


--
With best regards
  Max Dmitrichenko

Re: Странное поведение TCP

2015-09-29 Пенетрантность Mikhail A Antonov

29 сентября 2015 г., 10:17 пользователь Mikhail A Antonov
 написал:

> 29.09.2015 09:00, Max Dmitrichenko пишет:
>> Добрый день, коллеги. Вопрос не совсем по Debian, но связан в
>> некоторой степени с администрированием.
>>
>> Есть некоторый сервер, к которому выполняется TCP-подключение.
>> 1) Во-время установления соединения происходит стандартный TCP-шный
>> handshake (SYN, SYN-ACK, ACK).
> Что за сервер?
> На сколько далеко клиент и сервер? В одной локальной сети?
> Есть ли NAT между ними?

Вообще про сервер ничего не известно. Black box. Хотя подозреваю, что
там может быть некий load balancer или какая-то железка по отражению
атак.

--
With best regards
  Max Dmitrichenko

Re: Странное поведение TCP

29.09.2015 09:00, Max Dmitrichenko пишет:
> Добрый день, коллеги. Вопрос не совсем по Debian, но связан в
> некоторой степени с администрированием.
>
> Есть некоторый сервер, к которому выполняется TCP-подключение.
> 1) Во-время установления соединения происходит стандартный TCP-шный
> handshake (SYN, SYN-ACK, ACK).
Что за сервер?
На сколько далеко клиент и сервер? В одной локальной сети?
Есть ли NAT между ними?


-- 
Best regards,
Mikhail
-
WWW: http://www.antmix.ru/
XMPP: ant...@stopicq.ru



signature.asc
Description: OpenPGP digital signature

Re: Странное поведение TCP