Teeworlds - bridge

Learath2: is the master response interesting tho? Oh yea maybe :D

07:39

@heinrich5991 rcon passswords can be changed but users will log in to their accounts

ah

08:05

well then only master communication would be good

so this is fine 'src port 7303 and dst master1.teeworlds.com or dst master2.teeworlds.com or dst master3.teeworlds.com' ?

08:18

or do you need src as well?

08:18

@fokkonaut pls let me know when the server is broken and ill record sum traffic

break it

lol but .. :/

xd

if you can break it, do it while no one is online and just record all traffic

08:27

or open another private server and break it there

true

ChillerDragon, the response is also important imho

@heinrich5991 full cap with 20ish sec of working master then auth and then a few master errors https://zillyhuhn.com/tmp/fddr.cap

server requests token, master server sends a token back but the server does not do a heartbeat, instead it requests a token again and again

18:25

so far i did not find any issues in the rest. packets seem okay, no packet loss

18:25

seems like something breaks the token handling

ah, sounds similar to what happened last time

18:25

can you start it in a debugger and give us a coredump?

18:25

after it breaks

Yea I can do that tomorrow btw you could also do it if you feel extra motivated https://github.com/fokkonaut/F-DDrace/tree/F-DDrace

fokkonaut/F-DDrace

F-DDrace is a server mod for Teeworlds 0.7 developed by fokkonaut. - fokkonaut/F-DDrace

20:51

patch engine/server/server.h MAX_RCONCMD_SEND to 16 and build in release mode (ah ye the bug is rls only i think) and auth in rcon

While the server is trying to register, it should be queueing up the heartbeat packet until it gets a token message

21:07

When it gets the token message, it should go through the queue, find the packets that have their destination set to the addr that sent it, and send the packets

21:09

Where i'd add my dbg_msgs would be after network_token.cpp:L264 see if there is anything in the queue, if there isn't anything, then I'd start looking at CNetTokenCache::SendPacketConnless see whether it's even queueing these up properly

21:15

If it's getting queued up properly but it's gone by the time we get the token message, a watchpoint would be useful