[linux] Routing/bind problemen (virtuele netwerkkaart?) argh

[Tim]

Niet al te lang gelden werd ik gewezen op het bestaan van meerdere cursors op één X instantie. Daar moet uiteraard gebruik van gemaakt worden, en wat beter dan tegen elkaar te gamen (via wine, ieder een eigen monitor). Niet geheel onverwacht proberen spellen als je ze twee keer opstart ook 2 keer een port te binden. Ik heb daar een kleine LD_PRELOAD library voor gemaakt die een IP forceert. Met of zonder deze hack is dat genoeg voor de meeste spellen. Het probleem is Civilization 5:

Alle andere games werken omdat ze een 'connect to ip' functie hebben, maar Civ 5 niet. Bij het het aanmaken van een game bind Civ port 62900 (udp). Als de andere instantie een game zoekt dan stuurt deze een broadcast naar het lokale netwerk. Hier gaat het gebruik van de wrapper al mis, want een socket die gebind is op een ip luistert niet naar broadcasts.
De 'oplossing' hiervoor zou binden op een interface zijn. Maar dat lost het probleem niet op dat twee processen dezelfde port willen gebruiken (getest met twee dummy interfaces).

Oftewel een dilemma: óf niet op dezelfde port kunnen binden, óf geen broadcasts ontvangen.

Nu heb ik heel dit verhaal getypt, en wat me dwars zit:
- Ik kan geen Civ 5 spelen (duh)
- Civ maakt gebruik van udp, en udp kan wél twee sockets op dezelfde port binden (vreemd genoeg ontvangt dan maar een van beide iets bij een broadcast?).
- Bij het verzenden krijgen processen het verkeerde source ip, binden op een interface lost dat op. Ik zou ook de routing table kunnen aanpassen, of misschien zelfs gebruik maken van SNAT, maar iets zegt me dat dat makkelijk moet kunnen.

Is hier een mogelijkheid ergens? Heel Civ virtualiseren is geen optie, want dan heb ik geen hardware acceleratie meer. (Geen Civ 5 spelen ook niet, maar wel het overwegen waard )

TL, DR: Is het mogelijk een netwerk kaart zo te virtualiseren dat ik niet handmatig de volledige routing table hoef aan te passen en misschien zelfs gewoon DHCP zou kunnen gebruiken?

[deadinspace]

Hehe, yay for evil hacks

Een ideetje:
Zou je in je LD_PRELOAD lib voor één Civ5 instantie niet kunnen zorgen dat hij eigenlijk op poort 62901 luistert (ook al denkt hij op 62900 te luisteren), maar wel broadcast naar 62900. Dan zou je in de andere Civ5 instantie kunnen luisteren op 62900 en broadcasten naar 62901.

En als je dan toch systemcall semantics aan het aanpassen bent, dan zou je zelfs het hele luisteren op poorten kunnen omzeilen, door ook de read()/write() (danwel recv/recvfrom/recvmsg/send/sendto/sendmsg, en evt dingen als getpeername) af te vangen, en de data via een ander IPC mechanisme bij de andere instantie te krjigen (named pipe, named socket, shm, ...). Laat die Civ5 maar denken dat hij op een poort luistert

[Tim]

Ah, daar had ik niet aan gedacht. Het zijn wel goede ideeën. Misschien dat ik gewoon dat tweede probeer, en dan meteen van al het gezeur af ben.

Dat eerste idee heeft me de moed gegeven iets verder te kijken. Ik bind nu alle poorten behalve 62900. De communicatie gaat blijkbaar zo:

- Server luistert op 62056 en 62900.
- Client broadcast naar 62900 vanaf poort x (willekeurig).
- Server replied met informatie vanaf poort 62900 naar poort x.
- Client connect naar source ip van vorige pakketje op port 62056.
- De rest van de communicatie gaat via poort 62056, en er zijn geen broadcasts meer.

Dat maakt het al iets makkelijker, maar poort 62900 is dus niet gebind zodat die de broadcast kan ontvangen. Maar dat betekend ook dat het source ip niet is ingesteld, en dus vrij is. Vervolgens probeert de client met zichzelf te verbinden.

# ip route get 10.61.0.200
local 10.61.0.200 dev lo  src 10.61.0.200
# ip route del 10.61.0.200 dev lo src 10.61.0.200
# ip route add 10.61.0.200 dev lo src 10.61.0.201
# ip route get 10.61.0.200
local 10.61.0.200 dev lo  src 10.61.0.200

Dat is flauw...

Edit:

iptables -t nat -A POSTROUTING -p udp --sport 62900 -j SNAT --to-source 10.61.0.200

En het werkt.

[ Voor 5% gewijzigd door Tim op 16-11-2010 12:16 ]