Imenser lokaler Netzwerktraffic durch die IPC zwischen Steam & TpF2

bionade24 · 13. März 2026

Hallo,

ich habe festgestellt, dass während Tpf2 läuft bei mir ~50GiB Netzwerktraffic die Stunde durch das loopback interface gehen. Hauptmenü oder Spielstand machen keinen Unterschied. Da Steam darüber IPC macht, bin ich mir ziemlich sicher, dass es IPC zwischen Steam & Tpf2 ist. Warum das bei TpF2 so Berserker geht und bei anderen Linux-nativen spielen nicht, kann ich allerdings nicht erklären. Da aber ständig TCP-Verbindungen geöffnet & wieder geschlossen werden (siehe tcpdump & perf report screnshot), gehe ich davon aus, dass es ein Bug ist. Habe Tpf2 nochmal auf einem anderen Gerät ohne Mods oder irgendwelche Sondereinstellungen installiert, ~~selbes Problem.~~ Hoher Traffic nur im Hauptmenü, nicht im geladenen Spiel & um den soll es hier erstmal nicht gehen.

Ist das Problem bekannt bzw. falls ihr auf Linux via Steam spielt, könntet ihr bitte überprüfen ob dies bei euch auch so ist? Einfach mit b(py)top schauen ob der Netzwerktraffic auf dem lo Netzwerkinterface nach dem Spielstart massiv nach oben schießt.

Unten links im Screenshot kann der Netzwerktraffic gesehen werden.

tcpdump von lo interface (20s Tpf2 und schon so viel Pakete, dass das Logfile zstd komprimiet zu groß für hier ist, entpackt sinds 270MiB)

Übersicht vom perf tool:

Code

Samples: 207K of event 'cpu/cycles/P', Event count (approx.): 208665074754
  Children      Self  Command          Shared Object                                   Symbol
+   72,33%     0,00%  TransportFever2  libc.so.6                                       [.] 00007fb27d7292bc                                                                                                                                                                     ◆
+   72,33%     0,00%  TransportFever2  libc.so.6                                       [.] 0x00007fb27d6a597a                                                                                                                                                                   ▒
+   72,33%     0,00%  TransportFever2  libstdc++.so.6.0.34                             [.] 0x00007fb27d8e55a4                                                                                                                                                                   ▒
+   70,81%     0,00%  TransportFever2  TransportFever2                                 [.] 0x0000563b802df407                                                                                                                                                                   ▒
+   70,69%     0,00%  TransportFever2  libc.so.6                                       [.] pthread_once                                                                                                                                                                         ▒
+   70,69%     0,00%  TransportFever2  TransportFever2                                 [.] 0x0000563b7daf1172                                                                                                                                                                   ▒
+   70,58%     0,00%  TransportFever2  libc.so.6                                       [.] 0x00007fb27d6aada4                                                                                                                                                                   ▒
+   70,57%     0,00%  TransportFever2  TransportFever2                                 [.] 0x0000563b7daf0e22                                                                                                                                                                   ▒
+   31,79%     0,00%  TransportFever2  TransportFever2                                 [.] 0x0000563b7dd580b5                                                                                                                                                                   ▒
+   18,77%     0,00%  TransportFever2  TransportFever2                                 [.] 0x0000563b7dd6177d

Alles anzeigen

Reingezoomt auf syscalls beim obersten call:

Code

Samples: 207K of event 'cpu/cycles/P', Event count (approx.): 208665074754, DSO: [kernel.kallsyms]
  Children      Self  Command          Symbol
