Transfer closed - CURL ERROR CODE 18

Newer versions of the FiveM (after mid December) are causing this error, i have tried 3 different machines (Windows Server 2012 & 2016 and Ubuntu 16) using different networks and i still got this error, it happens with 80% of the players.

This error occurs only when player is downloading the resources for the first time and also it don’t happens on localhost.

Screenshot: https://cdn.discordapp.com/attachments/270064750384250882/571582109555228673/unknown.png

I have tried to give full permissions to cache folder, disable firewall and use different versions after the 936 version (The latest version that don’t have this issue on Windows) but i had no success on it.

On Linux i don’t know the exact version that this error started to appear.

Does even version 1.0.0.943 do this for your users? No changes were made server-side that could directly affect this, and this does not happen with any players normally.

Do your resources by chance have any ‘special’ characters in their name, any files contained inside them, or similar?

The only potentially relevant change after tag 936 would have been this:

… which could only possibly cause issues with specific edge case unicode filenames.

I tested for one hour with + 2 helpers and with different versions of the FiveM and here is the results:

Server specs (dedicated machine):

i7-4790K 4 cores / 8 logical
16 GB DRR3 RAM
250 MB internet
Ubuntu 18.10 64bits.

Players internet: two with 50mb and one with 35mb.

FiveM versions that worked:

936
955
961

Fivem versions that din’t worked:

1008
1012
1046
1056.

Everytime that this error occurried we experienced the error at the same time and on the versions that it worked it did worked to all of us.

Also, everytime that i changed the server version, we cleared the client cache and i also cleared the server cache and deleted the alpine folder.

Every version we did repeat the test two times.

Also, theres a jump between the version 961 to 1008 and the error occurs on the 1008 version but not on the 961, so i guess that the origin of the bug may be on some changes between the two release tags.

And i don’t have especial chars on folder names, im not sure about files names trough, but probably not. The only difference is that i use the [folder] namespace:

Look, on the 969 version, yall changed someting on the estructure that download the files:

Yall forked this Yijimbo lib and implemeted it, i can not test the 968 version on the Linux but its the only change that i have found so far that can relate to this error. Im downloading visual studio to verify if i can find this problem and fix it, by what im looking at it maybe related to this.

Has nothing to do with file downloading, but OK.

That guess was based on your initial incorrect bisect. If you’re trying to post a bug report, don’t start out with incorrect information.

i saw that later.

Thats right i went and test 10 different versions later. Look, like i said to the moderator that closed my topic. This is something that don’t happen only on my server, it does happens on the majory of brazilian servers (im one of the owner of one discord group of server owners that has more than 1.200 people on it and they report this alot).

Of course i can’t tell what the problem is right of the bat because im not a developer on your project lol, but i will try to see what is the problem because this is something that is happen for months now and im planing to use onesync (i already donate with patreon, but its not linked to this forum account).

Hello, I am also having this issue. (CURL 18)

I compared the amount of bytes remaining to what was in the server cache and it looks like to me they’re able to get like ~20 bytes before the error gets thrown.

We’ve tried: Reinstalling Steam, GTAV, and FiveM. Clearing both server and client cache. Connecting through VPN. I’ve tried disabling the firewall, and forwarded all the correct ports for when it’s up.

We’ve had 3 people with this issue, and we’re also not sure what to do. We’re a US based server.

If we get any more info I’ll post it here.

Hey! I believe i have found the issue with this problem. My only question to you; is are you running vMenu?

No, why ?

I went back to develop for FiveM this month and I’ve found the error, for some reason that i don’t really know it starts on the version 976 and i suspect that is related to this commit:

And what happens is:

  • For some moment in the download process the native API function GetPlayerPing return a -1.
  • As i’m using the vRP, the vRP has a loop that check if GetPlayerPing is 0 or below and if it’s is: kick’s the player
  • Because the player it’'s kicked, the request returns a 403 error (filters says no xD,: FilesHttpHandler: 148).
  • And because there’s no error treatment on download, the user get stuck on the download screen and has to quit the server.

So my “quick” solution for server developers that have the same error, comment the:

task_timeout()

On base.lua inside the vRP folder.

Also, another thing to note: after some new commits, when the request its 403, it don’t end the request and keep open.

So this is basically a ‘vRP’ bug, they’re calling DROP_PLAYER on a tempID as they don’t use the supported way for iterating over players, but maintain their own list including tempIDs.

The only reason this didn’t show before whatever version is that before that point any kicked player would linger in memory forever.

Yes and no.

Why the user has ping -1 when he is downloading a resource ? I agree with you but i also think that dropping player on download it’s not a good thing. Also i have to mention that need a error handling on the Launcher so the user can quit when he is disconnected on the download.

Because it’s a ‘tempID’, which is not supposed to have any ping (since the player hasn’t connected yet at that time! so the only valid values would be -1 or 0, both of which would trigger vRP’s incorrect behavior), or be used past the execution of the playerConnecting event.

1 Like

Yeah, so ask @Imagic or whoever maintains vRP to not call DROP_PLAYER on a tempID.

Alright

Don’t be too over aggressive bro.

There’s a indication that it has tempID in the wiki ? Forum ? Horever ? No. In fact, to discover what it was happening i had to clone the project and debug to find what changed.

I agree that it’s a error on the vRP. But if this was always broken since the vRP release (2017) to start of 2019, how can he (@Imagic) know that it’s broken ? (I’m talking about the ‘tempId’ here). Also, the code kicking a player with 0 or no ping exists exactly because the FiveM din’t kick the player when he disconnected from the server, so it was a workaround to fix the issue.

If you or somebody develop a code using a framework, lib, platform, whoever and works fine for 2 years and then all of the sudden stop working and there’s no explanation about what was modified. How can you know that it’s your fault or it’s the thing you use fault ?

Also, it’s not bad to point flaws in the project, because this is how the project improve, also because of the @nitrogen explanation i could understand why the problem happens and maybe in the future contribute.

If everybody went here just to say something nice about the platform, guess what ? It will stagnate, so don’t be mad and be more humble pls.

Not sure that post can even be considered aggressive.

In fact, since this report, the server was updated to disable DROP_PLAYER on any tempID, but that of course would not fix the issue for people running older versions.

It always did, however.