* traceroute failure in kernel 6.1 and 6.2
@ 2023-01-21 18:09 Mantas Mikulėnas
2023-01-23 15:21 ` Eric Dumazet
0 siblings, 1 reply; 12+ messages in thread
From: Mantas Mikulėnas @ 2023-01-21 18:09 UTC (permalink / raw)
To: Eric Dumazet, netdev
Hello,
Not sure whether this has been reported, but:
After upgrading from kernel 6.0.7 to 6.1.6 on Arch Linux, unprivileged
ICMP traceroute using the `traceroute -I` tool stopped working – it very
reliably fails with a "No route to host" at some point:
myth> traceroute -I 83.171.33.188
traceroute to 83.171.33.188 (83.171.33.188), 30 hops max, 60
byte packets
1 _gateway (192.168.1.1) 0.819 ms
send: No route to host
[exited with 1]
while it still works for root:
myth> sudo traceroute -I 83.171.33.188
traceroute to 83.171.33.188 (83.171.33.188), 30 hops max, 60
byte packets
1 _gateway (192.168.1.1) 0.771 ms
2 * * *
3 10.69.21.145 (10.69.21.145) 47.194 ms
4 82-135-179-168.static.zebra.lt (82.135.179.168) 49.124 ms
5 213-190-41-3.static.telecom.lt (213.190.41.3) 44.211 ms
6 193.219.153.25 (193.219.153.25) 77.171 ms
7 83.171.33.188 (83.171.33.188) 78.198 ms
According to `git bisect`, this started with:
commit 0d24148bd276ead5708ef56a4725580555bb48a3
Author: Eric Dumazet <edumazet@google.com>
Date: Tue Oct 11 14:27:29 2022 -0700
inet: ping: fix recent breakage
It still happens with a fresh 6.2rc build, unless I revert that commit.
The /bin/traceroute is the one that calls itself "Modern traceroute for
Linux, version 2.1.1", on Arch Linux. It seems to use socket(AF_INET,
SOCK_DGRAM, IPPROTO_ICMP), has neither setuid nor file capabilities.
(The problem does not occur if I run it as root.)
This version of `traceroute` sends multiple probes at once (with TTLs
1..16); according to strace, the first approx. 8-12 probes are sent
successfully, but eventually sendto() fails with EHOSTUNREACH. (Though
if I run it on local tty as opposed to SSH, it fails earlier.) If I use
-N1 to have it only send one probe at a time, the problem doesn't seem
to occur.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: traceroute failure in kernel 6.1 and 6.2
2023-01-21 18:09 traceroute failure in kernel 6.1 and 6.2 Mantas Mikulėnas
@ 2023-01-23 15:21 ` Eric Dumazet
2023-01-23 19:25 ` Mantas Mikulėnas
0 siblings, 1 reply; 12+ messages in thread
From: Eric Dumazet @ 2023-01-23 15:21 UTC (permalink / raw)
To: Mantas Mikulėnas; +Cc: netdev
On Sat, Jan 21, 2023 at 7:09 PM Mantas Mikulėnas <grawity@gmail.com> wrote:
>
> Hello,
>
> Not sure whether this has been reported, but:
>
> After upgrading from kernel 6.0.7 to 6.1.6 on Arch Linux, unprivileged
> ICMP traceroute using the `traceroute -I` tool stopped working – it very
> reliably fails with a "No route to host" at some point:
>
> myth> traceroute -I 83.171.33.188
> traceroute to 83.171.33.188 (83.171.33.188), 30 hops max, 60
> byte packets
> 1 _gateway (192.168.1.1) 0.819 ms
> send: No route to host
> [exited with 1]
>
> while it still works for root:
>
> myth> sudo traceroute -I 83.171.33.188
> traceroute to 83.171.33.188 (83.171.33.188), 30 hops max, 60
> byte packets
> 1 _gateway (192.168.1.1) 0.771 ms
> 2 * * *
> 3 10.69.21.145 (10.69.21.145) 47.194 ms
> 4 82-135-179-168.static.zebra.lt (82.135.179.168) 49.124 ms
> 5 213-190-41-3.static.telecom.lt (213.190.41.3) 44.211 ms
> 6 193.219.153.25 (193.219.153.25) 77.171 ms
> 7 83.171.33.188 (83.171.33.188) 78.198 ms
>
> According to `git bisect`, this started with:
>
> commit 0d24148bd276ead5708ef56a4725580555bb48a3
> Author: Eric Dumazet <edumazet@google.com>
> Date: Tue Oct 11 14:27:29 2022 -0700
>
> inet: ping: fix recent breakage
>
>
>
>
> It still happens with a fresh 6.2rc build, unless I revert that commit.
>
> The /bin/traceroute is the one that calls itself "Modern traceroute for
> Linux, version 2.1.1", on Arch Linux. It seems to use socket(AF_INET,
> SOCK_DGRAM, IPPROTO_ICMP), has neither setuid nor file capabilities.
> (The problem does not occur if I run it as root.)
>
> This version of `traceroute` sends multiple probes at once (with TTLs
> 1..16); according to strace, the first approx. 8-12 probes are sent
> successfully, but eventually sendto() fails with EHOSTUNREACH. (Though
> if I run it on local tty as opposed to SSH, it fails earlier.) If I use
> -N1 to have it only send one probe at a time, the problem doesn't seem
> to occur.
I was not able to reproduce the issue (downloading
https://sourceforge.net/projects/traceroute/files/latest/download)
I suspect some kind of bug in this traceroute, when/if some ICMP error
comes back.
Double check by
tcpdump -i ethXXXX icmp
While you run traceroute -I ....
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: traceroute failure in kernel 6.1 and 6.2
2023-01-23 15:21 ` Eric Dumazet
@ 2023-01-23 19:25 ` Mantas Mikulėnas
2023-01-23 20:56 ` Eric Dumazet
0 siblings, 1 reply; 12+ messages in thread
From: Mantas Mikulėnas @ 2023-01-23 19:25 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
On 2023-01-23 17:21, Eric Dumazet wrote:
> On Sat, Jan 21, 2023 at 7:09 PM Mantas Mikulėnas <grawity@gmail.com> wrote:
>>
>> Hello,
>>
>> Not sure whether this has been reported, but:
>>
>> After upgrading from kernel 6.0.7 to 6.1.6 on Arch Linux, unprivileged
>> ICMP traceroute using the `traceroute -I` tool stopped working – it very
>> reliably fails with a "No route to host" at some point:
>>
>> myth> traceroute -I 83.171.33.188
>> traceroute to 83.171.33.188 (83.171.33.188), 30 hops max, 60
>> byte packets
>> 1 _gateway (192.168.1.1) 0.819 ms
>> send: No route to host
>> [exited with 1]
>>
>> while it still works for root:
>>
>> myth> sudo traceroute -I 83.171.33.188
>> traceroute to 83.171.33.188 (83.171.33.188), 30 hops max, 60
>> byte packets
>> 1 _gateway (192.168.1.1) 0.771 ms
>> 2 * * *
>> 3 10.69.21.145 (10.69.21.145) 47.194 ms
>> 4 82-135-179-168.static.zebra.lt (82.135.179.168) 49.124 ms
>> 5 213-190-41-3.static.telecom.lt (213.190.41.3) 44.211 ms
>> 6 193.219.153.25 (193.219.153.25) 77.171 ms
>> 7 83.171.33.188 (83.171.33.188) 78.198 ms
>>
>> According to `git bisect`, this started with:
>>
>> commit 0d24148bd276ead5708ef56a4725580555bb48a3
>> Author: Eric Dumazet <edumazet@google.com>
>> Date: Tue Oct 11 14:27:29 2022 -0700
>>
>> inet: ping: fix recent breakage
>>
>>
>>
>>
>> It still happens with a fresh 6.2rc build, unless I revert that commit.
>>
>> The /bin/traceroute is the one that calls itself "Modern traceroute for
>> Linux, version 2.1.1", on Arch Linux. It seems to use socket(AF_INET,
>> SOCK_DGRAM, IPPROTO_ICMP), has neither setuid nor file capabilities.
>> (The problem does not occur if I run it as root.)
>>
>> This version of `traceroute` sends multiple probes at once (with TTLs
>> 1..16); according to strace, the first approx. 8-12 probes are sent
>> successfully, but eventually sendto() fails with EHOSTUNREACH. (Though
>> if I run it on local tty as opposed to SSH, it fails earlier.) If I use
>> -N1 to have it only send one probe at a time, the problem doesn't seem
>> to occur.
>
>
>
> I was not able to reproduce the issue (downloading
> https://sourceforge.net/projects/traceroute/files/latest/download)
>
> I suspect some kind of bug in this traceroute, when/if some ICMP error
> comes back.
>
> Double check by
>
> tcpdump -i ethXXXX icmp
>
> While you run traceroute -I ....
Hmm, no, the only ICMP errors I see in tcpdump are "Time exceeded in
transit", which is expected for traceroute. Nothing else shows up.
(But when I test against an address that causes *real* ICMP "Host
unreachable" errors, it seems to handle those correctly and prints "!H"
as usual -- that is, if it reaches that point without dying.)
I was able to reproduce this on a fresh Linode 1G instance (starting
with their Arch image), where it also happens immediately:
# pacman -Sy archlinux-keyring
# pacman -Syu
# pacman -Sy traceroute strace
# reboot
# uname -r
6.1.7-arch1-1
# useradd foo
# su -c "traceroute -I 8.8.8.8" foo
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 10.210.1.195 (10.210.1.195) 0.209 ms
send: No route to host
So now I'm fairly sure it is not something caused by my own network, either.
On one system, it seems to work properly about half the time, if I keep
re-running the same command.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: traceroute failure in kernel 6.1 and 6.2
2023-01-23 19:25 ` Mantas Mikulėnas
@ 2023-01-23 20:56 ` Eric Dumazet
2023-01-23 21:45 ` Mantas Mikulėnas
0 siblings, 1 reply; 12+ messages in thread
From: Eric Dumazet @ 2023-01-23 20:56 UTC (permalink / raw)
To: Mantas Mikulėnas; +Cc: netdev
On Mon, Jan 23, 2023 at 8:25 PM Mantas Mikulėnas <grawity@gmail.com> wrote:
>
> On 2023-01-23 17:21, Eric Dumazet wrote:
> > On Sat, Jan 21, 2023 at 7:09 PM Mantas Mikulėnas <grawity@gmail.com> wrote:
> >>
> >> Hello,
> >>
> >> Not sure whether this has been reported, but:
> >>
> >> After upgrading from kernel 6.0.7 to 6.1.6 on Arch Linux, unprivileged
> >> ICMP traceroute using the `traceroute -I` tool stopped working – it very
> >> reliably fails with a "No route to host" at some point:
> >>
> >> myth> traceroute -I 83.171.33.188
> >> traceroute to 83.171.33.188 (83.171.33.188), 30 hops max, 60
> >> byte packets
> >> 1 _gateway (192.168.1.1) 0.819 ms
> >> send: No route to host
> >> [exited with 1]
> >>
> >> while it still works for root:
> >>
> >> myth> sudo traceroute -I 83.171.33.188
> >> traceroute to 83.171.33.188 (83.171.33.188), 30 hops max, 60
> >> byte packets
> >> 1 _gateway (192.168.1.1) 0.771 ms
> >> 2 * * *
> >> 3 10.69.21.145 (10.69.21.145) 47.194 ms
> >> 4 82-135-179-168.static.zebra.lt (82.135.179.168) 49.124 ms
> >> 5 213-190-41-3.static.telecom.lt (213.190.41.3) 44.211 ms
> >> 6 193.219.153.25 (193.219.153.25) 77.171 ms
> >> 7 83.171.33.188 (83.171.33.188) 78.198 ms
> >>
> >> According to `git bisect`, this started with:
> >>
> >> commit 0d24148bd276ead5708ef56a4725580555bb48a3
> >> Author: Eric Dumazet <edumazet@google.com>
> >> Date: Tue Oct 11 14:27:29 2022 -0700
> >>
> >> inet: ping: fix recent breakage
> >>
> >>
> >>
> >>
> >> It still happens with a fresh 6.2rc build, unless I revert that commit.
> >>
> >> The /bin/traceroute is the one that calls itself "Modern traceroute for
> >> Linux, version 2.1.1", on Arch Linux. It seems to use socket(AF_INET,
> >> SOCK_DGRAM, IPPROTO_ICMP), has neither setuid nor file capabilities.
> >> (The problem does not occur if I run it as root.)
> >>
> >> This version of `traceroute` sends multiple probes at once (with TTLs
> >> 1..16); according to strace, the first approx. 8-12 probes are sent
> >> successfully, but eventually sendto() fails with EHOSTUNREACH. (Though
> >> if I run it on local tty as opposed to SSH, it fails earlier.) If I use
> >> -N1 to have it only send one probe at a time, the problem doesn't seem
> >> to occur.
> >
> >
> >
> > I was not able to reproduce the issue (downloading
> > https://sourceforge.net/projects/traceroute/files/latest/download)
> >
> > I suspect some kind of bug in this traceroute, when/if some ICMP error
> > comes back.
> >
> > Double check by
> >
> > tcpdump -i ethXXXX icmp
> >
> > While you run traceroute -I ....
>
> Hmm, no, the only ICMP errors I see in tcpdump are "Time exceeded in
> transit", which is expected for traceroute. Nothing else shows up.
>
> (But when I test against an address that causes *real* ICMP "Host
> unreachable" errors, it seems to handle those correctly and prints "!H"
> as usual -- that is, if it reaches that point without dying.)
>
> I was able to reproduce this on a fresh Linode 1G instance (starting
> with their Arch image), where it also happens immediately:
>
> # pacman -Sy archlinux-keyring
> # pacman -Syu
> # pacman -Sy traceroute strace
> # reboot
> # uname -r
> 6.1.7-arch1-1
> # useradd foo
> # su -c "traceroute -I 8.8.8.8" foo
> traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
> 1 10.210.1.195 (10.210.1.195) 0.209 ms
> send: No route to host
>
> So now I'm fairly sure it is not something caused by my own network, either.
>
> On one system, it seems to work properly about half the time, if I keep
> re-running the same command.
>
Here, running the latest upstream tree and latest traceroute, I have no issue.
Send us :
1) strace output
2) icmp packet capture.
Thanks.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: traceroute failure in kernel 6.1 and 6.2
2023-01-23 20:56 ` Eric Dumazet
@ 2023-01-23 21:45 ` Mantas Mikulėnas
2023-01-23 22:26 ` Eric Dumazet
0 siblings, 1 reply; 12+ messages in thread
From: Mantas Mikulėnas @ 2023-01-23 21:45 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 4127 bytes --]
On 23/01/2023 22.56, Eric Dumazet wrote:
> On Mon, Jan 23, 2023 at 8:25 PM Mantas Mikulėnas <grawity@gmail.com> wrote:
>>
>> On 2023-01-23 17:21, Eric Dumazet wrote:
>>> On Sat, Jan 21, 2023 at 7:09 PM Mantas Mikulėnas <grawity@gmail.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>> Not sure whether this has been reported, but:
>>>>
>>>> After upgrading from kernel 6.0.7 to 6.1.6 on Arch Linux, unprivileged
>>>> ICMP traceroute using the `traceroute -I` tool stopped working – it very
>>>> reliably fails with a "No route to host" at some point:
>>>>
>>>> myth> traceroute -I 83.171.33.188
>>>> traceroute to 83.171.33.188 (83.171.33.188), 30 hops max, 60
>>>> byte packets
>>>> 1 _gateway (192.168.1.1) 0.819 ms
>>>> send: No route to host
>>>> [exited with 1]
>>>>
>>>> while it still works for root:
>>>>
>>>> myth> sudo traceroute -I 83.171.33.188
>>>> traceroute to 83.171.33.188 (83.171.33.188), 30 hops max, 60
>>>> byte packets
>>>> 1 _gateway (192.168.1.1) 0.771 ms
>>>> 2 * * *
>>>> 3 10.69.21.145 (10.69.21.145) 47.194 ms
>>>> 4 82-135-179-168.static.zebra.lt (82.135.179.168) 49.124 ms
>>>> 5 213-190-41-3.static.telecom.lt (213.190.41.3) 44.211 ms
>>>> 6 193.219.153.25 (193.219.153.25) 77.171 ms
>>>> 7 83.171.33.188 (83.171.33.188) 78.198 ms
>>>>
>>>> According to `git bisect`, this started with:
>>>>
>>>> commit 0d24148bd276ead5708ef56a4725580555bb48a3
>>>> Author: Eric Dumazet <edumazet@google.com>
>>>> Date: Tue Oct 11 14:27:29 2022 -0700
>>>>
>>>> inet: ping: fix recent breakage
>>>>
>>>>
>>>>
>>>>
>>>> It still happens with a fresh 6.2rc build, unless I revert that commit.
>>>>
>>>> The /bin/traceroute is the one that calls itself "Modern traceroute for
>>>> Linux, version 2.1.1", on Arch Linux. It seems to use socket(AF_INET,
>>>> SOCK_DGRAM, IPPROTO_ICMP), has neither setuid nor file capabilities.
>>>> (The problem does not occur if I run it as root.)
>>>>
>>>> This version of `traceroute` sends multiple probes at once (with TTLs
>>>> 1..16); according to strace, the first approx. 8-12 probes are sent
>>>> successfully, but eventually sendto() fails with EHOSTUNREACH. (Though
>>>> if I run it on local tty as opposed to SSH, it fails earlier.) If I use
>>>> -N1 to have it only send one probe at a time, the problem doesn't seem
>>>> to occur.
>>>
>>>
>>>
>>> I was not able to reproduce the issue (downloading
>>> https://sourceforge.net/projects/traceroute/files/latest/download)
>>>
>>> I suspect some kind of bug in this traceroute, when/if some ICMP error
>>> comes back.
>>>
>>> Double check by
>>>
>>> tcpdump -i ethXXXX icmp
>>>
>>> While you run traceroute -I ....
>>
>> Hmm, no, the only ICMP errors I see in tcpdump are "Time exceeded in
>> transit", which is expected for traceroute. Nothing else shows up.
>>
>> (But when I test against an address that causes *real* ICMP "Host
>> unreachable" errors, it seems to handle those correctly and prints "!H"
>> as usual -- that is, if it reaches that point without dying.)
>>
>> I was able to reproduce this on a fresh Linode 1G instance (starting
>> with their Arch image), where it also happens immediately:
>>
>> # pacman -Sy archlinux-keyring
>> # pacman -Syu
>> # pacman -Sy traceroute strace
>> # reboot
>> # uname -r
>> 6.1.7-arch1-1
>> # useradd foo
>> # su -c "traceroute -I 8.8.8.8" foo
>> traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
>> 1 10.210.1.195 (10.210.1.195) 0.209 ms
>> send: No route to host
>>
>> So now I'm fairly sure it is not something caused by my own network, either.
>>
>> On one system, it seems to work properly about half the time, if I keep
>> re-running the same command.
>>
>
> Here, running the latest upstream tree and latest traceroute, I have no issue.
>
> Send us :
>
> 1) strace output
> 2) icmp packet capture.
>
> Thanks.
Attached both.
[-- Attachment #2: arch_kconfig.gz --]
[-- Type: application/gzip, Size: 62237 bytes --]
[-- Attachment #3: as_root.strace --]
[-- Type: text/plain, Size: 48164 bytes --]
2139 23:30:49.996472 execve("/usr/bin/traceroute", ["traceroute", "-I", "83.171.33.188"], 0x7ffd107f8760 /* 14 vars */) = 0
2139 23:30:49.996683 brk(NULL) = 0x5560fde31000
2139 23:30:49.996716 arch_prctl(0x3001 /* ARCH_??? */, 0x7ffe3e0acbf0) = -1 EINVAL (Invalid argument)
2139 23:30:49.996761 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
2139 23:30:49.996794 openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:49.996822 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=124691, ...}, AT_EMPTY_PATH) = 0
2139 23:30:49.996852 mmap(NULL, 124691, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff7648b4000
2139 23:30:49.996876 close(3) = 0
2139 23:30:49.996903 openat(AT_FDCWD, "/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:49.996925 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P4\2\0\0\0\0\0"..., 832) = 832
2139 23:30:49.996946 pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
2139 23:30:49.996968 newfstatat(3, "", {st_mode=S_IFREG|0755, st_size=1953472, ...}, AT_EMPTY_PATH) = 0
2139 23:30:49.996991 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff7648b2000
2139 23:30:49.997014 pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
2139 23:30:49.997034 mmap(NULL, 1994384, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ff7646cb000
2139 23:30:49.997055 mmap(0x7ff7646ed000, 1421312, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22000) = 0x7ff7646ed000
2139 23:30:49.997084 mmap(0x7ff764848000, 356352, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17d000) = 0x7ff764848000
2139 23:30:49.997111 mmap(0x7ff76489f000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d4000) = 0x7ff76489f000
2139 23:30:49.997140 mmap(0x7ff7648a5000, 52880, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ff7648a5000
2139 23:30:49.997171 close(3) = 0
2139 23:30:49.997196 mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff7646c8000
2139 23:30:49.997221 arch_prctl(ARCH_SET_FS, 0x7ff7646c8740) = 0
2139 23:30:49.997241 set_tid_address(0x7ff7646c8a10) = 2139
2139 23:30:49.997261 set_robust_list(0x7ff7646c8a20, 24) = 0
2139 23:30:49.997278 rseq(0x7ff7646c9060, 0x20, 0, 0x53053053) = 0
2139 23:30:49.997333 mprotect(0x7ff76489f000, 16384, PROT_READ) = 0
2139 23:30:49.997380 mprotect(0x5560fd525000, 4096, PROT_READ) = 0
2139 23:30:49.997405 mprotect(0x7ff764905000, 8192, PROT_READ) = 0
2139 23:30:49.997438 prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
2139 23:30:49.997468 munmap(0x7ff7648b4000, 124691) = 0
2139 23:30:49.997515 times(NULL) = 1431665562
2139 23:30:49.997535 getpid() = 2139
2139 23:30:49.997561 getrandom("\x75\xb0\xd4\xda\x78\x6a\x92\xd0", 8, GRND_NONBLOCK) = 8
2139 23:30:49.997584 brk(NULL) = 0x5560fde31000
2139 23:30:49.997603 brk(0x5560fde52000) = 0x5560fde52000
2139 23:30:49.997625 openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
2139 23:30:49.997651 openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:49.997674 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=2998, ...}, AT_EMPTY_PATH) = 0
2139 23:30:49.997699 read(3, "# Locale name alias data base.\n#"..., 4096) = 2998
2139 23:30:49.997728 read(3, "", 4096) = 0
2139 23:30:49.997748 close(3) = 0
2139 23:30:49.997771 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:49.997794 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=258, ...}, AT_EMPTY_PATH) = 0
2139 23:30:49.997817 mmap(NULL, 258, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff7648d2000
2139 23:30:49.997839 close(3) = 0
2139 23:30:49.997859 openat(AT_FDCWD, "/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory)
2139 23:30:49.997886 openat(AT_FDCWD, "/usr/lib/gconv/gconv-modules", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:49.997916 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=3916, ...}, AT_EMPTY_PATH) = 0
2139 23:30:49.997942 read(3, "# GNU libc iconv configuration.\n"..., 4096) = 3916
2139 23:30:49.997982 read(3, "", 4096) = 0
2139 23:30:49.998002 close(3) = 0
2139 23:30:49.998022 openat(AT_FDCWD, "/usr/lib/gconv/gconv-modules.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
2139 23:30:49.998047 newfstatat(3, "", {st_mode=S_IFDIR|0755, st_size=48, ...}, AT_EMPTY_PATH) = 0
2139 23:30:49.998073 getdents64(3, 0x5560fde34e80 /* 3 entries */, 32768) = 96
2139 23:30:49.998102 openat(AT_FDCWD, "/usr/lib/gconv/gconv-modules.d/gconv-modules-extra.conf", O_RDONLY|O_CLOEXEC) = 4
2139 23:30:49.998124 newfstatat(4, "", {st_mode=S_IFREG|0644, st_size=53974, ...}, AT_EMPTY_PATH) = 0
2139 23:30:49.998148 read(4, "# GNU libc iconv configuration.\n"..., 4096) = 4096
2139 23:30:49.998194 read(4, "B1002//\tJUS_I.B1.002//\nmodule\tJU"..., 4096) = 4096
2139 23:30:49.998255 read(4, "59-5//\nalias\tISO_8859-5//\t\tISO-8"..., 4096) = 4096
2139 23:30:49.998318 read(4, "59-16//\t\tINTERNAL\t\tISO8859-16\t1\n"..., 4096) = 4096
2139 23:30:49.998384 read(4, "-SE-A\t1\nmodule\tINTERNAL\t\tEBCDIC-"..., 4096) = 4096
2139 23:30:49.998457 read(4, "97\t\t1\n\n#\tfrom\t\t\tto\t\t\tmodule\t\tcos"..., 4096) = 4096
2139 23:30:49.998538 read(4, "1\n\n#\tfrom\t\t\tto\t\t\tmodule\t\tcost\nal"..., 4096) = 4096
2139 23:30:49.998629 read(4, "6//\t\tIBM1046//\nalias\tCP1046//\t\tI"..., 4096) = 4096
2139 23:30:49.998714 read(4, "\tto\t\t\tmodule\t\tcost\nalias\tRUSCII/"..., 4096) = 4096
2139 23:30:49.998779 brk(0x5560fde73000) = 0x5560fde73000
2139 23:30:49.998833 read(4, "03//\nmodule\tCSN_369103//\t\tINTERN"..., 4096) = 4096
2139 23:30:49.998967 read(4, "\tmodule\t\tcost\nalias\tISO-IR-8-1//"..., 4096) = 4096
2139 23:30:49.999214 read(4, "IBM1156\t\t1\n\n#\tfrom\t\t\tto\t\t\tmodule"..., 4096) = 4096
2139 23:30:49.999455 read(4, "\t\tIBM1166//\nalias\tCP1166//\t\tIBM1"..., 4096) = 4096
2139 23:30:49.999710 read(4, "alias\tROMAN9//\t\tHP-ROMAN9//\nalia"..., 4096) = 726
2139 23:30:49.999784 read(4, "", 4096) = 0
2139 23:30:49.999811 close(4) = 0
2139 23:30:49.999838 getdents64(3, 0x5560fde34e80 /* 0 entries */, 32768) = 0
2139 23:30:49.999870 close(3) = 0
2139 23:30:49.999971 futex(0x7ff7648a498c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
2139 23:30:50.000004 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_MEASUREMENT", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:50.000039 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=23, ...}, AT_EMPTY_PATH) = 0
2139 23:30:50.000073 mmap(NULL, 23, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff7648d1000
2139 23:30:50.000105 close(3) = 0
2139 23:30:50.000137 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_TELEPHONE", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:50.000170 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=47, ...}, AT_EMPTY_PATH) = 0
2139 23:30:50.000202 mmap(NULL, 47, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff7648d0000
2139 23:30:50.000232 close(3) = 0
2139 23:30:50.000265 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_ADDRESS", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:50.000297 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=127, ...}, AT_EMPTY_PATH) = 0
2139 23:30:50.000331 mmap(NULL, 127, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff7648cf000
2139 23:30:50.000360 close(3) = 0
2139 23:30:50.000391 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_NAME", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:50.000422 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=62, ...}, AT_EMPTY_PATH) = 0
2139 23:30:50.000454 mmap(NULL, 62, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff7648ce000
2139 23:30:50.000483 close(3) = 0
2139 23:30:50.000514 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_PAPER", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:50.000546 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=34, ...}, AT_EMPTY_PATH) = 0
2139 23:30:50.000578 mmap(NULL, 34, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff7648cd000
2139 23:30:50.000607 close(3) = 0
2139 23:30:50.000637 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_MESSAGES", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:50.000676 newfstatat(3, "", {st_mode=S_IFDIR|0755, st_size=30, ...}, AT_EMPTY_PATH) = 0
2139 23:30:50.000709 close(3) = 0
2139 23:30:50.000735 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_MESSAGES/SYS_LC_MESSAGES", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:50.000767 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=48, ...}, AT_EMPTY_PATH) = 0
2139 23:30:50.000799 mmap(NULL, 48, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff7648cc000
2139 23:30:50.000828 close(3) = 0
2139 23:30:50.000858 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_MONETARY", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:50.000890 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=270, ...}, AT_EMPTY_PATH) = 0
2139 23:30:50.000922 mmap(NULL, 270, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff7648cb000
2139 23:30:50.000952 close(3) = 0
2139 23:30:50.000984 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_COLLATE", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:50.001015 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=1406, ...}, AT_EMPTY_PATH) = 0
2139 23:30:50.001048 mmap(NULL, 1406, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff7648ca000
2139 23:30:50.001078 close(3) = 0
2139 23:30:50.001111 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_TIME", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:50.001144 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=3360, ...}, AT_EMPTY_PATH) = 0
2139 23:30:50.001176 mmap(NULL, 3360, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff7648c9000
2139 23:30:50.001205 close(3) = 0
2139 23:30:50.001238 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_NUMERIC", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:50.001270 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=50, ...}, AT_EMPTY_PATH) = 0
2139 23:30:50.001302 mmap(NULL, 50, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff7648c8000
2139 23:30:50.001333 close(3) = 0
2139 23:30:50.001365 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:50.001397 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=353616, ...}, AT_EMPTY_PATH) = 0
2139 23:30:50.001429 mmap(NULL, 353616, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff764671000
2139 23:30:50.001459 close(3) = 0
2139 23:30:50.001504 fcntl(0, F_GETFL) = 0x2 (flags O_RDWR)
2139 23:30:50.001532 fcntl(1, F_GETFL) = 0x2 (flags O_RDWR)
2139 23:30:50.001558 fcntl(2, F_GETFL) = 0x2 (flags O_RDWR)
2139 23:30:50.001590 socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP) = 3
2139 23:30:50.001624 socket(AF_INET, SOCK_RAW, IPPROTO_ICMP) = 4
2139 23:30:50.001654 close(3) = 0
2139 23:30:50.001682 bind(4, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 28) = 0
2139 23:30:50.001719 setsockopt(4, SOL_IP, IP_MTU_DISCOVER, [0], 4) = 0
2139 23:30:50.001749 setsockopt(4, SOL_SOCKET, SO_TIMESTAMP_OLD, [1], 4) = 0
2139 23:30:50.001778 setsockopt(4, SOL_IP, IP_RECVTTL, [1], 4) = 0
2139 23:30:50.001806 fcntl(4, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
2139 23:30:50.001832 connect(4, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, 28) = 0
2139 23:30:50.001866 setsockopt(4, SOL_IP, IP_RECVERR, [1], 4) = 0
2139 23:30:50.001894 getpid() = 2139
2139 23:30:50.001920 newfstatat(1, "", {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}, AT_EMPTY_PATH) = 0
2139 23:30:50.001956 write(1, "traceroute to 83.171.33.188 (83."..., 73) = 73
2139 23:30:50.001997 setsockopt(4, SOL_IP, IP_TTL, [1], 4) = 0
2139 23:30:50.002027 sendto(4, "\10\0z\36\10[\0\1HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.002117 sendto(4, "\10\0z\35\10[\0\2HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.002157 sendto(4, "\10\0z\34\10[\0\3HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.002195 setsockopt(4, SOL_IP, IP_TTL, [2], 4) = 0
2139 23:30:50.002233 sendto(4, "\10\0z\33\10[\0\4HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.002271 sendto(4, "\10\0z\32\10[\0\5HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.002308 sendto(4, "\10\0z\31\10[\0\6HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.002351 setsockopt(4, SOL_IP, IP_TTL, [3], 4) = 0
2139 23:30:50.002380 sendto(4, "\10\0z\30\10[\0\7HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.002417 sendto(4, "\10\0z\27\10[\0\10HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.002454 sendto(4, "\10\0z\26\10[\0\tHIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.002490 setsockopt(4, SOL_IP, IP_TTL, [4], 4) = 0
2139 23:30:50.002519 sendto(4, "\10\0z\25\10[\0\nHIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.002555 sendto(4, "\10\0z\24\10[\0\vHIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.002592 sendto(4, "\10\0z\23\10[\0\fHIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.002629 setsockopt(4, SOL_IP, IP_TTL, [5], 4) = 0
2139 23:30:50.002657 sendto(4, "\10\0z\22\10[\0\rHIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.002694 sendto(4, "\10\0z\21\10[\0\16HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.002730 sendto(4, "\10\0z\20\10[\0\17HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.002767 setsockopt(4, SOL_IP, IP_TTL, [6], 4) = 0
2139 23:30:50.002795 sendto(4, "\10\0z\17\10[\0\20HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.002832 poll([{fd=4, events=POLLIN|POLLERR}], 1, 5000) = 1 ([{fd=4, revents=POLLERR}])
2139 23:30:50.002866 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="\10\0z\36\10[\0\1HIJKLMNOPQRSTUVWXYZ[\\]^_"..., iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=2603}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[64]}, {cmsg_len=48, cmsg_level=SOL_IP, cmsg_type=IP_RECVERR, cmsg_data={ee_errno=113, ee_origin=2, ee_type=11, ee_code=0, ee_info=0, ee_data=0, offender={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.1.1")}}}], msg_controllen=104, msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 40
2139 23:30:50.002928 write(1, "\n", 1) = 1
2139 23:30:50.002963 newfstatat(AT_FDCWD, "/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=945, ...}, 0) = 0
2139 23:30:50.003007 openat(AT_FDCWD, "/etc/host.conf", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:50.003040 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=73, ...}, AT_EMPTY_PATH) = 0
2139 23:30:50.003077 read(3, "# Resolver configuration file.\n#"..., 4096) = 73
2139 23:30:50.003107 read(3, "", 4096) = 0
2139 23:30:50.003133 close(3) = 0
2139 23:30:50.003159 futex(0x7ff7648ac36c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
2139 23:30:50.003185 openat(AT_FDCWD, "/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:50.003219 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=945, ...}, AT_EMPTY_PATH) = 0
2139 23:30:50.003251 read(3, "# This is /run/systemd/resolve/s"..., 4096) = 945
2139 23:30:50.003283 read(3, "", 4096) = 0
2139 23:30:50.003309 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=945, ...}, AT_EMPTY_PATH) = 0
2139 23:30:50.003343 close(3) = 0
2139 23:30:50.003370 socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
2139 23:30:50.003400 connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
2139 23:30:50.003440 close(3) = 0
2139 23:30:50.003468 socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
2139 23:30:50.003497 connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
2139 23:30:50.003539 close(3) = 0
2139 23:30:50.003571 newfstatat(AT_FDCWD, "/etc/nsswitch.conf", {st_mode=S_IFREG|0644, st_size=397, ...}, 0) = 0
2139 23:30:50.003606 newfstatat(AT_FDCWD, "/", {st_mode=S_IFDIR|0755, st_size=162, ...}, 0) = 0
2139 23:30:50.003639 openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:50.003671 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=397, ...}, AT_EMPTY_PATH) = 0
2139 23:30:50.003709 read(3, "# Name Service Switch configurat"..., 4096) = 397
2139 23:30:50.003743 read(3, "", 4096) = 0
2139 23:30:50.003770 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=397, ...}, AT_EMPTY_PATH) = 0
2139 23:30:50.003802 close(3) = 0
2139 23:30:50.003830 openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:50.003861 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=80, ...}, AT_EMPTY_PATH) = 0
2139 23:30:50.003894 lseek(3, 0, SEEK_SET) = 0
2139 23:30:50.003920 read(3, "127.0.0.1 myth.nullroute.lt myth"..., 4096) = 80
2139 23:30:50.003950 read(3, "", 4096) = 0
2139 23:30:50.003975 close(3) = 0
2139 23:30:50.004007 socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
2139 23:30:50.004037 setsockopt(3, SOL_IP, IP_RECVERR, [1], 4) = 0
2139 23:30:50.004066 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
2139 23:30:50.004100 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
2139 23:30:50.004132 sendto(3, "\250D\1 \0\1\0\0\0\0\0\1\0011\0011\003168\003192\7in-addr"..., 53, MSG_NOSIGNAL, NULL, 0) = 53
2139 23:30:50.004183 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}])
2139 23:30:50.004357 ioctl(3, FIONREAD, [75]) = 0
2139 23:30:50.004388 recvfrom(3, "\250D\205\240\0\1\0\1\0\0\0\1\0011\0011\003168\003192\7in-addr"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28 => 16]) = 75
2139 23:30:50.004434 close(3) = 0
2139 23:30:50.004469 write(1, " 1 _gateway (192.168.1.1) 0.58"..., 36) = 36
2139 23:30:50.004501 sendto(4, "\10\0z\16\10[\0\21HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.004540 poll([{fd=4, events=POLLIN|POLLERR}], 1, 3) = 1 ([{fd=4, revents=POLLERR}])
2139 23:30:50.004573 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="\10\0z\35\10[\0\2HIJKLMNOPQRSTUVWXYZ[\\]^_"..., iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=2693}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[64]}, {cmsg_len=48, cmsg_level=SOL_IP, cmsg_type=IP_RECVERR, cmsg_data={ee_errno=113, ee_origin=2, ee_type=11, ee_code=0, ee_info=0, ee_data=0, offender={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.1.1")}}}], msg_controllen=104, msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 40
2139 23:30:50.004624 write(1, " 0.582 ms", 10) = 10
2139 23:30:50.004654 sendto(4, "\10\0z\r\10[\0\22HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.004692 poll([{fd=4, events=POLLIN|POLLERR}], 1, 3) = 1 ([{fd=4, revents=POLLERR}])
2139 23:30:50.004723 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="\10\0z\34\10[\0\3HIJKLMNOPQRSTUVWXYZ[\\]^_"..., iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=2761}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[64]}, {cmsg_len=48, cmsg_level=SOL_IP, cmsg_type=IP_RECVERR, cmsg_data={ee_errno=113, ee_origin=2, ee_type=11, ee_code=0, ee_info=0, ee_data=0, offender={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("192.168.1.1")}}}], msg_controllen=104, msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 40
2139 23:30:50.004771 write(1, " 0.610 ms", 10) = 10
2139 23:30:50.004801 setsockopt(4, SOL_IP, IP_TTL, [7], 4) = 0
2139 23:30:50.004829 sendto(4, "\10\0z\f\10[\0\23HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.004867 poll([{fd=4, events=POLLIN|POLLERR}], 1, 4998) = 1 ([{fd=4, revents=POLLERR}])
2139 23:30:50.041867 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="\10\0z\22\10[\0\r", iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=41671}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[252]}, {cmsg_len=48, cmsg_level=SOL_IP, cmsg_type=IP_RECVERR, cmsg_data={ee_errno=113, ee_origin=2, ee_type=11, ee_code=0, ee_info=0, ee_data=0, offender={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("213.190.41.3")}}}], msg_controllen=104, msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 8
2139 23:30:50.042016 sendto(4, "\10\0z\v\10[\0\24HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.042130 poll([{fd=4, events=POLLIN|POLLERR}], 1, 361) = 1 ([{fd=4, revents=POLLERR}])
2139 23:30:50.042220 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="\10\0z\21\10[\0\16", iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=41672}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[252]}, {cmsg_len=48, cmsg_level=SOL_IP, cmsg_type=IP_RECVERR, cmsg_data={ee_errno=113, ee_origin=2, ee_type=11, ee_code=0, ee_info=0, ee_data=0, offender={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("213.190.41.3")}}}], msg_controllen=104, msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 8
2139 23:30:50.042328 sendto(4, "\10\0z\n\10[\0\25HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.042418 poll([{fd=4, events=POLLIN|POLLERR}], 1, 361) = 1 ([{fd=4, revents=POLLERR}])
2139 23:30:50.042502 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="\10\0z\20\10[\0\17", iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=42437}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[252]}, {cmsg_len=48, cmsg_level=SOL_IP, cmsg_type=IP_RECVERR, cmsg_data={ee_errno=113, ee_origin=2, ee_type=11, ee_code=0, ee_info=0, ee_data=0, offender={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("213.190.41.3")}}}], msg_controllen=104, msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 8
2139 23:30:50.042626 setsockopt(4, SOL_IP, IP_TTL, [8], 4) = 0
2139 23:30:50.042688 sendto(4, "\10\0z\t\10[\0\26HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.042773 poll([{fd=4, events=POLLIN|POLLERR}], 1, 360) = 1 ([{fd=4, revents=POLLERR}])
2139 23:30:50.042836 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="\10\0z\25\10[\0\n", iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=42461}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[253]}, {cmsg_len=48, cmsg_level=SOL_IP, cmsg_type=IP_RECVERR, cmsg_data={ee_errno=113, ee_origin=2, ee_type=11, ee_code=0, ee_info=0, ee_data=0, offender={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("82.135.179.168")}}}], msg_controllen=104, msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 8
2139 23:30:50.042927 sendto(4, "\10\0z\10\10[\0\27HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.043000 poll([{fd=4, events=POLLIN|POLLERR}], 1, 369) = 1 ([{fd=4, revents=POLLERR}])
2139 23:30:50.043061 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="\10\0z\24\10[\0\v", iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=42551}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[253]}, {cmsg_len=48, cmsg_level=SOL_IP, cmsg_type=IP_RECVERR, cmsg_data={ee_errno=113, ee_origin=2, ee_type=11, ee_code=0, ee_info=0, ee_data=0, offender={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("82.135.179.168")}}}], msg_controllen=104, msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 8
2139 23:30:50.043163 sendto(4, "\10\0z\7\10[\0\30HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.043236 poll([{fd=4, events=POLLIN|POLLERR}], 1, 369) = 1 ([{fd=4, revents=POLLERR}])
2139 23:30:50.043297 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="\10\0z\30\10[\0\7", iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=42551}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[254]}, {cmsg_len=48, cmsg_level=SOL_IP, cmsg_type=IP_RECVERR, cmsg_data={ee_errno=113, ee_origin=2, ee_type=11, ee_code=0, ee_info=0, ee_data=0, offender={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("10.69.21.145")}}}], msg_controllen=104, msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 8
2139 23:30:50.043384 setsockopt(4, SOL_IP, IP_TTL, [9], 4) = 0
2139 23:30:50.043439 sendto(4, "\10\0z\6\10[\0\31HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.043510 poll([{fd=4, events=POLLIN|POLLERR}], 1, 371) = 1 ([{fd=4, revents=POLLERR}])
2139 23:30:50.043571 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="\10\0z\27\10[\0\10", iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=42551}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[254]}, {cmsg_len=48, cmsg_level=SOL_IP, cmsg_type=IP_RECVERR, cmsg_data={ee_errno=113, ee_origin=2, ee_type=11, ee_code=0, ee_info=0, ee_data=0, offender={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("10.69.21.145")}}}], msg_controllen=104, msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 8
2139 23:30:50.043659 sendto(4, "\10\0z\5\10[\0\32HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.043730 poll([{fd=4, events=POLLIN|POLLERR}], 1, 371) = 1 ([{fd=4, revents=POLLERR}])
2139 23:30:50.043805 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="\10\0z\23\10[\0\f", iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=42551}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[253]}, {cmsg_len=48, cmsg_level=SOL_IP, cmsg_type=IP_RECVERR, cmsg_data={ee_errno=113, ee_origin=2, ee_type=11, ee_code=0, ee_info=0, ee_data=0, offender={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("82.135.179.168")}}}], msg_controllen=104, msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 8
2139 23:30:50.043908 sendto(4, "\10\0z\4\10[\0\33HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.043991 poll([{fd=4, events=POLLIN|POLLERR}], 1, 371) = 1 ([{fd=4, revents=POLLERR}])
2139 23:30:50.044062 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="\10\0z\26\10[\0\t", iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=42551}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[254]}, {cmsg_len=48, cmsg_level=SOL_IP, cmsg_type=IP_RECVERR, cmsg_data={ee_errno=113, ee_origin=2, ee_type=11, ee_code=0, ee_info=0, ee_data=0, offender={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("10.69.21.145")}}}], msg_controllen=104, msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 8
2139 23:30:50.044166 setsockopt(4, SOL_IP, IP_TTL, [10], 4) = 0
2139 23:30:50.044230 sendto(4, "\10\0z\3\10[\0\34HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.044312 poll([{fd=4, events=POLLIN|POLLERR}], 1, 370) = 1 ([{fd=4, revents=POLLERR}])
2139 23:30:50.067592 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="\10\0z\17\10[\0\20", iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=67424}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[244]}, {cmsg_len=48, cmsg_level=SOL_IP, cmsg_type=IP_RECVERR, cmsg_data={ee_errno=113, ee_origin=2, ee_type=11, ee_code=0, ee_info=0, ee_data=0, offender={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("193.219.153.25")}}}], msg_controllen=104, msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 8
2139 23:30:50.067832 sendto(4, "\10\0z\2\10[\0\35HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.068033 poll([{fd=4, events=POLLIN|POLLERR}], 1, 347) = 1 ([{fd=4, revents=POLLERR}])
2139 23:30:50.069483 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="\10\0z\16\10[\0\21", iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=69338}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[244]}, {cmsg_len=48, cmsg_level=SOL_IP, cmsg_type=IP_RECVERR, cmsg_data={ee_errno=113, ee_origin=2, ee_type=11, ee_code=0, ee_info=0, ee_data=0, offender={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("193.219.153.25")}}}], msg_controllen=104, msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 8
2139 23:30:50.069713 sendto(4, "\10\0z\1\10[\0\36HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.069893 poll([{fd=4, events=POLLIN|POLLERR}], 1, 345) = 1 ([{fd=4, revents=POLLERR}])
2139 23:30:50.070043 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="\10\0z\r\10[\0\22", iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=69338}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[244]}, {cmsg_len=48, cmsg_level=SOL_IP, cmsg_type=IP_RECVERR, cmsg_data={ee_errno=113, ee_origin=2, ee_type=11, ee_code=0, ee_info=0, ee_data=0, offender={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("193.219.153.25")}}}], msg_controllen=104, msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 8
2139 23:30:50.070252 setsockopt(4, SOL_IP, IP_TTL, [11], 4) = 0
2139 23:30:50.070381 sendto(4, "\10\0z\0\10[\0\37HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2139 23:30:50.070549 poll([{fd=4, events=POLLIN|POLLERR}], 1, 344) = 1 ([{fd=4, revents=POLLIN}])
2139 23:30:50.073519 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="E\0\0<\361\212\0\0005\1]\31S\253!\274\300\250\1\16\0\0\202\f\10[\0\23HIJK"..., iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=73382}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[53]}], msg_controllen=56, msg_flags=0}, 0) = 60
2139 23:30:50.073708 poll([{fd=4, events=POLLIN|POLLERR}], 1, 341) = 1 ([{fd=4, revents=POLLIN}])
2139 23:30:50.097832 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="E\0\0<\361\217\0\0005\1]\24S\253!\274\300\250\1\16\0\0\202\v\10[\0\24HIJK"..., iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=97530}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[53]}], msg_controllen=56, msg_flags=0}, 0) = 60
2139 23:30:50.098088 poll([{fd=4, events=POLLIN|POLLERR}], 1, 316) = 1 ([{fd=4, revents=POLLIN}])
2139 23:30:50.110919 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="E\0\0<\361\220\0\0005\1]\23S\253!\274\300\250\1\16\0\0\202\n\10[\0\25HIJK"..., iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=110617}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[53]}], msg_controllen=56, msg_flags=0}, 0) = 60
2139 23:30:50.111198 poll([{fd=4, events=POLLIN|POLLERR}], 1, 303) = 1 ([{fd=4, revents=POLLIN}])
2139 23:30:50.111365 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="E\0\0<\361\221\0\0005\1]\22S\253!\274\300\250\1\16\0\0\202\t\10[\0\26HIJK"..., iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=110618}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[53]}], msg_controllen=56, msg_flags=0}, 0) = 60
2139 23:30:50.111563 poll([{fd=4, events=POLLIN|POLLERR}], 1, 303) = 1 ([{fd=4, revents=POLLIN}])
2139 23:30:50.113525 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="E\0\0<\361\224\0\0005\1]\17S\253!\274\300\250\1\16\0\0\202\10\10[\0\27HIJK"..., iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=113388}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[53]}], msg_controllen=56, msg_flags=0}, 0) = 60
2139 23:30:50.113711 poll([{fd=4, events=POLLIN|POLLERR}], 1, 301) = 1 ([{fd=4, revents=POLLIN}])
2139 23:30:50.113853 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="E\0\0<\361\225\0\0005\1]\16S\253!\274\300\250\1\16\0\0\202\7\10[\0\30HIJK"..., iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=113388}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[53]}], msg_controllen=56, msg_flags=0}, 0) = 60
2139 23:30:50.114034 poll([{fd=4, events=POLLIN|POLLERR}], 1, 300) = 1 ([{fd=4, revents=POLLIN}])
2139 23:30:50.114507 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="E\0\0<\361\226\0\0005\1]\rS\253!\274\300\250\1\16\0\0\202\6\10[\0\31HIJK"..., iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=114381}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[53]}], msg_controllen=56, msg_flags=0}, 0) = 60
2139 23:30:50.114689 poll([{fd=4, events=POLLIN|POLLERR}], 1, 300) = 1 ([{fd=4, revents=POLLIN}])
2139 23:30:50.114828 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="E\0\0<\361\227\0\0005\1]\fS\253!\274\300\250\1\16\0\0\202\5\10[\0\32HIJK"..., iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=114381}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[53]}], msg_controllen=56, msg_flags=0}, 0) = 60
2139 23:30:50.115010 poll([{fd=4, events=POLLIN|POLLERR}], 1, 300) = 1 ([{fd=4, revents=POLLIN}])
2139 23:30:50.115149 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="E\0\0<\361\230\0\0005\1]\vS\253!\274\300\250\1\16\0\0\202\4\10[\0\33HIJK"..., iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=114382}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[53]}], msg_controllen=56, msg_flags=0}, 0) = 60
2139 23:30:50.115329 poll([{fd=4, events=POLLIN|POLLERR}], 1, 299) = 1 ([{fd=4, revents=POLLIN}])
2139 23:30:50.115468 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="E\0\0<\361\231\0\0005\1]\nS\253!\274\300\250\1\16\0\0\202\3\10[\0\34HIJK"..., iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=114382}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[53]}], msg_controllen=56, msg_flags=0}, 0) = 60
2139 23:30:50.115694 poll([{fd=4, events=POLLIN|POLLERR}], 1, 299) = 1 ([{fd=4, revents=POLLIN}])
2139 23:30:50.122513 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="E\0\0<\361\232\0\0005\1]\tS\253!\274\300\250\1\16\0\0\202\2\10[\0\35HIJK"..., iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=122364}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[53]}], msg_controllen=56, msg_flags=0}, 0) = 60
2139 23:30:50.122704 poll([{fd=4, events=POLLIN|POLLERR}], 1, 292) = 1 ([{fd=4, revents=POLLIN}])
2139 23:30:50.127817 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="E\0\0<\361\234\0\0005\1]\7S\253!\274\300\250\1\16\0\0\202\1\10[\0\36HIJK"..., iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=127518}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[53]}], msg_controllen=56, msg_flags=0}, 0) = 60
2139 23:30:50.128081 poll([{fd=4, events=POLLIN|POLLERR}], 1, 286) = 1 ([{fd=4, revents=POLLIN}])
2139 23:30:50.132751 recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, msg_namelen=28 => 16, msg_iov=[{iov_base="E\0\0<\361\235\0\0005\1]\6S\253!\274\300\250\1\16\0\0\202\0\10[\0\37HIJK"..., iov_len=1280}], msg_iovlen=1, msg_control=[{cmsg_len=32, cmsg_level=SOL_SOCKET, cmsg_type=SO_TIMESTAMP_OLD, cmsg_data={tv_sec=1674509450, tv_usec=132451}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, cmsg_data=[53]}], msg_controllen=56, msg_flags=0}, 0) = 60
2139 23:30:50.132993 poll([{fd=4, events=POLLIN|POLLERR}], 1, 282) = 0 (Timeout)
2139 23:30:50.415763 write(1, "\n", 1) = 1
2139 23:30:50.415993 write(1, " 2 *", 5) = 5
2139 23:30:50.416223 write(1, " *", 2) = 2
2139 23:30:50.416418 write(1, " *", 2) = 2
2139 23:30:50.416611 write(1, "\n", 1) = 1
2139 23:30:50.416771 newfstatat(AT_FDCWD, "/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=945, ...}, 0) = 0
2139 23:30:50.416963 newfstatat(AT_FDCWD, "/etc/nsswitch.conf", {st_mode=S_IFREG|0644, st_size=397, ...}, 0) = 0
2139 23:30:50.417133 openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:50.417305 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=80, ...}, AT_EMPTY_PATH) = 0
2139 23:30:50.417469 lseek(3, 0, SEEK_SET) = 0
2139 23:30:50.417600 read(3, "127.0.0.1 myth.nullroute.lt myth"..., 4096) = 80
2139 23:30:50.417750 read(3, "", 4096) = 0
2139 23:30:50.417879 close(3) = 0
2139 23:30:50.418020 socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
2139 23:30:50.418171 setsockopt(3, SOL_IP, IP_RECVERR, [1], 4) = 0
2139 23:30:50.418317 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
2139 23:30:50.418483 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
2139 23:30:50.418642 sendto(3, "\272\207\1 \0\1\0\0\0\0\0\1\003145\00221\00269\00210\7in-add"..., 54, MSG_NOSIGNAL, NULL, 0) = 54
2139 23:30:50.418915 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}])
2139 23:30:50.419652 ioctl(3, FIONREAD, [103]) = 0
2139 23:30:50.419803 recvfrom(3, "\272\207\201\203\0\1\0\0\0\1\0\1\003145\00221\00269\00210\7in-add"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28 => 16]) = 103
2139 23:30:50.420015 close(3) = 0
2139 23:30:50.420183 write(1, " 3 10.69.21.145 (10.69.21.145) "..., 42) = 42
2139 23:30:50.420339 write(1, " 40.140 ms", 11) = 11
2139 23:30:50.420534 write(1, " 40.103 ms", 11) = 11
2139 23:30:50.420678 write(1, "\n", 1) = 1
2139 23:30:50.420832 newfstatat(AT_FDCWD, "/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=945, ...}, 0) = 0
2139 23:30:50.421008 newfstatat(AT_FDCWD, "/etc/nsswitch.conf", {st_mode=S_IFREG|0644, st_size=397, ...}, 0) = 0
2139 23:30:50.421173 openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:50.421331 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=80, ...}, AT_EMPTY_PATH) = 0
2139 23:30:50.421493 lseek(3, 0, SEEK_SET) = 0
2139 23:30:50.421621 read(3, "127.0.0.1 myth.nullroute.lt myth"..., 4096) = 80
2139 23:30:50.421767 read(3, "", 4096) = 0
2139 23:30:50.421897 close(3) = 0
2139 23:30:50.422032 socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
2139 23:30:50.422178 setsockopt(3, SOL_IP, IP_RECVERR, [1], 4) = 0
2139 23:30:50.422346 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
2139 23:30:50.422507 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
2139 23:30:50.422661 sendto(3, "\312\213\1 \0\1\0\0\0\0\0\1\003168\003179\003135\282\7in-a"..., 56, MSG_NOSIGNAL, NULL, 0) = 56
2139 23:30:50.422872 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}])
2139 23:30:50.423324 ioctl(3, FIONREAD, [100]) = 0
2139 23:30:50.423463 recvfrom(3, "\312\213\201\200\0\1\0\1\0\0\0\1\003168\003179\003135\282\7in-a"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28 => 16]) = 100
2139 23:30:50.423665 close(3) = 0
2139 23:30:50.423818 write(1, " 4 82-135-179-168.static.zebra."..., 62) = 62
2139 23:30:50.423973 write(1, " 40.002 ms", 11) = 11
2139 23:30:50.424125 write(1, " 39.965 ms", 11) = 11
2139 23:30:50.424271 write(1, "\n", 1) = 1
2139 23:30:50.424420 newfstatat(AT_FDCWD, "/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=945, ...}, 0) = 0
2139 23:30:50.424592 newfstatat(AT_FDCWD, "/etc/nsswitch.conf", {st_mode=S_IFREG|0644, st_size=397, ...}, 0) = 0
2139 23:30:50.424755 openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:50.424913 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=80, ...}, AT_EMPTY_PATH) = 0
2139 23:30:50.425080 lseek(3, 0, SEEK_SET) = 0
2139 23:30:50.425207 read(3, "127.0.0.1 myth.nullroute.lt myth"..., 4096) = 80
2139 23:30:50.425351 read(3, "", 4096) = 0
2139 23:30:50.425479 close(3) = 0
2139 23:30:50.425649 socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
2139 23:30:50.425792 setsockopt(3, SOL_IP, IP_RECVERR, [1], 4) = 0
2139 23:30:50.425934 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
2139 23:30:50.426092 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
2139 23:30:50.426246 sendto(3, "6\210\1 \0\1\0\0\0\0\0\1\0013\00241\003190\003213\7in-add"..., 54, MSG_NOSIGNAL, NULL, 0) = 54
2139 23:30:50.426450 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}])
2139 23:30:50.427006 ioctl(3, FIONREAD, [98]) = 0
2139 23:30:50.427147 recvfrom(3, "6\210\201\200\0\1\0\1\0\0\0\1\0013\00241\003190\003213\7in-add"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28 => 16]) = 98
2139 23:30:50.427350 close(3) = 0
2139 23:30:50.427501 write(1, " 5 213-190-41-3.static.telecom."..., 60) = 60
2139 23:30:50.427654 write(1, " 38.984 ms", 11) = 11
2139 23:30:50.427802 write(1, " 39.713 ms", 11) = 11
2139 23:30:50.427944 write(1, "\n", 1) = 1
2139 23:30:50.428093 newfstatat(AT_FDCWD, "/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=945, ...}, 0) = 0
2139 23:30:50.428268 newfstatat(AT_FDCWD, "/etc/nsswitch.conf", {st_mode=S_IFREG|0644, st_size=397, ...}, 0) = 0
2139 23:30:50.428433 openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:50.428588 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=80, ...}, AT_EMPTY_PATH) = 0
2139 23:30:50.428748 lseek(3, 0, SEEK_SET) = 0
2139 23:30:50.428902 read(3, "127.0.0.1 myth.nullroute.lt myth"..., 4096) = 80
2139 23:30:50.429086 read(3, "", 4096) = 0
2139 23:30:50.429217 close(3) = 0
2139 23:30:50.429352 socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
2139 23:30:50.429495 setsockopt(3, SOL_IP, IP_RECVERR, [1], 4) = 0
2139 23:30:50.429636 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
2139 23:30:50.429793 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
2139 23:30:50.429948 sendto(3, "\334I\1 \0\1\0\0\0\0\0\1\00225\003153\003219\003193\7in-a"..., 56, MSG_NOSIGNAL, NULL, 0) = 56
2139 23:30:50.430152 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}])
2139 23:30:50.430809 ioctl(3, FIONREAD, [116]) = 0
2139 23:30:50.430948 recvfrom(3, "\334I\201\203\0\1\0\0\0\1\0\1\00225\003153\003219\003193\7in-a"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28 => 16]) = 116
2139 23:30:50.431149 close(3) = 0
2139 23:30:50.431299 write(1, " 6 193.219.153.25 (193.219.153."..., 46) = 46
2139 23:30:50.431455 write(1, " 64.843 ms", 11) = 11
2139 23:30:50.431602 write(1, " 64.690 ms", 11) = 11
2139 23:30:50.431744 write(1, "\n", 1) = 1
2139 23:30:50.431890 newfstatat(AT_FDCWD, "/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=945, ...}, 0) = 0
2139 23:30:50.432060 newfstatat(AT_FDCWD, "/etc/nsswitch.conf", {st_mode=S_IFREG|0644, st_size=397, ...}, 0) = 0
2139 23:30:50.432244 openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
2139 23:30:50.432409 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=80, ...}, AT_EMPTY_PATH) = 0
2139 23:30:50.432572 lseek(3, 0, SEEK_SET) = 0
2139 23:30:50.432698 read(3, "127.0.0.1 myth.nullroute.lt myth"..., 4096) = 80
2139 23:30:50.432841 read(3, "", 4096) = 0
2139 23:30:50.432968 close(3) = 0
2139 23:30:50.433102 socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
2139 23:30:50.433244 setsockopt(3, SOL_IP, IP_RECVERR, [1], 4) = 0
2139 23:30:50.433385 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
2139 23:30:50.433542 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}])
2139 23:30:50.433696 sendto(3, "\370\307\1 \0\1\0\0\0\0\0\1\003188\00233\003171\283\7in-ad"..., 55, MSG_NOSIGNAL, NULL, 0) = 55
2139 23:30:50.433896 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}])
2139 23:30:50.434567 ioctl(3, FIONREAD, [115]) = 0
2139 23:30:50.434706 recvfrom(3, "\370\307\201\203\0\1\0\0\0\1\0\1\003188\00233\003171\283\7in-ad"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28 => 16]) = 115
2139 23:30:50.434906 close(3) = 0
2139 23:30:50.435057 write(1, " 7 83.171.33.188 (83.171.33.188"..., 44) = 44
2139 23:30:50.435209 write(1, " 55.530 ms", 11) = 11
2139 23:30:50.435357 write(1, " 68.302 ms", 11) = 11
2139 23:30:50.435498 write(1, "\n", 1) = 1
2139 23:30:50.435667 exit_group(0) = ?
2139 23:30:50.436192 +++ exited with 0 +++
[-- Attachment #4: traceroute.pcap --]
[-- Type: application/vnd.tcpdump.pcap, Size: 2326 bytes --]
[-- Attachment #5: traceroute.strace --]
[-- Type: text/plain, Size: 14195 bytes --]
2104 23:30:30.755404 execve("/usr/bin/traceroute", ["traceroute", "-I", "83.171.33.188"], 0x7ffe74f996e0 /* 51 vars */) = 0
2104 23:30:30.755677 brk(NULL) = 0x55d41463d000
2104 23:30:30.755707 arch_prctl(0x3001 /* ARCH_??? */, 0x7ffdd5717770) = -1 EINVAL (Invalid argument)
2104 23:30:30.755755 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
2104 23:30:30.755789 openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
2104 23:30:30.755818 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=124691, ...}, AT_EMPTY_PATH) = 0
2104 23:30:30.755850 mmap(NULL, 124691, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5612f1c000
2104 23:30:30.755875 close(3) = 0
2104 23:30:30.755902 openat(AT_FDCWD, "/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
2104 23:30:30.755925 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P4\2\0\0\0\0\0"..., 832) = 832
2104 23:30:30.755949 pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
2104 23:30:30.755971 newfstatat(3, "", {st_mode=S_IFREG|0755, st_size=1953472, ...}, AT_EMPTY_PATH) = 0
2104 23:30:30.755995 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5612f1a000
2104 23:30:30.756019 pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
2104 23:30:30.756040 mmap(NULL, 1994384, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f5612d33000
2104 23:30:30.756062 mmap(0x7f5612d55000, 1421312, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22000) = 0x7f5612d55000
2104 23:30:30.756092 mmap(0x7f5612eb0000, 356352, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17d000) = 0x7f5612eb0000
2104 23:30:30.756121 mmap(0x7f5612f07000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d4000) = 0x7f5612f07000
2104 23:30:30.756151 mmap(0x7f5612f0d000, 52880, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f5612f0d000
2104 23:30:30.756183 close(3) = 0
2104 23:30:30.756210 mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5612d30000
2104 23:30:30.756236 arch_prctl(ARCH_SET_FS, 0x7f5612d30740) = 0
2104 23:30:30.756257 set_tid_address(0x7f5612d30a10) = 2104
2104 23:30:30.756277 set_robust_list(0x7f5612d30a20, 24) = 0
2104 23:30:30.756295 rseq(0x7f5612d31060, 0x20, 0, 0x53053053) = 0
2104 23:30:30.756354 mprotect(0x7f5612f07000, 16384, PROT_READ) = 0
2104 23:30:30.756401 mprotect(0x55d413992000, 4096, PROT_READ) = 0
2104 23:30:30.756429 mprotect(0x7f5612f6d000, 8192, PROT_READ) = 0
2104 23:30:30.756463 prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
2104 23:30:30.756492 munmap(0x7f5612f1c000, 124691) = 0
2104 23:30:30.756536 times(NULL) = 1431663638
2104 23:30:30.756557 getpid() = 2104
2104 23:30:30.756584 getrandom("\xe4\x1b\x63\xb4\x36\xaa\xe4\xe9", 8, GRND_NONBLOCK) = 8
2104 23:30:30.756608 brk(NULL) = 0x55d41463d000
2104 23:30:30.756629 brk(0x55d41465e000) = 0x55d41465e000
2104 23:30:30.756652 openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
2104 23:30:30.756681 openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
2104 23:30:30.756705 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=2998, ...}, AT_EMPTY_PATH) = 0
2104 23:30:30.756731 read(3, "# Locale name alias data base.\n#"..., 4096) = 2998
2104 23:30:30.756761 read(3, "", 4096) = 0
2104 23:30:30.756782 close(3) = 0
2104 23:30:30.756806 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = 3
2104 23:30:30.756828 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=258, ...}, AT_EMPTY_PATH) = 0
2104 23:30:30.756852 mmap(NULL, 258, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5612f3a000
2104 23:30:30.756875 close(3) = 0
2104 23:30:30.756896 openat(AT_FDCWD, "/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory)
2104 23:30:30.756922 openat(AT_FDCWD, "/usr/lib/gconv/gconv-modules", O_RDONLY|O_CLOEXEC) = 3
2104 23:30:30.756952 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=3916, ...}, AT_EMPTY_PATH) = 0
2104 23:30:30.756978 read(3, "# GNU libc iconv configuration.\n"..., 4096) = 3916
2104 23:30:30.757017 read(3, "", 4096) = 0
2104 23:30:30.757038 close(3) = 0
2104 23:30:30.757059 openat(AT_FDCWD, "/usr/lib/gconv/gconv-modules.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
2104 23:30:30.757084 newfstatat(3, "", {st_mode=S_IFDIR|0755, st_size=48, ...}, AT_EMPTY_PATH) = 0
2104 23:30:30.757112 getdents64(3, 0x55d414640e80 /* 3 entries */, 32768) = 96
2104 23:30:30.757143 openat(AT_FDCWD, "/usr/lib/gconv/gconv-modules.d/gconv-modules-extra.conf", O_RDONLY|O_CLOEXEC) = 4
2104 23:30:30.757166 newfstatat(4, "", {st_mode=S_IFREG|0644, st_size=53974, ...}, AT_EMPTY_PATH) = 0
2104 23:30:30.757191 read(4, "# GNU libc iconv configuration.\n"..., 4096) = 4096
2104 23:30:30.757238 read(4, "B1002//\tJUS_I.B1.002//\nmodule\tJU"..., 4096) = 4096
2104 23:30:30.757302 read(4, "59-5//\nalias\tISO_8859-5//\t\tISO-8"..., 4096) = 4096
2104 23:30:30.757365 read(4, "59-16//\t\tINTERNAL\t\tISO8859-16\t1\n"..., 4096) = 4096
2104 23:30:30.757433 read(4, "-SE-A\t1\nmodule\tINTERNAL\t\tEBCDIC-"..., 4096) = 4096
2104 23:30:30.757506 read(4, "97\t\t1\n\n#\tfrom\t\t\tto\t\t\tmodule\t\tcos"..., 4096) = 4096
2104 23:30:30.757589 read(4, "1\n\n#\tfrom\t\t\tto\t\t\tmodule\t\tcost\nal"..., 4096) = 4096
2104 23:30:30.757681 read(4, "6//\t\tIBM1046//\nalias\tCP1046//\t\tI"..., 4096) = 4096
2104 23:30:30.757768 read(4, "\tto\t\t\tmodule\t\tcost\nalias\tRUSCII/"..., 4096) = 4096
2104 23:30:30.757834 brk(0x55d41467f000) = 0x55d41467f000
2104 23:30:30.757889 read(4, "03//\nmodule\tCSN_369103//\t\tINTERN"..., 4096) = 4096
2104 23:30:30.757986 read(4, "\tmodule\t\tcost\nalias\tISO-IR-8-1//"..., 4096) = 4096
2104 23:30:30.758093 read(4, "IBM1156\t\t1\n\n#\tfrom\t\t\tto\t\t\tmodule"..., 4096) = 4096
2104 23:30:30.758205 read(4, "\t\tIBM1166//\nalias\tCP1166//\t\tIBM1"..., 4096) = 4096
2104 23:30:30.758321 read(4, "alias\tROMAN9//\t\tHP-ROMAN9//\nalia"..., 4096) = 726
2104 23:30:30.758363 read(4, "", 4096) = 0
2104 23:30:30.758384 close(4) = 0
2104 23:30:30.758404 getdents64(3, 0x55d414640e80 /* 0 entries */, 32768) = 0
2104 23:30:30.758425 close(3) = 0
2104 23:30:30.758478 futex(0x7f5612f0c98c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
2104 23:30:30.758502 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_MEASUREMENT", O_RDONLY|O_CLOEXEC) = 3
2104 23:30:30.758528 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=23, ...}, AT_EMPTY_PATH) = 0
2104 23:30:30.758554 mmap(NULL, 23, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5612f39000
2104 23:30:30.758577 close(3) = 0
2104 23:30:30.758601 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_TELEPHONE", O_RDONLY|O_CLOEXEC) = 3
2104 23:30:30.758624 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=47, ...}, AT_EMPTY_PATH) = 0
2104 23:30:30.758647 mmap(NULL, 47, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5612f38000
2104 23:30:30.758668 close(3) = 0
2104 23:30:30.758692 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_ADDRESS", O_RDONLY|O_CLOEXEC) = 3
2104 23:30:30.758715 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=127, ...}, AT_EMPTY_PATH) = 0
2104 23:30:30.758738 mmap(NULL, 127, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5612f37000
2104 23:30:30.758760 close(3) = 0
2104 23:30:30.758795 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_NAME", O_RDONLY|O_CLOEXEC) = 3
2104 23:30:30.758820 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=62, ...}, AT_EMPTY_PATH) = 0
2104 23:30:30.758846 mmap(NULL, 62, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5612f36000
2104 23:30:30.758868 close(3) = 0
2104 23:30:30.758906 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_PAPER", O_RDONLY|O_CLOEXEC) = 3
2104 23:30:30.758931 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=34, ...}, AT_EMPTY_PATH) = 0
2104 23:30:30.758957 mmap(NULL, 34, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5612f35000
2104 23:30:30.758980 close(3) = 0
2104 23:30:30.759003 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_MESSAGES", O_RDONLY|O_CLOEXEC) = 3
2104 23:30:30.759034 newfstatat(3, "", {st_mode=S_IFDIR|0755, st_size=30, ...}, AT_EMPTY_PATH) = 0
2104 23:30:30.759059 close(3) = 0
2104 23:30:30.759079 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_MESSAGES/SYS_LC_MESSAGES", O_RDONLY|O_CLOEXEC) = 3
2104 23:30:30.759103 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=48, ...}, AT_EMPTY_PATH) = 0
2104 23:30:30.759128 mmap(NULL, 48, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5612f34000
2104 23:30:30.759151 close(3) = 0
2104 23:30:30.759174 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_MONETARY", O_RDONLY|O_CLOEXEC) = 3
2104 23:30:30.759198 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=270, ...}, AT_EMPTY_PATH) = 0
2104 23:30:30.759223 mmap(NULL, 270, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5612f33000
2104 23:30:30.759246 close(3) = 0
2104 23:30:30.759269 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_COLLATE", O_RDONLY|O_CLOEXEC) = 3
2104 23:30:30.759293 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=1406, ...}, AT_EMPTY_PATH) = 0
2104 23:30:30.759318 mmap(NULL, 1406, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5612f32000
2104 23:30:30.759341 close(3) = 0
2104 23:30:30.759367 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_TIME", O_RDONLY|O_CLOEXEC) = 3
2104 23:30:30.759392 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=3360, ...}, AT_EMPTY_PATH) = 0
2104 23:30:30.759417 mmap(NULL, 3360, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5612f31000
2104 23:30:30.759440 close(3) = 0
2104 23:30:30.759464 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_NUMERIC", O_RDONLY|O_CLOEXEC) = 3
2104 23:30:30.759488 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=50, ...}, AT_EMPTY_PATH) = 0
2104 23:30:30.759513 mmap(NULL, 50, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5612f30000
2104 23:30:30.759537 close(3) = 0
2104 23:30:30.759560 openat(AT_FDCWD, "/usr/lib/locale/C.UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = 3
2104 23:30:30.759584 newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=353616, ...}, AT_EMPTY_PATH) = 0
2104 23:30:30.759609 mmap(NULL, 353616, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f5612cd9000
2104 23:30:30.759632 close(3) = 0
2104 23:30:30.759668 fcntl(0, F_GETFL) = 0x2 (flags O_RDWR)
2104 23:30:30.759690 fcntl(1, F_GETFL) = 0x2 (flags O_RDWR)
2104 23:30:30.759711 fcntl(2, F_GETFL) = 0x2 (flags O_RDWR)
2104 23:30:30.759737 socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP) = 3
2104 23:30:30.759766 socket(AF_INET, SOCK_RAW, IPPROTO_ICMP) = -1 EPERM (Operation not permitted)
2104 23:30:30.759790 bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 28) = 0
2104 23:30:30.759820 setsockopt(3, SOL_IP, IP_MTU_DISCOVER, [0], 4) = 0
2104 23:30:30.759844 setsockopt(3, SOL_SOCKET, SO_TIMESTAMP_OLD, [1], 4) = 0
2104 23:30:30.759867 setsockopt(3, SOL_IP, IP_RECVTTL, [1], 4) = 0
2104 23:30:30.759889 fcntl(3, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
2104 23:30:30.759910 connect(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("83.171.33.188")}, 28) = 0
2104 23:30:30.759937 setsockopt(3, SOL_IP, IP_RECVERR, [1], 4) = 0
2104 23:30:30.759960 getsockname(3, {sa_family=AF_INET, sin_port=htons(16), sin_addr=inet_addr("192.168.1.14")}, [28 => 16]) = 0
2104 23:30:30.759987 newfstatat(1, "", {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}, AT_EMPTY_PATH) = 0
2104 23:30:30.760015 write(1, "traceroute to 83.171.33.188 (83."..., 73) = 73
2104 23:30:30.760059 setsockopt(3, SOL_IP, IP_TTL, [1], 4) = 0
2104 23:30:30.760091 sendto(3, "\10\0\202i\0\20\0\1HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2104 23:30:30.760190 sendto(3, "\10\0\202h\0\20\0\2HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2104 23:30:30.760226 sendto(3, "\10\0\202g\0\20\0\3HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2104 23:30:30.760258 setsockopt(3, SOL_IP, IP_TTL, [2], 4) = 0
2104 23:30:30.760281 sendto(3, "\10\0\202f\0\20\0\4HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2104 23:30:30.760312 sendto(3, "\10\0\202e\0\20\0\5HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2104 23:30:30.760350 sendto(3, "\10\0\202d\0\20\0\6HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2104 23:30:30.760381 setsockopt(3, SOL_IP, IP_TTL, [3], 4) = 0
2104 23:30:30.760404 sendto(3, "\10\0\202c\0\20\0\7HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2104 23:30:30.760434 sendto(3, "\10\0\202b\0\20\0\10HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2104 23:30:30.760465 sendto(3, "\10\0\202a\0\20\0\tHIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2104 23:30:30.760496 setsockopt(3, SOL_IP, IP_TTL, [4], 4) = 0
2104 23:30:30.760518 sendto(3, "\10\0\202`\0\20\0\nHIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2104 23:30:30.760549 sendto(3, "\10\0\202_\0\20\0\vHIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2104 23:30:30.760579 sendto(3, "\10\0\202^\0\20\0\fHIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2104 23:30:30.760610 setsockopt(3, SOL_IP, IP_TTL, [5], 4) = 0
2104 23:30:30.760633 sendto(3, "\10\0\202]\0\20\0\rHIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2104 23:30:30.760663 sendto(3, "\10\0\202\\\0\20\0\16HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = 40
2104 23:30:30.760707 sendto(3, "\10\0\202[\0\20\0\17HIJKLMNOPQRSTUVWXYZ[\\]^_"..., 40, 0, NULL, 0) = -1 EHOSTUNREACH (No route to host)
2104 23:30:30.760739 write(2, "\n", 1) = 1
2104 23:30:30.760774 openat(AT_FDCWD, "/usr/share/locale/C.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
2104 23:30:30.760822 openat(AT_FDCWD, "/usr/share/locale/C.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
2104 23:30:30.760848 openat(AT_FDCWD, "/usr/share/locale/C/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
2104 23:30:30.760884 write(2, "send: No route to host\n", 23) = 23
2104 23:30:30.760918 exit_group(1) = ?
2104 23:30:30.761038 +++ exited with 1 +++
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: traceroute failure in kernel 6.1 and 6.2
2023-01-23 21:45 ` Mantas Mikulėnas
@ 2023-01-23 22:26 ` Eric Dumazet
2023-01-24 5:34 ` Mantas Mikulėnas
0 siblings, 1 reply; 12+ messages in thread
From: Eric Dumazet @ 2023-01-23 22:26 UTC (permalink / raw)
To: Mantas Mikulėnas; +Cc: netdev
On Mon, Jan 23, 2023 at 10:45 PM Mantas Mikulėnas <grawity@gmail.com> wrote:
>
> On 23/01/2023 22.56, Eric Dumazet wrote:
> > On Mon, Jan 23, 2023 at 8:25 PM Mantas Mikulėnas <grawity@gmail.com> wrote:
> >>
> >> On 2023-01-23 17:21, Eric Dumazet wrote:
> >>> On Sat, Jan 21, 2023 at 7:09 PM Mantas Mikulėnas <grawity@gmail.com> wrote:
> >>>>
> >>>> Hello,
> >>>>
> >>>> Not sure whether this has been reported, but:
> >>>>
> >>>> After upgrading from kernel 6.0.7 to 6.1.6 on Arch Linux, unprivileged
> >>>> ICMP traceroute using the `traceroute -I` tool stopped working – it very
> >>>> reliably fails with a "No route to host" at some point:
> >>>>
> >>>> myth> traceroute -I 83.171.33.188
> >>>> traceroute to 83.171.33.188 (83.171.33.188), 30 hops max, 60
> >>>> byte packets
> >>>> 1 _gateway (192.168.1.1) 0.819 ms
> >>>> send: No route to host
> >>>> [exited with 1]
> >>>>
> >>>> while it still works for root:
> >>>>
> >>>> myth> sudo traceroute -I 83.171.33.188
> >>>> traceroute to 83.171.33.188 (83.171.33.188), 30 hops max, 60
> >>>> byte packets
> >>>> 1 _gateway (192.168.1.1) 0.771 ms
> >>>> 2 * * *
> >>>> 3 10.69.21.145 (10.69.21.145) 47.194 ms
> >>>> 4 82-135-179-168.static.zebra.lt (82.135.179.168) 49.124 ms
> >>>> 5 213-190-41-3.static.telecom.lt (213.190.41.3) 44.211 ms
> >>>> 6 193.219.153.25 (193.219.153.25) 77.171 ms
> >>>> 7 83.171.33.188 (83.171.33.188) 78.198 ms
> >>>>
> >>>> According to `git bisect`, this started with:
> >>>>
> >>>> commit 0d24148bd276ead5708ef56a4725580555bb48a3
> >>>> Author: Eric Dumazet <edumazet@google.com>
> >>>> Date: Tue Oct 11 14:27:29 2022 -0700
> >>>>
> >>>> inet: ping: fix recent breakage
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> It still happens with a fresh 6.2rc build, unless I revert that commit.
> >>>>
> >>>> The /bin/traceroute is the one that calls itself "Modern traceroute for
> >>>> Linux, version 2.1.1", on Arch Linux. It seems to use socket(AF_INET,
> >>>> SOCK_DGRAM, IPPROTO_ICMP), has neither setuid nor file capabilities.
> >>>> (The problem does not occur if I run it as root.)
> >>>>
> >>>> This version of `traceroute` sends multiple probes at once (with TTLs
> >>>> 1..16); according to strace, the first approx. 8-12 probes are sent
> >>>> successfully, but eventually sendto() fails with EHOSTUNREACH. (Though
> >>>> if I run it on local tty as opposed to SSH, it fails earlier.) If I use
> >>>> -N1 to have it only send one probe at a time, the problem doesn't seem
> >>>> to occur.
> >>>
> >>>
> >>>
> >>> I was not able to reproduce the issue (downloading
> >>> https://sourceforge.net/projects/traceroute/files/latest/download)
> >>>
> >>> I suspect some kind of bug in this traceroute, when/if some ICMP error
> >>> comes back.
> >>>
> >>> Double check by
> >>>
> >>> tcpdump -i ethXXXX icmp
> >>>
> >>> While you run traceroute -I ....
> >>
> >> Hmm, no, the only ICMP errors I see in tcpdump are "Time exceeded in
> >> transit", which is expected for traceroute. Nothing else shows up.
> >>
> >> (But when I test against an address that causes *real* ICMP "Host
> >> unreachable" errors, it seems to handle those correctly and prints "!H"
> >> as usual -- that is, if it reaches that point without dying.)
> >>
> >> I was able to reproduce this on a fresh Linode 1G instance (starting
> >> with their Arch image), where it also happens immediately:
> >>
> >> # pacman -Sy archlinux-keyring
> >> # pacman -Syu
> >> # pacman -Sy traceroute strace
> >> # reboot
> >> # uname -r
> >> 6.1.7-arch1-1
> >> # useradd foo
> >> # su -c "traceroute -I 8.8.8.8" foo
> >> traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
> >> 1 10.210.1.195 (10.210.1.195) 0.209 ms
> >> send: No route to host
> >>
> >> So now I'm fairly sure it is not something caused by my own network, either.
> >>
> >> On one system, it seems to work properly about half the time, if I keep
> >> re-running the same command.
> >>
> >
> > Here, running the latest upstream tree and latest traceroute, I have no issue.
> >
> > Send us :
> >
> > 1) strace output
> > 2) icmp packet capture.
> >
> > Thanks.
>
> Attached both.
Thanks.
I think it is a bug in this traceroute version, pushing too many
sendmsg() at once and hitting socket SNDBUF limit
If the sendmsg() is blocked in sock_alloc_send_pskb, it might abort
because an incoming ICMP message sets sk->sk_err
It might have worked in the past, by pure luck.
Try to increase /proc/sys/net/core/wmem_default
If this solves the issue, I would advise sending a patch to traceroute to :
1) attempt to increase SO_SNDBUF accordingly
2) use non blocking sendmsg() api to sense how many packets can be
queued in qdisc/NIC queues
3) reduce number of parallel messages (current traceroute behavior
looks like a flood to me)
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: traceroute failure in kernel 6.1 and 6.2
2023-01-23 22:26 ` Eric Dumazet
@ 2023-01-24 5:34 ` Mantas Mikulėnas
2023-01-24 6:03 ` Eric Dumazet
0 siblings, 1 reply; 12+ messages in thread
From: Mantas Mikulėnas @ 2023-01-24 5:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
On 24/01/2023 00.26, Eric Dumazet wrote:
> On Mon, Jan 23, 2023 at 10:45 PM Mantas Mikulėnas <grawity@gmail.com> wrote:
>>
>> On 23/01/2023 22.56, Eric Dumazet wrote:
>>> On Mon, Jan 23, 2023 at 8:25 PM Mantas Mikulėnas <grawity@gmail.com> wrote:
>>>>
>>>> On 2023-01-23 17:21, Eric Dumazet wrote:
>>>>> On Sat, Jan 21, 2023 at 7:09 PM Mantas Mikulėnas <grawity@gmail.com> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Not sure whether this has been reported, but:
>>>>>>
>>>>>> After upgrading from kernel 6.0.7 to 6.1.6 on Arch Linux, unprivileged
>>>>>> ICMP traceroute using the `traceroute -I` tool stopped working – it very
>>>>>> reliably fails with a "No route to host" at some point:
>>>>>>
>>>>>> myth> traceroute -I 83.171.33.188
>>>>>> traceroute to 83.171.33.188 (83.171.33.188), 30 hops max, 60
>>>>>> byte packets
>>>>>> 1 _gateway (192.168.1.1) 0.819 ms
>>>>>> send: No route to host
>>>>>> [exited with 1]
>>>>>>
>>>>>> while it still works for root:
>>>>>>
>>>>>> myth> sudo traceroute -I 83.171.33.188
>>>>>> traceroute to 83.171.33.188 (83.171.33.188), 30 hops max, 60
>>>>>> byte packets
>>>>>> 1 _gateway (192.168.1.1) 0.771 ms
>>>>>> 2 * * *
>>>>>> 3 10.69.21.145 (10.69.21.145) 47.194 ms
>>>>>> 4 82-135-179-168.static.zebra.lt (82.135.179.168) 49.124 ms
>>>>>> 5 213-190-41-3.static.telecom.lt (213.190.41.3) 44.211 ms
>>>>>> 6 193.219.153.25 (193.219.153.25) 77.171 ms
>>>>>> 7 83.171.33.188 (83.171.33.188) 78.198 ms
>>>>>>
>>>>>> According to `git bisect`, this started with:
>>>>>>
>>>>>> commit 0d24148bd276ead5708ef56a4725580555bb48a3
>>>>>> Author: Eric Dumazet <edumazet@google.com>
>>>>>> Date: Tue Oct 11 14:27:29 2022 -0700
>>>>>>
>>>>>> inet: ping: fix recent breakage
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> It still happens with a fresh 6.2rc build, unless I revert that commit.
>>>>>>
>>>>>> The /bin/traceroute is the one that calls itself "Modern traceroute for
>>>>>> Linux, version 2.1.1", on Arch Linux. It seems to use socket(AF_INET,
>>>>>> SOCK_DGRAM, IPPROTO_ICMP), has neither setuid nor file capabilities.
>>>>>> (The problem does not occur if I run it as root.)
>>>>>>
>>>>>> This version of `traceroute` sends multiple probes at once (with TTLs
>>>>>> 1..16); according to strace, the first approx. 8-12 probes are sent
>>>>>> successfully, but eventually sendto() fails with EHOSTUNREACH. (Though
>>>>>> if I run it on local tty as opposed to SSH, it fails earlier.) If I use
>>>>>> -N1 to have it only send one probe at a time, the problem doesn't seem
>>>>>> to occur.
>>>>>
>>>>>
>>>>>
>>>>> I was not able to reproduce the issue (downloading
>>>>> https://sourceforge.net/projects/traceroute/files/latest/download)
>>>>>
>>>>> I suspect some kind of bug in this traceroute, when/if some ICMP error
>>>>> comes back.
>>>>>
>>>>> Double check by
>>>>>
>>>>> tcpdump -i ethXXXX icmp
>>>>>
>>>>> While you run traceroute -I ....
>>>>
>>>> Hmm, no, the only ICMP errors I see in tcpdump are "Time exceeded in
>>>> transit", which is expected for traceroute. Nothing else shows up.
>>>>
>>>> (But when I test against an address that causes *real* ICMP "Host
>>>> unreachable" errors, it seems to handle those correctly and prints "!H"
>>>> as usual -- that is, if it reaches that point without dying.)
>>>>
>>>> I was able to reproduce this on a fresh Linode 1G instance (starting
>>>> with their Arch image), where it also happens immediately:
>>>>
>>>> # pacman -Sy archlinux-keyring
>>>> # pacman -Syu
>>>> # pacman -Sy traceroute strace
>>>> # reboot
>>>> # uname -r
>>>> 6.1.7-arch1-1
>>>> # useradd foo
>>>> # su -c "traceroute -I 8.8.8.8" foo
>>>> traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
>>>> 1 10.210.1.195 (10.210.1.195) 0.209 ms
>>>> send: No route to host
>>>>
>>>> So now I'm fairly sure it is not something caused by my own network, either.
>>>>
>>>> On one system, it seems to work properly about half the time, if I keep
>>>> re-running the same command.
>>>>
>>>
>>> Here, running the latest upstream tree and latest traceroute, I have no issue.
>>>
>>> Send us :
>>>
>>> 1) strace output
>>> 2) icmp packet capture.
>>>
>>> Thanks.
>>
>> Attached both.
>
> Thanks.
>
> I think it is a bug in this traceroute version, pushing too many
> sendmsg() at once and hitting socket SNDBUF limit
>
> If the sendmsg() is blocked in sock_alloc_send_pskb, it might abort
> because an incoming ICMP message sets sk->sk_err
>
> It might have worked in the past, by pure luck.
>
> Try to increase /proc/sys/net/core/wmem_default
>
> If this solves the issue, I would advise sending a patch to traceroute to :
>
> 1) attempt to increase SO_SNDBUF accordingly
> 2) use non blocking sendmsg() api to sense how many packets can be
> queued in qdisc/NIC queues
> 3) reduce number of parallel messages (current traceroute behavior
> looks like a flood to me)
It doesn't solve the issue; I tried bumping it from the default of
212992 to 4096-times-that, with exactly the same results.
The amount of packets it's able to send is variable, For example, right
now, on my regular VM (which is smaller than the PC that yesterday's
trace was done on), the program very consistently fails on the *second*
sendto() call -- I don't think two packets is an unreasonable amount.
The program has -q and -N options to reduce the number of simultaneous
probes, but the only effect it has is if I reduce the packets all the
way down to just one at a time.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: traceroute failure in kernel 6.1 and 6.2
2023-01-24 5:34 ` Mantas Mikulėnas
@ 2023-01-24 6:03 ` Eric Dumazet
2023-01-24 8:57 ` Eric Dumazet
0 siblings, 1 reply; 12+ messages in thread
From: Eric Dumazet @ 2023-01-24 6:03 UTC (permalink / raw)
To: Mantas Mikulėnas; +Cc: netdev
On Tue, Jan 24, 2023 at 6:34 AM Mantas Mikulėnas <grawity@gmail.com> wrote:
>
>
>
> On 24/01/2023 00.26, Eric Dumazet wrote:
> > On Mon, Jan 23, 2023 at 10:45 PM Mantas Mikulėnas <grawity@gmail.com> wrote:
> >>
> >> On 23/01/2023 22.56, Eric Dumazet wrote:
> >>> On Mon, Jan 23, 2023 at 8:25 PM Mantas Mikulėnas <grawity@gmail.com> wrote:
> >>>>
> >>>> On 2023-01-23 17:21, Eric Dumazet wrote:
> >>>>> On Sat, Jan 21, 2023 at 7:09 PM Mantas Mikulėnas <grawity@gmail.com> wrote:
> >>>>>>
> >>>>>> Hello,
> >>>>>>
> >>>>>> Not sure whether this has been reported, but:
> >>>>>>
> >>>>>> After upgrading from kernel 6.0.7 to 6.1.6 on Arch Linux, unprivileged
> >>>>>> ICMP traceroute using the `traceroute -I` tool stopped working – it very
> >>>>>> reliably fails with a "No route to host" at some point:
> >>>>>>
> >>>>>> myth> traceroute -I 83.171.33.188
> >>>>>> traceroute to 83.171.33.188 (83.171.33.188), 30 hops max, 60
> >>>>>> byte packets
> >>>>>> 1 _gateway (192.168.1.1) 0.819 ms
> >>>>>> send: No route to host
> >>>>>> [exited with 1]
> >>>>>>
> >>>>>> while it still works for root:
> >>>>>>
> >>>>>> myth> sudo traceroute -I 83.171.33.188
> >>>>>> traceroute to 83.171.33.188 (83.171.33.188), 30 hops max, 60
> >>>>>> byte packets
> >>>>>> 1 _gateway (192.168.1.1) 0.771 ms
> >>>>>> 2 * * *
> >>>>>> 3 10.69.21.145 (10.69.21.145) 47.194 ms
> >>>>>> 4 82-135-179-168.static.zebra.lt (82.135.179.168) 49.124 ms
> >>>>>> 5 213-190-41-3.static.telecom.lt (213.190.41.3) 44.211 ms
> >>>>>> 6 193.219.153.25 (193.219.153.25) 77.171 ms
> >>>>>> 7 83.171.33.188 (83.171.33.188) 78.198 ms
> >>>>>>
> >>>>>> According to `git bisect`, this started with:
> >>>>>>
> >>>>>> commit 0d24148bd276ead5708ef56a4725580555bb48a3
> >>>>>> Author: Eric Dumazet <edumazet@google.com>
> >>>>>> Date: Tue Oct 11 14:27:29 2022 -0700
> >>>>>>
> >>>>>> inet: ping: fix recent breakage
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> It still happens with a fresh 6.2rc build, unless I revert that commit.
> >>>>>>
> >>>>>> The /bin/traceroute is the one that calls itself "Modern traceroute for
> >>>>>> Linux, version 2.1.1", on Arch Linux. It seems to use socket(AF_INET,
> >>>>>> SOCK_DGRAM, IPPROTO_ICMP), has neither setuid nor file capabilities.
> >>>>>> (The problem does not occur if I run it as root.)
> >>>>>>
> >>>>>> This version of `traceroute` sends multiple probes at once (with TTLs
> >>>>>> 1..16); according to strace, the first approx. 8-12 probes are sent
> >>>>>> successfully, but eventually sendto() fails with EHOSTUNREACH. (Though
> >>>>>> if I run it on local tty as opposed to SSH, it fails earlier.) If I use
> >>>>>> -N1 to have it only send one probe at a time, the problem doesn't seem
> >>>>>> to occur.
> >>>>>
> >>>>>
> >>>>>
> >>>>> I was not able to reproduce the issue (downloading
> >>>>> https://sourceforge.net/projects/traceroute/files/latest/download)
> >>>>>
> >>>>> I suspect some kind of bug in this traceroute, when/if some ICMP error
> >>>>> comes back.
> >>>>>
> >>>>> Double check by
> >>>>>
> >>>>> tcpdump -i ethXXXX icmp
> >>>>>
> >>>>> While you run traceroute -I ....
> >>>>
> >>>> Hmm, no, the only ICMP errors I see in tcpdump are "Time exceeded in
> >>>> transit", which is expected for traceroute. Nothing else shows up.
> >>>>
> >>>> (But when I test against an address that causes *real* ICMP "Host
> >>>> unreachable" errors, it seems to handle those correctly and prints "!H"
> >>>> as usual -- that is, if it reaches that point without dying.)
> >>>>
> >>>> I was able to reproduce this on a fresh Linode 1G instance (starting
> >>>> with their Arch image), where it also happens immediately:
> >>>>
> >>>> # pacman -Sy archlinux-keyring
> >>>> # pacman -Syu
> >>>> # pacman -Sy traceroute strace
> >>>> # reboot
> >>>> # uname -r
> >>>> 6.1.7-arch1-1
> >>>> # useradd foo
> >>>> # su -c "traceroute -I 8.8.8.8" foo
> >>>> traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
> >>>> 1 10.210.1.195 (10.210.1.195) 0.209 ms
> >>>> send: No route to host
> >>>>
> >>>> So now I'm fairly sure it is not something caused by my own network, either.
> >>>>
> >>>> On one system, it seems to work properly about half the time, if I keep
> >>>> re-running the same command.
> >>>>
> >>>
> >>> Here, running the latest upstream tree and latest traceroute, I have no issue.
> >>>
> >>> Send us :
> >>>
> >>> 1) strace output
> >>> 2) icmp packet capture.
> >>>
> >>> Thanks.
> >>
> >> Attached both.
> >
> > Thanks.
> >
> > I think it is a bug in this traceroute version, pushing too many
> > sendmsg() at once and hitting socket SNDBUF limit
> >
> > If the sendmsg() is blocked in sock_alloc_send_pskb, it might abort
> > because an incoming ICMP message sets sk->sk_err
> >
> > It might have worked in the past, by pure luck.
> >
> > Try to increase /proc/sys/net/core/wmem_default
> >
> > If this solves the issue, I would advise sending a patch to traceroute to :
> >
> > 1) attempt to increase SO_SNDBUF accordingly
> > 2) use non blocking sendmsg() api to sense how many packets can be
> > queued in qdisc/NIC queues
> > 3) reduce number of parallel messages (current traceroute behavior
> > looks like a flood to me)
>
> It doesn't solve the issue; I tried bumping it from the default of
> 212992 to 4096-times-that, with exactly the same results.
>
> The amount of packets it's able to send is variable, For example, right
> now, on my regular VM (which is smaller than the PC that yesterday's
> trace was done on), the program very consistently fails on the *second*
> sendto() call -- I don't think two packets is an unreasonable amount.
>
> The program has -q and -N options to reduce the number of simultaneous
> probes, but the only effect it has is if I reduce the packets all the
> way down to just one at a time.
Problem is : if we revert the patch, unpriv users can trivially crash a host.
Also, sent ICMP packets look just fine to me, and the patch is
changing tx path.
The reported issue seems more like rx path related to me.
Like IP_RECVERR being not handled correctly.
I think more investigations are needed. Maybe contact Pavel Begunkov
<asml.silence@gmail.com>
because the initial crash issue came with
47cf88993c91 ("net: unify alloclen calculation for paged requests")
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: traceroute failure in kernel 6.1 and 6.2
2023-01-24 6:03 ` Eric Dumazet
@ 2023-01-24 8:57 ` Eric Dumazet
2023-01-24 15:27 ` Pavel Begunkov
2023-01-26 21:43 ` Mantas Mikulėnas
0 siblings, 2 replies; 12+ messages in thread
From: Eric Dumazet @ 2023-01-24 8:57 UTC (permalink / raw)
To: Mantas Mikulėnas; +Cc: netdev
On Tue, Jan 24, 2023 at 7:03 AM Eric Dumazet <edumazet@google.com> wrote:
>
> On Tue, Jan 24, 2023 at 6:34 AM Mantas Mikulėnas <grawity@gmail.com> wrote:
> >
> >
> >
> > On 24/01/2023 00.26, Eric Dumazet wrote:
> > > On Mon, Jan 23, 2023 at 10:45 PM Mantas Mikulėnas <grawity@gmail.com> wrote:
> > >>
> > >> On 23/01/2023 22.56, Eric Dumazet wrote:
> > >>> On Mon, Jan 23, 2023 at 8:25 PM Mantas Mikulėnas <grawity@gmail.com> wrote:
> > >>>>
> > >>>> On 2023-01-23 17:21, Eric Dumazet wrote:
> > >>>>> On Sat, Jan 21, 2023 at 7:09 PM Mantas Mikulėnas <grawity@gmail.com> wrote:
> > >>>>>>
> > >>>>>> Hello,
> > >>>>>>
> > >>>>>> Not sure whether this has been reported, but:
> > >>>>>>
> > >>>>>> After upgrading from kernel 6.0.7 to 6.1.6 on Arch Linux, unprivileged
> > >>>>>> ICMP traceroute using the `traceroute -I` tool stopped working – it very
> > >>>>>> reliably fails with a "No route to host" at some point:
> > >>>>>>
> > >>>>>> myth> traceroute -I 83.171.33.188
> > >>>>>> traceroute to 83.171.33.188 (83.171.33.188), 30 hops max, 60
> > >>>>>> byte packets
> > >>>>>> 1 _gateway (192.168.1.1) 0.819 ms
> > >>>>>> send: No route to host
> > >>>>>> [exited with 1]
> > >>>>>>
> > >>>>>> while it still works for root:
> > >>>>>>
> > >>>>>> myth> sudo traceroute -I 83.171.33.188
> > >>>>>> traceroute to 83.171.33.188 (83.171.33.188), 30 hops max, 60
> > >>>>>> byte packets
> > >>>>>> 1 _gateway (192.168.1.1) 0.771 ms
> > >>>>>> 2 * * *
> > >>>>>> 3 10.69.21.145 (10.69.21.145) 47.194 ms
> > >>>>>> 4 82-135-179-168.static.zebra.lt (82.135.179.168) 49.124 ms
> > >>>>>> 5 213-190-41-3.static.telecom.lt (213.190.41.3) 44.211 ms
> > >>>>>> 6 193.219.153.25 (193.219.153.25) 77.171 ms
> > >>>>>> 7 83.171.33.188 (83.171.33.188) 78.198 ms
> > >>>>>>
> > >>>>>> According to `git bisect`, this started with:
> > >>>>>>
> > >>>>>> commit 0d24148bd276ead5708ef56a4725580555bb48a3
> > >>>>>> Author: Eric Dumazet <edumazet@google.com>
> > >>>>>> Date: Tue Oct 11 14:27:29 2022 -0700
> > >>>>>>
> > >>>>>> inet: ping: fix recent breakage
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> It still happens with a fresh 6.2rc build, unless I revert that commit.
> > >>>>>>
> > >>>>>> The /bin/traceroute is the one that calls itself "Modern traceroute for
> > >>>>>> Linux, version 2.1.1", on Arch Linux. It seems to use socket(AF_INET,
> > >>>>>> SOCK_DGRAM, IPPROTO_ICMP), has neither setuid nor file capabilities.
> > >>>>>> (The problem does not occur if I run it as root.)
> > >>>>>>
> > >>>>>> This version of `traceroute` sends multiple probes at once (with TTLs
> > >>>>>> 1..16); according to strace, the first approx. 8-12 probes are sent
> > >>>>>> successfully, but eventually sendto() fails with EHOSTUNREACH. (Though
> > >>>>>> if I run it on local tty as opposed to SSH, it fails earlier.) If I use
> > >>>>>> -N1 to have it only send one probe at a time, the problem doesn't seem
> > >>>>>> to occur.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> I was not able to reproduce the issue (downloading
> > >>>>> https://sourceforge.net/projects/traceroute/files/latest/download)
> > >>>>>
> > >>>>> I suspect some kind of bug in this traceroute, when/if some ICMP error
> > >>>>> comes back.
> > >>>>>
> > >>>>> Double check by
> > >>>>>
> > >>>>> tcpdump -i ethXXXX icmp
> > >>>>>
> > >>>>> While you run traceroute -I ....
> > >>>>
> > >>>> Hmm, no, the only ICMP errors I see in tcpdump are "Time exceeded in
> > >>>> transit", which is expected for traceroute. Nothing else shows up.
> > >>>>
> > >>>> (But when I test against an address that causes *real* ICMP "Host
> > >>>> unreachable" errors, it seems to handle those correctly and prints "!H"
> > >>>> as usual -- that is, if it reaches that point without dying.)
> > >>>>
> > >>>> I was able to reproduce this on a fresh Linode 1G instance (starting
> > >>>> with their Arch image), where it also happens immediately:
> > >>>>
> > >>>> # pacman -Sy archlinux-keyring
> > >>>> # pacman -Syu
> > >>>> # pacman -Sy traceroute strace
> > >>>> # reboot
> > >>>> # uname -r
> > >>>> 6.1.7-arch1-1
> > >>>> # useradd foo
> > >>>> # su -c "traceroute -I 8.8.8.8" foo
> > >>>> traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
> > >>>> 1 10.210.1.195 (10.210.1.195) 0.209 ms
> > >>>> send: No route to host
> > >>>>
> > >>>> So now I'm fairly sure it is not something caused by my own network, either.
> > >>>>
> > >>>> On one system, it seems to work properly about half the time, if I keep
> > >>>> re-running the same command.
> > >>>>
> > >>>
> > >>> Here, running the latest upstream tree and latest traceroute, I have no issue.
> > >>>
> > >>> Send us :
> > >>>
> > >>> 1) strace output
> > >>> 2) icmp packet capture.
> > >>>
> > >>> Thanks.
> > >>
> > >> Attached both.
> > >
> > > Thanks.
> > >
> > > I think it is a bug in this traceroute version, pushing too many
> > > sendmsg() at once and hitting socket SNDBUF limit
> > >
> > > If the sendmsg() is blocked in sock_alloc_send_pskb, it might abort
> > > because an incoming ICMP message sets sk->sk_err
> > >
> > > It might have worked in the past, by pure luck.
> > >
> > > Try to increase /proc/sys/net/core/wmem_default
> > >
> > > If this solves the issue, I would advise sending a patch to traceroute to :
> > >
> > > 1) attempt to increase SO_SNDBUF accordingly
> > > 2) use non blocking sendmsg() api to sense how many packets can be
> > > queued in qdisc/NIC queues
> > > 3) reduce number of parallel messages (current traceroute behavior
> > > looks like a flood to me)
> >
> > It doesn't solve the issue; I tried bumping it from the default of
> > 212992 to 4096-times-that, with exactly the same results.
> >
> > The amount of packets it's able to send is variable, For example, right
> > now, on my regular VM (which is smaller than the PC that yesterday's
> > trace was done on), the program very consistently fails on the *second*
> > sendto() call -- I don't think two packets is an unreasonable amount.
> >
> > The program has -q and -N options to reduce the number of simultaneous
> > probes, but the only effect it has is if I reduce the packets all the
> > way down to just one at a time.
>
> Problem is : if we revert the patch, unpriv users can trivially crash a host.
>
> Also, sent ICMP packets look just fine to me, and the patch is
> changing tx path.
>
> The reported issue seems more like rx path related to me.
> Like IP_RECVERR being not handled correctly.
>
> I think more investigations are needed. Maybe contact Pavel Begunkov
> <asml.silence@gmail.com>
> because the initial crash issue came with
> 47cf88993c91 ("net: unify alloclen calculation for paged requests")
I am reasonably confident this is a bug in this traceroute binary.
It sets
setsockopt(3, SOL_IP, IP_RECVERR, [1], 4) = 0
So a sendto() can absolutely return the error set by last received
ICMP (cf ping_err()) on the socket,
as per RFC1122 4.1.3.3
4.1.3.3 ICMP Messages
UDP MUST pass to the application layer all ICMP error
messages that it receives from the IP layer. Conceptually
at least, this may be accomplished with an upcall to the
ERROR_REPORT routine (see Section 4.2.4.1).
DISCUSSION:
Note that ICMP error messages resulting from sending a
UDP datagram are received asynchronously. A UDP-based
application that wants to receive ICMP error messages
is responsible for maintaining the state necessary to
demultiplex these messages when they arrive; for
example, the application may keep a pending receive
operation for this purpose. The application is also
responsible to avoid confusion from a delayed ICMP
error message resulting from an earlier use of the same
Fix would be
diff traceroute/traceroute.c.orig traceroute/traceroute.c
1657c1657
< if (errno == EMSGSIZE)
---
> if (errno == EMSGSIZE || errno == EHOSTUNREACH)
or to collect a pending socket error (but that would be racy), using
SO_ERROR getsockopt()
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: traceroute failure in kernel 6.1 and 6.2
2023-01-24 8:57 ` Eric Dumazet
@ 2023-01-24 15:27 ` Pavel Begunkov
2023-01-24 16:14 ` Eric Dumazet
2023-01-26 21:43 ` Mantas Mikulėnas
1 sibling, 1 reply; 12+ messages in thread
From: Pavel Begunkov @ 2023-01-24 15:27 UTC (permalink / raw)
To: Eric Dumazet, Mantas Mikulėnas; +Cc: netdev
On 1/24/23 08:57, Eric Dumazet wrote:
> On Tue, Jan 24, 2023 at 7:03 AM Eric Dumazet <edumazet@google.com> wrote:
[...]
>>> It doesn't solve the issue; I tried bumping it from the default of
>>> 212992 to 4096-times-that, with exactly the same results.
>>>
>>> The amount of packets it's able to send is variable, For example, right
>>> now, on my regular VM (which is smaller than the PC that yesterday's
>>> trace was done on), the program very consistently fails on the *second*
>>> sendto() call -- I don't think two packets is an unreasonable amount.
>>>
>>> The program has -q and -N options to reduce the number of simultaneous
>>> probes, but the only effect it has is if I reduce the packets all the
>>> way down to just one at a time.
>>
>> Problem is : if we revert the patch, unpriv users can trivially crash a host.
>>
>> Also, sent ICMP packets look just fine to me, and the patch is
>> changing tx path.
>>
>> The reported issue seems more like rx path related to me.
>> Like IP_RECVERR being not handled correctly.
>>
>> I think more investigations are needed. Maybe contact Pavel Begunkov
>> <asml.silence@gmail.com>
>> because the initial crash issue came with
>> 47cf88993c91 ("net: unify alloclen calculation for paged requests")
>
> I am reasonably confident this is a bug in this traceroute binary.
>
> It sets
> setsockopt(3, SOL_IP, IP_RECVERR, [1], 4) = 0
>
> So a sendto() can absolutely return the error set by last received
> ICMP (cf ping_err()) on the socket,
> as per RFC1122 4.1.3.3
>
> 4.1.3.3 ICMP Messages
>
> UDP MUST pass to the application layer all ICMP error
> messages that it receives from the IP layer. Conceptually
> at least, this may be accomplished with an upcall to the
> ERROR_REPORT routine (see Section 4.2.4.1).
>
> DISCUSSION:
> Note that ICMP error messages resulting from sending a
> UDP datagram are received asynchronously. A UDP-based
> application that wants to receive ICMP error messages
> is responsible for maintaining the state necessary to
> demultiplex these messages when they arrive; for
> example, the application may keep a pending receive
> operation for this purpose. The application is also
> responsible to avoid confusion from a delayed ICMP
> error message resulting from an earlier use of the same
>
>
> Fix would be
>
> diff traceroute/traceroute.c.orig traceroute/traceroute.c
> 1657c1657
> < if (errno == EMSGSIZE)
> ---
>> if (errno == EMSGSIZE || errno == EHOSTUNREACH)
>
> or to collect a pending socket error (but that would be racy), using
> SO_ERROR getsockopt()
If it doesn't help I'll take a look, perfectly reproducible for me.
--
Pavel Begunkov
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: traceroute failure in kernel 6.1 and 6.2
2023-01-24 15:27 ` Pavel Begunkov
@ 2023-01-24 16:14 ` Eric Dumazet
0 siblings, 0 replies; 12+ messages in thread
From: Eric Dumazet @ 2023-01-24 16:14 UTC (permalink / raw)
To: Pavel Begunkov; +Cc: Mantas Mikulėnas, netdev
On Tue, Jan 24, 2023 at 4:28 PM Pavel Begunkov <asml.silence@gmail.com> wrote:
>
> On 1/24/23 08:57, Eric Dumazet wrote:
> > On Tue, Jan 24, 2023 at 7:03 AM Eric Dumazet <edumazet@google.com> wrote:
> [...]
> >>> It doesn't solve the issue; I tried bumping it from the default of
> >>> 212992 to 4096-times-that, with exactly the same results.
> >>>
> >>> The amount of packets it's able to send is variable, For example, right
> >>> now, on my regular VM (which is smaller than the PC that yesterday's
> >>> trace was done on), the program very consistently fails on the *second*
> >>> sendto() call -- I don't think two packets is an unreasonable amount.
> >>>
> >>> The program has -q and -N options to reduce the number of simultaneous
> >>> probes, but the only effect it has is if I reduce the packets all the
> >>> way down to just one at a time.
> >>
> >> Problem is : if we revert the patch, unpriv users can trivially crash a host.
> >>
> >> Also, sent ICMP packets look just fine to me, and the patch is
> >> changing tx path.
> >>
> >> The reported issue seems more like rx path related to me.
> >> Like IP_RECVERR being not handled correctly.
> >>
> >> I think more investigations are needed. Maybe contact Pavel Begunkov
> >> <asml.silence@gmail.com>
> >> because the initial crash issue came with
> >> 47cf88993c91 ("net: unify alloclen calculation for paged requests")
> >
> > I am reasonably confident this is a bug in this traceroute binary.
> >
> > It sets
> > setsockopt(3, SOL_IP, IP_RECVERR, [1], 4) = 0
> >
> > So a sendto() can absolutely return the error set by last received
> > ICMP (cf ping_err()) on the socket,
> > as per RFC1122 4.1.3.3
> >
> > 4.1.3.3 ICMP Messages
> >
> > UDP MUST pass to the application layer all ICMP error
> > messages that it receives from the IP layer. Conceptually
> > at least, this may be accomplished with an upcall to the
> > ERROR_REPORT routine (see Section 4.2.4.1).
> >
> > DISCUSSION:
> > Note that ICMP error messages resulting from sending a
> > UDP datagram are received asynchronously. A UDP-based
> > application that wants to receive ICMP error messages
> > is responsible for maintaining the state necessary to
> > demultiplex these messages when they arrive; for
> > example, the application may keep a pending receive
> > operation for this purpose. The application is also
> > responsible to avoid confusion from a delayed ICMP
> > error message resulting from an earlier use of the same
> >
> >
> > Fix would be
> >
> > diff traceroute/traceroute.c.orig traceroute/traceroute.c
> > 1657c1657
> > < if (errno == EMSGSIZE)
> > ---
> >> if (errno == EMSGSIZE || errno == EHOSTUNREACH)
> >
> > or to collect a pending socket error (but that would be racy), using
> > SO_ERROR getsockopt()
>
> If it doesn't help I'll take a look, perfectly reproducible for me.
>
My fix has the following consequence:
Instead of pretending ICMP packet has no 'transhdrlen',
it now calls sock_alloc_send_skb() (instead of alloc_skb()),
and thus is able to sleep/schedule (unless application
provides MSG_DONTWAIT), and is also
sensible to a prior setting of sk->sk_err (from ping_err())
This was probably not an intended behavior of initial
ping implementation (which was ignoring sk->sk_err until a recvmsg() or poll())
__ip_append_data()
if (transhdrlen) {
skb = sock_alloc_send_skb(sk, alloclen,
(flags & MSG_DONTWAIT), &err);
} else {
skb = NULL;
if (refcount_read(&sk->sk_wmem_alloc) + wmem_alloc_delta <=
2 * sk->sk_sndbuf)
skb = alloc_skb(alloclen,
sk->sk_allocation);
if (unlikely(!skb))
err = -ENOBUFS;
}
if (!skb)
goto error;
The intent for this code is to sleep/schedule only for the first skb,
and uses alloc_skb() for the following skbs, to increase chance
of not breaking the generation of the datagram in the middle.
Downside is that ICMP now reacts like UDP, thus the application
must correctly handle the sendmsg() returning the stored sk->sk_err.
Note 1: ipv6 ping implementation forces a MSG_DONTWAIT
while calling ip6_append_data(), for no apparent reason.
Note 2:
It seems strange that both udp_err() and ping_err()
call ip_icmp_error() when a matching socket is found (and used IP_RECVERR)
_and_ also set sk->sk_err
Perhaps ip_icmp_error() should return a bool and
we should not set sk->sk_err if a proper error skb has been
queued to sk->sk_error_queue
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: traceroute failure in kernel 6.1 and 6.2
2023-01-24 8:57 ` Eric Dumazet
2023-01-24 15:27 ` Pavel Begunkov
@ 2023-01-26 21:43 ` Mantas Mikulėnas
1 sibling, 0 replies; 12+ messages in thread
From: Mantas Mikulėnas @ 2023-01-26 21:43 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
On 24/01/2023 10.57, Eric Dumazet wrote:
> On Tue, Jan 24, 2023 at 7:03 AM Eric Dumazet <edumazet@google.com> wrote:
>>
>> On Tue, Jan 24, 2023 at 6:34 AM Mantas Mikulėnas <grawity@gmail.com> wrote:
>>>
>>>
>>>
>>> On 24/01/2023 00.26, Eric Dumazet wrote:
>>>> On Mon, Jan 23, 2023 at 10:45 PM Mantas Mikulėnas <grawity@gmail.com> wrote:
>>>>>
>>>>> On 23/01/2023 22.56, Eric Dumazet wrote:
>>>>>> On Mon, Jan 23, 2023 at 8:25 PM Mantas Mikulėnas <grawity@gmail.com> wrote:
>>>>>>>
>>>>>>> On 2023-01-23 17:21, Eric Dumazet wrote:
>>>>>>>> On Sat, Jan 21, 2023 at 7:09 PM Mantas Mikulėnas <grawity@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Not sure whether this has been reported, but:
>>>>>>>>>
>>>>>>>>> After upgrading from kernel 6.0.7 to 6.1.6 on Arch Linux, unprivileged
>>>>>>>>> ICMP traceroute using the `traceroute -I` tool stopped working – it very
>>>>>>>>> reliably fails with a "No route to host" at some point:
>>>>>>>>>
>>>>>>>>> myth> traceroute -I 83.171.33.188
>>>>>>>>> traceroute to 83.171.33.188 (83.171.33.188), 30 hops max, 60
>>>>>>>>> byte packets
>>>>>>>>> 1 _gateway (192.168.1.1) 0.819 ms
>>>>>>>>> send: No route to host
>>>>>>>>> [exited with 1]
>>>>>>>>>
>>>>>>>>> while it still works for root:
>>>>>>>>>
>>>>>>>>> myth> sudo traceroute -I 83.171.33.188
>>>>>>>>> traceroute to 83.171.33.188 (83.171.33.188), 30 hops max, 60
>>>>>>>>> byte packets
>>>>>>>>> 1 _gateway (192.168.1.1) 0.771 ms
>>>>>>>>> 2 * * *
>>>>>>>>> 3 10.69.21.145 (10.69.21.145) 47.194 ms
>>>>>>>>> 4 82-135-179-168.static.zebra.lt (82.135.179.168) 49.124 ms
>>>>>>>>> 5 213-190-41-3.static.telecom.lt (213.190.41.3) 44.211 ms
>>>>>>>>> 6 193.219.153.25 (193.219.153.25) 77.171 ms
>>>>>>>>> 7 83.171.33.188 (83.171.33.188) 78.198 ms
>>>>>>>>>
>>>>>>>>> According to `git bisect`, this started with:
>>>>>>>>>
>>>>>>>>> commit 0d24148bd276ead5708ef56a4725580555bb48a3
>>>>>>>>> Author: Eric Dumazet <edumazet@google.com>
>>>>>>>>> Date: Tue Oct 11 14:27:29 2022 -0700
>>>>>>>>>
>>>>>>>>> inet: ping: fix recent breakage
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It still happens with a fresh 6.2rc build, unless I revert that commit.
>>>>>>>>>
>>>>>>>>> The /bin/traceroute is the one that calls itself "Modern traceroute for
>>>>>>>>> Linux, version 2.1.1", on Arch Linux. It seems to use socket(AF_INET,
>>>>>>>>> SOCK_DGRAM, IPPROTO_ICMP), has neither setuid nor file capabilities.
>>>>>>>>> (The problem does not occur if I run it as root.)
>>>>>>>>>
>>>>>>>>> This version of `traceroute` sends multiple probes at once (with TTLs
>>>>>>>>> 1..16); according to strace, the first approx. 8-12 probes are sent
>>>>>>>>> successfully, but eventually sendto() fails with EHOSTUNREACH. (Though
>>>>>>>>> if I run it on local tty as opposed to SSH, it fails earlier.) If I use
>>>>>>>>> -N1 to have it only send one probe at a time, the problem doesn't seem
>>>>>>>>> to occur.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I was not able to reproduce the issue (downloading
>>>>>>>> https://sourceforge.net/projects/traceroute/files/latest/download)
>>>>>>>>
>>>>>>>> I suspect some kind of bug in this traceroute, when/if some ICMP error
>>>>>>>> comes back.
>>>>>>>>
>>>>>>>> Double check by
>>>>>>>>
>>>>>>>> tcpdump -i ethXXXX icmp
>>>>>>>>
>>>>>>>> While you run traceroute -I ....
>>>>>>>
>>>>>>> Hmm, no, the only ICMP errors I see in tcpdump are "Time exceeded in
>>>>>>> transit", which is expected for traceroute. Nothing else shows up.
>>>>>>>
>>>>>>> (But when I test against an address that causes *real* ICMP "Host
>>>>>>> unreachable" errors, it seems to handle those correctly and prints "!H"
>>>>>>> as usual -- that is, if it reaches that point without dying.)
>>>>>>>
>>>>>>> I was able to reproduce this on a fresh Linode 1G instance (starting
>>>>>>> with their Arch image), where it also happens immediately:
>>>>>>>
>>>>>>> # pacman -Sy archlinux-keyring
>>>>>>> # pacman -Syu
>>>>>>> # pacman -Sy traceroute strace
>>>>>>> # reboot
>>>>>>> # uname -r
>>>>>>> 6.1.7-arch1-1
>>>>>>> # useradd foo
>>>>>>> # su -c "traceroute -I 8.8.8.8" foo
>>>>>>> traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
>>>>>>> 1 10.210.1.195 (10.210.1.195) 0.209 ms
>>>>>>> send: No route to host
>>>>>>>
>>>>>>> So now I'm fairly sure it is not something caused by my own network, either.
>>>>>>>
>>>>>>> On one system, it seems to work properly about half the time, if I keep
>>>>>>> re-running the same command.
>>>>>>>
>>>>>>
>>>>>> Here, running the latest upstream tree and latest traceroute, I have no issue.
>>>>>>
>>>>>> Send us :
>>>>>>
>>>>>> 1) strace output
>>>>>> 2) icmp packet capture.
>>>>>>
>>>>>> Thanks.
>>>>>
>>>>> Attached both.
>>>>
>>>> Thanks.
>>>>
>>>> I think it is a bug in this traceroute version, pushing too many
>>>> sendmsg() at once and hitting socket SNDBUF limit
>>>>
>>>> If the sendmsg() is blocked in sock_alloc_send_pskb, it might abort
>>>> because an incoming ICMP message sets sk->sk_err
>>>>
>>>> It might have worked in the past, by pure luck.
>>>>
>>>> Try to increase /proc/sys/net/core/wmem_default
>>>>
>>>> If this solves the issue, I would advise sending a patch to traceroute to :
>>>>
>>>> 1) attempt to increase SO_SNDBUF accordingly
>>>> 2) use non blocking sendmsg() api to sense how many packets can be
>>>> queued in qdisc/NIC queues
>>>> 3) reduce number of parallel messages (current traceroute behavior
>>>> looks like a flood to me)
>>>
>>> It doesn't solve the issue; I tried bumping it from the default of
>>> 212992 to 4096-times-that, with exactly the same results.
>>>
>>> The amount of packets it's able to send is variable, For example, right
>>> now, on my regular VM (which is smaller than the PC that yesterday's
>>> trace was done on), the program very consistently fails on the *second*
>>> sendto() call -- I don't think two packets is an unreasonable amount.
>>>
>>> The program has -q and -N options to reduce the number of simultaneous
>>> probes, but the only effect it has is if I reduce the packets all the
>>> way down to just one at a time.
>>
>> Problem is : if we revert the patch, unpriv users can trivially crash a host.
>>
>> Also, sent ICMP packets look just fine to me, and the patch is
>> changing tx path.
>>
>> The reported issue seems more like rx path related to me.
>> Like IP_RECVERR being not handled correctly.
>>
>> I think more investigations are needed. Maybe contact Pavel Begunkov
>> <asml.silence@gmail.com>
>> because the initial crash issue came with
>> 47cf88993c91 ("net: unify alloclen calculation for paged requests")
>
> I am reasonably confident this is a bug in this traceroute binary.
>
> It sets
> setsockopt(3, SOL_IP, IP_RECVERR, [1], 4) = 0
>
> So a sendto() can absolutely return the error set by last received
> ICMP (cf ping_err()) on the socket,
> as per RFC1122 4.1.3.3
>
> 4.1.3.3 ICMP Messages
>
> UDP MUST pass to the application layer all ICMP error
> messages that it receives from the IP layer. Conceptually
> at least, this may be accomplished with an upcall to the
> ERROR_REPORT routine (see Section 4.2.4.1).
>
> DISCUSSION:
> Note that ICMP error messages resulting from sending a
> UDP datagram are received asynchronously. A UDP-based
> application that wants to receive ICMP error messages
> is responsible for maintaining the state necessary to
> demultiplex these messages when they arrive; for
> example, the application may keep a pending receive
> operation for this purpose. The application is also
> responsible to avoid confusion from a delayed ICMP
> error message resulting from an earlier use of the same
>
>
> Fix would be
>
> diff traceroute/traceroute.c.orig traceroute/traceroute.c
> 1657c1657
> < if (errno == EMSGSIZE)
> ---
>> if (errno == EMSGSIZE || errno == EHOSTUNREACH)
>
> or to collect a pending socket error (but that would be racy), using
> SO_ERROR getsockopt()
Yes, this seems to solve the problem. I guess now I need to figure out
where to report it to the traceroute developers...
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2023-01-26 21:43 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-01-21 18:09 traceroute failure in kernel 6.1 and 6.2 Mantas Mikulėnas
2023-01-23 15:21 ` Eric Dumazet
2023-01-23 19:25 ` Mantas Mikulėnas
2023-01-23 20:56 ` Eric Dumazet
2023-01-23 21:45 ` Mantas Mikulėnas
2023-01-23 22:26 ` Eric Dumazet
2023-01-24 5:34 ` Mantas Mikulėnas
2023-01-24 6:03 ` Eric Dumazet
2023-01-24 8:57 ` Eric Dumazet
2023-01-24 15:27 ` Pavel Begunkov
2023-01-24 16:14 ` Eric Dumazet
2023-01-26 21:43 ` Mantas Mikulėnas
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).