Free routing protocols software for linux

Routing incoming ppp0 is a netfilter firewall.

Sample:

#!/bin/bash

# Load required modules
insmod ip_tables
insmod ip_conntrack
insmod iptable_nat
insmod ipt_MASQUERADE

# Then flush all rules
iptables -F
iptables -t nat -F

# In the NAT table (-t nat), Append a rule (-A) after routing
# (POSTROUTING) for all packets going out ppp0 (-o ppp0) which says to
# MASQUERADE the connection (-j MASQUERADE).

#iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

# Below means route 192.168.1.x
iptables -t nat -A POSTROUTING -d ! 192.168.1.0/24 -j MASQUERADE

iptables -A FORWARD -s 192.168.1.0/24 -j ACCEPT
iptables -A FORWARD -d 192.168.1.0/24 -j ACCEPT
iptables -A FORWARD -s ! 192.168.1.0/24 -j DROP

# Disallow NEW and INVALID incoming or forwarded packets from ppp0.
#iptables -A INPUT -i ppp0 -m state --state NEW,INVALID -j DROP
#iptables -A FORWARD -i ppp0 -m state --state NEW,INVALID -j DROP

# port 113 is evil ;)
iptables -A INPUT --protocol udp --source-port 113 -j DROP
iptables -A INPUT --protocol udp --destination-port 113 -j DROP

# Turn on IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

#iptables -A INPUT --protocol udp --source-port 113 -j DROP

# Route incoming ppp0 at port 80, to 192.168.1.18:80
iptables -A PREROUTING -t nat -p tcp -i ppp0 --dport 80 -j DNAT --to 192.168.1.18:80

# Route incoming ppp0 at port 21, to 192.168.1.18:21
iptables -A PREROUTING -t nat -p tcp -i ppp0 --dport 21 -j DNAT --to 192.168.1.18:21

Multi-Protocol Remote Login provides a middleware allowing SSH, telnet, and local logins from the login: prompt.
MPRL is a middleware application between a *getty program and SSH, telnet, and other such remote-login protocols. It allows a user at a Linux terminal to log into other systems without needing a valid local user-id. It currently supports telnet, ssh, and /bin/login.
It syntax follows the [protocol:]user[@host][:port] fashion.
These are valid logins:
- buanzo - Normal local login: /bin/login gets called.
- buanzo@linux.org.ar - SSH protocol by default: /usr/bin/ssh gets called
- ssh:buanzo@webserver.algo.net

BitWise Routing Server allows multiple PCs behind a router to make direct connections.

The BitWise Routing Server allows you to accept BitWise connections to multiple computers behind a router. Typically, using a router, you would set up port forwarding on BitWises client port (4137), and specify a single destination IP. This is fine until multiple users behind a router all need to accept incoming connections.

As shown by the picture at right, the Routing Server allows individual users to register themselves with the Routing Server, and then the Routing Server accepts all incoming connections and directs those connections to the appropriate user.

The Routing Server requires that your physical router support port forwarding with a way to specify different external and internal ports (this is sometimes labeled "UPnP" by many common home routers).

The Routing Server has several options allowing you to customize the Routing Server for your environment. Many of the options are self-explanatory. The two that are not are Listen on Port and IP filtering. IP filtering is explained in the next section.

The BitWise Routing Server listens on a different port than the BitWise IM client. This allows the Routing Server and the IM client to be run on the same computer without causing conflicts. You will want to set up your router (more detail in a later step) to shift the port of the incoming connections from 4137 to another port. It doesnt particularly matter which port you want to use, as long as it is not a port used by another program. The default port is 4200.

Depending on the complexity of the network, it may be desirable to filter the IP addresses that are allowed to register with the Routing Server. This can be done in the preferences. One very likely scenario would be limiting registrations to the 192.168.1.x IP addresses (192.168 is reserved for local networks). When specifying an IP as the comparison address, you can use any valid IP numbers for wildcards.

In the case shown here, the Routing Server will limit connections to computers having IP addresses of 192.168.1.x. Any number, 0 through 255, could be placed for x in the Routing Server preferences.

If you are not familiar with IP address classes and IP filtering, it will usually be safe to leave Any selected.

Setting up the physical router

The picture at right was taken from a Linksys router, other routers will have a similar capability, although it may be layed out differently. On some routers, the advanced port forwarding options are mistakingly labeled UPnP.

The router setup shows that we are accepting connections on port 4137 and then sending them inside the network on port 4200 (the default port). Enter the IP address of the machine on the network running the Routing Server, and make sure that the rule is enabled. You will want to enter a rule for both TCP and UDP (UDP is used only for voice).

Please consult your router manual for more detailed instructions about how to set up port forwarding on your specific model.

Configuring BitWise to use the Routing Server

In order for you to enjoy the connectivity benefits of the Routing Server, you will need to register with the Routing Server when you log in to BitWise. Prior to logging in to BitWise, click the Setup button next to the Connect button to open the BitWise Setup. There is an area to enter an address for the Routing Server, and to specify what port to use. The port must be the same as the port used above (4200 is the default).

Upon connecting to BitWise, you will be registered with the Routing Server. If you could not be registered, an error message will be displayed. Double-check that the correct address was entered in the Setup.

Registration with the Routing Server

Upon successfully registering with the Routing Server, the Routing Server will display the user name and the IP address of the registration. If you want to unregister a user, click on the username, and then click Unregister. Incoming connections will no longer be forwarded to the specified computer.

