Free technique software for linux

Check Your Network Address Translator for Compatibility with Peer-to-Peer Protocols.
If you are accessing the Internet from behind a Network Address Translator (NAT) of some kind, I would appreciate your help in surveying the behavior of different NATs, in terms of how and whether they support a certain technique for enabling peer-to-peer communication between NATted hosts (particularly when both endpoints are behind NATs). Down, you can understand what NAT is.
Suppose there are three communicating hosts: A, B, and C. Host A is a "well-known" Internet server with a permanent IP address, which acts as an "introducer" for the other two nodes. (For example, Host A might be a well-known ultrapeer or a game catalog server of some kind.) Host B, using Host As "introduction" services, would like to establish a direct peer-to-peer connection with host C. Both B and C, however, are behind (probably different) network address/port translators, and neither of them has exclusive use of any public IP address.
To initiate a peer-to-peer connection with host C, host B first sends A a message requesting an "introduction" to host C. A sends B a reply message containing Cs IP address and UDP port number as reported by host C, in addition to Cs IP address and UDP port number as observed by A. (If C is behind a NAT, then these two address/port combinations will be different.) At the same time, host A sends host C a message containing Bs IP address and UDP port numbers - again, both the ones reported by B and the ones observed by A, which will be different if B is behind a NAT.
Now B and C each know that they want to initiate a connection with each other, and they know each others public (NATted) as well as original IP addresses and UDP port numbers. Both B and C now start attempting to send UDP messages directly to each other, at each of the available addresses. If B and C happen to be behind the same NAT, then they will be able to communicate with each other directly using their "originally reported" IP addresses and UDP port numbers.
In the more common case where B and C are behind different NATs, the "originally reported" addresses will be useless because they will both be private IP addresses in different addressing domains. Instead, the IP address/UDP port combinations observed by A can be used in this case to establish direct communication. Although Bs NAT will initially filter out any UDP packets arriving from Cs public (NATted) UDP port directed at Bs public port, the first UDP message B sends to C will cause Bs NAT to open up a new UDP session keyed on Cs public port, allowing future incoming traffic from C to pass through the NAT to B. Similarly, the first few messages from B to C may be filtered out by Cs NAT, but will be able to start passing through the firewall as soon as Cs first message to B causes Cs NAT to open up a new session. In this way, each NAT is tricked into thinking that its respective internal host is the "initiator" of this new session, when in fact the session is fully symmetrical and was initiated (with As help) simultaneously in each direction.
Required NAT Behavior
There is one important requirement that the NATs must satisfy in order for this technique to work: the NATs must be designed so that they assign only one (public IP address, public UDP port) pair to each (internal IP address, internal UDP port) combination, rather than allocating and assigning a new public UDP port for each new UDP session. Recall that a "session" in Internet terminology is defined by the IP addresses and port numbers of both communicating endpoints, so host Bs communication with host A is considered to be one session while host Bs communication with host C is a different session. If Bs NAT, for example, assigns one public UDP port for Bs communication with A, and then assigns B a different public UDP port for the new session B tries to open up with C, then the above technique for peer-to-peer communication will not work because Cs messages to B will be directed to the wrong UDP port.
RFC 3022 explicitly allows and suggests that NATs behave in the former, "desirable" fashion, by maintaining a single (public IP, public port) mapping for a given (internal IP, internal port) combination independent of the number of active sessions involving this mapping. This behavior is not only good for compatibility with UDP applications, but it also helps to conserve the NATs scarce pool of public port numbers. Maintaining a consistent public port mapping does not adversely affect security in any way, either, because incoming traffic can still be filtered on a per-session basis regardless of how addresses are translated. There in fact appears to be no good reason not to implement the desirable behavior in a NAT, except perhaps for the implementation simplicity of naively allocating a new public port for every new session. Unfortunately, RFC 3022 does not require NATs to implement the desirable behavior, which has led me to wonder just how many real NATs actually do, and hence this page.
What NAT Check Does
The program natcheck.c is basically just a program that "pings" a well-known UDP port at two different servers that are publically accessible on the Internet. Both of these servers run the program natserver.c, with the command-line arguments "1" and "2" respectively. In addition, there a third "conspiring" server runs natserver with the command-line argument "3". Whenever each of the first two servers receives a UDP request, it not only sends a reply directly to the sender of that request, but also sends a message to the third server, which in turn "bounces" the reply back to the original client. The effect is that the client will receive not only solicited "ping" replies from the server the request was directed to, but also "unsolicited" replies from the third server.
To determine if the network address translator in use is implementing the desirable behavior of maintaining a single (public IP address, public port) mapping for a given (client IP address, client port), the client program natcheck.c basically just initiates a sequence of simultaneous pings to the first two servers (in case some of the requests or replies are lost in transit) and checks that the clients address and UDP port as reported by both servers is the same. If the NAT naively allocates a new public port for each new session, then the source port as reported by the two servers will be different, and its time to upgrade your NAT.
The replies echoed from the third server are used only to check whether the NAT properly filters out unsolicited incoming traffic on a per-session basis. Since the client never sends any messages to the third server, if the NAT is properly implementing firewall functionality, the client should never see the third servers echoed replies even after opening up active communication sessions with the first two servers.
Enhancements:
- The NAT Check client no longer attempts to guess whether you have Basic NAT or Network Address/Port Translation (NAPT). It turns to be quite difficult to test for this property reliably, because many NAPTs attempt to bind a private UDP port to a public port with the same port number if that port number is available, causing NAT Check to falsely report Basic NAT. The only way to test for this property reliably would be to run NAT Check on at least two client machines simultaneously, and since this property isnt terribly important to P2P apps its just not worth the trouble.
- The NAT Check client now tests for one additional NAT feature, which I call loopback translation. If a NAT supports loopback translation, it means that a host on the private network behind the NAT can communicate with other hosts on the same private network using public (translated) port bindings assigned by the NAT. Most NATs probably do not support this feature yet, but it may become increasingly important in the future where P2P clients may be located behind a common ISP-deployed NAT as well as individual home NATs. More details on loopback translation will appear in the next version of my Internet-Draft, to be released soon.
- The NAT Check client program now has a command-line option, "-v", which turns on verbose messages during the test.

