| Time |
Nick |
Message |
| 00:25 |
|
FrostRanger joined #minetest-hub |
| 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:00 |
|
FrostRanger joined #minetest-hub |
| 02:07 |
|
behalebabo joined #minetest-hub |
| 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 |
| 03:14 |
|
Ruslan1 joined #minetest-hub |
| 06:31 |
|
rud0lf joined #minetest-hub |
| 07:45 |
|
Jordach joined #minetest-hub |
| 09:01 |
|
Jordach joined #minetest-hub |
| 09:25 |
|
calcul0n joined #minetest-hub |
| 10:43 |
|
aerozoic joined #minetest-hub |
| 10:48 |
|
Fuchs joined #minetest-hub |
| 10:59 |
|
Peppy joined #minetest-hub |
| 10:59 |
Peppy |
hello |
| 11:17 |
|
Jordach joined #minetest-hub |
| 11:50 |
|
Krock joined #minetest-hub |
| 11:52 |
Krock |
\[°∪°]/ |
| 11:52 |
Krock |
\(*⌣*)/ |
| 12:00 |
ChimneySwift |
<o/ |
| 12:00 |
|
Fixer joined #minetest-hub |
| 12:00 |
Krock |
hi Fixer |
| 12:00 |
Krock |
and ChimneySwift |
| 12:01 |
ChimneySwift |
XD hi Krock |
| 12:06 |
|
Fixer_ joined #minetest-hub |
| 12:17 |
|
twoelk joined #minetest-hub |
| 12:43 |
|
CWz joined #minetest-hub |
| 13:04 |
|
T4im joined #minetest-hub |
| 13:42 |
|
Jordach joined #minetest-hub |
| 14:03 |
|
Gael-de-Sailly joined #minetest-hub |
| 14:31 |
|
Ruslan1 joined #minetest-hub |
| 14:39 |
|
sniper338 left #minetest-hub |
| 14:40 |
Krock |
merging https://github.com/minetest-mods/framedglass/pull/2 soon |
| 14:57 |
Krock |
200 OK |
| 15:05 |
|
DI3HARD139 joined #minetest-hub |
| 15:39 |
rubenwardy |
we've ran out of stickers! |
| 15:40 |
rubenwardy |
there's 2 left, but of course no one is taking them due to English politefulness |
| 15:40 |
rubenwardy |
s/English //g |
| 15:53 |
|
IhrFussel joined #minetest-hub |
| 16:16 |
|
_Xenon joined #minetest-hub |
| 17:13 |
|
Jordach joined #minetest-hub |
| 17:41 |
|
Jordach joined #minetest-hub |
| 18:25 |
|
FrostRanger joined #minetest-hub |
| 19:13 |
|
garywhite joined #minetest-hub |
| 19:25 |
|
garywhite joined #minetest-hub |
| 19:27 |
rubenwardy |
yay, Windows 10 has finished installing bugs https://i.rubenwardy.com/h9ICi.png |
| 19:27 |
rubenwardy |
(installing in a VM) |
| 19:28 |
Krock |
Same icons as in Windows Vista/7 I think |
| 19:29 |
Krock |
rubenwardy: Seamless Mode -> On |
| 19:29 |
rubenwardy |
will do |
| 19:30 |
|
garywhite joined #minetest-hub |
| 19:31 |
Krock |
but sadly that won't alter the GUI style of Windows apps |
| 19:57 |
|
paramat joined #minetest-hub |
| 20:09 |
|
paramat left #minetest-hub |
| 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 |
| 21:11 |
|
Ruslan1 joined #minetest-hub |
| 21:28 |
|
garywhite joined #minetest-hub |
| 22:41 |
|
garywhite1 joined #minetest-hub |
| 23:21 |
|
GreenDimond joined #minetest-hub |
