Free mobile agent software for linux

Mobile::UserAgent is a mobile user agent string parsing class.

SYNOPSIS

### Print the information parsed from a user-agent string:
use Mobile::UserAgent;
my $useragent = Nokia6600/1.0 (4.09.1) SymbianOS/7.0s Series60/2.0 Profile/MIDP-2.0 Configuration/CLDC-1.0;
my $uaobj = new Mobile::UserAgent($useragent);
if ($uaobj->success()) {
print Vendor: . $uaobj->vendor() . "n";
print Model: . $uaobj->model() . "n";
print Version: . $uaobj->version() . "n";
print Series60: . $uaobj->isSeries60() . "n";
print Imode?: . $uaobj->isImode() . "n";
print Mozilla?: . $uaobj->isMozilla() . "n";
print Standard?: . $uaobj->isStandard() . "n";
print Rubbish?: . $uaobj->isRubbish() . "n";
}
else {
print "Not a mobile user-agent: $useragentn";
}


### Determine if the client is a mobile device.
use Mobile::UserAgent ();
use CGI ();

# Check 1: (check if it sends a user-agent profile URL in its headers)
foreach my $name (X_WAP_PROFILE,PROFILE,13_PROFILE,56_PROFILE) {
if (exists($ENV{"HTTP_$name"})) {
print "Client has a user-agent profile header, so its probably a mobile device.n";
last;
}
}

# Check 2: (check if it supports WML):
my $q = new CGI();
if ($q->Accept(text/vnd.wap.wml) == 1) {
print "Client supports WML so its probably a mobile device.n";
}

# Check 3: (check if this class can parse it)
my $uaobj = new Mobile::UserAgent();
if ($uaobj->success()) {
print "Clients user-agent could be parsed, so its a mobile device.n";
}

Parses a mobile user agent string into its basic constituent parts, the most important being vendor and model.

One reason for doing this would be to use this information to lookup vendor-model specific device characteristics in a database. You can use also use user agent profiles to do this (for which Ive developed other classes), but not all mobile phones have these, especially the older types. Another reason would be to detect if the visiting client is a mobile handset.

Only real mobile user-agent strings can be parsed succesfully by this class. Most WAP emulators are not supported because they usually dont use the same user-agent strings as the devices they emulate.

HTTP::MobileAgent::EZweb is a EZweb implementation.

SYNOPSIS

use HTTP::MobileAgent;

local $ENV{HTTP_USER_AGENT} = "UP.Browser/3.01-HI02 UP.Link/3.2.1.2";
my $agent = HTTP::MobileAgent->new;

printf "Name: %sn", $agent->name; # "UP.Browser"
printf "Version: %sn", $agent->version; # 3.01
printf "DevieID: %sn", $agent->device_id; # HI02
printf "Server: %sn", $agent->server; # "UP.Link/3.2.1.2"

# e.g.) UP.Browser/3.01-HI02 UP.Link/3.2.1.2 (Google WAP Proxy/1.0)
printf "Comment: %sn", $agent->comment; # "Google WAP Proxy/1.0"

# e.g.) KDDI-TS21 UP.Browser/6.0.2.276 (GUI) MMP/1.1
print "XHTML compiant!n" if $agent->xhtml_compliant; # true

HTTP::MobileAgent::EZweb is a subclass of HTTP::MobileAgent, which implements EZweb (WAP1.0/2.0) user agents.

HTTP::MobileAgent::JPhone Perl module is a J-Phone implementation.

SYNOPSIS

use HTTP::MobileAgent;

local $ENV{HTTP_USER_AGENT} = "J-PHONE/2.0/J-DN02";
my $agent = HTTP::MobileAgent->new;

printf "Name: %sn", $agent->name; # "J-PHONE"
printf "Version: %sn", $agent->version; # 2.0
printf "Model: %sn", $agent->model; # "J-DN02"
print "Packet is compliant.n" if $agent->packet_compliant; # false

# only availabe in Java compliant
# e.g.) "J-PHONE/4.0/J-SH51/SNXXXXXXXXX SH/0001a Profile/MIDP-1.0 Configuration/CLDC-1.0 Ext-Profile/JSCL-1.1.0"
printf "Serial: %sn", $agent->serial_number; # XXXXXXXXXX
printf "Vendor: %sn", $agent->vendor; # SH
printf "Vender Version: %sn", $agent->vendor_version; # "0001a"

