[0.12.29] Can't connect with too many mods

[scitor]

This is networking stuff...

Description:
The game seems to exchange all the installed mods on connection request. It does this within the first UDP packet it sends.
It seems that when you activate too many mods, this packet gets fragmented and not always fully transmitted -> you can't connect, even to a server with matching modlist.

How to reproduce:
Activate more mods than fit into a single UDP packet and try to connect to any server.

Expected behaviour:
Connecting to a game with any amount of mods should work to any network.

Current behaviour:
Connecting to a game with too many (client side) mods causes a connection failure in specific configurations
(Couldn't establish network communication with server.)

Tested on
0.12.26 - 0.12.29
Win (64, p.forward on router), Linux (32&64, wan interface & open ports)

more details

As long as all the mods names fit into one packet everything works fine.

As soon as there are too many, the packet gets fragmented, which gets filtered out underway (seems by my ISP) since it never reaches my server. (nothing in logs, not even tcpdump)

However, when I connect via LAN everything works despite wireshark still showing fragmented packets.
But in LAN there are no such filters and you can connect even with those packets. The game doesn't seem to need the rest of the packets, or whatever happens, it works like this.

Strange thing is, it works the other way around. When the server has too many mods and a vanilla client tries to connect the client shows a message with missing mods.

I have .pcap files on all scenarios, just tell me where to send them, but you can reproduce it fairly simply by yourself.

Just for completeness: I tested this with the default port and multiple other ports, on a lan machine with port forwarding (win) and on a dedicated with external ip on eth0 (linux-headless), all the same.
Everything (connecting & playing) works flawlessly with less mods.

even more details

As it turns out this is also related to my server's hoster. They seem to filter out these packets since they appear invalid.
I can start up a server for you to test, or I could ask the hoster for a firewall log (never did, don't know if they have anything like this).

When I try to host a factorio server with too many mods on their network, it doesn'twork, but it seems they only filter incoming packets.
Another thing I tested to confirm this:
When I host the same scenarios at home (DSL, linux router, win client) everything works.
With forwarded ports I can host from my windows machine and from the linux router it works just with opening the appropriate firewall (iptables) port, just like it should.

Honestly that never happened before to any server I have there (hoster is hetzner.de), and I wonder why they filter packets in the first place.
But since all the other services I ever had (many games, some steam, most of them UDP, like Factorio) are working and had never problems I suspect this should be fixed on the software side.
I even started an instance of another steam game which uses UDP only too, on the same port to test the connectivity and it worked just fine.

modlist

Advanced_Assembling_Machines_0.1.0.zip
Advanced-Drills_0.1.4.zip
advanced-logistics-system_0.2.12.zip
Advanced-turrets_1.0.0.zip
Advanced-Weaponry_0.3.0.zip
Aircraft_1.0.0.zip
air-filtering_0.3.2.zip
AmmoBox_0.3.0.zip
AmmoBox_Autorequest_0.0.1.zip
AutoDeconstruct_0.0.7.zip
Bergius_Process_0.1.0.zip
BetterMines_0.1.0.zip
BetterPersoPorts_0.1.0.zip
Burner_Generator_0.2.6.zip
burner_manufacturing_unit_0.1.2.zip
Cannon-Turret_0.0.1.zip
Combat_Trains_0.0.2.zip
Compression Chests_1.3.8.zip
Concrete_Lamppost_0.1.0.zip
Crafted Artifacts_1.2.0.zip
Electric Furnaces_1.3.1.zip
Equalizer_Chests_1.1.4.zip
ExtendedRobotic_0.1.0.zip
ExtraToolbelts_0.1.1.zip
FARL_0.5.17.zip
Fishing Pole_0.0.4.zip
Flare Stack_1.0.3.zip
Flow Control_1.1.0.zip
fluid-barrel_1.0.0.zip
Force Fields_1.0.6.zip
GhostTime_0.1.0.zip
gravestone-mod_1.0.3.zip
Honk_0.2.1.zip
K&L-Inserters_0.2.1.zip
KS_Power_0.1.1.zip
Landfill_2.1.7.zip
LogicBelt_0.3.1.zip
logistic-combinators_0.1.2.zip
Logistics Railway_1.0.4.zip
LongElectricBoiler_0.12.11.zip
LuaCombinator_0.0.2.zip
Military_Research_5_0.1.0.zip
Minable Rock_0.0.2.zip
Modular-Armor_0.0.21.zip
more-locomotives_0.2.1.zip
motrans_0.1.8.zip
Nucular_0.1.0.zip
Orbital Ion Cannon_1.0.9.zip
packager_0.2.1.zip
Plasma Shotgun Shells_1.0.1.zip
RailTanker_1.1.2.zip
Red_Assembling_Machine_0.1.1.zip
research-queue_1.2.4.zip
RoboCharge_0.0.4.zip
SignPosts_0.2.0.zip
SimpleTeleporters_0.0.5.zip
SmartSplitters_0.12.17.zip
SmartTrains_0.3.75.zip
Squeak Through_1.0.0.zip
Stainless Steel Wagon_1.0.0.zip
steel_manufacturing_unit_0.1.3.zip
Terraforming_0.12.3.zip
train-tracker_1.0.0.zip
Treefarm-AC_0.2.3.zip
Treefarm-Lite_0.3.2.zip
Ultra Inserters_1.0.0.zip
UpgradedElectric_1.0.2.zip
usefulSpace_0.2.2.zip
Warehousing_0.0.6.zip
weaponry_0.2.0.zip

...and yes, I know it's a ridiculous amount of mods, but this should still work
They don't interfere but even if they would, connecting should be possible.

[kovarex]

Does it happen always, or just randomly?
As with fragmented packet, the probability that all of the parts are transfered is lower.

[scitor]

Yes, I can reproduce it every time.

I've narrowed it down to a firewall rule:

Works:

Code: Select all

iptables -A INPUT -p udp -m udp --dport 29000 -j ACCEPT

Doesn't work:

Code: Select all

iptables -A INPUT -p udp -m udp --dport 29000 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

This works with any other service / game, and it works as long as the packets are valid.

[scitor]

Well, it seems to work with the experimental alpha version 0.12.30.

The problem doesn't seem to appear anymore, so this issue can be closed.