From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 6673 invoked from network); 17 Feb 2022 21:39:27 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 17 Feb 2022 21:39:27 -0000 Received: (qmail 9729 invoked by uid 550); 17 Feb 2022 21:39:25 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 9693 invoked from network); 17 Feb 2022 21:39:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=L92HR7IGLBTti6EtYbq2gtUwN8OlNpsUu3lXbW0yTNM=; b=UI+c3cdw5hGhRZSFYzdijQN451A8ImrQptcmPJySTkpwGB2Uo/T49683pHJ9Jh6c7Y ImbgfBEnDBU0TOAXkvKNNiq9UqRUYQZ04yTvopgxZ7aaujjeRuB6sIUBaE2HauDIGDbD zzXu0oRWpsCQQpNGXxKRpRAb6mYU/FdSi+ymRui3wfPVvobMpg7ZreTdhH2JIOR+bWAF TNz2wEK+lDPrFWf/dfANxmX9iz1mJlC2BShxH9K/qtCHPuEN4YwsS+uUYx/oRAe99r7t HkbP0vO0bRtL04j4JE2H6TM9xxGIlyNb09zFLpQhFkMp0Jchq0dZLVAyp1dTnEaHh9OJ 4JQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=L92HR7IGLBTti6EtYbq2gtUwN8OlNpsUu3lXbW0yTNM=; b=4rRJf/jckHCmgIuuUbzSGrzav4+UkvLimRhGsKj7R4qfMuJttuDBKbCq3lqHFWGe8u dX0EVio8q4hokrBXhwUZaf75l50ow2inwgTAdg0M91xhFYRwx6YKhGFwgO+gkc9ca/or NEcqr8/UQUHdmnqkKge9MZdpEuxnHsnkO1AfnvVt5bThJk+ez7BRLTauXLAYED7kBLfW YtI+qYIHaQTAojgzvnOiBAA6aSoVZA+echSqq3WjyaC94lX4AOURCR4uyUHjFFevZJV4 n/xJ16Jto+IjsUFqISBxRrYykQKXouFjUacd0tdaMlR47NyWVfuHs0OuOmI4kb14s1XK P9cw== X-Gm-Message-State: AOAM530EUe0gRUUxUDPVgGnh8j2nrkSBkZSj9KbxR78sidCeZG1XQ9wt 0m9x39bDjrvXZybxIlV/wdfwmvGyxlHtT6ZdawqjzcVzCUM= X-Google-Smtp-Source: ABdhPJw0hYI9JLaXkfh4wXVCYbVMhLtS6U3XD5j4EebpFP7/J25ZW00Nq9YrnlX5rFav+LI9y9w81WSIvpBlXnPaAjE= X-Received: by 2002:a05:651c:12c6:b0:244:c116:3b75 with SMTP id 6-20020a05651c12c600b00244c1163b75mr3793494lje.193.1645133953071; Thu, 17 Feb 2022 13:39:13 -0800 (PST) MIME-Version: 1.0 References: <20220217132434.GP7074@brightrain.aerifal.cx> <20220217134651.GQ7074@brightrain.aerifal.cx> <20220217155351.GR7074@brightrain.aerifal.cx> <20220217160501.GS7074@brightrain.aerifal.cx> <20220217181705.GT7074@brightrain.aerifal.cx> In-Reply-To: <20220217181705.GT7074@brightrain.aerifal.cx> From: Satadru Pramanik Date: Thu, 17 Feb 2022 16:39:02 -0500 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000e17fa305d83d9807" Subject: Re: [musl] Re: musl getaddr info breakage on older kernels --000000000000e17fa305d83d9807 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm noticing one small issue with this suggested patch: In file included from ../src_musl/src/internal/syscall.h:6, from ../src_musl/src/dirent/opendir.c:6: ../src_musl/arch/i386/syscall_arch.h: In function =E2=80=98__syscall0=E2=80= =99: ../src_musl/arch/i386/syscall_arch.h:17:28: error: =E2=80=98ENOSYS=E2=80=99= undeclared (first use in this function) 17 | if (n>350) return -ENOSYS; | ^~~~~~ ../src_musl/arch/i386/syscall_arch.h:17:28: note: each undeclared identifier is reported only once for each function it appears in ../src_musl/arch/i386/syscall_arch.h: In function =E2=80=98__syscall1=E2=80= =99: ../src_musl/arch/i386/syscall_arch.h:25:28: error: =E2=80=98ENOSYS=E2=80=99= undeclared (first use in this function) 25 | if (n>350) return -ENOSYS; | ^~~~~~ ../src_musl/arch/i386/syscall_arch.h: In function =E2=80=98__syscall2=E2=80= =99: ../src_musl/arch/i386/syscall_arch.h:33:28: error: =E2=80=98ENOSYS=E2=80=99= undeclared (first use in this function) 33 | if (n>350) return -ENOSYS; Should we be adding an include or just defining this locally? Satadru On Thu, Feb 17, 2022 at 1:17 PM Rich Felker wrote: > On Thu, Feb 17, 2022 at 11:36:31AM -0500, Satadru Pramanik wrote: > > This machine is a EOL Samsung Series 5 Chromebook > > < > https://www.chromium.org/chromium-os/developer-information-for-chrome-os-= devices/samsung-series-5-chromebook/ > > > > code > > named Alex > > < > https://www.chromium.org/chromium-os/developer-information-for-chrome-os-= devices/#:~:text=3DSeries%205%20Chromebook-,Alex,-x86%2Dalex%20%26%20x86 > > > > .. > > It is the target device for our i686 builds for Chromebrew. > > > > It is running a 3.8.11 kernel, and I believe the kernel source for that > is > > here: > > > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/he= ads/chromeos-3.8 > > > > Getting a signed kernel update for an EOL kernel for an EOL machine is > > close to impossible from Google, so we're just trying to work around > these > > If these are machines you're in control of, you may be able to load a > module to patch it. If this is something you're deploying to users > stuck on that kernel who don't want to fix their systems, then of > course that's not a practical option. > > > issues in userspace to maintain some functionality for any users who ma= y > > still be using the device. > > > > The simplest workaround possible would be ideal. > > If you're shipping binaries specifically for these devices, the > simplest fix is just to emulate the failure that should happen in the > kernel in userspace, using the attached patch. DO NOT deploy this > patch in binaries meant to be used on modern systems, since they will > break when Y2038 rolls around. (Your old Chromebooks will break then > too.) > > > It is interesting though > > that the sample program works fine when built against near-stock glibc > > 2.23, no? > > No. If your kernel has a bug that makes something behave wildly wrong, > whether you do or don't see that as visible breakage with a particular > piece of software is not particularly interesting. > > I'm pretty sure, however, that you just haven't tested enough to see > any failures. glibc 2.23 is from 2016, so any functionality in it > using syscalls added after 2011 (3.8 kernel) is going to blow up > badly, thinking the syscall succeeded and returned some positive value > when actually the kernel lacks it. > > In the particular case of clock_gettime, it's just that your glibc > 2.23 has a hard Y2038 EOL and does not use/support the missing time64 > syscalls. > > > > On Thu, Feb 17, 2022 at 11:05 AM Rich Felker wrote: > > > > > On Thu, Feb 17, 2022 at 10:53:52AM -0500, Rich Felker wrote: > > > > On Thu, Feb 17, 2022 at 09:49:45AM -0500, Satadru Pramanik wrote: > > > > > Apologies for not being as familiar with gdb as I ought to be. > > > > > I used the __clock_gettime64 breakpoint and did a backtrace and > finish > > > > > repeatedly. > > > > > I couldn't figure out how to best get the timespec struct info. > > > > > > > > > > Alternately if you want to throw out a sample test program for me > to > > > build > > > > > and run, and what gdb commands to run to get the right info, happ= y > to > > > do > > > > > that too. > > > > > > > > > > gdb output is attached. > > > > > > > > If gdb reported it correctly, clock_gettime returned 403, which > should > > > > be impossible. It can only return 0 or -1. Incidentally, 403 is the > > > > syscall number for SYS_clock_gettime64, which suggests your kernel = is > > > > simply *returning the syscall number* instead of -ENOSYS for syscal= ls > > > > that don't exist on it. Is this a stock kernel (3.8 IIRC) or does i= t > > > > have any sort of weird vendor patching? Any LSMs loaded? > > > > > > > > If you'd like to run a test just to make sure we're accurately seei= ng > > > > what's happening, the attached should work. It should print 0 > followed > > > > by the current time in seconds and nanoseconds. > > > > > > It looks like you hit the bug introduced in commit > > > 554086d85e71f30abe46fc014fea31929a7c6a8a and fixed in commit > > > 8142b215501f8b291a108a202b3a053a265b03dd. It looks like, since the > > > former was a CVE fix, somebody backported it to the kernel you're > > > using, but they failed to backport the fix-for-the-fix, so you have a > > > kernel that operates dangerously incorrectly for syscall numbers it's > > > unaware of. > > > > > > This really needs to be fixed in the kernel if you can. On our side > > > (musl) we probably need to find out if such kernels are actually out > > > in the wild, and if so, whether there's any reasonable way to detect > > > the false success and treat it as failure. > > > > > > > > On Thu, Feb 17, 2022 at 8:46 AM Rich Felker > wrote: > > > > > > > > > > > On Thu, Feb 17, 2022 at 08:30:47AM -0500, Satadru Pramanik wrot= e: > > > > > > > *This is a failure:* > > > > > > > tcpdump -i any -vvv host 192.168.0.115 > > > > > > > tcpdump: listening on any, link-type LINUX_SLL (Linux cooked > v1), > > > capture > > > > > > > size 262144 bytes > > > > > > > 08:29:38.043849 IP (tos 0x0, ttl 64, id 0, offset 0, flags > [DF], > > > proto > > > > > > UDP > > > > > > > (17), length 56) > > > > > > > 192.168.0.115.60625 > office.lan.53: [udp sum ok] 0+ A? > > > google.com. > > > > > > (28) > > > > > > > 08:29:38.044237 IP (tos 0x0, ttl 64, id 11463, offset 0, flag= s > > > [DF], > > > > > > proto > > > > > > > UDP (17), length 72) > > > > > > > office.lan.53 > 192.168.0.115.60625: [bad udp cksum 0x820= a > -> > > > > > > 0x5c7d!] > > > > > > > 0 q: A? google.com. 1/0/0 google.com. [2m15s] A 142.250.80.11= 0 > > > (44) > > > > > > > 08:29:38.047754 IP (tos 0x0, ttl 64, id 0, offset 0, flags > [DF], > > > proto > > > > > > UDP > > > > > > > (17), length 56) > > > > > > > 192.168.0.115.60625 > office.lan.53: [udp sum ok] 0+ AAAA= ? > > > > > > google.com. > > > > > > > (28) > > > > > > > 08:29:38.048078 IP (tos 0x0, ttl 64, id 11464, offset 0, flag= s > > > [DF], > > > > > > proto > > > > > > > UDP (17), length 84) > > > > > > > office.lan.53 > 192.168.0.115.60625: [bad udp cksum 0x821= 6 > -> > > > > > > 0xb42f!] > > > > > > > 0 q: AAAA? google.com. 1/0/0 google.com. [4m26s] AAAA > > > > > > > 2607:f8b0:4006:80d::200e (56) > > > > > > > 08:29:38.048955 IP (tos 0xc0, ttl 64, id 59728, offset 0, fla= gs > > > [none], > > > > > > > proto ICMP (1), length 112) > > > > > > > 192.168.0.115 > office.lan: ICMP 192.168.0.115 udp port > 60625 > > > > > > > unreachable, length 92 > > > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > > > > > > > OK, this shows that the client has requested both answers and t= he > > > > > > nameserver replied almost immediately (about 0.5ms later), but > when > > > > > > the second reply arrives (to the AAAA), the client has already > closed > > > > > > the listening port, despite only a few ms having passed. The > only way > > > > > > I see this could happen is by "timing out". This suggests that > > > > > > something is wrong with telling time. > > > > > > > > > > > > Can you either put a breakpoint in __clock_gettime64 (this is t= he > > > name > > > > > > you have to use for a breakpoint -- sorry I messed it up last > time) > > > > > > and then see what it returns when you "finish" it and what's in > the > > > > > > timespec struct after that? Or just write a test program to cal= l > > > > > > clock_gettime(CLOCK_REALTIME, &ts) (note: you do NOT need or > want to > > > > > > use the time64 symbol name here) and print the results (return > value > > > > > > and contents of the timespec struct). > > > > > > > > > > > > > > > > > > > > > > > > > IP (tos 0x0, ttl 64, id 11464, offset 0, flags [DF], > proto > > > UDP > > > > > > > (17), length 84) > > > > > > > office.lan.53 > 192.168.0.115.60625: [udp sum ok] 0 q: > AAAA? > > > > > > google.com. > > > > > > > 1/0/0 google.com. [4m26s] AAAA 2607:f8b0:4006:80d::200e (56) > > > > > > > 08:29:39.476101 IP (tos 0x0, ttl 64, id 12690, offset 0, flag= s > > > [DF], > > > > > > proto > > > > > > > TCP (6), length 52) > > > > > > > 192.168.0.115.51204 > lga34s35-in-f3.1e100.net.80: Flags > [.], > > > cksum > > > > > > > 0xa666 (correct), seq 1466707759, ack 3358943837, win 115, > options > > > > > > > [nop,nop,TS val 198422160 ecr 2351261566], length 0 > > > > > > > 08:29:39.478914 IP (tos 0x80, ttl 122, id 6227, offset 0, fla= gs > > > [none], > > > > > > > proto TCP (6), length 52) > > > > > > > lga34s35-in-f3.1e100.net.80 > 192.168.0.115.51204: Flags > [.], > > > cksum > > > > > > > 0xa5b7 (correct), seq 1, ack 1, win 282, options [nop,nop,TS > val > > > > > > 2351306585 > > > > > > > ecr 198377148], length 0 > > > > > > > ^C > > > > > > > 7 packets captured > > > > > > > 7 packets received by filter > > > > > > > 0 packets dropped by kernel > > > > > > > > > > > > > > > > > > > > > #include > > > > #include > > > > int main() > > > > { > > > > struct timespec ts; > > > > printf("%d", clock_gettime(CLOCK_REALTIME, &ts)); > > > > printf(" %lld %.9ld\n", (long long)ts.tv_sec, ts.tv_nsec); > > > > } > > > > > > > --000000000000e17fa305d83d9807 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm noticing one small issue with this suggested patch= :