+    2,67%     0,06%  TransportFever2  [k] do_syscall_64                                                                                                                                                                                                                        ◆
+    2,65%     0,01%  TransportFever2  [k] entry_SYSCALL_64_after_hwframe                                                                                                                                                                                                       ▒
+    0,75%     0,02%  TransportFever2  [k] __tcp_transmit_skb                                                                                                                                                                                                                   ▒
+    0,71%     0,02%  TransportFever2  [k] __ip_queue_xmit                                                                                                                                                                                                                      ▒
+    0,68%     0,01%  TransportFever2  [k] __x64_sys_sendto                                                                                                                                                                                                                     ▒
+    0,65%     0,01%  TransportFever2  [k] tcp_sendmsg                                                                                                                                                                                                                          ▒
+    0,64%     0,02%  TransportFever2  [k] tcp_sendmsg_locked                                                                                                                                                                                                                   ▒
+    0,62%     0,01%  TransportFever2  [k] ip_output                                                                                                                                                                                                                            ▒
+    0,58%     0,01%  TransportFever2  [k] ip_finish_output2                                                                                                                                                                                                                    ▒
+    0,57%     0,01%  TransportFever2  [k] handle_softirqs                                                                                                                                                                                                                      ▒
+    0,56%     0,01%  TransportFever2  [k] __dev_queue_xmit                                                                                                                                                                                                                     ▒
+    0,55%     0,02%  TransportFever2  [k] __x64_sys_futex                                                                                                                                                                                                                      ▒
+    0,55%     0,02%  TransportFever2  [k] tcp_write_xmit                                                                                                                                                                                                                       ▒
+    0,54%     0,00%  TransportFever2  [k] __tcp_push_pending_frames                                                                                                                                                                                                            ▒
+    0,53%     0,01%  TransportFever2  [k] asm_sysvec_apic_timer_interrupt                                                                                                                                                                                                      ▒
+    0,52%     0,02%  TransportFever2  [k] __local_bh_enable_ip

Alles anzeigen

Grüße

Oskar

**eis_os** · 13. März 2026

Im Hauptmenü oder im Spiel?

Es könnte intern die Nachfrage bei File IO sein, sprich Mapping zwischen dem virtuellen Filesystem und dann zu einem bestimmten Steam Mod. (Workshop ID zum Verzeichnis Nachfrage)

Dann gäbe es noch die Steam Achievements...

Meine Mini Testmap mit CommonAPI2 zeigt da so 179KiB/s da gerade an.

Wird es denn weniger wenn du ein Spielstand ohne Workshop Mods startest?

bionade24 · 13. März 2026

Sowohl im Hauptmenü als auch weiterhin während des Spielens, hab den Beitrag entsprechend editiert.

Auf dem 2. Gerät, von welchem tcpdump & der Screenshot sind, ist kein einziger Mod abboniert, alles rausgefiltert. Verhalten genau gleich zu meinem Desktop mit vielen Mods.

Steam Offline-Modus ändert auch nix.

**eis_os** · 13. März 2026

Ja im Hauptmenü hab ich so 37MiB/s, im Spiel viel weniger.

Ich hab mal mir den Spaß gemacht und den call zu UI::CGameUI::CheckAchievements via debugger raus genommen, das hat nix geändert.

Alternativ könnte es auch noch modio Kram sein...

bionade24 · 13. März 2026

Danke für deine beiden Tests.

Hat mod.io irgendeinen extra Prozess mit dem Tpf2 IPC machen könnte? Ist ja kein Netzwerktraffic nach "draußen" über eth*, sondern nur lokal auf lo.

**eis_os** · 13. März 2026

Mir fällt da gerade nichts ein. Das müsste alles im selben Process laufen und daher kein lo traffic machen.

Das SteamOverlay hab ich bei mir abgeschaltet, kann also auch eigentlich nicht der Steam Browser sein.

bionade24 · 13. März 2026

Steam overlay habe ich auch abgeschaltet, ich hab auch mal veruscht LD_PRELOAD zu überschreiben, sodass gameoverlayrender.so überhaupt nicht reingeladen wird. Hilft beides nix. Hatte vergessen bei tcpdump mir den Inhalt der Pakete anzuschauen, bei einigen kommt im kodierten Binärmatch immer wieder Pfade zu workshopmods vor. Werde gleich mal probieren statt die Workshop mods nur zu deaktivieren, wirklich alle zu deabbonieren.

Dr.Dosenbier · 13. März 2026

Warum lange suchen ? Zieh doch einfach mal für 5 Min den LAN-Kabel oder deaktiviere das W-Lan

Alle Apps und Co die dann rumschreien: "... ich hab und brauche eine I-Netverbindung" sind dann die Übeltäter 😉

Kirsche · 13. März 2026

Das kann ja nur an steam liegen.

Ich nutze TPF2 nicht über steam und habe daher auch NULL traffic. Da ich modio innerhalb TPF nicht nutze, kommt daher auch nichts.