Enblend project is a postprocessing tool for creating panoramic images. After you align image features using a program like Hugin, there are often photometric problems that lead to ugly seams in the final composite.
Enblend blends away these seams using a multiresolution spline. This technique gives good results on both low spatial frequency objects (sky and clouds) and high spatial frequency objects (trees and houses).
Enhancements:
- This release features faster image processing computations and a new seam line optimization algorithm.
- Masks can now be saved and loaded from files, color blending can be done with the CIECAM02 color appearance model, and the graphics processor can be leveraged for higher performance.

The openais project is a project to implement a production quality "Revised BSD" licensed implementation of the SA Forums Application Interface Specification. OpenAIS project implements cutting edge research on virtual synchrony to provide 100% correct operation in the face of failures or partitionable networks with excellent performance characteristics.
The Application Interface Specification is a software API and policies which are used to develop applications that maintain service during faults. The API consists of Availability Management Framework (AMF) which provides application failover, Cluster Membership (CLM), Checkpointing (CKPT), Event (EVT), Messaging (MSG), and Distributed Locks (DLOCK).
Faults occur for various reasons:
- Application Failure
- Middleware Failure
- Operating System Failure
- Hardware Failure
The major focus of high availability in the past has been to mask hardware faults. Faults in other components of the system have gone unsolved until AIS. AIS can mask many types of faults in applications, middleware, operating systems, or even hardware by providing a simple framework for allowing developers to create redundant applications. These redundant applications can be distributed over multiple nodes such that if any one node faults, another node can recover.
Application programmers develop applications to periodically record their state using the checkpointing service. When an active application fails, a standby application recovers the state of the application. This technique, called stateful application failover, provides the fundamental difference between openais and other systems that have come before it. With stateful application failover, the end-application user doesnt have to reload the application or redial a telephone. The full state is recorded, so the end-application user sees no interruption in service.
Because programmers can now distribute applications across multiple processes or nodes, a mechanism must exist for them to communicate. This mechanism is provided by two services. The event service provides a publish/subscribe model for events. The messaging service provides end to end messaging. Finally a mechanism to synchronize access is provided by the distributed lock service.
Enhancements:
- This version significantly improves support for AMF B.02.01 n+m failover of components.
- Most of the QA that went into Whitetank (0.80.2) has been merged.

bilateral filter is a denoising filter using the same technique as the selective gaussian blur, but with speedups and other enhancements.

The filter is slow when the blur radius is small but speeds up when the radius gets larger, which is the opposite behavior of the selective gaussian blur. Theres also an option for improved denoising of image gradients.

Emacspeak is a speech interface that allows visually impaired users to interact independently and efficiently with the computer.