In file included from ../src_musl/src/internal/syscall= .h:6,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0from= ../src_musl/src/dirent/opendir.c:6:
../src_musl/arch/i386/syscall_arch.= h: In function =E2=80=98__syscall0=E2=80=99:
../src_musl/arch/i386/sysca= ll_arch.h:17:28: error: =E2=80=98ENOSYS=E2=80=99 undeclared (first use in t= his function)
=C2=A0 =C2=A017 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (n>350= ) return -ENOSYS;
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^~~~~~../src_musl/arch/i386/syscall_arch.h:17:28: note: each undeclared identifi= er is reported only once for each function it appears in
../src_musl/arc= h/i386/syscall_arch.h: In function =E2=80=98__syscall1=E2=80=99:
../src_= musl/arch/i386/syscall_arch.h:25:28: error: =E2=80=98ENOSYS=E2=80=99 undecl= ared (first use in this function)
=C2=A0 =C2=A025 | =C2=A0 =C2=A0 =C2=A0= =C2=A0 if (n>350) return -ENOSYS;
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0^~~~~~
../src_musl/arch/i386/syscall_arch.h: In function = =E2=80=98__syscall2=E2=80=99:
../src_musl/arch/i386/syscall_arch.h:33:28= : error: =E2=80=98ENOSYS=E2=80=99 undeclared (first use in this function)=C2=A0 =C2=A033 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (n>350) return -ENOSY= S;

