Macht es Sinn/Wäre es möglich Abstimmungen zurückstellbar zu machen?
So, dass sie nicht am Rundenanfang, sondern erst im Laufe der Runde die Aktion getätigt werden muss?
Macht es Sinn/Wäre es möglich Abstimmungen zurückstellbar zu machen?
So, dass sie nicht am Rundenanfang, sondern erst im Laufe der Runde die Aktion getätigt werden muss?
Freedom's just another word for nothing left to lose
@Zulan: Zu folgendem Problem gibt es jetzt Neuigkeiten:
Tritt dies beim Verbindungsaufbau zum Spieler auf, ist der PBServer bis zum Restart nicht mehr erreichbar.Code:The network socket encountered an error and was closed. Disconnected.
Ein Tcp-Dump zeigt nun an, dass der Provider beim Spieler den Port Null benutzt!
Da ergibt sich sofort die Frage ob wir da nicht mit iptables eine Regel definieren können, die Anfragen auf Port Null auf eine andere Nummer ummappt?!
Das wäre auch zum Testen sinnvoll. Leider erlaubt mir mein Router nicht beim Portvorwarding auf Port Null zu mappen.
Ich habe es mir noch nicht angeschaut, aber es sollte möglich sein. Da das Spiel ja so robust ist, dass es auch damit klar kommt, wenn eine Teilmenge der Spieler gar nicht abstimmt, sollte man einen Button für einen Delay der Abstimmung einbauen können und später erneut die Anfrage erstellen.
Als Ergänzung zum vorherigen Post:
Auf Spielerseite, Vodafone/IPv4-Anschluss, verlässt das Datenpaket den Rechner noch mit dem normalen Port, 2056.
Auf dem Wege wird das dann auf Null abgewandelt. Das sollte meiner Meinung nach nicht vorkommen, da Null nur lokal verwendet wird um bei bind() automatisch eine freie Nummer zu erhalten.
Bleibt die Frage wer die Null einstreut. Ich glaube man kann für Null mit Iptables keine Regel erstellen. Zumindest war ich bisher nicht erfolgreich.
Zitat von https://www.lifewire.com/port-0-in-tcp-and-udp-818145
Das ist ja absurd. Ist das auch noch reproduzierbar ? Oder ist das so ein 0.0015% Chance ding?
Zu iptables, was hast du probiert?
(Ich hab keine ahnung von iptables, nur manpage)Code:iptables -A INPUT -p udp --sport 0 -j REJECT
Source port 0 gibt es eigentlich nicht, das bedeutet es wird kein Antwortport angegeben. Da muss NAT ja vollkommen fehlgeschlagen sein.
Was mich zum natneg bringt - ist das eingerichtet? Da koennten wir mal testen ob ich da irgendwas sehe.Source Port is an optional field, when meaningful, it indicates the port
of the sending process, and may be assumed to be the port to which a
reply should be addressed in the absence of any other information. If
not used, a value of zero is inserted.
Achtung Spoiler:
Reproduzierbar in dem Sinne, dass in drei fehlgeschlagenen Versuchen der Port Null war und in anderen, erfolgreichen Login-Versuchen nicht. Der finale Test, bei dem ich selber Pakete mit Port null an einen PBServer sende war mir noch nicht gelungen, da ich mich auch erst in IPTables einlesen muss (oder mit Scapy ein Paket zusammenstelle )
Die Chance muss höher sein, da sich Charriu nicht sooo oft einloggt . Ob die Zuweisung des Ports Null durch einen Routerreset seinerseits zurückgesetzt wird haben wir nicht ausprobiert. Hätte den für Test guten Zustand zerstört.
Ich dumpe den Traffic vom Spiel derzeit mit und sehe dann bei seinem nächsten Login wie der sport-Wert aussieht.
Bevor ich was auf dem Server probiere wollte ich lieber erst auf dich warten. Wäre dumm wenn ich uns z.B. durch ne fehlerhafte Regel aussperre.Zu iptables, was hast du probiert?
Ich vermute dass REJECT keinen Unterschied ausmacht, da eine REJECT-Regel ja nicht dazu führt, dass eine Antwort mit Ablehnung an den ISP zurück geht. Damit entspricht das (keine Antwort) dann dem normalen Verhalten.(Ich hab keine ahnung von iptables, nur manpage)Code:iptables -A INPUT -p udp --sport 0 -j REJECT
Aber zumindest stürzt dann zumindest der Server nicht ab
Edit: Habe ich mich geirrt: Bei REJECT wird der Absender informiert.
Ich hatte an einen Filter gedacht, der den SPORT überschreibt. Ich habe aber noch nicht gesehen wie ich beim überschreiben des Ports die Absende-IP behalten kann.
Folgendes sollte bei eingehenden Pakten den Absender mit den Dummy-Werten 127.0.0.56:4056 überschreiben:
In der zweiten Zeile stehen die Regeln für den Filter, in der dritten die Änderungen.Code:sudo iptables -t nat -A PREROUTING -p tcp \ -d $SERVER_IP --dport 2056 --sport 0 \ -j SNAT --to-source 127.0.0.56:4056
Für den Rückweg der Pakete fehlt mir dann leider die Info wie die ursprüngliche IP
des Absenders aussah:
Wenn man in beiden Regeln die Spieler-IP beibehalten könnte, wäre das Problem IHMO behobben. Man könnte alternativ mit dem Watchdog die Regeln dynamisch erstellen und dabei die passenden IP's des Spielers eintragen.Code:sudo iptables -t nat -A OUTPUT -p tcp \ -s $SERVER_IP --sport 2056 --dport 4056 \ -j DNAT --to-destination $SPIELER_IP:0
Als dritte Möglichkeit bliebe die Variante den Traffic bei sport=0 komplett durch den Watchdog schleifen :cz:
Eingerichtet?! Geändert habe ich nichts, ihn nur aus Versehen mal neu gestartet.Source port 0 gibt es eigentlich nicht, das bedeutet es wird kein Antwortport angegeben. Da muss NAT ja vollkommen fehlgeschlagen sein.
Was mich zum natneg bringt - ist das eingerichtet? Da koennten wir mal testen ob ich da irgendwas sehe.
Ich schlage vor ich erstelle als erstes mal eine Möglichkeit so ein Paket mit Port 0 zu senden und teste aus, ob ich den PBServer damit lokal zum „Absturz“ bekomme. Dann probiere ich deine REJECT-Regel aus und dann meine Regeln mit fixen IP's.
Geändert von Ramkhamhaeng (26. Oktober 2020 um 14:02 Uhr)
Ich bezweifele, dass diese Pakete durch umschreiben des sports zu "retten" sind. Ich glaube eher, da sollten wir uns drauf konzentrieren den PB Server zu retten / schuetzen, und die betroffenen Spieler muessen dann solange neu probieren / router neu starten / ??? bis mal ein ordentlicher sport ankommt.
Ich meinte damit, ob Charriu mit der aktuellen exe / hosts Datei laeuft, damit der richtige NatNeg verwendet wird.
Ja, probier das mal. Vielleicht sogar besser DROP als REJECT.
Achtung Spoiler:
Ich konnte jetzt verifizieren, dass es an 'sport=0' liegt. Der PBServer stürzt nicht bei einer beliebigen Nachricht mit dem Quellport ab, aber bei einer gültigen Nachricht, die ihn zu einer Antwort bewegt, schon.
Zur Dokumentation hier mal der Weg, mit dem man es mit Scapy reproduzieren kann.
1. Login-Versuch auf einem PB-Server mitschneiden (login.dump)
2. In Python dannCode:sudo tcpdump -C 1 -i any -w login.dump -n udp port 2056
Damit man Senden kann muss man python mit erweiterten Rechten starten.Code:import scapy from scapy.all import * session_good = rdpcap("login.dump") # Erstes Paket auf IP-Ebene kopieren. (Ethernet-Daten stören beim Senden später) bad = session_good[0].payload.copy() # Die Checksummen löschen, damit scapy gültige neue beim Senden berechnet bad.chksum = None # IP bad.payload.chksum = None # UDP # Port und (optional) Ziel anpassen bad.payload.sport = 0 bad.dst = "..." # PBServer-IP # Absenden send(bad, iface="...")
PB-Server weint dann
Edit: Jetzt weine ich Das hat zwar mal kurzzeitig lokal und dem Test-PB funktioniert, aber jetzt kann ich ihn nicht mehr abschießen.
Edit²: Aha, die src-IP muss eine andere sein
Code:Disconnected: The network socket encountered an error and was closed. Disconnected.
Als nächstes kann mit dem Test der Gegenmaßnamen beginnen
Geändert von Ramkhamhaeng (26. Oktober 2020 um 20:15 Uhr)
Also deine Ipfilter-Regel greift die Pakete raus und verhindert den Server-Crash. Allerdings geht das nur bei mir lokal (iptables 1.8.4), aber auf dem Server nicht
Als Tipp fand ich noch, dass man mit "-p udp -m udp" noch ein Modul für die Option nachladen muss, was aber auch nicht ging.Code:server#) sudo iptables -A INPUT -p udp --sport 0 -j REJECT iptables v1.8.5 (legacy): unknown option "--sport"
Nach Lesen von http://www.chiark.greenend.org.uk/~p...drop-vs-reject würde ich für REJECT plädieren. Aber ob der ISP daraus den Schluss zieht, es doch mal mit einem anderen Source-port zu probieren ist dann doch recht fraglich.
Also die „ideale Lösung” mit dem Ummappen des Traffics werde ich erst mal nicht weiter verfolgen.
Diese Befehle sollten das erledigen…
… aber die DNAT-Regel wird bei Port 0 verständlicherweise nicht erlaubt.Code:# Maskiere Quelle für Eingang auf Port 0 sudo iptables -t nat -A POSTROUTING -p tcp \ -d 192.168.0.99 --dport 2056 --sport 0 \ -j SNAT --to-source 127.0.0.56:4056 # Und der Rückweg.. sudo iptables -t nat -A OUTPUT -p tcp \ -s 192.168.0.99 --sport 2056 --dport 4056 \ -j DNAT --to-destination 192.168.0.42:0
Damit komme ich nicht zurück zur ungültigen Eingabe.iptables v1.8.4 (legacy): Port `0' not valid
Bleibt als Frage noch übrig wie wir die Blockier-Regel auf dem Server zum Laufen kriegen.
Ja, ich laufe mit der aktuellen exe sowie dem Wrapper. Ich hab auch alles mögliche an Ports freigegeben, was relevant sein sollte.
Weitere Faktoren. Ich bin nicht der einzige Spieler dem es passiert und es passiert natürlich nicht jede Runde. Ramk hat es aber wohl hinbekommen, dass der Server nicht abstürzt. Wenn das also wieder passiert, kann ich mal ausprobieren, was ein Neustart des Routers oder andere Sachen auf meiner Seite bewirken.
Damit wir die iptables-Filterregel auf dem Server setzen, kommen wir vermutlich nicht um einen Reboot herum. Ich finde zu dem Fehler sehr häufig die allgemeine Lösung, dass nach einem Kernelupdate auf einem Archsystem ein Reboot hilft, z.B. https://github.com/chef-cookbooks/iptables/issues/101
Die Tipps, /usr/bin/iptables-nft zu nutzen oder das Kernelmodul xt_nat zu laden (nicht installiert/vorhanden für 4.18.5) ging nicht.
Danke für eure Mühen
Freedom's just another word for nothing left to lose
Gute Neuigkeiten. Der Fix den Ramk eingebaut hat für Port 0 funktioniert. Ich hatte eben gerade wieder die gleichen Probleme beim Connecten. Aber diesmal stürzte der Server nicht ab und durch ein neu verbinden meines Routers konnte ich dann auch wieder connecten.