Re: buildfarm server suddenly not talking to old SSL stacks? - Mailing list pgsql-www
From | Tom Lane |
---|---|
Subject | Re: buildfarm server suddenly not talking to old SSL stacks? |
Date | |
Msg-id | 27207.1531858451@sss.pgh.pa.us Whole thread Raw |
In response to | Re: buildfarm server suddenly not talking to old SSL stacks? (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>) |
Responses |
Re: buildfarm server suddenly not talking to old SSL stacks?
|
List | pgsql-www |
Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes: > On 07/17/2018 09:22 PM, Tom Lane wrote: >> Also, if the issue is somewhere in between, that fails to explain why >> "curl" works but not perl. > not sure that proofs that v4 vs v6 is out entirely, there could be other > factors involved (like your isp mapping v4 to v6 on the router(!) maybe > combined with dns64/dns46 related tricks). > It should still be possible to figure out where exactly the "network > unreachable" comes from - whether it is something the local tcp/ip stack > generates or something that comes in as an icmp-error from remote using > tcpdump or similiar. Good idea ... tcpdump says *nothing at all* is happening during the https request, which led me to try strace'ing the perl run, and that tells the tale: [ lots of setup omitted ] socket(PF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP) = 3 connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}]) sendto(3, "\370-\1\0\0\1\0\0\0\0\0\0\tbuildfarm\npostgresq"..., 42, MSG_NOSIGNAL, NULL, 0) = 42 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}]) ioctl(3, FIONREAD, [70]) = 0 recvfrom(3, "\370-\201\200\0\1\0\1\0\0\0\0\tbuildfarm\npostgresq"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")},[16]) = 70 close(3) = 0 socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = 3 ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7ffe430799c0) = -1 EINVAL (Invalid argument) lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7ffe430799c0) = -1 EINVAL (Invalid argument) lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) fcntl(3, F_SETFD, FD_CLOEXEC) = 0 bind(3, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},28) = 0 connect(3, {sa_family=AF_INET6, sin6_port=htons(443), inet_pton(AF_INET6, "2001:4800:1501:1::217", &sin6_addr), sin6_flowinfo=0,sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable) close(3) = 0 write(2, "500 Can't connect to buildfarm.p"..., 83500 Can't connect to buildfarm.postgresql.org:443 (connect: Network isunreachable)) = 83 write(2, " <URL:https://buildfarm.postgres"..., 65 <URL:https://buildfarm.postgresql.org/branches_of_interest.txt> ) = 65 So for some reason, perl's https support is trying to bind to the IPv6 address of buildfarm.postgresql.org, even though no IPv6 support is configured at all on this machine. I wonder how long that's been going on? Has anything about the machine's DNS entries changed recently? (Also, "ssh buildfarm.postgresql.org" binds to IPv4 just fine.) Also, checking the equally inexplicable failure on dromedary, it looks like the explanation might be similar there, only reversed: the http: request produces zero interface traffic, suggesting that it's getting mapped to an IPv6 address. I don't seem to have a working strace equivalent on that machine so it's harder to be sure about it. regards, tom lane