Time Nick Message 00:31 BillyS I'm back again 00:31 BillyS Managed to get a packet capture between a minetest server and client via wireshark 00:32 BillyS It left me more confused than before ... 00:33 BillyS This is the hex dump of the first packet 00:33 BillyS Since it's the first packet, I assume it's the TOSERVER_INIT 00:33 BillyS http://pasteall.org/1355103 00:42 BillyS Well, I guess the first 7 bytes are the header 00:42 BillyS At least, that's what the docs say 00:51 BillyS So that would make the header ... '02 00 00 00 45 00 00' 00:52 BillyS The protocal id is the first 4 bytes I think ... which would make it '02 00 00 00' 00:52 BillyS huh 00:52 BillyS that makes no sense 00:53 BillyS I guess that means it's a split packet ...? 00:54 BillyS ..wait 00:55 BillyS What is the protocol_id? 00:55 BillyS Because if that specifies what command is being used, that would make more sense ... 00:56 BillyS If that's so, then it's a TOSERVER_INIT 00:56 BillyS The peer number is 45 00:56 BillyS and the channel is 0 00:57 BillyS Can someone confirm / deny that, or am I just annoying everyone? :P 00:58 * BillyS pokes sfan5 01:05 BillyS No one around, it seems ... 01:05 BillyS Hmm, guess I'll have to figure it out myself 01:05 BillyS Yeah, that's definately wrong 01:07 T4im the protocol id is a #define on 0x4f457403 01:07 T4im so look for that, and read from there 01:16 BillyS Found it in networkprotocol.h 01:17 T4im or generally speaking, make sure when using wireshark to select the payload to highlight what it is 01:17 BillyS OH 01:17 BillyS It all makes sense now 01:17 T4im because it is giving you *everything* 01:17 BillyS Yeah, that was my problem 01:17 T4im including ip 01:17 T4im as in protocol not address 01:17 BillyS I thought all that stuff was part of the data, but it wasn't 01:18 T4im no, that's really the entire network packet as seen from your operating system 01:18 BillyS The part that I am interested in is the last line: "4f 45 74 03 00 00 00 03 ff dc 01 00 00" 01:18 BillyS That's the actual data 01:18 T4im yupp 01:19 BillyS And there is the 4-byte protocol in the beginning ... 01:19 T4im the list over the data has these tree structure that interprets the data, when clicking it, it highlights the parts of the data that belong to it 01:19 T4im and i think there is even a minetest wireshark plugin to specifically interpret minetest traffic, but i never tried that 01:19 BillyS Oh really? Ill look for that 01:19 T4im and perhaps it might not hurt you to go through this manually :p 01:19 T4im good learning experience 01:19 BillyS True 01:20 BillyS I don't care if it's hard, I just need to be given a starting point (which you guys have done) 01:22 BillyS Thanks for pointing that out, that was quite the lifesaver 01:23 T4im no problem :) 01:26 BillyS Hmm ... so the data is '4f 45 74 03 00 00 00 03 ff dc 01 00 00' 01:26 BillyS The header is ''4f 45 74 03 00 00 00' 01:26 BillyS So the message (idk the proper term) is '03 ff dc 01 00 00' 01:27 BillyS the '03' means that it is a reliable packet 01:28 BillyS And I guess the 'ff dc' is the seqnum, whatever that is 01:29 T4im in terms of udb based protocols that usually means that the receiver is supposed to acknowledge the reception and that otherwise the sender will retry to make sure the packet is delivered reliably 01:29 T4im seqnum looks like sequence number 01:29 T4im probably for reliability reasons 01:29 BillyS Ah ... 01:30 T4im like if you get packet 1, 2, 3, 6, wait a moment..! can you send me 4 and 5 again? :p 01:30 BillyS Oh, cool 01:30 T4im but also ordering might be an issue 01:31 T4im no guarantee they won't arrive out of order 01:31 BillyS Then there is the '01 00 00' ... I think the '01' means that it's an original packet 01:31 T4im but it's likely for stuff like that; concrete implementations may vary 01:32 BillyS I see ... I think reliable packets do stay in order (or rather get re-ordered) in minetest 01:32 BillyS RELIABLE: Delivery of all RELIABLE packets shall be forced by ACKs, and they shall be delivered in the same order as sent. 01:32 T4im there you go 01:32 BillyS That's what the docs say 01:32 T4im ACKs is the acknowledgement part 01:33 BillyS Makes sense 01:33 BillyS Hmm ... what is the "00 00" though? Is that the actual packet 'data', so to speak? 01:34 BillyS This packet seems to match the 'RELIABLE(ORIGINAL(data)) - reliable small data ' packet type 01:34 BillyS So I'm guessing so 01:36 BillyS Ooh ... hmmm 01:38 BillyS Well that stumps me 01:40 T4im i think that is the connection command 01:41 T4im https://github.com/minetest/minetest/blob/d7d451c647f1fff7983178a9817888f4d0bab695/src/network/connection.h#L309 01:42 T4im that enum is just big enough to need a second byte :D 01:43 BillyS Ooh 01:43 T4im eh no sorry, it's not big enough to need a second byte 01:43 * T4im is getting tired 01:44 T4im it's still CONNCMD_NONE tho 01:44 BillyS I was wondering ... I think it would have to be 16+ elements to need 2 bytes 01:45 BillyS Why would the client send CONNCMD_NONE though ... that's rather confusing 01:45 BillyS Is that it's way of seeing if the server is online? 01:46 BillyS Hmm, need to look into this .. 01:46 T4im it's just how it handshakes.. not uncommon; others just say HELO :) 01:47 BillyS ah 01:47 BillyS Hmm, okay 01:48 BillyS That's quite interesting ... I'll document this 01:56 BillyS I thought clients started the handshake by sending TOSERVER_INIT 01:56 BillyS Or is that after the handshake? 01:57 T4im that's probably all still part of the handshake 01:57 BillyS Ah 01:58 BillyS That's the second part, so to speak I guess 01:58 BillyS I'll probably have to look into the next packets to find that 01:58 T4im handshakes can go on for a few exchanges.. that's why they are called handshakes and not high fives :p 01:58 BillyS lol 01:58 T4im although i suppose at some point you'd call it a negotiation of something 01:59 BillyS Found the ascii art in clientiface.h ... very helpful 01:59 BillyS Though it doesn't mention this "CONNCMD_NONE" ... I guess that's why it's called high-level. :P 02:00 T4im :D 02:07 BillyS Hmm, the next packet is slightly puzzling 02:07 BillyS Unwrapped a bit, it's data is '00 01 00 02' 02:07 BillyS This is a control packet 02:08 BillyS CONTROLTYPE_SET_PEER_ID to be exact 02:08 BillyS So it's telling the client to set it's peer id to 00 02 02:09 BillyS But ... oh, never mind 02:09 BillyS I forgot that the second packet has the server's peer id, not the clients 02:25 BillyS T4im: For the fourth packet, I have a reliable packet with contents '00 04'. Any idea what that could be? 02:25 BillyS I'm thinking maybe CONNCMD_DISCONNECT_PEER? 02:26 BillyS Oh, wait 02:26 BillyS Could it be TOCLIENT_ACCEPT_SUDO_MODE? 02:26 BillyS No, I don't think so 02:27 BillyS It's a client to server packet, so definitely not 02:35 BillyS Hmm 02:36 BillyS CONNCMD_DISCONNECT_PEER makes the most sense (its the only option I can find) but in context seems wrong 02:37 BillyS OOOH 02:37 BillyS I'll bet it's CONCMD_DISABLE_LEGACY 02:38 BillyS But ... hmm ... maybe ... gah 02:44 BillyS This is difficult 02:48 BillyS Well, it seems like it's a control packet 02:48 BillyS But there is no controltype 4 02:48 BillyS Only controltype 0, 1, 2, and 3 02:53 BillyS ..wait 02:53 BillyS THE DOCS LIED 02:53 BillyS #define CONTROLTYPE_ENABLE_BIG_SEND_WINDOW 4 10:59 Peppy hello 11:52 Krock \[°∪°]/ 11:52 Krock \(*⌣*)/ 12:00 ChimneySwift On 19:29 rubenwardy will do 19:31 Krock but sadly that won't alter the GUI style of Windows apps 20:29 rubenwardy seamless mode doesn't work :( 20:30 rubenwardy https://i.rubenwardy.com/fvMKt.png 20:31 Calinou I never understood how it works in VirtualBox 20:31 Calinou perhaps it's broken for years now? :P 20:31 Calinou (I mean, look at its 3D acceleration support, it never supported anything more than OpenGL 2.1) 20:32 * VanessaE pokes Calinou with a screwdriver 20:32 Jordach rubenwardy: https://i.imgur.com/Qx0AtbS.png 20:32 Jordach boom 20:32 rubenwardy works now 20:32 rubenwardy I clicked task view, which caused a redraw of the entire screen