It is worth pointing out two things here. First, if you later log in from a different computer, and that computer is also set to use the Routing Server, you will be re-registered with your new IP address. Second, if you are unregistered, or move to another computer but are not set up to use the Routing Server, you will not be able to benefit from the services of the Routing Server.
By default, the Routing Server saves the registered user list when it is closed down.

Using the Routing Server

Assuming that everything is set up correctly, everyone that registers with the Routing Server when they log in to BitWise will be able to enjoy significantly increased connectivity with other BitWise users. As incoming connections are established, you will see the connections listed in the right pane of the Routing Server window. The IP address and the time of the connection is also displayed, and the connection is later marked when it is disconnected.

The disconnected/closed connections may be cleaned from the list at any time using the Clean List button. Only active connections will be left displayed.

Generic Protocol Framework aims to allow users to rapidly prototype different emerging communications protocols. Implementations can be easily "dropped in" and tested independant of a finished product. Testing on both the end product, and the protocol itself can be easily accomplished. The tool aims to provide the developer and end user with a robust solution which can track the size of messages, how rapidly they will be generated, and how many of each type can be seen.
Why the GPF:
There are many similar tools available. The problem with many of these tools is that they are 1) closed source, 2) not easily adaptable to a specific implementation (they use custom languages), 3) expensive. The advantages of the GPF are its open source nature, the ease of which it can be adapted, and the cost: free!
Basic Flow:
Modification of the GPF is fairly simple. Tool-opts.h contains the basic options that will be applied to the packet while it is being built. To transmit a packet, the system calls the tx_message() function, and passes the message ID as well as the option block. This is then passed to the custom function: tx_message_custom() in tx.c. From the message id, the system selects an appropriate tx_* function (to be implemented by the user) and passes an unsigned char **, where the buffer will be written, and the option block. In turn, that function will make heavy use of the add_buf_tu*() functions, which will allow the user to add a tubyte8, tuint16, or tuint32 number to the buffer.
In daemonize mode, the basic options are set, and the system then listens for incomming packets. When a packet arrives, the system calls basic_parse() on the packet. This function then calls basic_parse_custom(), found in parse.c. In turn, this can call any appropriate parsing helpers, including the get_tu*() functions, which allow the user to retrieve a tubyte8, tuint16, or tuint32 from the buffer. CAVEAT: if the first two bytes of the buffer are zerod, it will be treated as an END message. However, recovery is available. In the basic_parse_custom() message, you can set the end_signal_caught variable of the option_block to 0. In this case, it will not stop the daemon from running.
Enhancements:
- Currently, TCP support is somewhat experimental.
- Testing for that portion will be ongoing.
- No clear examples are provided.
- The examples/ directory contains the precursors to a MIP example.

Linux Advanced Routing & Traffic Control HOWTO is a document concerning iproute2, traffic control (shaping), and more!

The LARTC-HOWTO describes many advanced ways of routing and shaping traffic.

Using the HOWTO, you will be able to shape traffic in myriad ways, which will help you lower latency for interactive use when others are downloading or uploading.

It will also teach you how to limit certain hosts/protocols bandwidth usage. It also explains many aspects of routing using the ip tool from the iproute2 suite.

mrouted project is a DVMRP multicast routing daemon.
mrouted is an implementation of the DVMRP multicast routing protocol. It turns a UNIX workstation into a DVMRP multicast router with tunnel support, in order to cross non-multicast-aware routers.
Enhancements:
- IGMP could report membership in local-only groups (i.e. 224.0.0.X)
- IGMP could get confused by hearing its own new membership reports, thus a router would never perform fast leave.
- IGMP could reset timers for the wrong interface.
- mrouted put a bogus value in the maximum timeout field of IGMPv2 query packets.
- Non-querier mrouters would respond to IGMP leave messages
- mrouted was not performing fast leave properly
- If the last member goes away on a transit network, the upstream router would stop forwarding even if there are downstream members.
- Kernel hash function improved
- Eliminated possibility of panic(): timeout in cache maintenance
- Reordered resource allocation when sending upcall to handle failure properly
- some endian-ness bugs squashed in mrouted, probably more to go.
- Multicast traceroute could send a reply on a disabled interface.

Internet Registry Routing Daemon (IRRd) is a freely available, stand-alone Internet Routing Registry database server. IRRd supports the RPSL and RPSLng Routing Policy Specification Language standards.

The IRRd package includes all required IRR support services, including: automated near real-time mirroring of other IRR databases, update syntax checking, authentication/security, and notification.

Invisible IRC Project is a three-tier, peer distributed network designed to be a secure and private transport medium for high speed, low volume, dynamic content. IIP uses Trent that facilitates nickname and channel control.
Main features:
- Perfect Forward Security using Diffie-Hellman Key Exchange Protocol
- Constant session key rotation
- 128 bit Blowfish node-to-node encryption
- 160 bit Blowfish end-to-end encryption
- Chaffed traffic to thwart traffic analysis
- Secure dynamic routing using cryptographically signed namespaces for node Identification
- Node level flood control
- Seamless use of standard IRC clients
- Gui interface
- Peer distributed topology for protecting the identity of users
- Completely modular in design, all protocols are plug-in capable
Enhancements:
- System tray icon recovery on exporer crash (windows)
- Commandline -h argument displayed even if not configured (unix)
- Path fix for logfile location (unix)
- install-local added in Makefile (unix)
- Ignoring empty node.ref from server
- FreeBSD compatibility patch in socket code
- iip.log and mynode.ref also stored in ~/.iip/ (unix)
- Entropy gathering detects repeated sequences of characters and multibyte characters.