Audio formatting --a technique pioneered by AsTeR-- and full support for W3Cs Aural CSS (ACSS) allows Emacspeak to produce rich aural presentations of electronic information. By seamlessly blending all aspects of the Internet such as Web-surfing and messaging, Emacspeak speech-enables local and remote information via a consistent and well-integrated user interface.

Available free of cost on the Internet, Emacspeak has dramatically changed how the author and hundreds of blind and visually impaired users around the can interact with the their computer and the Internet. A rich suite of task-oriented tools provides efficient speech-enabled access to the audio desktop and evolving semantic WWW. When combined with Linux running on low-cost PC hardware, Emacspeak/Linux provides a reliable, stable speech-friendly solution that opens up the Internet to visually impaired users around the world.

Maypole::Plugin::QuickTable is a HTML::QuickTable convenience.

SYNOPSIS

use Maypole::Application qw( LinkTools QuickTable );

METHODS

setup

quick_table

Returns a HTML::QuickTable object for formatting data.

print $request->quick_table( %args )->render( $data );

The method gathers arguments from the quicktable_defaults method on the model class. This is a Class::Data::Inheritable method, so you can set global defaults on the main model class, and then override them in model subclasses. To preserve most settings and override others, say something like

$sub_model->quicktable_defaults( { %{ $model->quicktable_defaults }, %hash_of_overrides } );

Arguments passed in the method call override those stored on the model.

Arguments are passed directly to HTML::QuickTable->new, so see HTML::QuickTable for a description.

Additional arguments are:

object => a Maypole/CDBI object

Pass a Maypole/CDBI object in the object slot, and its data will be extracted and $qt->render called for you:

print $request->quick_table( %args, object => $object );

Related objects will be displayed as links to their view template.
If no object is supplied, a HTML::QuickTable object is returned. If an object is supplied, it is passed to tabulate to extract its data, and the data passed to the render method of the HTML::QuickTable object.

To render a subset of an objects columns, say:

my @data = $request->tabulate( objects => $object, with_colnames => 1, fields => [ qw( foo bar ) ] );

$request->quick_table( @data );

tabulate( $object|$arrayref_of_objects, %args )

Extract data from a Maypole/CDBI object (or multiple objects), ready to pass to quick_table->render. Data will start with a row of column names if $args{with_colnames} is true.

A callback subref can be passed in $args{callback}. It will be called in turn with each object as its argument. The result(s) of the call will be added to the row of data for that object. See the list template in Maypole::FormBuilder, which uses this technique to add edit and delete buttons to each row.

Similarly, a field_callback coderef will be called during rendering of each field, receiving the object and the current field as arguments. See the addmany template for an example.

Arguments:

callback coderef
field_callback coderef
with_colnames boolean
fields defaults to ( $request->model_class->display_columns, $request->model_class->related )
objects defaults to $request->objects
orderby_link( $field, [ $model_class ] )

Build a link for a column header. Controls whether the table should be sorted by that column. Toggles sort direction.

The $model_class parameter is only necessary when building a table for a class different from the current model class for the request.

Welcome to the world of Fuzzy Fingerprinting, a new technique to attack cryptographic key authentication protocols that rely on human verification of key fingerprints. It is important to note that while fuzzy fingerprinting is an attack against a protocol, it is not a cryptographic attack and thus does not attack any cryptographic algorithm.

THC-FuzzyFingerprint tool generates fuzzy fingerprints as described in the corresponding paper. It is an ideal extension to man-in-the-middle attacks against the SSH service. The current version supports RSA and DSA key generation and MD5 and SHA1 fingerprints.

The Challenge:

THC is doing a little "seti@home" like competition. The challenge is to generate the best fuzzy fingerprint for our target public SSH host key. Here are some information on our victims SSH public host key.

The victim host: kimble.org
Public SSH key: kimble.org.pub
Public key algorithm: RSA
Public key length: 1024
MD5 key fingerprint: 08:54:5d:27:f8:e9:47:4e:49:8a:87:7e:03:cc:98:73

Download the fuzzy fingerprint release from the link at the top of this page and join the competition. Compile ffp and launch the tool against the victim hosts fingerprint and key algorithm using the following setup. (It is essential that you provide all of the given arguments to ffp so that we are able to compare different peoples fuzzy fingerprints)

$ ffp -f md5 -k rsa -b 1024
-t 08:54:5d:27:f8:e9:47:4e:49:8a:87:7e:03:cc:98:73
-s /var/tmp/kimble.org.state

You can stop the process at any point and continue later by just using the following comman line options.

$ ffp -s /var/tmp/kimble.org.state