From: Satadru Pramanik <satadru@gmail.com>
To: Rich Felker <dalias@aerifal.cx>
Cc: musl@lists.openwall.com
Subject: Re: [musl] Re: musl getaddr info breakage on older kernels
Date: Thu, 17 Feb 2022 11:17:16 -0500 [thread overview]
Message-ID: <CAFrh3J8WwsQ6mOFLgGCTAkCd496KW0=BiRrEqH9A7_9WpC-6xw@mail.gmail.com> (raw)
In-Reply-To: <20220217155351.GR7074@brightrain.aerifal.cx>
[-- Attachment #1: Type: text/plain, Size: 4942 bytes --]
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 <dalias@aerifal.cx> 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 <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)
> > > > 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
> > >
>
>
>
[-- Attachment #2: Type: text/html, Size: 6842 bytes --]
next prev parent reply other threads:[~2022-02-17 16:17 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAFrh3J9CK67S=Jn531zTK04QeR8yiZwro_ZThQD=3aUx5XghCA@mail.gmail.com>
2022-02-06 21:30 ` Rich Felker
2022-02-06 23:25 ` Satadru Pramanik
2022-02-06 23:44 ` Rich Felker
2022-02-07 1:29 ` Satadru Pramanik
2022-02-07 2:40 ` Rich Felker
2022-02-07 19:19 ` Satadru Pramanik
2022-02-07 21:02 ` Rich Felker
2022-02-14 17:24 ` Satadru Pramanik
2022-02-14 18:29 ` Rich Felker
2022-02-14 19:00 ` Satadru Pramanik
2022-02-14 22:00 ` Rich Felker
2022-02-15 16:59 ` Satadru Pramanik
2022-02-15 17:44 ` Rich Felker
2022-02-15 22:56 ` Satadru Pramanik
2022-02-16 1:41 ` Rich Felker
2022-02-16 18:37 ` Satadru Pramanik
2022-02-16 18:44 ` Satadru Pramanik
2022-02-16 21:33 ` Rich Felker
2022-02-16 21:53 ` Satadru Pramanik
2022-02-17 1:44 ` Satadru Pramanik
2022-02-17 4:14 ` Satadru Pramanik
2022-02-17 13:17 ` Satadru Pramanik
2022-02-17 13:24 ` Rich Felker
2022-02-17 13:30 ` Satadru Pramanik
2022-02-17 13:46 ` Rich Felker
2022-02-17 14:49 ` Satadru Pramanik
2022-02-17 15:53 ` Rich Felker
2022-02-17 16:05 ` Rich Felker
2022-02-17 16:36 ` Satadru Pramanik
2022-02-17 18:17 ` Rich Felker
2022-02-17 21:39 ` Satadru Pramanik
2022-02-17 21:42 ` Satadru Pramanik
[not found] ` <CAFrh3J9CBGagzmnn9E7W0H15iiOzZEtg4YKfJ1qRwCtrjnw6tA@mail.gmail.com>
2022-02-17 21:43 ` Fwd: " Satadru Pramanik
2022-02-17 22:48 ` Rich Felker
2022-02-18 1:25 ` Satadru Pramanik
2022-02-17 16:17 ` Satadru Pramanik [this message]
2022-02-07 5:35 ` Markus Wichmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFrh3J8WwsQ6mOFLgGCTAkCd496KW0=BiRrEqH9A7_9WpC-6xw@mail.gmail.com' \
--to=satadru@gmail.com \
--cc=dalias@aerifal.cx \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
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).