Usage:
./udprelay LST-ADDR LST-PORT DST-PORT DST-ADDR [DST-ADDR]...
udprelay bind()s to address LST-ADDR on port LST-PORT and retransmits UDP packets received to addresses(s) DST-ADDR(s) on port DST-PORT, with modified headers to reflect the new target.
To receive broadcast traffic, use a LST-ADDR of 0.0.0.0. If a program is already listening on LST-PORT on LST-ADDR, you may listen on a broadcast address such as 255.255.255.255.
Steam broadcasts to a number of different ports, so it is sufficient to listen on a different port to your game server.
e.g. a LST-PORT of 27016 and a DST-PORT of 27015 will let you listen on a different port to a game server, but for it to still directly receive packets that were broadcast.
It was written to address the problem of getting Source Dedicated Server (srcds) hosted games that are bound to a specific IP address to be able to show up in the Steam LAN browser.
An example scenario:
Given two srcds servers, bound to 192.168.0.200 and 192.168.0.201 (by passing -ip or +ip) on port 27015.
The srcds servers will not receive broadcast traffic, so will not show up in the LAN browser.
Running udprelay on the same machine, like so, will fix the problem:
./udprelay 255.255.255.255 27015 27015 192.168.0.200 192.168.0.201
This will direct broadcast traffic directly at the two specified IP addresses, while keeping the source headers, causing srcds to receive the requests and reply to the original client (i.e. the LAN browser).
An alternative for the above scenario is to run the following instead:
./udprelay 0.0.0.0 27016 27015 192.168.0.200 192.168.0.201
This works as the Steam LAN browser broadcasts to multiple ports, including 27016.
This redirects traffic bound for port 27016 to port 27015, again causing srcds listening on port 27015 to reply to the original client.
Source: udprelay-1.2.tar.gz
Questions or comments, email Luke Bratch <luke@bratch.co.uk>.