Constant Disconnect w/ UserInitiated = False

[killemth]

Is anyone having constant issues where the disconnect callback is triggered, and the model states UserIntiaited = false?

{"UserInitiated":false,"JobID":{"SequentialCount":1048575,"StartTime":"2039-01-10T13:37:03","ProcessID":15,"BoxID":1023,"Value":18446744073709551615}}

Is this perhaps a transient issue with Steam today, or were there protocol changes on their end?

This is using SteamKit2 v1.7.0. Upgraded to v1.8.3, same issue.

[killemth]

This appears to only affect certain servers running the instance. Perhaps the IP, or hardware ID used when communicating with Steam has been banned due to too many interactions.

[voided]

Perhaps the IP, or hardware ID used when communicating with Steam has been

banned due to too many interactions. That's very likely to be the case. There are unpublished rate limits on (at the very least) connection and logon attempts from any given IP. If I remember correctly, these sometimes manifest themselves as network level connection rejections, rather than something in the Steam protocol that might have been otherwise obvious. If you aren't doing so already, I would add handling for LoggedOffCallback to see if there's a particular EResult you're getting before your connections start getting dropped. On Dec 4, 2017 10:06 AM, "killemth" <[email protected]> wrote: This appears to only affect certain servers running the instance. Perhaps the IP, or hardware ID used when communicating with Steam has been banned due to too many interactions. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#496 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACUdfRK_aSS_-EFjuu4X3ZNCxIEe6UyUks5s9BiUgaJpZM4Q020D> .

[killemth]

This possibly seems related to #394 -- where they mention changing a hardware identifier in the HardwareUtil class -- however, there was never an official resolution.

This issue just occurred earlier today when running ~10-12 threads communicating with the Steam network in parallel.

I added some extra logging for the OnLoggedOff callback. Oddly enough, running it now seems to work -- but this is just one thread. So, perhaps the ban has expired. Will update once it happens again.

Earlier, I did notice that after many disconnects, it would then throw an exception for InvalidPassword on authentication (which wasn't actually true). Was fairly odd behavior.

[JustArchi]

My ASF users are launching even up to a hundred of bots at the same time, and while it's not always flawless for obvious reasons, it works well most of the time, as Steam network has some upper limit of open connections from a single device (IP address), but this is more or less close to 100, not 10-12 that you mentioned.

On the other hand I've also seen people being unable to spawn more than just a few connections, so I'm not entirely sure if my theory is right. It's probably a mix of both, and you're more likely to hit your issue with non-private IP (such as shared network in school or likewise).

[killemth]

This is a service running on one or more AWS instances, each of which has a unique public interface.

[JustArchi]

It'd be best if you could verify your issue on some other machine, even your private network would do. It's very likely that it's a limit of Steam network and you're not doing anything wrong, you're just super unlucky on that particular machine with this.

Like I said - I have cases of people having no issues when launching 100+ bots on 100 different Steam accounts, all at the same time (in my ASF), but I've also seen people struggling with just a few, in the same program and same manner. Obviously code is not at fault here, since it's not SK2's decision whether it will connect or not. You could try to workaround this issue by using different IPs, different protocols and different CM servers, but it'll probably be a lottery that even if works, might not work tomorrow.