Free resp software for linux

seppl is both a protocol definition and a software implementation of a new encryption layer for IPv4. seppl project makes use of symmetric cryptography for encrypting the whole traffic on a network. Its implementation is designed around Linux netfilter/iptables.
seppl introduces two new netfilter targets: CRYPT and DECRYPT. A firewall rule may thus be used for encrypting/decrypting the incoming and outgoing network traffic. This makes seppl extraordinarily easy to use, since no daemons need to run for secure communication.
seppl uses the encryption engine of the Linux Cryptographic API which is available in kernel 2.4.22 and newer.
seppl is primarily intended for encrypting wireless LANs (as secure replacement of the broken WEP encryption) and local ethernet networks but may be used for large scale VPN solutions as well.
The protocol seppl relies on is not compatible with any other software. The protocol is open and well defined but there is no implementation other than this reference software.
Why SEPPL, there are already IPSEC, CIPE,...?
CIPE may be used for point-to-point connections only. It has tunnel structure and thus introduces new IP addresses. This is not always desirable. It requires a user space daemon.
IPSEC/FreeSwan is extremely complicated to use. Due to its strange routing scheme it is nearly impossible to use together with routing daemons. IPSEC is heavyweight.
seppl is truely peer-to-peer. It encrypts seamlessly all outgoing traffic and it thus compatible with routing daemons. It is extremely easy to use as well, as it makes no change to the normal routing behaviour. seppl is extremely lightweight.
The Implementation
The implementation consists of three Linux kernel modules: seppl.o, ipt_CRYPT.o and ipt_DECRYPT.o. The former is the in-kernel key manager, the latter are the two new netfilter targets. Both depend on seppl.o.
seppl.o must be inserted into kernel in first place. The key manager may be accessed with the file /proc/net/seppl_keyring. It contains binary key data, and is initially empty. You may add a new key by writing it to that file.
The two Python scripts seppl-ls and seppl-gen-key me be used for key management. seppl-ls may be used for converting seppl keys between the binary format used by /proc/net/seppl_keyring and a human readable XML based format. Simply call seppl-ls for a list of all currently active keys. seppl-gen-key generates a new key from /dev/urandom. By default it will use the XML format. The parameter -x forces binary mode. You may generate and activate two keys "linus" and "alan" by issuing the following command lines:
seppl-gen-key -n linus -x > /proc/net/seppl_keyring
seppl-gen-key -n alan -x > /proc/net/seppl_keyring
seppl-ls without argument lists the new keys saved in the kernel keyring. You may remove all (currently unused) keys by issuing:
echo clear > /proc/net/seppl_keyring
Since seppl is based on symmetric cryptography using shared keys you have to copy newly generated keys to every host you want to connect to your seppl infrastructure. (preferably via SSH or any other secure file transfer) You get a binary copy of your current keyring by issuing:
cat /proc/net/seppl_keyring > keyring.save
Now copy that file keyring.save to all other hosts and issue the following command there:
cat keyring.save > /proc/net/seppl_keyring
That is simple, isnt it?
After doing so you may configure your firewall settings on each host:
iptables -t mangle -A POSTROUTING -o eth0 -j CRYPT --key linus
iptables -t mangle -A PREROUTING -i eth0 -j DECRYPT
This will encrypt all outgoing traffic on eth0 with the key "linus". All incoming traffic is decrypted with either "linus" or "alan", depending on the key name specified in the specific network packet. Unencrypted incoming packets are silently dropped. Use
iptables -t mangle -A PREROUTING -p 177 -i eth0 -j DECRYPT
for allowing both crypted and unencrypted incoming traffic.
Thats it. Youre done. All your traffic on the local subnet is now crypted with seppl.
The default cipher is AES-128. If you dont specify the name of the used key it defaults to "def".
An SysV init script /etc/init.d/seppl is provided. It will load seppls kernel modules and write all keys from the directory /etc/seppl to the kernel keyring. It will not add any firewall rules, however.
Performance issues
The network packets are increased in size when they are crypted, since two new headers and the IV are added. (36 bytes in average) This conflicts on some way with the MTU management of the Linux kernel and results in having all large packets (that is: package size near MTU) fragmented in one large and another very small package. This will hurt network performance. A work-around of this limitation is using the TCPMSS target of netfilter to adjust the MSS value in the TCP header to smaller values. This will increase TCP perfomance, since TCP packets of the size of the MTU are no longer generated. Thus no fragmentation is needed. However, TCPMSS is TCP specific, it wont help on UDP or other IP protocols.
Add the following line before encryption to your firewall setup:
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j TCPMSS --set-mss $((1500-40-8-16-6-15))
The Protocol
For encryption every single unencrypted packet is taken and converted to a crypted one. Not a single further packet is ever sent.
Original SEPPL counterpart
+------------+ +-----------------------+
| IP-Header | | Modified IP-Header | |
+------------+ +-----------------------+ |
| Payload | | SEPPL-Header | > Unencrypted
+------------+ +-----------------------+ |
| Initialization Vector | |
+-----------------------+ /
| SEPPL-Header |
+-----------------------+ | Crypted
| Payload | |
+-----------------------+ /
The original IP header is kept as far as possible. Only three fields are replaced with new values. The protocol number is set to 177, the fragment offset is set to 0 and the total length is corrected to the new length. All other fields are kept as is, including IP options.
The unencrypted seppl header consists of a one-byte cipher number and a key name. Currently only 0 and 1 are defined as cipher numbers for AES with 128bit key, resp. AES with 192bit key. The key name (7 bytes) may be used to select a specific key in a larger keyring.
The IV is used for CBC coding of the cipher used. It differs from packet to packet, but is not randomly generated. Due to perfomance reasons, only the initial IV on system startup is randomized, all following IVs are generated by incrementing the previous ones.
The crypted seppl header consists of three saved fields of the original IP header (protocol number, fragment offset, total length) and a byte which is always 0 for detecting unmatching keys.
The payload is the original IP-playload, from the TCP/UDP/other header to the end.
Version restrictions:
- seppl interferes with netfilters connection tracking in some way. Thus you will not be able to use NAT in conjunction with seppl. If you use connection tracking in some other way together with seppl your mileage may vary.
- seppl is tested with Linux 2.6.1. Use version 0.3 for Linux 2.4.

