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 22504 invoked from network); 17 Feb 2022 14:50:11 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 17 Feb 2022 14:50:11 -0000 Received: (qmail 22267 invoked by uid 550); 17 Feb 2022 14:50:09 -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 22231 invoked from network); 17 Feb 2022 14:50:08 -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=anD6GcPMvStrqYRenV0KQXNm/7/lPc1+ZeoG/c/HyiA=; b=WcPJ/43rYb5uNq9iSKZc/yMXMzjnYL7uXZObZCVBQYJK7qzoSquYcFgbehioYOW8Op doH4U58rGe4W1y4YW2J6hLcKY+eX8/BlV/Illn2L+b8tUYHW5SaaY3BjeRhx2tm1zE6V KjDJOqmyBKYMc5zPCIdX/0wWrCLhxk7H9jyM8WIKGBc7Xx3uJPJ2dZAJkfbHDOs85Vsx euAwhRYkixuDFoYsW/0sUUG6ddw84JyjROsYJ/+0ukps+S6m/ybKwwqjE03tbfGXGNgo XyZL0b1GSZ0t+c7ryf57BZazCJb1bxANkpMo1XlYlTWZim1gtOMu/8SqwmFE698sOs58 Jlmw== 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=anD6GcPMvStrqYRenV0KQXNm/7/lPc1+ZeoG/c/HyiA=; b=QKh5UiTaaFz/S1R6/QsuzZCIeAqcwPSt4PuTwwzryx9gfCV+XxJ1hAquy6XSIUFW+E SczkPHnorB9rcyEY10TdMrpuwtkRPzcR3QaCGFYxXhdBeYC4kd90NOv5uaMDoSiNTnMx npbRQ0i27B+EKyPz2XIKS4Z3EDOw2V8mUQXEp7uWcUNBSQKZFvbmt0kPb7Dug0N536gj Dr27ruGRwk3KBmPXssawSgk+Hmt2GerPVvzePeKpcFi6AYUhULjvInWqWU6ndSaGvQ9c NdnCyL2am3WNwO1y6QgW81OBB0PY0OIMb+tGKDkS04hLQPJcwOt+HaxmxoPehbW3XULD bPMg== X-Gm-Message-State: AOAM532iE9fwWhiGOM4JE3LjQtVRTbDsWdDEUVObdG4iFh3fCAeKdtxp Tfo++fSh2DA//W5zoXZHIXl+QAJiZqUOFw8dvZNBT2Z5 X-Google-Smtp-Source: ABdhPJx/j6dQcEhEJ/kZr8CxbfsA39tsF2loXfLWdB0sdNqNJPRHUpnn2ujIzakv++Q48DawTTwFTs+8OZg5m8ntBB4= X-Received: by 2002:a05:6512:3455:b0:443:5dc0:a32d with SMTP id j21-20020a056512345500b004435dc0a32dmr2265376lfr.38.1645109396573; Thu, 17 Feb 2022 06:49:56 -0800 (PST) MIME-Version: 1.0 References: <20220216014153.GM7074@brightrain.aerifal.cx> <20220216213335.GO7074@brightrain.aerifal.cx> <20220217132434.GP7074@brightrain.aerifal.cx> <20220217134651.GQ7074@brightrain.aerifal.cx> In-Reply-To: <20220217134651.GQ7074@brightrain.aerifal.cx> From: Satadru Pramanik Date: Thu, 17 Feb 2022 09:49:45 -0500 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: multipart/mixed; boundary="0000000000003333a105d837e183" Subject: Re: [musl] Re: musl getaddr info breakage on older kernels --0000000000003333a105d837e183 Content-Type: multipart/alternative; boundary="0000000000003333a005d837e181" --0000000000003333a005d837e181 Content-Type: text/plain; charset="UTF-8" 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. 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 > --0000000000003333a005d837e181 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apologies for not being as familiar with gdb as I ought to= be.
I used the __clock_gettime64 breakpoint and did a backtrace and fi= nish repeatedly.
I couldn't figure out how to best get the ti= mespec struct info.

Alternately if you want to thr= ow out a sample test program for me to build and run, and what gdb commands= to run to get the right info,=C2=A0happy to do that too.

gdb output is attached.


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 Praman= ik 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), capt= ure
> 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, flags [DF], p= roto
> UDP (17), length 72)
>=C2=A0 =C2=A0 =C2=A0office.lan.53 > 192.168.0.115.60625: [bad udp ck= sum 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)
>=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, flags [DF], p= roto
> UDP (17), length 84)
>=C2=A0 =C2=A0 =C2=A0office.lan.53 > 192.168.0.115.60625: [bad udp ck= sum 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)
>=C2=A0 =C2=A0 =C2=A0192.168.0.115 > office.lan: ICMP 192.168.0.115 u= dp port 60625
> unreachable, length 92
=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 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).



