Date: Thu, 17 Feb 2022 10:53:52 -0500 From: Rich Felker <dalias@...ifal.cx> To: Satadru Pramanik <satadru@...il.com> Cc: musl@...ts.openwall.com Subject: Re: Re: musl getaddr info breakage on older kernels 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@...ifal.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 188.8.131.52 (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 > > View attachment "cgt.c" of type "text/plain" (185 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.