fixsrcip is a tool for binding outgoing TCP and UDP client sockets (IPv4) to specific source IP addresses on multi-homed hosts. It requires a current Linux system. fixsrcip tool uses LD_PRELOAD for preloading a small shared object to executables. The shared object overwrites the connnect() (for TCP) and sendto()/sendmsg() (for UDP) functions.

If you dont understand the short description above, fixsrcip is probably not what youre looking for.

For compiling and installing just run "make" and copy the newly created shared object "fixsrcip.so" and the shell script "fixsrcip" to some suitable places. (i.e. /usr/local/lib resp. /usr/local/bin) Edit fixsrcip and adjust the path to the shared object in the variable FIXSRCIP. (For building fixsrcip you have to install gcc, make and the glibc header files.)

After that you may use fixsrcip like this:

fixsrcip 47.11.8.15 telnet heise.de 80

(This will start telnet for a connction to heise.de on port 80 using the source address 47.11.8.15.)

You may use fixsrcp.so without using the supplied shell script. The shared object relies on $LD_PRELOAD set to the path of the shared object and $FIXSRCIP set to the source IP address to use. This is especially useful for assigning different IP adresses for different users: just put

export LD_PRELOAD=/path/to/fixsrcip.so FIXSRCIP=47.11.8.15

into the respective ~/.bashrc file. Whenever the user logs in hell make his connections from 47.11.8.15.

No, theres no protection that the user disables fixsrcip at his own will.

