UDP port redirector

uredir is a small Linux daemon to redirect UDP connections. It can be used to forward connections on small and embedded systems that do not have (or want to use) iptables.

uredir can be used with the built-in inetd service in Finit to listen for, e.g. SNMP connections, on some (safe) interfaces and forward to an SNMP daemon on loopback.

• In normal mode it forwards packets to a given destination and remembers the sender's address. Packets received from the given destination are forwarded to the sender.
• In inetd mode uredir lingers for three (3) seconds after forwarding a reply. This to prevent inetd from spawning new instances for multiple connections, e.g. an SNMP walk.

For a TCP port redirector, see redir.

Usage

uredir [-hinsv] [-I NAME] [-l LEVEL] [-t SEC] [SRC:PORT] DST:PORT

  -h      Show this help text
  -i      Run in inetd mode, get SRC:PORT from stdin, implies -n
  -I NAME Identity, tag syslog messages with NAME, default: uredir
  -l LVL  Set log level: none, err, info, notice (default), debug
  -n      Run in foreground, do not detach from controlling terminal
  -s      Use syslog, even if running in foreground, default w/o -n
  -t SEC  Timeout for connections, default 3 seconds
  -v      Show program version

 Bug report address: https://github.com/troglobit/uredir/issues

Examples

This simple UDP proxy example forwards inbound DNS requests on any interface to an external DNS server on 192.168.0.1:

uredir :53 192.168.0.1:53

To run uredir from a process monitor like Finit or systemd, tell it to not background itself and to only use the syslog for log messages:

uredir -ns :53 127.0.0.1:53

To run uredir in inetd mode, e.g. to redirect SNMP requests, try the following. Runs in foreground, as required for inetd services, and uses syslog for logging:

snmp  dgram  udp  wait  root  uredir -i 127.0.0.1:16161

Build & Install

uredir is tailored for Linux systems and should build against any (old) C libray. However, uredir v3.0 and later require an external library, libuEv. Installing it should present no surprises since it too use a standard configure script and support pkg-config. The latter is used by the uredir build to locate the library and header files.

Hence, the regular ./configure && make is usually sufficient to build uredir. But if libuEv is installed in non-standard location you may need to provide the path:

    PKG_CONFIG_PATH=/opt/lib/pkgconfig:/home/ian/lib/pkgconfig ./configure
    make

Origin & References

The uredir project is open source under the ISC license and actively maintained at GitHub. Please use its interface for reporting bugs and an pull requests.

uredir was heavily inspired by redir(1), by Sam Creasey.

Copyright (C) 2016-2018  Joachim Nilsson <troglobit@gmail.com>
Copyright (c)      2017  Tobias Waldekranz <tobias@waldekranz.com>

Permission to use, copy, modify, and/or distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.

THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

Contributing to uredir

Thank you for considering contributing back to the community!

There are a few things we would like you to consider when filing an issue or making a pull request with this project:

1. If you are filing a bug report or feature request

   Please take the time to check if an issue already has been filed matching your problem

2. What version are you running, have you tried the latest release?

   UNIX distributions often package and test software for their particular brand. If you are using a pre-packaged version, then please file a bug with that distribution instead.

3. Coding Style

   Lines are allowed to be longer than 72 characters these days, there is no enforced maximum line length.

Tip: Always submit code that follows the style of surrounding code!

The coding style itself is strictly Linux KNF, like GIT it is becoming a de facto standard for C programming

https://www.kernel.org/doc/Documentation/CodingStyle

4. Logical Change Sets

   Changes should be broken down into logical units that add a feature or fix a bug. Keep changes separate from each other and do not mix a bug fix with a whitespace cleanup or a new feature addition.

   This is important not only for readilibity, or for the possibility of maintainers to revert or isolate changes when bisecting for a bug. It also increases the chances of having your change accepted.

5. Commit messages

   Commit messages exist to track why a change was made. Try to be as clear and concise as possible in your commit messages, and always, be proud of your work and set up a proper GIT identity for your commits:

    git config --global user.name "J. Random Hacker"
    git config --global user.email random.j.hacker@example.com
   

   See this helpful guide for how to write simple, readable commit messages, or have at least a look at the below example.

   http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

Example

Example commit message from the Pro Git online book, notice how git commit -s is used to automatically add a Signed-off-by:

Capitalized, short (50 chars or less) summary

More detailed explanatory text, if necessary.  Wrap it to about 72
characters or so.  In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body.  The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.

Write your commit message in the imperative: "Fix bug" and not "Fixed bug"
or "Fixes bug."  This convention matches up with commit messages generated
by commands like git merge and git revert.

Further paragraphs come after blank lines.

- Bullet points are okay, too

- Typically a hyphen or asterisk is used for the bullet, followed by a
  single space, with blank lines in between, but conventions vary here

- Use a hanging indent

Signed-off-by: J. Random Hacker <random.j.hacker@example.com>