| TimRiker | nc -N -i 1 -u localhost 5154 < README.md does not seem to do anything against your server. | 01:38 |
|---|---|---|
| TimRiker | tcp ports both work. | 01:39 |
| blast007 | I was just using 'nc 127.0.0.1 5154' or 'nc ::1 5154' and typing lines of text followed by the enter key | 01:49 |
| blast007 | oh, also you're using UDP in that example, and I don't have UDP hooked up yet | 01:50 |
| TimRiker | interesting, but old, read: http://www.kegel.com/c10k.html | 02:03 |
| TimRiker | I use the -i to keep the connection open and spread out writes. | 02:04 |
| TimRiker | Do you think libevent is an option? Seems like that's been around for a while. I think it supports windows, but I've never used it there. | 02:09 |
| TimRiker | https://libevent.org/libevent-book/01_intro.html has some sample code. | 02:10 |
| blast007 | I briefly looked at that but it seemed like overkill | 02:10 |
| blast007 | specifically, this stuff "Libevent additionally provides a sophisticated framework for buffered network IO, with support for sockets, filters, rate-limiting, SSL, zero-copy file transmission, and IOCP. Libevent includes support for several useful protocols, including DNS, HTTP, and a minimal RPC framework. " | 02:10 |
| TimRiker | still reading up on it. if it includes dns, we could use that instead of c-ares. we have talked about adding SSL/TLS, so that might be good too. Still reading up on it. No decision yet. | 02:12 |
| blast007 | their SSL support requires either OpenSSL or mbedTLS | 02:16 |
| blast007 | OpenSSL is a no-go on Windows because I don't want to have to install Perl, but mbedTLS might be an option | 02:17 |
| blast007 | heh.. nope.. mbedTLS also needs Perl to build it.. plus Python | 02:18 |
| TimRiker | ugh. and no pre-built versions around we trust? | 02:20 |
| blast007 | we build our dependencies | 02:20 |
| blast007 | it makes sure we're building against the same version of Visual C++ | 02:21 |
| TimRiker | ++ | 02:21 |
| blast007 | I don't know if we really need full encryption of the network traffic anyway | 02:22 |
| blast007 | is the concern about spoofed UDP traffic? | 02:23 |
| blast007 | if it's about chat, we could use something to encrypt just the text in transit | 02:28 |
| TimRiker | rot13 was an interesting option. This works against the test app: | 02:30 |
| TimRiker | nc -N -i 1 localhost 40713 < README.md | nc -N localhost 40713 | 02:31 |
| TimRiker | It's not a critical feature in my mind. The extra overhead might detrimentally affect gameplay. If we had a tls/ssl session though that would validate udp traffic. it would be a tradeoff for sure. | 02:33 |
| blast007 | a previous suggestion was a 2 byte security prefix on UDP packets, but I don't know if that actually helps in practice | 02:34 |
| TimRiker | easy enough to just send 64k spoofed packets I suppose. and if someone can intercept one packet, they have the reusable key. | 02:35 |
| TimRiker | right now you need to match the client ip and port. presumably if there is someone spoofing, they got that info from a packet? | 02:35 |
| TimRiker | I guess if they don't have the port, and we add another 16 bits, that's 2^32 spoofed packets needed. | 02:36 |
| blast007 | they'd have to find their IP from some other means, like getting the victim to join a server they have admin right on or visit a web link | 02:36 |
| blast007 | (both of which happened before) | 02:36 |
| TimRiker | agreed | 02:37 |
| blast007 | back then though they just did straight up DoS attacks on the victums | 02:37 |
| blast007 | victims* | 02:37 |
| TimRiker | so they got the ip, and how did they find the port? brute force? | 02:37 |
| TimRiker | ah. ddos on the client ip. Was there reported spoofing of packets? | 02:38 |
| blast007 | IIRC they weren't spoofing victim IPs to mess with game servers, but instead for use in UDP amplification attacks | 02:39 |
| TimRiker | I used hexdump in my example just to validate that it takes binary input. rot13 would still give binary output, which I suppose one could pipe to hd or the like. :) | 02:39 |
| blast007 | so they get an IP to attack, and use that as the source IP in a spoofed request to some server | 02:39 |
| blast007 | some server being something like DNS or chargen | 02:39 |
| TimRiker | are there sequences there that would actually amplify? From what I recall, our udp packets are not very large. | 02:40 |
| blast007 | they weren't using our servers to amplify | 02:40 |
| TimRiker | k | 02:41 |
| blast007 | they were hitting our stuff with amplifcation attacks from DNS servers, chargen servers, etc | 02:41 |
| TimRiker | I moved bzflag.* off buddydns as it kept getting hit with amplification attacks and buddy would stop serving. he.net has been great with it in that respect. | 02:42 |
| *** Zehra <Zehra!~Yukari@user/yukari> has joined #bzflag | 02:50 | |
| blast007 | Zehra: re: MsgTimeUpdate, what kind of control of match time are you looking for? Seems like you could already set the time remaining from the API, and bzfs sends a time update every 30 seconds | 02:54 |
| blast007 | it also sends out an update immediately if clOptions->addedTime is set to a non-zero value, which could be modified from a new bzfsAPI function | 02:57 |
| Zehra | blast007: I'm looking to modify timing during a match period. Match is active at 5 mins 39 seconds, while 40 seconds is added when game play objective is accomplished. | 02:59 |
| blast007 | Zehra: does bz_setTimeLimit(bz_getTimeLimit+40.0f) not work for that? | 03:01 |
| blast007 | sorry, bz_setTimeLimit(bz_getTimeLimit()+40.0f) | 03:01 |
| blast007 | (again, might take up to 30 seconds for the change to reflect on clients) | 03:02 |
| Zehra | I haven't tested it yet. I'm assuming it only works before/after a match is started.(At least from all examples I've seen.) | 03:02 |
| Zehra | (Viewing bzfsAPI.cxx and bzfs.cxx) | 03:04 |
| blast007 | there's no logic in the function to detect if a match is running, and the code in bzfs.cxx always references clOptions->timeLimit when calculating what time remaining value to send | 03:04 |
| Zehra | Ah, now I see: in bzfs.cxx float timeLeft = clOptions->timeLimit - newTimeElapsed; and clOptions->timeLimit = timeLimit; in bzfsAPI.cxx | 03:06 |
| blast007 | you could also add a bz_modTimeLimit function that adds on to clOptions->addedTime | 03:06 |
| Zehra | I think it's more of something I missed while working on some API bypasses. | 03:08 |
| Zehra | Come to think of it, would a small change to bzfs.cxx's logic be alright, if it works with timing? | 03:10 |
| blast007 | what change are you thinking of? | 03:10 |
| Zehra | Slight change to: if ((timeLeft == 0.0f || newTimeElapsed - clOptions->timeElapsed >= 30.0f || clOptions->addedTime != 0.0f) | 03:11 |
| blast007 | what of that would you change? | 03:13 |
| Zehra | I'd add an additional conditional, either a boolean with something like instantTimeUpdate being true. | 03:17 |
| Zehra | (Probably the least neat option, but it certain to work.) | 03:17 |
| Zehra | Or if the time differences are off by more than 1 second. | 03:17 |
| blast007 | perhaps bz_setTimeLimit() *should* return false if a match is active and instead bz_modTimeLimit should be created/used and that would alter clOptions->addedTime | 03:21 |
| blast007 | altering the addedTime value immediately sends a time update | 03:22 |
| Zehra | Ah, okay! | 03:23 |
| Zehra | That works way better, actually makes a lot more sense. | 03:24 |
| Zehra | Also maybe perhaps with added option of notify on timelimit change as function? | 03:24 |
| blast007 | wonder if any plugins are using bz_setTimeLimit() during an active match | 03:25 |
| blast007 | do any of our other functions notify players? | 03:26 |
| Zehra | I just see them modify clOptions->(option), no control over notifications it seems in a quick search. | 03:28 |
| blast007 | even BZDB functions in the API might not trigger an automatic notification | 03:29 |
| Zehra | I mainly don't want it to spam a notification for timelimit updates/changes. | 03:32 |
| Zehra | It might be distracting for players/admins if it's occurring a few times. | 03:33 |
| blast007 | I would think in general the API functions *shouldn't* trigger any kind of notification | 03:33 |
| blast007 | it should be up to the plugin itself to send a notification | 03:34 |
| TimRiker | the clients display a countdown, right? that should update. not a visible notification, but a change to the timer time? | 03:36 |
| Zehra | I did some tests, but I can't say from the server side of things, since it was with bypassing the API. | 03:37 |
| blast007 | TimRiker: yeah, I *think* we were both referring to a chat message notification | 03:38 |
| TimRiker | blast007, I'm often on WSL2 these days. no working ipv6 routing there. that's in my way... If I convert the Hyper-V network to bridged, then I can get IPv6, but I loose my VPN access. ugh. | 03:38 |
| TimRiker | blast007++ | 03:38 |
| Zehra | I noticed you can let the "clock" reach zero and it remains there the entire time. (Not the server messages.) | 03:42 |
| Zehra | (only works with bypass though.) | 03:43 |
| blast007 | TimRiker: I also found libuv, but it looks like they intend to drop support for older Windows platforms I'd still rather support | 03:58 |
| blast007 | (their website also seems to not resolve on OpenDNS, so I couldn't even get to it) | 04:01 |
| TimRiker | which website? libuv? or libevent? | 04:07 |
| blast007 | libuv | 04:07 |
| *** FastLizard4 is back | 05:03 | |
| *** FastLizard4 is now away: IN-GAME - Stardew Valley | 05:03 | |
| *** Zehra <Zehra!~Yukari@user/yukari> has quit IRC (Quit: Quit.) | 05:07 | |
| *** yuitimothy is back | 05:13 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 255 seconds) | 05:27 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 05:40 | |
| *** yuitimothy is now away: I've done some soul-searching and I still can't find it. | 05:41 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 05:44 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 255 seconds) | 05:46 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 255 seconds) | 05:51 | |
| *** FastLizard4 is back | 06:15 | |
| *** FastLizard4 is now away: AWAY from keyboard | 06:17 | |
| *** TimRiker <TimRiker!~TimRiker@2001:470:43cb::13> has quit IRC (Read error: Connection reset by peer) | 07:15 | |
| *** TimRiker <TimRiker!~TimRiker@2001:470:43cb::13> has joined #bzflag | 07:15 | |
| *** SpringTank <SpringTank!~quassel@75.28.20.205> has quit IRC (Ping timeout: 255 seconds) | 07:16 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has quit IRC (Read error: Connection reset by peer) | 08:39 | |
| *** blast007[m] <blast007[m]!~blast007m@2001:470:69fc:105::7ec> has quit IRC (Quit: You have been kicked for being idle) | 09:00 | |
| *** SpringTank <SpringTank!~quassel@75.28.20.205> has joined #bzflag | 09:24 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 12:31 | |
| *** FastLizard4 is back | 13:44 | |
| *** FastLizard4 is now away: AWAY from keyboard | 14:18 | |
| *** FastLizard4 is now away: GONE - Screen Detached and Disconnected from IRC (I'm probably asleep, at work, or doing something in real life) | 14:31 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has joined #bzflag | 15:27 | |
| *** _I_Died_Once <_I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 17:00 | |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 248 seconds) | 17:04 | |
| *** TimRiker <TimRiker!~TimRiker@2001:470:43cb::13> has quit IRC (Remote host closed the connection) | 22:01 | |
| *** FastLizard4 is back | 22:53 | |
| *** FastLizard4 is now away: AWAY from keyboard | 23:02 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!