Free input and output devices software for linux

Audio Input-Output Library (libaio) is meant to solve the problem of differing digital audio platforms once and for all.

JACK is unnecessarily complex for most applications, and while libaos support for file output is cool, it limits what the API can do and is therefore inadequate for any kind of real time application.

libaio provides a clean application interface and a simple compile-time driver switching decision, yielding a lightweight way to use the local sound hardware without having to care what it is.

Libaios first sparkle was when I, Hod McWuff (alias, of course), found myself trying to debug ALSA implementations for libao and madplay, and another audio-related project Id been working on. That project needed multiplatform audio support of its own, with latency management, which libao lacked.

It also seemed that libao shouldnt have been trying to be both a hardware abstraction *AND* an output abstraction, and also that it seemed more intuitive as an output (live vs file) abstraction.

Enter libaio. All it does is abstract the local sound hardware platform, to present a clean, uniform interface to playing and capturing digital audio, with facilities for basic latency management. It was written from scratch around its developing ALSA driver, from many many reference sources including libao and Robert Leslies excellent madplay MP3 decoder, and of course the ALSA documentation and examples.

Libaios distinction comes from its build-time decisionmaking. It only compiles and links the best driver available for the given platform. Therefore, selecting and loading a driver no longer applies; and well it shouldnt, theres never more than one correct choice anyway.

Libaio is not intended to replace libao; rather it is intended to supplement it. The key argument is, why would anyone EVER have more than one running sound platform type on any single machine? Sure, they might have ESD or ARTS, but they more resemble file output than a live device. Theres also the OSS emulation in ALSA, but given a good ALSA driver, whod use OSS?

Then theres the fact that applications have to tell libao what "plugin" to use, and all the drivers in libao have different parameters. That means the application has to know more than it should about what it shouldnt have to see. The app shouldnt have to say more than "give me the local device for playback with *** format" or something to that effect, and start writing.

Finally, plugins for stuff like proprietary file formats, ESD et al, but there shouldnt be any need for more than one of (ALSA|OSS|SUN|WIN32|MACOSX ) on any given distribution. Therefore, binary distribution of a compiled-in driver is possible, even preferred.

It is proposed that all of the hardware drivers in libao, and madplay, and several other places, be reviewed and ported to libaio. Then, they can be removed from those packages in favor of an AIO interface.

Installation:

## building
./configure
make


## installing (as root)
make install