my $info = $self->java_info; # hash reference
print map { "$_: $info->{$_}n" } keys %$info;

HTTP::MobileAgent::JPhone is a subclass of HTTP::MobileAgent::Vodafone.

Mobile Web Proxy is a (CGI) tool to make more Web pages available from some mobile devices (cell phone Web browsers, etc.).
When I began using my cell phones mobile web browser, one of the things I realized was that there were a lot of web pages that my cell phones web browser simply wouldnt let me see. My shiny new Motorola Razr from T-Mobile, for many pages, would display an error message like "413: Page cannot be displayed." It happened annoyingly often; browsing the web from my cell phone was a lot like trying to read a book or a magazine with large chunks simply ripped out. And when I tried troubleshooting, I might have missed something, but it seemed like a big problem without an easily available solution.
So I tried to provide my own solution. I made a proxy that would present webpages for the mobile web so that they would display in a way that would work for my cell phones web browser. Technologies include paging, tag cleaning, and optional caching to improve performance, but without getting into technical details, this means that I can access some pages on the web that I couldnt access earlier.
Enhancements:
- A bug that caused the script to spuriously report 404 errors was fixed.
- A smaller default page size was set so that tag-rich pages would be rendered in a way more likely to be displayable on mobile Web browsers.

Mobile::Wurfl is a Perl module interface to WURFL (the Wireless Universal Resource File.

SYNOPSIS

my $wurfl = Mobile::Wurfl->new(
wurfl_home => "/path/to/wurfl/home",
db_descriptor => "DBI:mysql:database=wurfl:host=localhost",
db_username => wurfl,
db_password => wurfl,
wurfl_url => q{http://wurfl.sourceforge.net/wurfl.xml}
);

my $dbh = DBI->connect( $db_descriptor, $db_username, $db_password );
my $wurfl = Mobile::Wurfl->new( dbh => $dbh );

my $desc = $wurfl->get( db_descriptor );
$wurfl->set( wurfl_home => "/another/path" );

$wurfl->create_tables( $sql );
$wurfl->update();
$wurfl->get_wurfl();
$wurfl->rebuild_tables();

my @devices = $wurfl->devices();

for my $device ( @devices )
{
print "$device->{user_agent} : $device->{id}n";
}

my @groups = $wurfl->groups();
my @capabilities = $wurfl->capabilities();
for my $group ( @groups )
{
@capabilities = $wurfl->capabilities( $group );
}

my $ua = $wurfl->canonical_ua( "SonyEricssonK750i/R1J Browser/SEMC-Browser/4.2 Profile/MIDP-2.0 Configuration/CLDC-1.1" );
my $deviceid = $wurfl->deviceid( $ua );

my $wml_1_3 = $wurfl->lookup( $ua, "wml_1_3" );
print "$wml_1_3->{name} = $wml_1_3->{value} : in $wml_1_3->{group}n";
my $fell_back_to = wml_1_3->{deviceid};
my $width = $wurfl->lookup_value( $ua, "max_image_height", no_fall_back => 1 );
$wurfl->cleanup();

Mobile::Wurfl is a perl module that provides an interface to mobile device information represented in wurfl (http://wurfl.sourceforge.net/). The Mobile::Wurfl module works by saving this device information in a database (preferably mysql).

It offers an interface to create the relevant database tables from a SQL file containing "CREATE TABLE" statements (a sample is provided with the distribution). It also provides a method for updating the data in the database from the wurfl.xml file hosted at http://www.nusho.it/wurfl/dl.php?t=d&f=wurfl.xml.
It provides methods to query the database for lists of capabilities, and groups of capabilities. It also provides a method for generating a "canonical" user agent string (see "canonical_ua").

Finally, it provides a method for looking up values for particular capability / user agent combinations. By default, this makes use of the hierarchical "fallback" structure of wurfl to lookup capabilities fallback devices if these capabilities are not defined for the requested device.

Mobile Device Information project is a Java Swing application that provides desktop interface access to the WURFL (Wireless Universal Resource FiLe).
The WURFL contains information about the capabilities of a huge number of wireless devices.
The project has been created by me (Jim McLachlan), a software consultant specialising in Java projects for mobile devices (primarily J2METM clients with J2EETM back-ends).
Part of my consultancy work has been the "education" of clients to the limitations of the cross-platform nature of Java on mobile devices. I have regularly had to field questions like "Is the < mobile device > MIDP-1.0 or MIDP-2.0 compliant?" and "How many different MIDP-2.0 devices are there?".
As part of my recent web site development, where I intend to sell my J2ME applications, I found myself in need of some "rich content" that would be useful to consumers and not just developers. Hopefully, this tool will be useful to people wanting to know more about their devices.
Enhancements:
- This release finally resolves problems with the id pseudo-capability.
- Version 1.2 caused make/model data to be hidden; 1.2.1 fixed this, but added a bug which used the fallback instead of the current "id".

Linux Mobile System project (LMS) is a full Linux system whose support is the new USB Flash Memory Drives. The intention is to boot any PC with USB support with our system and therefore we will have every administration and analysis applications that we have selected, so we will not need install it. This way, always we will be able to get our Linux system ready to use in our pocket.
This project arose with the intention to study the Linux system of exhaustive way and simultaneously enjoy with it. The initial idea is to fuse two separated disciplines: the programming and the systems management. So well center our study in the denominated "system programming, as much networking level as at device level (drivers).
Main features:
- To initiate our Linux system from memories flash USB.
- The system will be a selection of common GNU tools in every system: disk diagnosis, memory, hardware, networks monitoring tools, etc.
- LMS Tux
- As far as possible well develop new tools and/or utilities with the objective to study deeply the underlying technology.
- The programming languages used will be C, C++, Python and Perl, without forget the system shell scripts.
- The resources minimization (disk space, memory...) isnt a functional objective of the developments.
LMSs main aim is to achieve a highly specialized distribution of GNU/Linux which can carried through the USB Flash Memory Drives. Once the distribution is ready in the USB device, it can be carried in your own pocket and you can start up any PC x86 with no need to install it directly in the PC.
The LMS system is aimed at the development of specific tasks such as network administration, security analysis of networks, and recovery and repair of host data, as well as all information exchange, which is what makes it different from other portable systems such as "live CDs". The main idea is to carry all the potency of Linux and our tools in our own pockets, ready to be used.

Remote Monitoring Agent (RMA in short) is an auxiliary application for HostMonitor. Enterprise license for Advanced Host Monitor already includes license for 10 installations of the agent. Holders of a Lite, Standard or Professional licenses may buy an additional license for Remote Monitoring Agent separately.
HostMonitor 4.0+ can monitor remote networks using Remote Monitoring Agents (RMA). RMA is small application that accepts requests from HostMonitor, performs test and provides information about test result back to HostMonitor.
Why you may need RMA? Here are just several reasons:
RMA increases security of the network. When you have to run the tests such as CPU Usage test or Performance Counters tests on a remote Windows system, HostMonitor must be able to log in to that system with administrators privileges. Instead you may now use an agent installed on that remote system. In this case HostMonitor will not have to log on to that system at all. HostMonitor needs just one TCP port to communicate with the RMA agent (by default it uses #1055 port, however you may set an agent to use any other port).
Remote Monitoring Agent is also a very useful tool when you have to monitor two (or many) separated networks (connected through Internet). In this case installing just one instance of RMA behind the firewall in network "A" will allow to monitor entire network "A" using the HostMonitor located in the network "B" with just one open TCP port.
RMA decreases the network traffic. E.g. frequent use of "File Integrity" or "Compare Files" tests in an array of remote systems may apply significant load on the network. The more and the bigger files you test the more traffic increase you get. RMA runs locally and sends only the test results to the HostMonitor thus decreasing the amount of network traffic.
Remote Monitoring Agent simplifies network administration. You no longer need to share local drives/folders to perform tests such as File Integrity, Folder/File Size, File Availability, Count Files, etc
RMA for Linux / BSD / Solaris allows you to perform tests that HostMonitor cannot perform. For example HostMonitor cannot monitor processes that are running on Linux systems. RMA can do that.
Main features:
- All traffic between Remote Monitoring Agents and HostMonitor is encrypted.
- It is possible to customize the list of enabled tests for each of the agents (e.g. living only Count Files and UNC tests only).
- You can restrict incoming TCP connections with the list of acceptable addresses.
- With RMA Manager you may configure, restart and even upgrade agent(s) remotely.