Both in 4 and in cauldron, I get a lot of errors while updating or installing additional packages (some packages *do* install fine, though) On kernel.org and utwente I get timeouts like this ...retrieving failed: curl: (28) Timeout was reached 0% of 0 completed, ETA = --:--:--, speed = 0 which appear /extremely/ fast and then ...retrieving failed: curl: (28) Timeout was reached ...retrieving failed: curl failed: exited with 28 on jussieux I get "access denied"s instead and then: ...retrieving failed: curl: (67) Access denied: 530 ...retrieving failed: curl failed: exited with 67 Neoclust reported the access denied problem, too: 2014:02:05:11:40 < neoclust> marja: in fact i have curl pbs now 2014:02:05:11:40 < neoclust> ... échec de la récupération : curl: (67) Access denied: 530 @ Nicolas Do you need more information?
Whiteboard: (none) => MGA4TOO
(In reply to Marja van Waes from comment #0) > @ Nicolas > > Do you need more information? I mean Nicolas Vigier, the maintainer
btw, in Mageia 4 this first occurred after installing libcurl4-7.34.0-1.1.mga4 and curl-7.34.0-1.1.mga4 from updates_testing (bug 12476)
in cauldron it first occurred right after installing curl4-7.35.0-1.mga5.x86_64.rpm lib64curl4-7.35.0-1.mga5.x86_64.rpm cc'ing Funda
CC: (none) => fundawang
Created attachment 4947 [details] urpmi --auto-update run in which, right after curl was updated, the error started (In reply to Marja van Waes from comment #3) > in cauldron it first occurred right after installing > > curl4-7.35.0-1.mga5.x86_64.rpm > lib64curl4-7.35.0-1.mga5.x86_64.rpm > attaching the cli output from the update run in which curl was updated to the above version, and where it failed immediately after that
just downgraded to curl-7.34.0-1.mga4.x86_64.rpm lib64curl4-7.34.0-1.mga4.x86_64.rpm and don't see the problem any more
I don't see any way the patch added to fix CVE-2014-0015 could cause this, and Debian used the same fix in their update. I don't see how NTLM could have anything to do with this. I did see this on the curl site: http://curl.haxx.se/mail/tracker-2014-02/0016.html The fix for that is here: https://github.com/bagder/curl/commit/1ebf22cc0eaea3c8513d2bc23937e4388681f3b8 So, that's a timeout issue, but I don't know if it's the same one you're seeing. Anyway, that particular issue wouldn't affect curl 7.34.0, so it would be Cauldron-only, not the Mageia 4 update. BTW, instead of disabling test 172, we should apply the fix for that: https://github.com/bagder/curl/commit/ffb8a21d85bde8
Blocks: (none) => 12476
I also don't see how the CVE-2014-0015 fix would cause this, and the problem fixed by commit 1ebf22cc is also very unlikely to be seen consistently in real life. There were numerous other changes upstream between 7.34.0 and 7.35.0 that could conceivably cause differing behaviour with timeouts, but I can't explain how there could be any noticable difference between curl-7.34.0-1.mga4 and curl-7.34.0-1.1.mga4. Was libcurl4 in all test cases also upgraded/downgraded to match the curl package? It would be interesting to see a curl log for a failing session, such as "urpmi --downloader curl --curl-options '--trace /tmp/curl.log' foo" making sure that the last file downloaded is one that results in an error (since the log file is overwritten each time).
CC: (none) => dan
Created attachment 4979 [details] compressed curl.log of a timeout (In reply to Dan Fandrich from comment #7) > Was libcurl4 in all test cases > also upgraded/downgraded to match the curl package? Yes, it was > > It would be interesting to see a curl log for a failing session, such as > "urpmi --downloader curl --curl-options '--trace /tmp/curl.log' foo" making > sure that the last file downloaded is one that results in an error (since > the log file is overwritten each time). it wasn't easy to get a log that wasn't way too big (even compressed) to upload, but the one I now try to attach should be OK. At the end of the file, there are messages about there being too many connections from my internet address. I'm wondering whether the timeouts also exist for people with only an IPv4 connection
Sure enough, it's a curl regression with the use of --anyauth. Rather than reusing an already-open connection to the same FTP server when retrieving a subsequent file from the same server, it opens a brand-new one. Eventually, after several files, the FTP server complains about too many simultaneous connections and errors out. I'll bring this upstream and see what kind of resolution we can come up with.
And wouldn't you know it, it was the CVE-2014-0015 fix that caused if after all!
(In reply to Dan Fandrich from comment #10) > And wouldn't you know it, it was the CVE-2014-0015 fix that caused if after > all! Thanks for finding this out, Dan!
Keywords: (none) => UPSTREAMWhiteboard: MGA4TOO => MGA4_testing_TOO
CC: (none) => dglent
Seems there will be a fix for this eventually: http://curl.haxx.se/mail/lib-2014-02/0255.html
CC: (none) => oe
Assignee: boklm => bugsquad
fixed two days ago by luigi12, curl works well now
Status: NEW => RESOLVEDResolution: (none) => FIXEDAssignee: bugsquad => luigiwalser