Luigi Auriemma

some hours ago I have released a new version of sudppipe in which I have added support for multiple hosts and a particular option which, if the target hosts are all the same (like 1.2.3.4,1.2.3.4,1.2.3.4,1.2.3.4,1.2.3.4,1.2.3.4), allows to reach them with a different source port.
practically like the following example:so the host (1.2.3.4 in this example) sees 6 UDP connections (not the right term, but try to think to a classical game that recognizes new "connections" from the source port) from the same source IP address/client.

just for fun I have tried this thing with a game that doesn't use a challenge-response mechanism like Unreal 1 and obviously there are 6 players which join the server.

I have tried the same also with a couple of games based on the Quake 3 engine (challenge-response based) and I see another funny effect, the server continues to report the message "SV_PacketEvent: fixing up a translated port" for each packet received from the ports not assigned to the in-game client (because obviously only one of the six "fake connections" has joined the server).

usage example:
well, probably nothing so special but I guess was interesting or at least "curious" to show some of the effects of this new option.

It's influencing JK3 so much, real DoS attack. :DD lags... Gooood Job of course, but it became known not only to me. Any fixes? :)

fixes? uhmmm I don't think this can be considered a bug.
have you tested this with your local server (LAN/localhost) or your internet one (if you have one)?

obviously in LAN/localhost the effects are exagerated due to the low latency, high bandwidth and the usage of the virtual loopback interface (I refer to localhost) so it must be not considered.

anyway it looks strange that a so simple and basic feature like the replication of packets using different source ports/sockets can have similar effects... really strange and imho interesting.

Yes, localhost.

Ah sry ^^.

luigi, can I load 2 plugins in one time?
+
Can I change the packets sent, and resend them somehow?
Having control of the game :O

no, you can't do this with sudpipe.

but you can do it with proxocket building a myproxocket.dll plugin, in that case there are no limitations in what you can do since you can also use the real send(), sendto(), recv() and recvfrom() functions when you want.

proxocket includes a half-life decoding plugin?

not by default (it has only the example myproxocket.c in the package) but it's enough to copy the hldec function from the sudppipe one and using it there in myrecvfrom

myrecfrom is a function inside myproxocket,
what code do I need to add to the file to have it use hldec?
#include?

the attached is a full example of decrypt and and re-encryption of the sent and received packets.
I don't know exactly what you need to do so I have allowed the monitoring of both the input and output packets and the possibility to use real_sendto so you can send a packet if you want.

this thing should work with Q3based games

only for the "connect" packet because the in-game data requires a more complex compression+encryption mechanism that obviously can be implemented but it's not that joke to do like calling huffman over the "connect" packet

from version 0.4.1 sudppipe supports also the plugins of proxocket (mysendto and myrecvfrom) making them portable on both the tools and less work (for additional compatible versions) from me.