Ulysses
Ulysses Stuff => General Chat & Help and Support => Topic started by: Ludicium on April 24, 2012, 08:23:54 PM
-
Here is an example of myself joining as a super admin+ rank.
L 04/24/2012 - 21:48:49: [ULX] (Console) added <DGC> Ludicium to group dev
L 04/24/2012 - 21:48:49: rcon from "<ip here>": command "ulx adduser lud dev"
L 04/24/2012 - 21:48:56: STEAMAUTH: Client <DGC> Ludicium received failure code 6
L 04/24/2012 - 21:48:56: "<DGC> Ludicium<38><steamid><>" disconnected (reason "Client left game (Steam auth ticket has been canceled)
")
(Correction that is joined as admin then switched to Dev and then lost auth)
Here is what happens when a user attempts to connect as a super admin+ rank.
L 04/24/2012 - 21:35:06: "<DGC> Ludicium<26><STEAM_id><>" entered the game
L 04/24/2012 - 21:35:29: "<DGC> Ludicium<26><STEAM_id><>" disconnected (reason "<DGC> Ludicium timed out")
Any in site into why this is happening would be greatly appreciated.
~Ludicium
-
I just verified that everything was working fine for me on my local dedicated server-- made sure everything was up-to-date, connected as superadmin, removed/re-added access, I'm not getting any issues here.
To me it doesn't look like this error has anything to do with ULX at all, but if you want to you can remove your permissions via server console and see if you can join then.
-
Happening to me as well, if anyone joins my server as a superadmin in ULX their GMod silently crashes. If I remove ULX and give them superadmin in users.txt it works fine. Admins and anyone in a ULX group that doesn't inherit from superadmin can join fine.
-
Same here... linux server, maybe that's why it works for you if you're running on windows?
(Console) removed all access rights from TonyCip
Client "TonyCip" connected (<snip>:27005).
(Console) added TonyCip to group respected
ulx adduser tony admin
(Console) added TonyCip to group admin
STEAMAUTH: Client TonyCip received failure code 6
Dropped TonyCip from server (Client left game (Steam auth ticket has been canceled)
)
-
This is happening in both my servers as well. One of my admin's was having the same problem where it crashes silently. I removed his admin and he was able to join.
The weird part is that I can connect to one of my servers but not the other. The one where I CAN connect my rank is "root_user" and on the other one, I'm set as "owner."
I gave admin to a random player just for kicks:
14:33:56 "xxxxxxxxxxxxxxxx" disconnected (reason "Client left game (Steam auth ticket has been canceled)")
-
I think it's just any admin rank
-
I'm running a Linux server too, might be Linux specific.
Edit: Also works fine if you run just ULib and not ULX.
Edit: I had a friend with a Windows server test and it worked fine, it appears it is specific to Linux servers.
-
My servers run on Windows and they're giving me this problem.
-
Out of curiosity what game mode are you running, for me it would be TTT.
-
Also i would be on a vps and not a dedicated server.
-
DarkRP, tried sandbox too with same issue, also tried deleting all addons from client and server, worked fine, readded ULX, broke again.
-
Same problem for me on a Windows sandbox server. I've tried even renaming the admin/superadmin groups I have to something else for now so they can use their commands, but of course they aren't detected as admin for addons like simple prop protection.
-
Are you guys on Vps or dedi?
-
ooooo there was just a gmod update not too long ago. Im going to go see if that was a fix :D.
-
Dedi & still broken after GMod update for us.
-
same here...
-
Hmm.
http://garrysmod.com/
Not sure it's something even we can fix folks. (Not saying we won't try)
Even Garry had to reach out to Valve for his fixes..seems he went new engine.
Sounds like something acts like a VAC system, where, if you use lua to change group access, the server sees it as a 'hack' and kicks you off.
Just my theory.
-
Mine's a debian vps
-
If ULX is causing this issue, it would be due to a bug that garry introduced into the API. Hopefully Garry will find it and fix it quickly. If this problem still exists this weekend, I'll look into it further.
-
I'm going to do some digging around when I get off of work today.
We haven't really seen any common elements that cause the crash based on OS, gamemodes, or other addons-- perhaps it's caused by some specific ULX permission?
The weird part is that I can connect to one of my servers but not the other. The one where I CAN connect my rank is "root_user" and on the other one, I'm set as "owner."
Bungletrpg, if you don't mind, can you send us your groups.txt files for both servers? (PM or email at teamulysses@ulyssesmod.net) We can take a look at what each rank has and see if that may be an issue.
All, If you're having this problem, does it still occur if you backup then remove the ulx/ulib related data files (and just for good measure the banned_users.cfg file) and run the server off of the default ULX configuration with no bans?
Yet even if this is the cause, why did it work on my server but not others? .. Perhaps I just fail at testing thoroughly :P
-
On my server, I have the admin and superadmin rank, if anyone who has these ranks joins they get the steam auth ticket drop error and their game crashes.
I've tried making a rank called "supermod" and have it inherit superadmin and add myself to that, which worked. Garrysmod wouldn't detect me as an admin for simple prop protection, but all the ulx commands would work.
However, when I did the same thing for the admin rank, created a rank called "mod" and have it inherit admin, I added some of my admins to that but they still crashed.
-
Hmm.. interesting. I can't really do anything about this till I get off of work, and Megiddo's scrambling to get his important schoolwork done so he can look into it also, but if you guys can keep posting any useful information about this that you can, we greatly appreciate it. :)
-
Managed to narrow it down, deleting just bans.txt from data/ULib seemed to fix it for me, will try and investigate further now.
-
Thanks Drakehawke, that could very well be a possibility since Garry did just change the ban system to support cheaters.cfg. This post on facepunch (http://facepunch.com/threads/1179747?p=35713153&viewfull=1#post35713153) is also relevant to the possibility of it being related to bans.
-
Narrowed down even further, if you have access to "xgui_managebans" and bans.txt exists on the server it occurs. Adding user specific access to this whilst in-game causes my GMod to silently crash. Being in any group with access to this crashes on join.
-
Hmm, It probably happens when the user requests a TON of ban data from the server upon joining. Does it work fine if you join the server, then give the group access to xgui_managebans? (On giving the group access, XGUI client should automatically request for the ban data if it now has access)
Also, how many bans do you currently have? A ton like I'm assuming here?
-
Joining then giving group access does crash too, yes.
I have about 400 bans, I removed them all and added a few new ones and it worked fine.
May or may not be related, but when I was originally investigating the source of this (before I knew it was ULX), due to the extra delay in crashing when joining a busy server compared to an empty one, I did suspect networking was the cause. I made a quick script to log calls to umsg.Start, writing the name of the usermessage to a text file if the target had my SteamID. I noticed that there was a lot of UL* messages (from ULibs custom datastream I think), but there was always a "ULStart" usermessage sent with nothing after it (no ULPacket or ULEnd following), right before the crash.
Edit: I'm sure there's a good reason for this, but why exactly do you send all details of all server bans to people with access to the xgui bans menu when they join? Surely it would make more sense to send the information when they request it - i.e. when they open the bans menu?
-
ULStart by itself wouldn't cause a crash since it's just setting Lua variables. Perhaps the client is just being overwhelmed with user messages, though...
-
Edit: I'm sure there's a good reason for this, but why exactly do you send all details of all server bans to people with access to the xgui bans menu when they join? Surely it would make more sense to send the information when they request it - i.e. when they open the bans menu?
I think there is a slight but noticeable lag in most cases when you receive the bandata. When you get the data on join it tends to be less noticeable since everything else is loading, and most people expect there to be some lag when they first get into a server. I have tested XGUI with a couple thousand bans before, but they didn't contain any extraneous information (just the SteamID and unban "0"), so this partly an issue that I haven't done proper testing of. (When I originally designed the ban menu I didn't really think about servers having so many bans-- I don't run a server, if you can't tell. :P)
Also the banmenu is one of the things I haven't optimized extensively yet. I do have plans to change the ban menu to only display a "page" of bans at a time (25 or so), then add cool features like searching/filtering, but I haven't gotten around to it.
I'll probably make the new ban menu a priority (Well, that and getting XGUI working for Gmod13), but for filtering my idea was to allow clients to filter any fields on ban information so they can pinpoint bans they're looking for. I have two options for doing this:
1) Send all of the ban information once to the clients that have access to it, but at a slower, more reliable rate, then have all of the filter processing done client-side.
2) Have the clients send filter data to the server, the server will then process the filter and send the results back to the client.
Option 1 or 2 is better depending on how often the ban menu and the filtering tools will be used-- Theoretically, on a server with 500 bans and a filter that returns 25 results per page, if a filter is performed more than 20 times per admin per mapchange/rejoin (that includes going to additional pages of results), it will be better for the server to send all of the ban data once and then not have to do any extraneous processing. If it's performed less often than that, then it would certainly be better to have the server process the filters and send only the current page of results that the client needs.
(Actually, having typed that up and looked at it, to me it seems like the server processing of filters would be the better option, even with the rare exception that an admin goes ban-filter happy)
Either way, I believe I can fix the current problem temporarily by slowing down the chunks of bandata sent (or by changing the size of each chunk). Yes, I could send brief information about all of the bans to start with, then send the extra ban information on request when the user wants to see more details, but I have to see how everything is going to play out. And do more testing!
-
We think we know the cause of the problem and are working on a fix now. :)
Major thanks to Drakehawke for narrowing the problem down as much as he did.
-
For those interested to know, we got a banlist from someone who was having this issue and put it on our own server. We traced it down to a ban entry that had a very large number for the unban time:
"STEAM_0:<numbers>"
{
<other stuff>
"unban" "8.2931441613731e+015"
}
By removing all of the other bans and testing, we crashed. By setting the unban value of this entry to "0", it worked fine. Megiddo traced the problem down to some of XGUIs code in handling the receiving of the ban data, which I later traced down to XGUI's clientside bans.lua file.
After searching the file for a bit, I realized that I was using os.date() to convert various times to something more pretty-- And if any of you have used os.date before, it can be.. unstable. After more prodding, I found that giving os.date() raw time values greater than 32535244799 (regardless of formatting tags) caused it to crash. Why the Garry's Mod update may have changed something is beyond me.
I'm working on a fix where any time os.date is called, cap the time value at 32535244799. I'll figure out a less hackish solution in the future. I hope to have the fix sometime tomorrow.
If you want to fix the problem right now, go to your garrysmod\data\ULib\bans.txt file, find any entries where the value of unban is greater than "32535244799" and set it to "0". (Be sure to keep the quotes. 0 will turn it into a permaban, but I'm pretty sure if the unban year is set to more than 3001, we'll all be dead anyways). Then just be careful not to ban anyone for too long until we get this fix pushed.
-
The above fix should now be pushed to SVN! Update your working copy and let me know if it works for you.
-
Apparently it wasnt put into svn says NFOservers
-
Apparently it wasnt put into svn says NFOservers
SVN rev. 193 has the fix. However, I did forget to change the ULX version (so it still says 3.53), so I've just committed rev 194 so ULX shows the correct version number.
If you don't want to wait for NFOservers to update the SVN for you, I'd recommend opening your garrysmod\data\bans.txt files and searching for any bans where "unban" is set to a really big number, and change it to "unban" "0", then restart the server.