simple instant messaging (sim) is an IRC client specialized for use with bitlbee. It is based on sic (http://suckless.org). It reads commands from standard input and prints all server output to standard output.
simple instant messaging also multiplexes all channel traffic into one output, so you dont have to switch to different channel buffers. sim must be customized by editing its source code to insert the correct username, server, password, and identification information.
Enhancements:
- The command operator was changed.
- Some code simplifications were done.
- The output format was adjusted.

Linux::Input is a Linux input event interface.

SYNOPSIS

Example: 1 joystick using event API

my $js1 = Linux::Input->new(/dev/input/event3);
while (1) {
while (my @events = $js1->poll(0.01)) {
foreach (@event) {
}
}
}

Example: 2 joysticks using joystick API (different event structure)

my $js1 = Linux::Input::Joystick->new(/dev/input/js0);
my $js2 = Linux::Input::Joystick->new(/dev/input/js1);
my $selector = IO::Select->new();
$selector->add($js1->fh);
$selector->add($js2->fh);

while (my $fh = $selector->can_read) {
my @event;
if ($fh == $js1->fh) {
@event = $js1->poll()
} elsif ($fh == $js2->fh) {
@event = $js2->poll()
}
foreach (@event) {
# work
}
}

Example 3: monitor all input devices

use File::Basename qw(basename);
my @inputs = map { "/dev/input/" . basename($_) }
;

my @dev;
my $selector = IO::Select->new();
foreach (@inputs) {
my $device = Linux::Input->new($_);
$selector->add($device->fh);
push @dev, $device;
}

while (my $fh = $selector->can_read) {
# work
}

Example 4: testing for events on the command line

# information on what event queue belongs to what device
cat /proc/bus/input/devices

# verify that events are coming in
sudo evtest.pl /dev/input/event*

Script for a multi-homed firewall is an example IPTables 1.2.1 script for a dual-homed firewall.

This script has not yet been tested thoroughly on a dual-homed firewall. If you find any problems, please drop me an email.

Current versions and documentation are available at http://www.sentry.net/~obsid/IPTables/rc.scripts.dir/current/

## User-defined Chains ##

Chain KEEP_STATE
The KEEP_STATE chain holds a few rules for generic stateful packet filtering.
This chain is called from many of the INPUT/OUTPUT chains to DROP "INVALID"
and perhaps "UNCLEAN" packets and allow other packets from "RELATED" or
"ESTABLISHED" connections.

CHECK_FLAGS
The CHECK_FLAGS chain contains a few rules to filter based on TCP flags.
These rules do indeed filter mainly bogus/malicious traffic(scans, etc). It
would be a good idea to keep an eye on what these rules send to the logs.
Null scans are also logged and dropped, in the mangle table.

DENY_PORTS
The DENY_PORTS chains contains a few rules to DROP and/or LOG packets based
on the source and/or destination port number of the packet.

Packets destined to/from the following ports are dropped by default in the script. These are just some examples of some commonly used ports that certain daemons/trojans/DDoS agents may utilize.

## TCP ##
137:139 SMB
2049 NFS
6000:6063 X
20034 Netbus 2 Pro
12345:12346 Netbus
27374 SubSeven
27665,27444,31335 Trinoo
10498,12754 Mstream

## UDP ##
2049 NFS
31337 BO2k
27444,31335 Trinoo
10498 mstream

These are just examples to stare at. They guarantee no real protection against the associated trojans.

For more common port numbers check out:
http://www.sans.org/newlook/resources/IDFAQ/oddports.htm

ALLOW_PORTS
The ALLOW_PORTS chain simply ACCEPTs packets based on port number. If you have
a default FORWARD policy of DROP, then you would need to utilize a chain like
this if you are DNATing/routing connections behind the firewall or perhaps
running services on(!!!) the firewall.

ALLOW_ICMP
The ALLOW_ICMP chains simply allows packets based on ICMP type. Currently
the firewall allows the flow of the following ICMP types:
Echo Reply (pong)
Destination Unreachable
Echo Request (ping)
TTL Exceeded (traceroute)

SRC_EGRESS && DST_EGRESS
The SRC_EGRESS and DST_EGRESS chains filter packets that have a source or
destination IP address matching an array of private or reserved subnets.

TOS_OUTPUT
The TOS_OUTPUT chain exists in the mangle table and mangles the TOS(Type
of Service) field in the IP header of locally generated, outgoing packets.

TOS_PREROUTING
The TOS_PREROUTING chain exists in the mangle table and mangles the TOS(Type
of Service) field in the IP header of packets being routed through the firewall.

The following user-defined chains are pretty obvious. The firewall script is designed to have a user-defined INPUT and OUTPUT chain for every available interface. From these user-defined chains are called the user-defined chains
mentioned above, which I call "Special Chains". The chains below are then called by the built-in INPUT/OUTPUT/FORWARD chains. This isnt really the rule, of course, alot of the user-defined chains mentioned above are called directly from the built-in INPUT/OUTPUT/FORWARD chains. This is done to assure proper flow of the packets through the filters.

EXTERNAL_INPUT
INTERNAL_INPUT
DMZ_INPUT
LO_INPUT
EXTERNAL_OUTPUT
INTERNAL_OUTPUT
DMZ_OUTPUT
LO_OUTPUT

GnuPG::Interface is a Perl interface to GnuPG.

SYNOPSIS

# A simple example
use IO::Handle;
use GnuPG::Interface;

# settting up the situation
my $gnupg = GnuPG::Interface->new();
$gnupg->options->hash_init( armor => 1,
homedir => /home/foobar );

# Note you can set the recipients even if you arent encrypting!
$gnupg->options->push_recipients( ftobin@cpan.org );
$gnupg->options->meta_interactive( 0 );

# how we create some handles to interact with GnuPG
my $input = IO::Handle->new();
my $output = IO::Handle->new();
my $handles = GnuPG::Handles->new( stdin => $input,
stdout => $output );

# Now well go about encrypting with the options already set
my @plaintext = ( foobar );
my $pid = $gnupg->encrypt( handles => $handles );

# Now we write to the input of GnuPG
print $input @plaintext;
close $input;

# now we read the output
my @ciphertext = ;
close $output;

waitpid $pid, 0;

GnuPG::Interface and its associated modules are designed to provide an object-oriented method for interacting with GnuPG, being able to perform functions such as but not limited to encrypting, signing, decryption, verification, and key-listing parsing.

How Data Member Accessor Methods are Created

Each module in the GnuPG::Interface bundle relies on Class::MethodMaker to generate the get/set methods used to set the objects data members. This is very important to realize. This means that any data member which is a list has special methods assigned to it for pushing, popping, and clearing the list.

Understanding Bidirectional Communication

It is also imperative to realize that this package uses interprocess communication methods similar to those used in IPC::Open3 and "Bidirectional Communication with Another Process" in perlipc, and that users of this package need to understand how to use this method because this package does not abstract these methods for the user greatly. This package is not designed to abstract this away entirely (partly for security purposes), but rather to simply help create proper, clean calls to GnuPG, and to implement key-listing parsing. Please see "Bidirectional Communication with Another Process" in perlipc to learn how to deal with these methods.

Using this package to do message processing generally invovlves creating a GnuPG::Interface object, creating a GnuPG::Handles object, setting some options in its options data member, and then calling a method which invokes GnuPG, such as clearsign. One then interacts with with the handles appropriately, as described in "Bidirectional Communication with Another Process" in perlipc.

HistView application takes an ASCII changelog as input and outputs a formatted HTML page.

When developing some piece of software, one usually records its development history in an ASCII file, preceding all changes with a "hint" of the kind of change - such as an "+" for a new addition, or a "!" for a bug fix. After a while, one decides to release the package. And a while later the question arises, how to present the latest changes to users who wish to see the list of changes first to decide whether its worth to update. At this moment, one can just place the plain text file somewhere accessible on the net - but wouldnt it look smarter to have it formatted as a nice HTML document? If you would like this, but dont want to waste time rewriting the history in HTML, HistView ist for you: it just reads in the history file, and formats it in HTML. Provided you use a style similiar to what I do.

Apache2::DebugFilter is a Perl module to debug mod_perl and native Apache2 filters.

Synopsis

# httpd.conf
# ----------
PerlModule Apache2::DebugFilter
# Connection snooping (everything)
PerlInputFilterHandler Apache2::DebugFilter::snoop_connection
PerlOutputFilterHandler Apache2::DebugFilter::snoop_connection

# HTTP Request snooping (only HTTP request body)
< Location /foo >
PerlInputFilterHandler Apache2::DebugFilter::snoop_request
PerlOutputFilterHandler Apache2::DebugFilter::snoop_request
< /Location >

# in handlers
#------------
use Apache2::DebugFilter;
# convert bb to an array of bucket_type => data pairs
my $ra_data = Apache2::DebugFilter::bb_dump($bb);
while (my($btype, $data) = splice @data, 0, 2) {
print "$btype => $datan";
}

# dump pretty formatted bbs content to a filehandle of your choice
bb_dump($bb, *STDERR);

Filter Handlers

snoop_connection()

The snoop_connection() filter handler snoops on request and response data flow. For example if the HTTP protocol request is filtered itll show both the headers and the body of the request and response.

Notice that in order to see requests input body, the response handler must consume it.

The same handler is used for input and output filtering. It internally figures out what kind of stream its working on.
To configure the input snooper, add to the top level server or virtual host configuration in httpd.conf:

PerlInputFilterHandler Apache2::DebugFilter::snoop_connection

To snoop on response output, add:

PerlOutputFilterHandler Apache2::DebugFilter::snoop_connection

Both can be configured at the same time.

If you want to snoop on what an output filter MyApache2::Filter::output does, put the snooper filter after it:

PerlOutputFilterHandler MyApache2::Filter::output
PerlOutputFilterHandler Apache2::DebugFilter::snoop_connection

On the contrary, to snoop on what an input filter MyApache2::Filter::input does, put the snooper filter before it:

PerlInputFilterHandler Apache2::DebugFilter::snoop_connection
PerlInputFilterHandler MyApache2::Filter::input

This is because snoop_connection is going to be invoked first and immediately call MyApache2::Filter::input the input filter for data. Only when the latter returns, snoop_connection will do its work.

snoop_request()

The snoop_request() filter handler snoops only on HTTP request and response bodies. Otherwise its similar to snoop_connection(). Only normally its configured for a specific < Location >. For example:

< Location /foo >
PerlInputFilterHandler Apache2::DebugFilter::snoop_request
PerlOutputFilterHandler Apache2::DebugFilter::snoop_request
< /Location >

HCS Open Source Project consists of a do-it-yourself home automation hardware and software system.

The HCS Open Source Project is a stand-alone home automation control system which consists of hardware (main controllers and remote networked controllers) and software to monitor and control various devices around your house.

The current plans support using wired and wireless X10 modules, as well as analog, digital, and voice input and output. Once the HCS is programmed, the use of a PC is not required.

CS stands for Home Control System. Originally designed by Steve Ciarcia for the article "Home Run Control System" for Byte magazine.

What is the HCS II? The HCS II is an expandable, network-based (RS485), intelligent-node, industrial-oriented supervisory control system intended for demanding home control applications.

The HCS incorporates direct and remote digital inputs and outputs, direct and remote analog inputs and outputs, real-time or Boolean decision event triggering, X-10 transmission and reception, infrared remote control transmission and reception, remote LCD displays, and a master console.

The HCS II system architecture consists of a central supervisory controller (SC) connected to up to 32 other functional modules (called links) via a RS485 serial network. The SC and the COMM-Links can operate independently and dont need each other to function.

This allows easy testing or incorporation as intelligent subsystems in other control equipment. Initially the subsystems links all shared a comon 8031 controller board (generically called a COMM-Link) with the I/O customized for each application.