Should we be adding an include or just defi= ning this locally?

Satadru

On Thu, Feb 17, 20= 22 at 1:17 PM Rich Felker <dalias@a= erifal.cx> wrote:
On Thu, Feb 17, 2022 at 11:36:31AM -0500, Satadru Pramanik wrote= :
>=C2=A0 This machine is a EOL Samsung Series 5 Chromebook
> <https://www.chromium.org/chromium-os/developer-informatio= n-for-chrome-os-devices/samsung-series-5-chromebook/>
> code
> named Alex
> <https://www.chromium.= org/chromium-os/developer-information-for-chrome-os-devices/#:~:text=3DSeri= es%205%20Chromebook-,Alex,-x86%2Dalex%20%26%20x86>
> ..
> It is the target device for our i686 builds for Chromebrew.
>
> It is running a 3.8.11 kernel, and I believe the kernel source for tha= t is
> here:
> https:= //chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/chro= meos-3.8
>
> Getting a signed kernel update for an EOL kernel for an EOL machine is=
> close to impossible from Google, so we're just trying to work arou= nd these

If these are machines you're in control of, you may be able to load a module to patch it. If this is something you're deploying to users
stuck on that kernel who don't want to fix their systems, then of
course that's not a practical option.

> issues in userspace to maintain some functionality for any users who m= ay
> still be using the device.
>
> The simplest workaround possible would be ideal.

