00:46 < Savander> good night
01:16 < o_be_one> wtf is this last cheat ?
01:16 < o_be_one> and shit
01:16 < o_be_one> someone is able to make some tees doing stupid stuff
01:16 < o_be_one> like chatting things, self-kill, dont move ...
01:16 < o_be_one> they use original TW or Disoka TW (something like that)
01:18 <@deen> yes, that's the spoofing stuff
01:18 <@deen> that EastByte has been working on
01:18 <@deen> are you running the current DDNet server from git?
01:22 <@deen> I'm hearing even worse things
01:23 <@deen> people are claiming to belong to ddnet team and tell players to use ddnet client or they will be attacked
01:23 <@deen> and then the stuff you just described, o_be_one, happens to them
01:23 <@deen> so people now think I do that stuff...
01:23 < o_be_one> yes deen 
01:24 < o_be_one> antispoof id 1
01:24 < o_be_one> antispoof is 1
01:24 < o_be_one> oh
01:24 <@deen> wouldn't really wonder if DDNet gets banned from the master servers soon
01:24 < o_be_one> deen, ive seen players getting this shit, saying things that they dont want, etc. I just said that ddnet is patched about that
01:25 < o_be_one> a player just told me that he will report me to police, and an other to you -_-
01:25 < o_be_one> sometime i'm just like "they have a brain or ?"
01:26 < o_be_one> josh... rode .. someone we know ?
01:26 < o_be_one> its like captain teemo
01:26 <@deen> dunno
01:29 < o_be_one> well i just change how i say message so i hope they'll understand in the good way
01:29 < o_be_one> deen, if you have problem with matricks or smthg, tell me, all is logged, i'll be able to give what he needs
01:30 <@deen> with matricks?
01:30 <@deen> i don't really talk to the official devs
01:30 <@deen> and he's not having any official position
01:32 < o_be_one> but anyway a lot people knows what you do deen, and heinrich5991 too, so its not possible to think you made this
01:36 < o_be_one> its really shitty, btw
01:36 < o_be_one> and boring
01:36 < o_be_one> for players
01:43 < o_be_one> its vali deen 
01:43 < o_be_one> he never move when shits happen
02:33 <@deen> We're currently getting ddosed with a CS1.6 server query amplification attack...
03:06 < fstd> wow. nostalgia ddos from hell
03:06 < fstd> erm, from 2000
05:05 < eeeee> o_be_one: sv_vanilla_antispoof only prevents connections from spoofed ips
05:05 < eeeee> name is a bit misleading since it's not vanilla specific in any way (albeit vanilla compatible)
05:06 < eeeee> it does not prevent packet injection into established connections, so vanilla users still have no protection against those bad things you've mentioned
05:07 < eeeee> switching to ddnet client is currently the only solution to that, we don't know how to trick vanilla client into "signing" packets
05:10 < o_be_one> oh ok thank you eeeee 
09:29 <@EastByte> o_be_one: use "status" in rcon, for each player you can see the entry "secure=yes/no"
09:30 <@EastByte> which indicates that the client supports the token extension (secure against packet injection)
09:37 <@EastByte> eeeee: I used the term "vanilla" because it's related to the vanilla network engine
11:29 <@heinrich5991> eeeee: have you seen Oy's spoofing protection for 0.6? it's somehow using the ack field
12:48 <@EastByte> heinrich5991: it's more solid than I thought, for vital msgs you have to guess the correct ack and seq number of the client
12:49 <@heinrich5991> at the start of the connection they both start with 0, I guess
12:50 <@EastByte> the initial value is guessable
12:50 <@EastByte> they start with 0, yes
12:51 <@EastByte> the problem is for control messages you only have to guess the ack number
13:08 <@EastByte> strange, on the tw06 branch I cannot disconnect anymore, slot isn't reset
13:11 <@EastByte> and now it works again (after rebinding a different port)
13:53 < uchar> hi.. ummm in effect... 50Hz not are working like 100Hz? https://github.com/CytraL/ddnet/blob/master/src/game/client/components/effects.cpp#L262
13:55 <@EastByte> hm they look the same
13:56 < uchar> yep... copy/paste issue xD
14:05 <@EastByte> 3
14:05 <@EastByte> 2
14:05 <@EastByte> 1
14:05 < ddnet-commits> [ddnet] east opened pull request #321: 0.6.4 vital/sequence checking (master...vitalcheck2) http://git.io/vGaZy
14:05 <@EastByte> hm
14:38 <@EastByte> I think know it's basically impossible to inject packets without knowing the exact ip+port of a player
14:38 <@EastByte> mass ip spoofing attacks (like injecting chat msgs containing ip+port of the player) require way too much traffic know
14:56 < o_be_one> hello :)
14:57 < o_be_one> EastByte: oh awesome thks for information :)
14:58 < o_be_one> EastByte: so you secured this more ?
17:18 < WolfAlex> o_be_one: got my server :)
17:19 <@EastByte> EastByte: it's 'now' not 'know'
17:19 <@EastByte> hi WolfAlex 
17:19 < WolfAlex> hi EastByte 
17:19 <@EastByte> o_be_one: it isn't merged yet but yes it will be more secure
17:19 < o_be_one> WolfAlex: oh woaw ? already ?
17:20 < o_be_one> awesome EastByte :D
17:20 < WolfAlex> o_be_one: yea :D
17:20 < o_be_one> ok i'll ask my server WolfAlex i cant accept that you got it before me ahah
17:20 < WolfAlex> o_be_one: :D
17:20 < WolfAlex> i'll set it now up with EastByte, if he got some time? :p
17:20 <@EastByte> so gra is processed earlier
17:20 <@EastByte> give me root!!!
17:21 <@EastByte> maybe I should update my keyfile now
17:21 < WolfAlex> EastByte: yea
17:22 < WolfAlex> ed25519
17:23 < WolfAlex> EastByte: eh
17:23 < WolfAlex> Rechenzentrum
17:23 < WolfAlex>     SBG 2
17:23 <@EastByte> lel
17:23 < WolfAlex> oh no
17:23 < WolfAlex> thats my old one xD
17:23 < WolfAlex> GRA 1 <3
17:25 <@EastByte> WolfAlex: http://eastbit.net/priv/id_ed25519.pub
17:56 <@EastByte> heinrich5991: right, forgot about not vital MAP_DATA
19:18 < Chairn> hello
19:20 <@EastByte> hi
19:28 < Nimda> Shadow by Deeper just released on Novice at 2015-09-01 19:20
20:55 <@heinrich5991> where's the ddnet-commits bot?
20:56 < ddnet-commits> [ddnet] heinrich5991 opened pull request #322: Introduce new, vanilla-compatible server info protocol (also known as: the solution to all problems) (master...pr_ddnet_extended_info) http://git.io/vGrca
20:56 <@heinrich5991> anyway: EastByte: the solution to all problems: https://github.com/ddnet/ddnet/pull/322
20:56 <@heinrich5991> ahh
20:56 <@heinrich5991> deen: I had an idea for reliably sending 64p requests, without the extra round trip
20:56 <@heinrich5991> see above
20:58 <@heinrich5991> fstd: protocol design ^ you might need to implement it in your libtw, so please comment on it :)
20:59 < Chairn> heinrich5991: can it be used to see if server supports /emote?
20:59 <@heinrich5991> Chairn: no. perhaps add a non-connless notification for that
21:00 <@EastByte> heinrich5991: can you explain how it works? the pr is quite huge
21:01 <@heinrich5991> sure. there's quite a few unused fields in the tw package header if the packet is connless
21:01 <@EastByte> 3 flags, 3 byte padding
21:01 <@EastByte> and 64info is extendable
21:02 <@EastByte> iirc
21:02 <@heinrich5991> the first two bytes are set to "ex", the other four can be used in further protocol versions, currently zeroed
21:02 <@heinrich5991> the current protocol has a few problems, namely it sends the server info with each response and it can only send 24 players per packet
21:03 < Chairn> im not fan of that #define in the middle of a function ^^
21:03 < Chairn> +#undef after
21:03 <@heinrich5991> it shortens the code by a significant amount
21:04 <@heinrich5991> compare GET_STRING(Info.m_aVersion); to str_copy(Info.m_aVersion, Up.GetString(CUnpacker::SANITIZE_CC|CUnpacker::SKIP_START_WHITESPACES), sizeof(Info.m_aVersion));
21:04 < Chairn> i guess im too used to see that in the beginning
21:04 <@EastByte> so how does the client know if it's a 64pl server?
21:04 < fstd> heinrich5991: i like it better than using one of the reserved flag bits; this is much less likely to collide with other mods attempting to do the same/equivalent
21:05 < fstd> however "ex" is maybe a bit unfortunate
21:05 <@heinrich5991> that can be changed, what do you suggest?
21:05 <@heinrich5991> (also, why is it unfortunate?)
21:06 <@EastByte> oh I see there are 6 unused bytes
21:06 < fstd> well, basically because it is the obvious choice, and was your first choice.  so it's likely to be the first choice of other developers, too (and hence more likely to collide in the future)
21:06 <@heinrich5991> haha ok
21:07 < fstd> "xe" would be okay IMO :)
21:08 < Chairn> i really dont get those do{ } while(0)
21:08 < Chairn> (im kinda not used to original form of coding)
21:08 < fstd> it's statementification ;)
21:09 < Chairn> ?
21:09 < fstd> Chairn: see http://www.bruceblinn.com/linuxinfo/DoWhile.html
21:09 < Chairn> ah, its just for the define, it has no use anywhere else except with a continue(or break) statement?
21:10 <@heinrich5991> yes
21:12 < fstd> heinrich5991: those macros are lacking some other safety measures though
21:12 < fstd> namely ()'ing the parameters
21:12 <@heinrich5991> yea
21:12 <@heinrich5991> forgot that
21:18 < fstd> the "extra info, reserved" is the hook into the future, right?
21:18 <@heinrich5991> yes
21:18 <@heinrich5991> one byte for each packet and player sent
21:19 < fstd> well, except you're in the future :)
21:20 <@heinrich5991> but then it's actually useful ^^
21:20 < fstd> i don't think it matters much, but i'd probably have made it an integer
21:20 <@heinrich5991> that's less capacity though
21:20 <@EastByte> heinrich5991: for a token handshake the "extra rountrip" is needed, but that wouldn't affect the needed time since now there is one way less
21:21 <@EastByte> that's what I thought about
21:22 <@heinrich5991> huh? one extra roundtrip will affect the needed time
21:22 <@EastByte> your pr doesn't require waiting for vanilla response anymore
21:22 <@EastByte> which is how it currently works
21:22 <@heinrich5991> oh, you mean it's not worse than the status quo
21:22 <@EastByte> yes
21:23 <@EastByte> my approach was pretty much the same
21:23 < fstd> heinrich5991: okay i guess it depends on whether you'd use that reserved value as a sort of flag, or to contain actual (payload) information
21:25 < fstd> i.e. intuitively (without implying it is better or worse) i'd have made it an int, and given one bit the meaning 'this is an extension', and the actual information associated with that extension is to be found in a-priori agreed upon (by the one implementing the extension) location
21:26 < fstd> and non-extended-extended servers would simply not set that bit, and non-extended-extended clients would require it to be zero
21:28 < fstd> (i suppose it doesn't really matter though, as our packets are either considerably smaller than their tcp/ip/ethernet overhead, or big enough (serverinfo response) to make a few-bytes difference negligible)
21:31 <@heinrich5991> EastByte: but that negates all the gains ^^
21:35 <@EastByte> so you think a token handshake is not needed?
21:35 <@heinrich5991> perhaps it can be done if the server is under attack or so
21:36 <@EastByte> optionally, yes would be nice
21:36 <@EastByte> iirc the udp data can get above 2K for a full 64pl server info 
21:38 <@heinrich5991> it's capped at 1400 now
21:38 <@heinrich5991> but still a high ratio
21:39 <@EastByte> right
21:40 <@EastByte> since the response can be splitted into multi packets the result is even worse
21:45 < fstd> heinrich5991: you need to thoroughly document it if you want it to become de-facto industry standard
21:47 <@heinrich5991> fstd: (taunt:) like your awesome documentation for the 64p protocol? ^^
21:48 < fstd> no, more like my awesome POSIX shell lists! https://github.com/fstd/lstd/blob/master/README
21:48 < fstd> that said, i wasn't aiming for it becoming a standard :)
21:49 <@EastByte> but you kept your name in it^^
21:49 < fstd> yeah, even more so to mark it as "this is my protocol message, stay away from it" :P
21:49 <@EastByte> haha
21:58 <@heinrich5991> fstd:  Returns successfully.
21:59 <@heinrich5991> maybe rather "Return success"?
22:01 < fstd> mhm i also was unsure about that, but shell functions calls are syntactically the same as invoked commands, and those 'exit successfully/unsuccessfully', i felt that's more appropriate
22:01 < fstd> still not really sure about it though
22:01 < fstd> thanks for reading my README :)
23:19 < ddnet-commits> [ddnet] Chairn opened pull request #323: Added sv_dragger_range. (master...drag_range) http://git.io/vGoY0
23:20 < Chairn> still needs some deeper test than mine ^^