On Thu, Sep 29, 2022 at 08:05:00PM +0000, Mark Fanara wrote: > Sorry if my response is not per best practices as far as formatting goes. I > will respond to a number of your questions here rather than inline.
See https://curl.se/mail/etiquette.html#Do_Not_Top_Post > As to MTU - I of course can't increase the MTU on the fielded system, so I > have a test system that does not include the wireless link. I have a wired > router in place of the wireless router. I have set the MTU of the outside > interface to value matching the wireless router. When I do that, the file is > not sent. When I simply change the MTU back to default 1500, all works fine. > I can use this setup with and old client/sending device and it works > regardless of MTU. Ok, it sounds like you're pretty confident that MTU is the issue. Did the old OS use the same MTU? > * SSL certificate verify result: unable to get local issuer certificate > (20), continuing anyway. I assume you're deliberately not verifying certificates to get around this issue, but it's bad for security. > Expect: 100-continue > > * Expire in 10000 ms for 0 (transfer 0x10823a80) ---- I changed this value > from 1000ms to 10000ms to see if it made any difference > * Done waiting for 100-continue Some servers have an issue with 100-continue, and I don't recall which version of libcurl enabled it by default. You could try disabling it and see what happens. It theoretically shouldn't have anything to do with MTU, though. What happens in this case when the MTU is greater? How do the client and server handle this 100-continue? > * OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104 > * Closing connection 0 > > libcurl: (56) ERROR : OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104 errno 104 is ECONNRESET "Connection reset by peer", which makes it look like the server is closing the connection while waiting for the rest of the message after the 100-continue. I might have though it could be bad timing on a slow wireless link, except that you tried changing that timeout without a difference in behaviour. It just occurred to me that the 564 byte MTU your link has is less than the RFC 791 specified minimum 576 byte datagrams for IPv4. But, that is after reassembly, and 564 bytes is more than the 68 byte minimum datagram size, so you should actually be OK here. But, it's possible something is in the path that assumes 576 byte minimums and is improperly messing things up. Dan -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