If you're shipping binaries specifically for these devices, the
simplest fix is just to emulate the failure that should happen in the
kernel in userspace, using the attached patch. DO NOT deploy this
patch in binaries meant to be used on modern systems, since they will
break when Y2038 rolls around. (Your old Chromebooks will break then
too.)

> It is interesting though
> that the sample program works fine when built against near-stock glibc=
> 2.23, no?

No. If your kernel has a bug that makes something behave wildly wrong,
whether you do or don't see that as visible breakage with a particular<= br> piece of software is not particularly interesting.

I'm pretty sure, however, that you just haven't tested enough to se= e
any failures. glibc 2.23 is from 2016, so any functionality in it
using syscalls added after 2011 (3.8 kernel) is going to blow up
badly, thinking the syscall succeeded and returned some positive value
when actually the kernel lacks it.

In the particular case of clock_gettime, it's just that your glibc
2.23 has a hard Y2038 EOL and does not use/support the missing time64
syscalls.


> On Thu, Feb 17, 2022 at 11:05 AM Rich Felker <dalias@aerifal.cx> wrote:
>
> > On Thu, Feb 17, 2022 at 10:53:52AM -0500, Rich Felker wrote:
> > > On Thu, Feb 17, 2022 at 09:49:45AM -0500, Satadru Pramanik w= rote:
> > > > Apologies for not being as familiar with gdb as I ought= to be.
> > > > I used the __clock_gettime64 breakpoint and did a backt= race and finish
> > > > repeatedly.
> > > > I couldn't figure out how to best get the timespec = struct info.
> > > >
> > > > Alternately if you want to throw out a sample test prog= ram for me to
> > build
> > > > and run, and what gdb commands to run to get the right = info, happy to
> > do
> > > > that too.
> > > >
> > > > gdb output is attached.
> > >
> > > If gdb reported it correctly, clock_gettime returned 403, wh= ich should
> > > be impossible. It can only return 0 or -1. Incidentally, 403= is the
> > > syscall number for SYS_clock_gettime64, which suggests your = kernel is
> > > simply *returning the syscall number* instead of -ENOSYS for= syscalls
> > > that don't exist on it. Is this a stock kernel (3.8 IIRC= ) or does it
> > > have any sort of weird vendor patching? Any LSMs loaded?
> > >
> > > If you'd like to run a test just to make sure we're = accurately seeing
> > > what's happening, the attached should work. It should pr= int 0 followed
> > > by the current time in seconds and nanoseconds.
> >
> > It looks like you hit the bug introduced in commit
> > 554086d85e71f30abe46fc014fea31929a7c6a8a and fixed in commit
> > 8142b215501f8b291a108a202b3a053a265b03dd. It looks like, since th= e
> > former was a CVE fix, somebody backported it to the kernel you= 9;re
> > using, but they failed to backport the fix-for-the-fix, so you ha= ve a
> > kernel that operates dangerously incorrectly for syscall numbers = it's
> > unaware of.
> >
> > This really needs to be fixed in the kernel if you can. On our si= de
> > (musl) we probably need to find out if such kernels are actually = out
> > in the wild, and if so, whether there's any reasonable way to= detect
> > the false success and treat it as failure.
> >
> > > > On Thu, Feb 17, 2022 at 8:46 AM Rich Felker <dalias@aerifal.cx> w= rote:
> > > >
> > > > > On Thu, Feb 17, 2022 at 08:30:47AM -0500, Satadru = Pramanik wrote:
> > > > > > *This is a failure:*
> > > > > > tcpdump -i any -vvv host 192.168.0.115
> > > > > > tcpdump: listening on any, link-type LINUX_SL= L (Linux cooked v1),
> > capture
> > > > > > size 262144 bytes
> > > > > > 08:29:38.043849 IP (tos 0x0, ttl 64, id 0, of= fset 0, flags [DF],
> > proto
> > > > > UDP
> > > > > > (17), length 56)
> > > > > >=C2=A0 =C2=A0 =C2=A0192.168.0.115.60625 > o= ffice.lan.53: [udp sum ok] 0+ A?
> > google.com.
> > > > > (28)
> > > > > > 08:29:38.044237 IP (tos 0x0, ttl 64, id 11463= , offset 0, flags
> > [DF],
> > > > > proto
> > > > > > UDP (17), length 72)
> > > > > >=C2=A0 =C2=A0 =C2=A0office.lan.53 > 192.168= .0.115.60625: [bad udp cksum 0x820a ->
> > > > > 0x5c7d!]
> > > > > > 0 q: A? google.com. 1/0/0 google.com. [2m15s] A 142.2= 50.80.110
> > (44)
> > > > > > 08:29:38.047754 IP (tos 0x0, ttl 64, id 0, of= fset 0, flags [DF],
> > proto
> > > > > UDP
> > > > > > (17), length 56)
> > > > > >=C2=A0 =C2=A0 =C2=A0192.168.0.115.60625 > o= ffice.lan.53: [udp sum ok] 0+ AAAA?
> > > > > google.com.
> > > > > > (28)
> > > > > > 08:29:38.048078 IP (tos 0x0, ttl 64, id 11464= , offset 0, flags
> > [DF],
> > > > > proto
> > > > > > UDP (17), length 84)
> > > > > >=C2=A0 =C2=A0 =C2=A0office.lan.53 > 192.168= .0.115.60625: [bad udp cksum 0x8216 ->
> > > > > 0xb42f!]
> > > > > > 0 q: AAAA? google.com. 1/0/0 google.com. [4m26s] AAA= A
> > > > > > 2607:f8b0:4006:80d::200e (56)
> > > > > > 08:29:38.048955 IP (tos 0xc0, ttl 64, id 5972= 8, offset 0, flags
> > [none],
> > > > > > proto ICMP (1), length 112)
> > > > > >=C2=A0 =C2=A0 =C2=A0192.168.0.115 > office.= lan: ICMP 192.168.0.115 udp port 60625
> > > > > > unreachable, length 92
> > > > >=C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > >
> > > > > OK, this shows that the client has requested both = answers and the
> > > > > nameserver replied almost immediately (about 0.5ms= later), but when
> > > > > the second reply arrives (to the AAAA), the client= has already closed
> > > > > the listening port, despite only a few ms having p= assed. The only way
> > > > > I see this could happen is by "timing out&quo= t;. This suggests that
> > > > > something is wrong with telling time.
> > > > >
> > > > > Can you either put a breakpoint in __clock_gettime= 64 (this is the
> > name
> > > > > you have to use for a breakpoint -- sorry I messed= it up last time)
> > > > > and then see what it returns when you "finish= " it and what's in the
> > > > > timespec struct after that? Or just write a test p= rogram to call
> > > > > clock_gettime(CLOCK_REALTIME, &ts) (note: you = do NOT need or want to
> > > > > use the time64 symbol name here) and print the res= ults (return value
> > > > > and contents of the timespec struct).
> > > > >
> > > > >
> > > > >
> > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IP (tos 0x0,= ttl 64, id 11464, offset 0, flags [DF], proto
> > UDP
> > > > > > (17), length 84)
> > > > > >=C2=A0 =C2=A0 =C2=A0office.lan.53 > 192.168= .0.115.60625: [udp sum ok] 0 q: AAAA?
> > > > > google.com.
> > > > > > 1/0/0 google.com. [4m26s] AAAA 2607:f8b0:4006:80d= ::200e (56)
> > > > > > 08:29:39.476101 IP (tos 0x0, ttl 64, id 12690= , offset 0, flags
> > [DF],
> > > > > proto
> > > > > > TCP (6), length 52)
> > > > > >=C2=A0 =C2=A0 =C2=A0192.168.0.115.51204 > l= ga34s35-in-f3.1e100.net.80: Flags [.],
> > cksum
> > > > > > 0xa666 (correct), seq 1466707759, ack 3358943= 837, win 115, options
> > > > > > [nop,nop,TS val 198422160 ecr 2351261566], le= ngth 0
> > > > > > 08:29:39.478914 IP (tos 0x80, ttl 122, id 622= 7, offset 0, flags
> > [none],
> > > > > > proto TCP (6), length 52)
> > > > > >=C2=A0 =C2=A0 =C2=A0lga34s35-in-f3.1e100.net.8= 0 > 192.168.0.115.51204: Flags [.],
> > cksum
> > > > > > 0xa5b7 (correct), seq 1, ack 1, win 282, opti= ons [nop,nop,TS val
> > > > > 2351306585
> > > > > > ecr 198377148], length 0
> > > > > > ^C
> > > > > > 7 packets captured
> > > > > > 7 packets received by filter
> > > > > > 0 packets dropped by kernel
> > > > >
> > >
> > >
> >
> > > #include <time.h>
> > > #include <stdio.h>
> > > int main()
> > > {
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0struct timespec ts;
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0printf("%d", clock_getti= me(CLOCK_REALTIME, &ts));
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0printf(" %lld %.9ld\n", = (long long)ts.tv_sec, ts.tv_nsec);
> > > }
> >
> >
--000000000000e17fa305d83d9807--