Add Forge handshake support (#88) #134

iceiix · 2019-05-04T02:17:02Z

Allow connecting to Forge servers for #88 1.7.10: Forge handshake support

iceiix · 2019-05-04T02:18:15Z

Doesn't complete the Forge handshake yet, makes some progress but have to finish parsing it, may want to refactor with the packet parsing code to reuse the same logic.

iceiix · 2019-05-04T21:08:02Z

Reworked parsing to use Serialization, gets this far:

about to parse id=3f, dir=Clientbound state=Play
packet = Some(PluginMessageClientbound_i16(PluginMessageClientbound_i16 { channel: "REGISTER", data: [70, 77, 76, 124, 72, 83, 0, 70, 77, 76, 0, 70, 77, 76, 0, 70, 79, 82, 71, 69] }))
about to parse id=3f, dir=Clientbound state=Play
packet = Some(PluginMessageClientbound_i16(PluginMessageClientbound_i16 { channel: "FML|HS", data: [0, 2, 0, 0, 0, 0] }))
Received plugin message: channel=REGISTER, data=[70, 77, 76, 124, 72, 83, 0, 70, 77, 76, 0, 70, 77, 76, 0, 70, 79, 82, 71, 69]
Received plugin message: channel=FML|HS, data=[0, 2, 0, 0, 0, 0]
FML|HS ServerHello: fml_protocol_version=2, override_dimension=Some(0)
FML|HS msg=ServerHello { fml_protocol_version: 2, override_dimension: Some(0) }
Received FML|HS ServerHello 2 Some(0)
Sending plugin message: channel=REGISTER, data=[70, 77, 76, 124, 72, 83, 0, 70, 77, 76, 0, 70, 77, 76, 124, 77, 80, 0, 70, 77, 76, 0, 70, 79, 82, 71, 69]
Sending plugin message: channel=FML|HS, data=[1, 2]
Sending plugin message: channel=FML|HS, data=[2, 0]
about to parse id=3f, dir=Clientbound state=Play
packet = Some(PluginMessageClientbound_i16(PluginMessageClientbound_i16 { channel: "FML|HS", data: [2, 4, 3, 70, 77, 76, 10, 55, 46, 49, 48, 46, 57, 57, 46, 57, 57, 8, 107, 105, 109, 97, 103, 105, 110, 101, 3, 48, 46, 50, 5, 70, 111, 114, 103, 101, 12, 49, 48, 46, 49, 51, 46, 52, 46, 49, 54, 49, 52, 3, 109, 99, 112, 4, 57, 46, 48, 53] }))
Received plugin message: channel=FML|HS, data=[2, 4, 3, 70, 77, 76, 10, 55, 46, 49, 48, 46, 57, 57, 46, 57, 57, 8, 107, 105, 109, 97, 103, 105, 110, 101, 3, 48, 46, 50, 5, 70, 111, 114, 103, 101, 12, 49, 48, 46, 49, 51, 46, 52, 46, 49, 54, 49, 52, 3, 109, 99, 112, 4, 57, 46, 48, 53]
FML|HS msg=ModList { mods: [Mod { name: "FML", version: "7.10.99.99" }, Mod { name: "kimagine", version: "0.2" }, Mod { name: "Forge", version: "10.13.4.1614" }, Mod { name: "mcp", version: "9.05" }] }
about to parse id=0, dir=Clientbound state=Play

This is sending an empty list of mods. Modded Forge server would let in with no (other) server mods installed. Connecting to a server with more mods installed, get kicked with:

packet = Some(Disconnect(Disconnect { reason: Text(TextComponent { text: "Mod rejections...

To send the right client mods, could capture from the server list same way currently used for the protocol version detection.

…eHandler" This reverts commit f91f592.

… from_message

… Mod>

iceiix · 2019-05-04T23:17:34Z

Rebased after fixing squash merge of #132. The problem of connecting the Forge mods from the server ping to the client ModList handshake runs into the same problem as #114 #90, how to share this piece of data between the two parts of code. Ugly workaround put in place before was to write to server_versions.json in src/screen/server_list.rs tick(), and read server_versions.json in src/main.rs connect_to(). Now we need the mods list, more data to stuff in here, but it is not a good design either way. Tying the server list to vital information to connect breaks the command-line server connection support attempt (#114 #90), maybe it is time to re-ping the server in connect_to() instead of relying wholly on the server list? Would this make it easier to bridge the mods list data? It should be possible to share all this data between threads as needed, avoiding the second ping (even though that may be a good idea later for #114 #90, again). Rust supports message passing through mpsc to do this:

https://doc.rust-lang.org/book/ch16-02-message-passing.html

… list; remove server_versions.json

…here

iceiix · 2019-05-06T00:48:24Z

Connects to an FTB:IE 3.0.2 server:

https://www.feed-the-beast.com/projects/ftb-infinity-evolved

FTBInfinityServer_3.0.2.zip

but soon panics, without crashing:

Received plugin message: channel=BloodMagic, data=[11, 0, 0, 0, 11, 0, 0, 0, 0, 0, 0, 0, 1]
Received plugin message: channel=BloodMagic, data=[11, 0, 0, 0, 11, 0, 0, 0, 0, 0, 0, 0, 1]
Received plugin message: channel=thaumcraft, data=[0, 255, 255, 255, 46, 0, 0, 0, 112, 0, 194]
Received plugin message: channel=MrTJPCoreMod, data=[1, 255, 255, 255, 163, 0, 0, 0, 80, 0, 0, 0, 231, 0, 231]
Received plugin message: channel=FOR, data=[10, 223, 253, 255, 255, 15, 71, 177, 1, 10]
Received plugin message: channel=FOR, data=[10, 223, 253, 255, 255, 15, 71, 176, 1, 10]
Received plugin message: channel=thaumcraft, data=[16, 0, 0, 53, 54, 0, 0, 0, 0]
Received plugin message: channel=FOR, data=[10, 223, 253, 255, 255, 15, 71, 170, 1, 10]
Received plugin message: channel=FOR, data=[10, 223, 253, 255, 255, 15, 71, 169, 1, 10]
Received plugin message: channel=FOR, data=[10, 223, 253, 255, 255, 15, 71, 172, 1, 10]
Received plugin message: channel=FOR, data=[10, 223, 253, 255, 255, 15, 71, 171, 1, 10]
Received plugin message: channel=FOR, data=[10, 223, 253, 255, 255, 15, 71, 174, 1, 10]
Received plugin message: channel=FOR, data=[10, 223, 253, 255, 255, 15, 71, 173, 1, 10]
Received plugin message: channel=FOR, data=[10, 223, 253, 255, 255, 15, 71, 175, 1, 10]
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Error("EOF while parsing a value", line: 1, column: 0)', src/libcore/result.rs:997:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::continue_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::result::unwrap_failed
   9: <stevenarella::format::Component as stevenarella::protocol::Serializable>::read_from
  10: stevenarella::protocol::packet::packet_by_id
  11: stevenarella::protocol::Conn::read_packet

iceiix · 2019-05-06T01:27:21Z

panic in UpdateSign_u16?

about to parse id=33, dir=Clientbound state=Play
thread '' panicked at 'called Result::unwrap() on an Err value: Error("EOF while parsing a value", line: 1, column: 0)', src/libcore/result.rs:997:5

https://wiki.vg/index.php?title=Protocol&oldid=6003#Update_Sign

steven $ hexdump -C last-packet 
00000000  33 ff ff fe c1 00 53 00  00 00 a6 00 0a 41 70 6f  |3.....S......Apo|
00000010  74 68 65 63 61 72 79 00  00                       |thecary..|
00000019

Adds support for connecting to 1.7.10 modded servers using the FML|HS protocol: https://wiki.vg/Minecraft_Forge_Handshake * Handle client-bound plugin message packets * Parse FML|HS plugin channel messages * Add ModList serialization using Mod serializable, LenPrefixed<VarInt, Mod> * Save forge_mods from server ping and send in FML|HS ModList packet * Show Forge mod count in server ping listing * Send acknowledgements, completing the handshake * Add VarShort to custom payload len prefix replaces i16, fixes OOM on large modded servers * Add custom CoFHLib's SendUUID packet -26 See explanation at SpigotMC/BungeeCord#1437 This packet is defined by CoFHLib in https://github.com/CoFH/CoFHLib/blob/1.7.10/src/main/java/cofh/lib/util/helpers/SecurityHelper.java#L40 Fixes thread '' panicked at 'bad packet id 0xffffffe6 in Clientbound Play' with FTB:IE

Adds support for connecting to Forge servers from 1.8.9 up to 1.12.2. (1.7.10 was already supported with #134 #88) Tested on: - 1.8.9 + forge 11.15.1.2318 + ironchest - 1.10.2 + forge 12.18.3.2511 + ironchest - 1.11.2 + forge 13.20.1.2588 + ironchest - 1.12.2 + forge 14.23.5.2837 + ironchest Changes: * Parse and handle FmlHs::RegistryData packet for 1.8+ * Fix RegistryData acknowledgement phase WaitingServerComplete * Fix acknowledgement phase for 1.7.10 ModIdData too, somehow it worked accidentally * Append \0FML\0 to end of server hostname if Forge mods detected https://wiki.vg/Minecraft_Forge_Handshake#Connection_to_a_forge_server

The first in support for modded content, a simple custom block: "rockwool" from the Thermal Expansion and Thermal Foundation mods for Forge: https://ftb.gamepedia.com/Rockwool_(Thermal_Expansion_3) This makes use of the Forge handshake (#88 #134 #144), matching the mod block names from the negotiation to numeric identifiers in the world to steven_blocks. Rockwool was chosen due to ease of implementation, it looks like wool from vanilla (except is fire-proof), and by supporting it the groundwork necessary is laid for more sophisticated mod support. Tested with Thermal Expansion on 1.7.10, 1.10.2 (FTB Beyond), and 1.12.2 Forge servers. * Add `modid` macro token, skipped from vanilla mappings * Add ThermalExpansionRockwool block (1.7.10) * Register modded blocks by modid->[data], and lookup block metadata * Save block IDs from ModIdData/RegistryData to World modded_block_ids * Add namespaced mod ids for ModIdData, \u{1}=block \u{2}=item * Add ThermalFoundation's Rockwool (1.12.2)