No, fixsrcip doesnt work on SETUID programs. This is a limitation of LD_PRELOAD.

No, fixsrcip doesnt work for ICMP. This is a limitation of BSD sockets. Yes, that means that ping doesnt care about $FIXSRCIP.

GKrellM Newsticker project is a newsticker plugin for GKrellM.
GKrellM Newsticker is a newsticker plugin for the GTK+ system monitor GKrellM. It supports the widely-used RDF format.
GKrellM Newsticker is a plugin for GKrellM, a great GTK+ system monitor. This plugin scrolls headlines retrieved from news sites like Slashdot and others, each in its own panel.
The plugin comes with RDF entries for Slashdot, KDE Dot News and Gnotices. Integrating custom RDF files can be done in no time using the configuration dialog. The plugin is quite customizable, e.g. the user can set the speed the headlines are scrolled with, how many headlines should be displayed for each site etc. Clicking on a panel brings up the users favoritoute browser with the site belonging to the panel/headlines.
To easily share RDF URLs resp. newsticker sources, a users list can be exported and imported.
Enhancements:
- fixed the parser, so GKrellM Newsticker will work with more RDF files
- fixed a small bug in the proxy code
- number of headlines that are scrolled can be set
- added the ability to import and export a list of RDF sources
- code cleanup
- added a timeout of 10 seconds for downloading
- added a THEMES file