Ich finde das schon arg bedenklich was da so an traffic statt findet. Das Spiel selbst benötigt ihn ja offensichtlich nicht.

TPF2 selbst versucht nichtmal eine Verbindung aufzubauen.

**eis_os** · 13. März 2026

Ihr versteht schon, das LO Interface der Loopback Adapter ist um TCP Verbindungen zwischen Userprozesse zu ermöglichen.

Naja, ein dump wäre nur aussagekräftig während des Spiels.
Während man im Hauptmenü ist, lädt TPF2 ja ggf. noch Mods per Workshop herunter, der Traffic wäre also normal. Auch das an der Stelle TPF2 nach dem Mapping zwischen IDs und Dateipfade macht.

(Das macht CommonAPI2 ja auch sobald ne neue Liste von Mods irgendwie aktiv ist)

Bei einer Mod wird halt an verschiedenen stellen, auch in der CommonAPI2 schlussendlich eine Funktion aufgerufen, die aus der Workshop ID dann den Pfad erstellt. Das macht im Endeffekt dann die Steam API schlussendlich.

Ich könnte da wohl via CommonAPI2 einen Cache einbauen, keine Ahnung ob das sinnvoll ist. Aber was ich nicht verstehe, warum es keine Änderung zwischen einen Savegame mit Mods und ohne Steam Mods gibt.

Unter Einstellungen mal den Debug Modus von UG abstellen, speichern und Spiel komplett neu starten. (wichtig! und dann den traffic anschauen.)

Die UG LUA Console hat auch ne Funktion die irgendwie ne Modliste nutzt, ggf. gibt es dort Probleme,

bionade24 · 14. März 2026

Vor dem Deabbonieren aller bereits deaktivierten (2. Gerät) Workshop-Mods ist mir aufgefallen, dass ich auf dem 2. System mir nur den Traffic während das Hauptmenü läuft angeguckt habe. Sobald das eigentliche Spiel läuft habe ich die gleichen Werte wie eis_os. Ich kann es also nicht reproduzieren. Das ist mir leider durchgerutscht. Entschuldigung für die Verwirrung.

Wird ein Spielstand ohne irgendwelche Mods geladen, dann sind im Spiel nur noch konstant 50 Mib/s, während es ja wohl eher <1Mib/s sein sollte. Als ich dann in Steam alle Workshop-Mods deaktiviert hatte, hatte ich mit dem Modlosen Spielstand nur noch 200-700 Kib/s traffic. Debug Modus an/aus hat nix gebracht.

Wenn ich mehr Zeit & Geduld habe, werde ich mal tcpdumps mit Inhalt der TCP-Pakete von Hauptmenü, dem 200 Kib/s & dem 50 Mib/s szenario mit nem fuzz diff Skript, dass ich mir mal geschrieben hatte, vergleichen. Eventuell sind da aufschlussreiche Muster drin.

**eis_os** · 14. März 2026

Also ich hab mal ein pcap (nur während des Spiels) in Wireshark geladen, das sieht mir während des Spiels nach einer Workshopliste aus. Zumindest das große Datenpaket.

Die ModRep hat ne std::list<std::pair<int, std::string>> m_workshopId2path; Liste, also daher sollte es nicht kommen.

Spaßeshalber hab ich - da ich Puzzle liebe - mal ein commonapi._native.dampf.getMods() gemacht,

und finde so auch die Daten TCP Steam wieder, wie Timestamp oder sizeOnDisk

Code

  {
    folder = "/ZEUGS/Games/Steam/steamapps/workshop/content/1066780/1957631242",
    handle = 1957631242,
    sizeOnDisk = 9996549,
    timestamp = 1676107902,
  },

Sprich es gibt vom Anschein nach zumindest bei mir hier ein regen Datenaustausch zwischen Steam Ciient und Steam API im Spiel.

Ob das durch UG verursacht hat, keine Ahnung.

Wireshark:

Code

0000479A  1a 00 00 00                                        ....
0000479E  01 20 01 00 00 00 ba 19  10 20 1c 47 10 00 (0a 15   . ...... . .G....
000047AE  af 74 00 00 00 00) 6f a6  73 24                     .t....o. s$
    0008967C  05 00 00 00                                        ....
    00089680  0b 05 00 00 00                                     .....