>=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], p= roto
> TCP (6), length 52)
>=C2=A0 =C2=A0 =C2=A0192.168.0.115.51204 > lga34s35-in-f3.1e100.net.8= 0: 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)
>=C2=A0 =C2=A0 =C2=A0lga34s35-in-f3.1e100.net.80 > 192.168.0.115.5120= 4: Flags [.], cksum
> 0xa5b7 (correct), seq 1, ack 1, win 282, options [nop,nop,TS val 23513= 06585
> ecr 198377148], length 0
> ^C
> 7 packets captured
> 7 packets received by filter
> 0 packets dropped by kernel
--0000000000003333a005d837e181-- --0000000000003333a105d837e183 Content-Type: application/gzip; name="gdb.out.txt.gz" Content-Disposition: attachment; filename="gdb.out.txt.gz" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kzr3mnfr0 H4sICIxfDmIAA2dkYi5vdXQudHh0AO2cW2/bNhTHn6NPceAMnZy5tu620xpDN/ShQNcBxbqXohAo ibKFyJRDUrlsX36Hkp3IqdvGqaxamAwosWiGPBeen/gXFJMoAnG7DLIUJAlSCjHPlhAn+K43ygUf pVlI0pFYEE5Hy1ykozQJ1BEORdbT3lMSJWy+HkKUfz0sOvpzKkkU8YTFmS+pkMPhUPuNU3KxyhIm wQQiwbhxJ4E3Pi9nHA5Hgod+MQ2+GclkSUchWnChBlNnw3AAacIoeOZQuyac4eTn8IEVpssMh2ER dgjkAieK/CiAJZHhQpmIdlCeZPxnAeWnqh8n/HawOY9okM/nqu91kqbAMgkBBXJFklSNP9S2zB+A 72/ZBnqYXswMHE7MjJtxHMcRCSd95eZjHDv3TM0zT07U4PpZ3NeLz5PIlwMQkuehBNVRrGgIZ32Y aacGHMCEUxMwK+NxTBzPiTBqOAenwl9eXOaU34KerdQEESNLup6D0siB3jzL5hikMFv2BhCmRIgZ xkjerqj6HRFJsLtRvkspU4Mwes152aoBvoI83pgdTgzo4UDYpDpbE2OnF4zK64xfjCoWohu2q51a GzcsEsfKDWWwr9anHzEB+v1c1HPQgJCwjG1aXMd44NDX3S2sj8kySW+VX2HG7ga3nfCrlqdZdpGv fDU+Wm66tnZqb0y3bcf8zHRfUMLDBej3830jF1/37EHkVTT2MNgyp9qpoxZipb3m6N47Gqdkjiu7 X9j8aBtty9JO3U1QDdvyVFAreAJ9kQn5ZQME5VflMkWS3PUL6GQAuPDuz51vGlaZFA2bYrl5yi5X vcZxqOxaEvyhEz4PZ9YA8PfVZoIwcIrM7KYr5sLQ3ucMKYHwojeJLGl8GEw0AoXaeOBptodkjWCG Lg/llc8EUvSXysnIc13b+/AWnmE6cML4hfY3SXOKCZY5ZxRJKOAnEwdwDHuN3tZh0avQvX1YtNqG RbsFWHSOFItuM1g8VAkXDh+GZM2Vbz2V62p4nOAriUG/RJfFR3b5CWYzeG72d0HWQshak4KxrUSV W6FsW1BltQBV9pGiymkCVXVWQgmnRkq/U8xPu65Yk/0vLNF0UpdkDpywRcDtJHMnmf8XkvmLVDgE EOrSzHatmvkxIXgomr83DhXR3DowdqK5E83HJpqb39zcqeYG6vcHqWbnM9XcLlZ1qrlTzYdSzbVU wjGr5sDYvXYbVM37mlBVzUG5AMqRv811QVmk0l6VrM6UjCvSW3XxeQg6U9eABBcrrqnN282NWNfB NoXWuxYPWwgT15RXeoXr3JPtrthMRPIPnbmmtV/Cq06YZlW9WsF03B5me9WtUFuY7baA2d6RMnt8 HMJ7X9TsDRZPs1D6ltsr0HMmkrnaZqUZm/dL+auk8BmYhmHs2ou5Fcn7hMkraGwz1az2Uq27ndjd TqyXak/AQBMIOFD1exoeJydxxkF/AdJ6Lg14WWwrs1yqhlkRD73fh393AdRDgJqeouv9Lr69LNy+ g9g2FnZ3ELs7iIdQ5fXVc+lmk3TbX6CbP16g72lC3QI9dEhr8d0J9E6gdwL98QJ9T9Q0LtDHtQn0 NlOtE+idQO8E+ncL9IMi4EgF+gQBaj/Q521GYafPO33e6fNtfV5bPTevz5ur5brKGI/yWZ/tcGO0 MaKrdVQxPqt11HCZYaSyGM4I+lPO3keEGzsfDpoiro2tZ4PaRrnu2aDu2aDDPBtURyU09WwQVsJ2 FTS7xPZZXo6GR4m0kMmX6q/Xeh1P4dfi5zm8fvXGf/fnu1d/vN79/9YGguu5XSFXE44/INfTvL8n 1pEVl9VccdWTrL2K62nJaiBReyTJ0qbrzQBTzaK4rG+qp2zaXS3mw2o5pqW3uYg3s/Tq9bxw9XsS WqPblnEC6xfHfFc6qRGvPpqfBvDuw9u3A3im/MCd4jO0PE9lf/eisaqLpjYre3HCErHoFd+itKRE fVFTnKdqXLmgkOWS8iWmA/OmylD7PWMyYTn2GmqVEc/hL34LZI6maB/frL/BCUzQVzwLqRBguqY7 7RdLAB26TuQCr68RBcP8pF3midT+A+tutCzhSgAA --0000000000003333a105d837e183--