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 670 invoked from network); 17 Feb 2022 16:17:42 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 17 Feb 2022 16:17:42 -0000 Received: (qmail 9644 invoked by uid 550); 17 Feb 2022 16:17:40 -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 9611 invoked from network); 17 Feb 2022 16:17:39 -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=T3P0Ew+cnGBOlZBqRDzTrdm9Uaj+eBIUFZB4OQ8jfAc=; b=pHkgknfzVs3/QPo9pQjFnYo63OWdpKIbW86BijAdIAmKytWT2j5za/Ig/uhb5rop7u 0aJ2p01A8kTpM+QL1qbgQfhNRTXX8WG5mG4uK72R04nd62OnPAG7kzi8AQAVc5LrBow2 uQNvrqMVpZ7WcJLsrhRlE/WjLoTs0/mNgAXyuTgQu9rnqAKWjY+IYBZQVtbL1GgbyW7v fLjZN1OIzRwykFFUAgdwy94z9kQD4KY0GtxxUf1VpLmtCRnSunHjQQuSAT62oGdZOwMC MPFAmlWgOX4wjZsHUh7kEYTnllCclMz8YrPwYXGJroNCGXNiCy9/UT3mpUXQkYPDuRZw PKNA== 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=T3P0Ew+cnGBOlZBqRDzTrdm9Uaj+eBIUFZB4OQ8jfAc=; b=SQu1owqEz10oqPRImDJHdyDLDZlzMAozYOsDsCP9qEJpDoIT5q/UMjvLOwBj8iqq2x VuXFTT0N1ggI94iO/UTD/ME1+DuDMRXQd6GijLkZc+igqzTA6fRDOyNZUOyetOybmytv 0cvr0lDAzZZyxf/j6CBKzzDAameYO3uafM1JJ7ZE27+1WDwKeHWJ4foSkf/h2GbAYRaQ 4LHq748DCAvj/fxNEasBVc83ApnahrSHJsVbhUqeeNlmoI407zH+Cn/tHI2vAq0WR0N8 ZFf9Ny2LhNk9bYPS3oor/aqPSC3bsCfm7LiUXWEj//ke3GiSCm6AxDRaByrAbT+kjO0v 8w9Q== X-Gm-Message-State: AOAM532fTV/qhptyYjrd7PNfv5npCoq4Ylb65q+K7y4hFbKrhfI3SACv 2mlv678h4X0nLQT6eCwyNf17fDRX9zz0fxNZI4NnfIDP X-Google-Smtp-Source: ABdhPJz/O18VmS5tEm+dbmlXJAiesviKdpWqNgKHzWTWIZ7s1cjr2gyoTiTLiahp2nH1p574ZnZrhQ89RClWXOrPgLo= X-Received: by 2002:ac2:5234:0:b0:436:e6a8:edbb with SMTP id i20-20020ac25234000000b00436e6a8edbbmr2386780lfl.406.1645114647611; Thu, 17 Feb 2022 08:17:27 -0800 (PST) MIME-Version: 1.0 References: <20220216213335.GO7074@brightrain.aerifal.cx> <20220217132434.GP7074@brightrain.aerifal.cx> <20220217134651.GQ7074@brightrain.aerifal.cx> <20220217155351.GR7074@brightrain.aerifal.cx> In-Reply-To: <20220217155351.GR7074@brightrain.aerifal.cx> From: Satadru Pramanik Date: Thu, 17 Feb 2022 11:17:16 -0500 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="0000000000002f8c1205d8391a77" Subject: Re: [musl] Re: musl getaddr info breakage on older kernels --0000000000002f8c1205d8391a77 Content-Type: text/plain; charset="UTF-8" I get an output of "403 4 000000000" when built against musl. When built against glibc I get "0 1645114577 573811224" On Thu, Feb 17, 2022 at 10:53 AM 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, happy 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 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 print 0 followed > by the current time in seconds and nanoseconds. > > > > > On Thu, Feb 17, 2022 at 8:46 AM Rich Felker wrote: > > > > > 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_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, flags [DF], > > > proto > > > > UDP (17), length 72) > > > > office.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.250.80.110 (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, flags [DF], > > > proto > > > > UDP (17), length 84) > > > > office.lan.53 > 192.168.0.115.60625: [bad udp cksum 0x8216 -> > > > 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, flags > [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 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 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 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 program to call > > > 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, flags [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, flags > [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 > > > > > > --0000000000002f8c1205d8391a77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I get an output of "403 4 000000000" when built = against musl.
When built against glibc I get "0 1645114577 5738112= 24"

On Thu, Feb 17, 2022 at 10:53 AM Rich Felker <dalias@aerifal.cx> wrote:
On Thu, Feb 17, 2022 at 09:49:4= 5AM -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 b= uild
> 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, 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 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 seei= ng
what's happening, the attached should work. It should print 0 followed<= br> by the current time in seconds and nanoseconds.



> On Thu, Feb 17, 2022 at 8:46 AM Rich Felker <dalias@aerifal.cx> wrote:
>
> > 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_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)
> > >=C2=A0 =C2=A0 =C2=A0192.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, fla= gs [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.250.80.110 (44)<= br> > > > 08:29:38.047754 IP (tos 0x0, ttl 64, id 0, offset 0, flags [= DF], proto
> > UDP
> > > (17), length 56)
> > >=C2=A0 =C2=A0 =C2=A0192.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, fla= gs [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] AAAA
> > > 2607:f8b0:4006:80d::200e (56)
> > > 08:29:38.048955 IP (tos 0xc0, ttl 64, id 59728, offset 0, fl= ags [none],
> > > proto ICMP (1), length 112)
> > >=C2=A0 =C2=A0 =C2=A0192.168.0.115 > office.lan: ICMP 192.1= 68.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 wh= en
> > the second reply arrives (to the AAAA), the client has already cl= osed
> > the listening port, despite only a few ms having passed. The only= way
> > I see this could happen is by "timing out". This sugges= ts that
> > something is wrong with telling time.
> >
> > Can you either put a breakpoint in __clock_gettime64 (this is the= name
> > you have to use for a breakpoint -- sorry I messed it up last tim= e)
> > and then see what it returns when you "finish" it and w= hat's in the
> > timespec struct after that? Or just write a test program to call<= br> > > clock_gettime(CLOCK_REALTIME, &ts) (note: you do NOT need or = want to
> > use the time64 symbol name here) and print the results (return va= lue
> > and contents of the timespec struct).
> >
> >
> >
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IP (tos 0x0, ttl 64, id 114= 64, 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, fla= gs [DF],
> > proto
> > > TCP (6), length 52)
> > >=C2=A0 =C2=A0 =C2=A0192.168.0.115.51204 > lga34s35-in-f3.1= e100.net.80: Flags [.], cksum
> > > 0xa666 (correct), seq 1466707759, ack 3358943837, win 115, o= ptions
> > > [nop,nop,TS val 198422160 ecr 2351261566], length 0
> > > 08:29:39.478914 IP (tos 0x80, ttl 122, id 6227, offset 0, fl= ags [none],
> > > proto TCP (6), length 52)
> > >=C2=A0 =C2=A0 =C2=A0lga34s35-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
> >


--0000000000002f8c1205d8391a77--