000047B8  1e 00 00 00                                        ....
000047BC  01 20 01 00 00 00 45 64  99 9d 1c 47 10 00 (0a 15   . ....Ed ...G....
000047CC  af 74 00 00 00 00) 00 08  00 00 03 28 ff a1         .t...... ...(..
    00089685  0e 08 00 00                                        ....
    00089689  0b 01 {05 89 98 00 00 00  00 00} 2f 5a 45 55 47 53   ........ ../ZEUGS
    00089699  2f 47 61 6d 65 73 2f 53  74 65 61 6d 2f 73 74 65   /Games/S team/ste
    000896A9  61 6d 61 70 70 73 2f 77  6f 72 6b 73 68 6f 70 2f   amapps/w orkshop/
    000896B9  63 6f 6e 74 65 6e 74 2f  31 30 36 36 37 38 30 2f   content/ 1066780/
    000896C9  31 39 35 37 36 33 31 32  34 32 00 00 00 00 00 00   19576312 42......
    000896D9  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
...
    00089E89  00 00 00 00 00 00 00 00  00 00 [7e 60 e7 63]         ........ ..~`.c

Alles anzeigen

() = WorkshopID (bzw. Handle)
{} = sizeOnDisk

[] = timeStamp

-edit-

Bin mir nun ziemlich sicher woran es liegt. Es liegt an dem neuen ModHub von UG.

Keine Ahnung was UG sich dabei gedacht hat... da gibt es halt einen Thread der ständig die Steam IPC nutzt um die ModHub Daten zu füttern.

Nur der Thread läuft auch während eines Spiels.

Urban Games macht halt Urban Games Sachen...

bionade24 · 14. März 2026

Danke für deine Nachforschungen! Macht es Sinn, UG darüber nen Bugreport zu schreiben ? Der Bug könnte ja eventuell auch noch in Tpf3 drinnen sein.

P8_2401_Coeln · 14. März 2026

Zitat von Kirsche

Ich nutze TPF2 nicht über steam und habe daher auch NULL traffic.

Kann ich nur bestätigen.

**eis_os** · 16. März 2026

Keine Ahnung ob sie einen Bugreport haben wollen, manche Nutzer hatten einen Erfolg.

Ich hab mir das mal näher angeschaut und UGs Code funktioniert so:

Code

  while ( !a1->m_modhub_steambackend->mdata->thread_should_exit )
  {
    mdata = a1->m_modhub_steambackend->mdata;
    if ( !mdata->disableSleep )
    {
      sched_yield();
      requested_time.tv_sec = 0LL;
      requested_time.tv_nsec = 200000000LL;
      while ( nanosleep(&requested_time, &requested_time) == -1 && *__errno_location() == 4 )
      {
        ;
      }
    }
    modhub::SteamModHubBackend::Init::lambda_fn(mdata);
    SteamAPI_RunCallbacks();
  }

Alles anzeigen

disableSleep = 1 im Hauptmenü und wird im Spiel 0, d.h. UG bremst den thread per nanosleep aus.
Wenn ich da bei Sekunden ne 2 ms machen, mein 8600G ist mit den par Kb unterfordert so das man nix im Spiel merkt...

Ob das daher Spiel relevant ist, keine Ahnung. Es könnte sein, wenn man viele Mods im Abo hat, das sich das dann doch summiert.

Wer Linux und CommonAPI2 nutzt und alle 200ms ein Frame Einbrauch verzeichnet, dem könnte ich ggf testweise einen Patch dafür schreiben, das im Spiel nur noch nanosleep ausgeführt wird.

Alternativ Versuchsweise, dieses im Speicher / TransportFever

48 C7 45 D0 00 00 00 00 48 C7 45 D8 00 C2 EB 0B

durch dieses hier ersetzen:

48 C7 45 D0 14 00 00 00 48 C7 45 D8 00 C2 EB 0B

Das würde dann nanosleep 20ms warten lassen..

-edit-

PS: Das passiert natürlich nur mit der Steam Version. Wie viele Mods Ihr im Spielstand aktiviert habt ist unerheblich. Die Anzahl der im Workshop abonnierten Mods ist ausschlaggebend. Sprich auch eine leere Map ohne Mods. (Wie am Anfang, hat man dann halt ~8MB/s zusätzlichen Traffic intern. (Also Loopback zurm Steamclient, nicht nach außen)

Graf Romanic · 16. März 2026

Sieht mir aber ganz stark nach einem Busy-Waiting im Spiel zur Synchronisation mit dem Steam-Backend aus. Könnte auch wieder unangenehme Racing-Condition verursachen sofern man es ändert. Ist also mit ziemlicher Vorsicht zu verwenden.

**eis_os** · 16. März 2026

Da ich meinen eigenen Dampf Client API geschrieben habe, hab ich gute Chancen das ich das nicht schlimmer mache als es gerade ist und ich weiß was ich tue

Der ModHub ist das neue Teil Ingame ModBrowser. Ich kann mir auch denken warum UG das so gemacht hat, um oben Links eine % Anzeige darzustellen.

Laut SteamSDK Beschreibung kann man sonst nur auf eine Status Änderung via callback reagieren.
Das wäre https://partner.steamgames.com…ISteamUGC#ItemInstalled_t

Ich kann gefahrlos modhub::SteamModHubBackend::Init::lambda_fn(mdata); aus dem Spiel entfernen, bzw. das Interval ändern.
Man bekommt halt kein Feedback bzw. erst wenn man im Menü wieder ist oder nur alle X ms. Wie ich schon oben ausgeführt habe, hat das keine ModRep Verbindung,

Quasi macht die lambda Funktion nichts anderes als ständig die Steam API nach der Liste:

Mutex
ISteamUGC->GetNumSubscribedItems()
Vector allozieren für die IDs
ISteamUGC->GetSubscribedItems()
Mutex
SteamModHubBackend->flathashmap reallozieren
Für alle IDs dann:
- ISteamUGC->GetItemState()
- ISteamUGC->GetItemInstallInfo() ggf. Progress?
- Alle die Daten in eine flathashmap schreiben

D.h. es muss dann nach jedem Durchlauf mindestens 8 Bytes * ModIds für die Ids alloziert werden im Thread

Via TCP müssen mindestens jeweils ein Datenpaket zum SteamClient gesendet werden, und die Daten dann abgeholt werden.

Bei 2000 Mods hast dann schon mal 2002 Roundtrips zum Kernel, lecker.. Ach und GetItemInstallInfo holt auch den Pfad ab, wenn wir den bei 512Bytes einstellen, haben wir dann alle 200 ms 1MB durch den Kernel gejagt für nicht Spielrelevantes.

Außerdem, gibt es für alle solche Sachen einen Schalter in CommonAPI2, man muss den Fix nicht aktivieren, wenn man nicht möchte.

bionade24 · 17. März 2026

Zitat von eis_os

Alternativ Versuchsweise, dieses im Speicher / TransportFever
48 C7 45 D0 00 00 00 00 48 C7 45 D8 00 C2 EB 0B
durch dieses hier ersetzen:

48 C7 45 D0 14 00 00 00 48 C7 45 D8 00 C2 EB 0B
Das würde dann nanosleep 20ms warten lassen..

Ich kann den hexstring weder im Tpf2 binary, den mitgelieferten libs noch dem gedumpten Prozess finden.

Habs mit hexer & mit grep -obUaP '\x48\xC7\x45\xD0\x00\x00\x00\x00\x48\xC7\x45\xD8\x00\xC2\xEB\x0B' * versucht.

**eis_os** · 18. März 2026

Steam Build 35924 Linux.Build, hier via edb: TransportFever2

Auch per Hex Editor auffindbar, Okteta mag nur keine Abstände:

48C745D00000000048C745D800C2EB0B

Keine Ahnung... das Fragment ist auch so in Build 35915 vorhanden...

bionade24 · 19. März 2026

Habe die Änderung jetzt hinbekommen. Im geladenen Spiel habe ich jetzt nur noch 65KiB/s ! Vielen Danke für die Hilfe.

Imenser lokaler Netzwerktraffic durch die IPC zwischen Steam & TpF2

Willkommen in der Transport Fever Community

bionade24 19. März 2026

Teilen

Tags