ulxmlrpcpp is a library to call methods on a remote server. ulxmlrpcpps main goal is to be as easy to use as possible but be fully compliant. It is object oriented and written in C++.
ulxmlrpcpp is a library to perform calls via XML-RPC in an object oriented approach implemented in C++. It is intended to have simple interfaces and to be easy to learn. But it shall still be fully compliant to the standards and safe in its use.
Unlike other implementations is does not insist on HTTP for transportation but might also accept other ways. For example a simple serial line with a user defined protocol.
This library uses expat as xml parser. In the unlikely case that you dont have it on your system download it from http://expat.sourceforge.net.
The following files are useful to learn more about this library:
- contrib/*
Contributed demos or other useful stuff
- ulxmlrpcpp/tests/*
Validators and test applications. Intended mainly for visual checking.
For the expected output see the according *.out.
val1_[server|client] are most important since they check most of the
functionality several thousand times.
secure_[server|client] demonstrates an approach to send and receive secure calls.
But dont take the encryption algorithm to serious, it is just to show how to do it
basically :-) Replace it by your favourite encryption algorithm.
mt_[server|client] does all the processing in parallel using threads.
- ulxmlrpcpp/apps/*
More or less useful applications in the real world
- ulxmlrpcpp/docs/en/index.html
The handbook with an introduction.
- ulxmlrpcpp/docs/api/html/index.html
The api docs. They are not part of the source distribution. Either download
them from the same place or generate yourself if you have doxygen installed.
Just type "make apidoc" in the the source directory.
In ulxr_config.h/ulxr_config-bcb5.h/ulxr_config-msvc.h/... there are some #defines that might be useful on non-autoconf systems or when you need to set up some things manually after running "configure".
There is also a directory for Borland BCB5 or M$VC++ users with project files. See "bcb5" resp. msvc and its subdirectories with the READMEs.
BCB5 users will want to turn off CodeGuard to increase the speed after they have verified that everything is working correctly with their applications.
ulxmlrpcpp is known to run fine on Linux, OpenBSD and Solaris, Windoze ports are working but not very reliably (BCB5 is ok from my point of view).
Enhancements:
- This release contains several fixes regarding SSL, timeout handling, and code generation.
- There are now more possibilities to create client and server code from sources as well as from introspection.
- The documentation contains examples on how to use the generated files.

Gtk2::Helper is a Perl module for convenience functions for the Gtk2 module.

SYNOPSIS

use Gtk2::Helper;

# Handle I/O watchers easily, like Gtk 1.x did
$tag = Gtk2::Helper->add_watch ( $fd, $cond, $callback, $data )
$rc = Gtk2::Helper->remove_watch ( $tag )

ABSTRACT

This module collects Gtk2 helper functions, which should make implementing some common tasks easier.

Gtk2::Helper->add_watch ( ... )

$tag = Gtk2::Helper->add_watch ( $fd, $cond, $callback, $data )

This method is a wrapper for Glib::IO->add_watch. The callback is called every time when its safe to read from or write to the watched filehandle.

$fd

Unix file descriptor to be watched. If you use the FileHandle module you get this value from the FileHandle->fileno() method.

$cond

May be either in or out, depending if you want to read from the filehandle (in) or write to it (out).

$callback

A subroutine reference or closure, which is called, if you can safely operate on the filehandle, without the risk of blocking your application, because the filehandle is not ready for reading resp. writing.

But aware: you should not use Perls builtin read and write functions here because these operate always with buffered I/O. Use low level sysread() and syswrite() instead. Otherwise Perl may read more data into its internal buffer as your callback actually consumes. But Glib wont call the callback on data which is already in Perls buffer, only when events on the the underlying Unix file descriptor occur.

The callback subroutine should return always true. Two signal watchers are connected internally (the I/O watcher, and a HUP watcher, which is called on eof() or other exceptions). Returning false from a watcher callback, removes the correspondent watcher automatically. Because we have two watchers internally, only one of them is removed, but probably not both. So always return true and use Gtk2::Helper->remove_watch to disable a watcher, which was installed with Gtk2::Helper->add_watch.

(Gtk2::Helper could circumvent this by wrapping your callback with a closure returning always true. But why adding another level of indirection if writing a simple "1;" at the end of your callback solves this problem? ;)

$data

This data is passed to the callback.

$tag

The method returns a tag which represents the created watcher. Later you need to pass this tag to Gtk2::Helper->remove_watch to remove the watcher.

Japa short from JACK and ALSA Perceptual Analyser is a perceptual or psychoacoustic audio spectrum analyser.

In contrast to JAAA, this is more an acoustical or musical tool than a purely technical one.

Possible uses include spectrum monitoring while mixing or mastering, evaluation of ambient noise, and (using pink noise), equalisation of PA systems.

JAPA allows you to measure two inputs at the same time, compare them, store them to memory and compare them to stored traces. It offers a number of resolutions, speeds, and various display options. The dual inputs and memories will find their way into future JAAA versions as well.

Display controls:

The controls below the spectrum window modify only the way things are presented, and not the actual measurement.

Range: Vertical display range, 20, 40, 60 or 80 dB. There are two scales. The one at the left is used for absolute displays. The one at the right always has 0 dB at half scale and is used when comparing two signals.

Scale: Controls the frequency scale. Grid lines are one octave apart, minor ticks are 1/3 octave. The default scale is logarithmic with ticks the standard 1/3 octave frequencies. There are two alternatives:

440 Hz log scale (click ) This follows the filter bandwidths, i.e. all filters will have the same width on the screen. The exact layout of this scale depends on the "warp factor" (see below).

Resp: The normal frequency response is flat in the sense that it will correctly indicate the level of a sine wave at all frequencies. The Prop setting adds a correction that is inversely proportional to the relative bandwidth of each filter. This will give a flat display when the input is pink noise.

Input controls:

There are two channels, called A and B. Each of them can be connected to one of four inputs, or switched off (this conserves CPU cycles - switching off the corresponding trace display does not).

Below the input selection is the gain control. Input gain can be set in steps of 5 dB. There are two more buttons:

Auto: Sets the gain based on the current signal level. This a momentary action.

Lnk: The second channels gain can be linked to the first for stereo operation. This includes the Auto function.

Analyser controls

Resol: Resolution of the filter bank. This sets the FFT size to 128, 256, or 512. The number of filters effectively used is almost equal to this number (japa interpolates between FFT bins to give correct amplitudes at all frequencies).

Warp: JAPA uses a warped FFT to analyse the spectrum. Frequency warping is done by replacing each delay element in the digital processing by an all-pass filter. This control allows you to set the warp factor, and this in turn determines how the filter bandwidths change as a function of the center frequency. You can see the warped scales by selecting the Warp option in the Scale display control. The default setting corresponds closely to the Bark scale. Higher values give more detail in the lower frequency range at the expense of the higher.

Speed: This controls the averaging filters that follow the spectrum analyser. The Low setting is mainly for noise measurement.

Memory store controls:

Each channel has a peak hold function. Note that this operates *after* the averaging done in the analyser and set by the Speed controls. There are two memories called X and Y. The current data for each channel can be stored to either memory. When the peak hold function is active, the current peak values are stored.

Note: the peak hold function and the two memories are reset when either the Resolution or Warp factor are changed. This may change in future versions.

Note: the gain controls are shown as part of the input blocks, but in reality the gain is applied only much later: when a trace is displayed or stored to memory. The result is that the peak hold function is not disturbed by changing the gain.

Trace display controls:

Three traces can be displayed at any time, and each row controls one of them. Options of the form A/B compare two inputs or memories. This means that the difference in dB between them is displayed rather than the actual levels.

KChart is the KOffice chart drawing application part of the KOffice suite. Use it to embed charts into your KOffice documents, e.g. a report written with KWord or a slideshow made with KPresenter.
Main features:
Easy to Use:
- default values for all parameters
- automatic ordinate axis computation based on highest/lowest data value
- default sizes (fonts, line widths...) relative to the window size
Highly Configurable:
- All of the parameters may be changed after configuring/drawing the chart.
- Size values (axis/grid line width, font sizes, bar width, dataset gap, pie chart radius ... ) may be specified in either absolute pixels or relative to the window size. This makes your chart layout-independent since such values are being recalculated automatically when the window dimensions have changed.
Flexible Layout:
- Legends may be centered at a chart edge or in a corner with the chart making way in vertical and/or in horizontal direction thus offering 16 legend/chart relationships to choose from
- Header and footer texts have special font type/size and color settings
Axes and Data:
- Automatical ordinate axis computation based on highest/lowest data value which can be easily replaced by programmer-defined start, end and delta value settings.
- Abscissa labels may be taken either from data cells containing the respective strings or from programmer-defined QStringLists or calculated automatically based on a format chosen by the user and values found in the cells
- Up to 8 axes: 2 left, 2 right, 2 top, 2 bottom
- A chart may have 2 different ordinates: e.g. left axis for series 1,2,3 right axis for data series 4
- Each axis may draw (sub-)grid lines using their own color, line width, style
Chart Combinations:
- sharing the same abscissa axis or using different ones (e.g Top and Bottom axis)
- sharing the same ordinate or using different ones (e.g Left and Right axis)
- Axes may use the same line color / line width as the bars (or the lines, resp.) which they belong to.
Chart Types:
- Bar: normal | stacked | percent, 2D | 3D-Look
- Line: normal | stacked | percent, 2D | 3D-Look, show marker: circle | square | diamond
- Area: normal | stacked | percent
- HiLo: normal | open-close
- Pie: normal | exploded | some exploded, 2D | 3D
- Ring: normal | exploded | some exploded, fixed thickness | relative thickness
- Polar: normal | stacked | percent

KSMS-Tool is a tool for sending SMS via your mobile phone. In principle, every modern mobile phone should be supported; these have been explicitely tested so far:
- Siemens S55
- Sony-Ericsson K700i
The connection to the mobile phone is established via the serial interface. In principle, every serial emulation (e.g. via USB, IrDA, Bluetooth) should also work if an error-free connection is guaranteed (especially in the wireless cases IrDA resp. Bluetooth).
Details on choosing a non-default connection to the mobile phone or on how to populate the user-defined addressbook can be found on the KSMS-Tool homepage.