Free automated routing software software for linux

Automated Linux From Scratch (ALFS) is a project that creates the generic framework for an extendable system builder and package installer.

Why would I want to use ALFS?

After having gone through the LFS and BLFS books more than 2 or 3 times, you will quickly appreciate the ability to automate the task of compiling the software you want for your systems.

What can I do with ALFS?

The goal of ALFS is to automate the process of creating an LFS system. It seeks to make the process of building LFS easier and more efficient while still providing flexibility by granting the user total control and insight into the compilation and management of his LFS build.

How is ALFS implemented?

nALFS

The first ALFS implementation was nALFS by Neven Has. nALFS is a small program written in C. It first parses an XML profile that contains information concerning the LFS build process into a series of internal commands. It can then execute these at your discretion, thus automating the compilation of LFS.

jhalfs

Currently, the official implementation is jhalfs. Originally created by Jeremy Huntwork, but since developed and maintained by Manuel Canales Esparcia and George Boudreau, jhalfs has become a light-weight, practical method of automating an LFS build. jhalfs is a Bash shell script that makes use of Subversion and xsltproc to first download the XML sources of the Linux From Scratch book and then extract any necessary commands, placing them into executable shell scripts. If you do not already have the necessary source packages in place on your system jhalfs can fetch them. Finally, jhalfs generates a Makefile which will control the execution of the shell scripts, allowing for recovery if the build should encounter an error. Since jhalfs extracts its commands to run directly from the LFS book, there are no profiles to edit or maintain.

Note: The 2.2 version of jhalfs has been released. A tarball can been downloaded from http://www.linuxfromscratch.org/alfs/downloads/jhalfs/stable/.

alfs

There are many in-depth features that have been requested for future ALFS implementations. Because of this, development has been slated for an entirely new build tool which will be called alfs. To see a list of features that will appear in alfs, please read our Software Requirements Specification. If you wish to help develop this new tool, please subscribe to the alfs-discuss mailing list and leave a note there explaining your desire to help.

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.

Aargh is a code generator, written in C++ and licensed under the terms of the GNU General Public License (GPL). It generates C++ code to parse a command line, using the getopt() facility available in UNIX and UNIX-like environments.
Automated Argument Helper project supports command-line options with integer arguments, string arguments, and no arguments. The generated code is commented and carefully indented for readability.
Its nice to have lots of command line options, but its a real pain to code for them.
Not that its difficult. Its just tedious, time-consuming, error prone, and no fun. I used to wince at the thought of adding command line options.
Not any more. All I have to do is define the options I want in a small XML file, and run it through aargh. Instantly I have C++ source code that I can compile and link into my program.
If I need to add another option, or otherwise change the rules, I can edit the XML and regenerate the code. No muss, no fuss. Now I can spend more time on the interesting parts of the project.
To use aargh, write an XML file to describe the options you want. When aargh reads the file, it generates two C++ files.
One file is a header that declares a class to represent the options. By default this class is named "Opts," but you can specify a different name. The other file is the implementation of Opts, or whatever you decide to call it. The Opts class provides member functions to parse the command line and return the results.
In your own code, declare an instance of Opts and call Opts::get() to parse the command line, passing it the argc and argv arguments from main(). Opts::get() returns zero if the command line follows the rules that you have outlined in the XML file, or non-zero otherwise. If the parsing is successful, the Opts object stores the results and makes them available to your program by a series of accessor functions.
Main features:
- You can enforce upper and/or lower limits on the number of non-option arguments.
- You can distinguish between options that take arguments and those that dont.
- You can specify that an option is required.
- You can require that the argument to an option be a non-negative integer.
- For an integer argument you can enforce upper and/or lower limits.
- For a string argument you can enforce upper and/or lower limits on the string length.
- For a string argument you can call a function of your own to validate the argument.
- You can allow multiple occurrences of the same option. In that case the generated code builds an STL vector to hold the arguments. By default the generated software allows only one occurrence of any given option.
Enhancements:
- You can now specify the location of the generated header file independently of its name.
- This feature may make it easier to incorporate aargh into complex build environments.

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.

YateAdmin is a FREE powerful web interface which helps to set up the telephony engine Yate.
You can use it to setup:
- Users lines
- Register to other servers
- Routes for gateways
- Fallback routing
- Call Detail Report
- Yate status

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.

JOpt.SDK library is a routing software for Java that uses specialized genetic algorithms to calculate an optimized allocation of orders and stops to mobile resources.
The algorithm not only provides tours at minimum costs but also considers an arbitrary set of constraints for each tour. You may define your own constraints and optimization goals in order to customize JOpt.SDK to your specific planning needs or you decide to use one of our best practices addons in order to achieve a fast application of our optimization algorithms to selected industries.
JOpt.SDK can solve nearly any problem that can be classified by one of the following types:
TSP - Traveling Salesman Problem. JOpt.SDK finds the shortest or fastest path for your mobile resources
VRPTW - Vehicle routing problem with time windows - like TSP but for a set of vehicles. JOpt.SDK finds an optimal allocation of orders and stops within a vehicle fleet. It may also consider different constraints for vehicles, drivers and stops.
JOpt.SDK functionality can be accessed via Java API and thus fits seamlessly into any JAVA application. Software developers may integrate the JOpt.SDK component into their application in order to offer their customers a consistent solution including optimization of mobile workforce schedules.
Enhancements:
- The tutorial has been revised to reflect some major API changes introduced since JOpt 2.0.0.

Ad-hoc Wireless Distribution Service (AWDS) is a Layer 2 routing protocol for wireless mesh networks. The project provides transparent Ethernet-like access to all participating nodes, thus easily allowing the employment of different higher level protocols like IP (with DHCP), IPv6, AppleTalk, ...

A Linux implementation of AWDS can be downloaded from our download section. Ports to other platforms are highly appreciated!