On Thu, Sep 27, 2018 at 10:47 AM sven falempin <[email protected]> wrote:
> I m not sure how this is possible but here s the data : > > i used the ENV to push -w 5 in my pkg_add process : > # date > Thu Sep 27 10:40:28 EDT 2018 > # ps auxww | grep pkgfet > _pkgfetc 60348 0.0 0.1 1728 5456 ?? INp Wed05PM 0:00.09 /usr/bin/ftp -w 5 > -S session -o - https:// > myportal.com/tar/6.3/packages/amd64/p5-LWP-MediaTypes-6.02.tgz > # fstat -p 60348 > _pkgfetc ftp 60348 5* internet stream tcp 0xffff8000006e8548 > 172.16.1.35:5512 --> 92.222.70.241:443 > > I can see the PF state on the natting device: > > tcp 206.180.254.190:52251 (172.16.1.35:5512) -> 92.222.70.241:443 > ESTABLISHED:ESTABLISHED > age: 16:55:28 expires: 07:07:25 id: 5b7ce30b0094854a > rule: pass out quick on em5 all flags S/SA label "READY_TO_NAT" tagged > READY_TO_NAT > > this is stock 6.3 ftp which is still the same now ( > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ftp/ ) > > # ktrace -p 60348 > generate an empty 64 bit file. > > Any other test i could do to understand ? > > My understanding of the code is that the -w cannot work . I have been using a lot of socket and c code, and always ended using non blocking fd because : life the code is not using non blocking fd , and rely on the POLLIN of tls in a strange way The syscall in fetch.c are ( geee the get_url is crazy long and full o ifdef :s ) error = getaddrinfo(host, port, &hints, &res0); fd = socket(res->ai_family, res->ai_socktype, res->ai_protocol); (void)signal(SIGALRM, tooslow); alarmtimer(connect_timeout); connect ( and tls_init and stuff and then directly tls_read like that : do { tret = tls_read(tls, buf, len); } while (tret == TLS_WANT_POLLIN || tret == TLS_WANT_POLLOUT); i did not code much with tls_read but calling tls_read on TLS_WANT_POLLOUT seems far FETCH Cheers. -- -- --------------------------------------------------------------------------------------------------------------------- Knowing is not enough; we must apply. Willing is not enough; we must do
