Ports Search

hping is a command-line oriented TCP/IP packet assembler/analyzer. The interface is inspired to the ping(8) Unix command, but hping isn't only able to send ICMP echo requests. It supports TCP, UDP, ICMP and RAW-IP protocols, has a traceroute mode, the ability to send files between a covered channel, and many other features. While hping was mainly used as a security tool in the past, it can be used in many ways by people that don't care about security to test networks and hosts. A subset of the stuff you can do using hping: - Test firewall rules - [spoofed] port scanning - Test net performance using different protocols, packet size, TOS (type of service) and fragmentation. - Path MTU discovery - Files transfering even between really fascist firewall rules. - Traceroute like under different protocols. - Firewalk like usage. - Remote OS fingerprint. - TCP/IP stack auditing.

iLBC (internet Low Bitrate Codec) iLBC is a FREE speech codec suitable for robust voice communication over IP. The codec is designed for narrow band speech and results in a payload bit rate of 13.33 kbit/s with an encoding frame length of 30 ms and 15.20 kbps with an encoding length of 20 ms. The iLBC codec enables graceful speech quality degradation in the case of lost frames, which occurs in connection with lost or delayed IP packets. Features: * Bitrate 13.33 kbps (399 bits, packetized in 50 bytes) for the frame size of 30 ms and 15.2 kbps (303 bits, packetized in 38 bytes) for the frame size of 20 ms * Basic quality higher then G.729A, high robustness to packet loss * Computational complexity in a range of G.729A * Royalty Free Codec

Frontier::RPC implements UserLand Software's XML RPC (Remote Procedure Calls using Extensible Markup Language). Frontier::RPC includes both a client module for making requests to a server and a daemon module for implementing servers. Frontier::RPC uses RPC2 format messages. RPC client connections are made by creating instances of Frontier::Client objects that record the server name, and then issuing `call' requests that send a method name and parameters to the server. RPC daemons are mini-HTTP servers (using HTTP::Daemon from the `libwww' Perl module). Daemons are created by first defining the procedures you want to make available to RPC and then passing a list of those procedures as you create the Frontier::Daemon object. The Frontier::RPC2 module implements the encoding and decoding of XML RPC requests using the XML::Parser Perl module.

This module implements a scalable method of quickly propagating files to a large number of servers in one or more locations via rsync or scp. This module and the included script, ccp, take a much more efficient approach that is O(log n). Once the file(s) are been copied to a remote server, that server will be promoted to be used as source server for copying to remaining servers. Thus, the rate of transfer increases exponentially rather than linearly. Servers can be specified in groups (e.g. datacenter) to prevent copying across groups. This maximizes the number of transfers done over a local high-speed connection (LAN) while minimizing the number of transfers over the WAN. The number of multiple simultaneous transfers per source point is configurable. The total number of simultaneously forked processes is limited via Proc::Queue, and is currently hard coded to 32.

EPP is the Extensible Provisioning Protocol. EPP (defined in RFC 3730) is an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. As of writing, its only well-developed application is the provisioning of Internet domain names, hosts, and related contact details. RFC 3734 defines a TCP based transport model for EPP, and this module implements a proxy server for this model. You can use it to construct a daemon that maintains a single connection to the EPP server that can be used by many local clients, thereby reducing the overhead for each transaction. Net::EPP::Proxy is based on the Net::Server framework and Net::EPP::Client, which it uses to communicate with the server.

Is this module just like Net::FTP? No it is not! 1. It is a subclass and not a new class that uses Net::FTP underneath. That means the object is a normal Net::FTP object and has all the methods Net::FTP has. 2. It does not override Net::FTP methods (IE does not have methods the same name as Net::FTP) which means you don't have to sort through how the function differs from the standard version in the Net::FTP module. 3. Its waaaay simpler to use without a bunch of weird config stuff to cloud the issue, odd hard to remember arguments, obscure methods to replace valid existing ones that are part of Net::FTP, or new methods that are badly named (IE think "grep" on this one). There are other things as well. 4. It follows the paradigm of Perl name spaces, objects, and general good practice much better and in a way that is more intuitive and expandable.

This is the FreeBSD port of the OpenBSD relayd and relayctl. relayd is a daemon to relay and dynamically redirect incoming connections to a target host. Its main purposes are to run as a load-balancer, application layer gateway, or transparent proxy. The daemon is able to monitor groups of hosts for availability, which is determined by checking for a specific service common to a host group. When availability is con- firmed, Layer 3 and/or layer 7 forwarding services are set up by relayd. Layer 3 redirection happens at the packet level; to configure it, relayd communicates with pf(4). The following relayd functionality is not (yet) implemented in FreeBSD: - carp demote - modifying routing tables - snmp traps The relayctl program controls the relayd(8) daemon.

The paper library and accompanying files are intended to provide a simple way for applications to take actions based on a system- or user-specified paper size. This release is quite minimal, its purpose being to provide really basic functions (obtaining the system paper name and getting the height and width of a given kind of paper) that applications can immediately integrate. A more complete library, using a capabilities file for papers (giving, in addition to the size, informations like paper weigth, color, etc) will be released later. See the sources for paperconf(1) in src/paper.c for how to use the library. Copyright (C) Yves Arrouye <yves@debian.org>, 1996 Adrian Bunk <bunk@fs.tum.de> , 2000

If PDF is electronic paper, then pdftk is an electronic staple-remover, hole-punch, binder, secret-decoder-ring, and X-Ray-glasses. Pdftk is a simple tool for doing everyday things with PDF documents. Keep one in the top drawer of your desktop and use it to: Merge PDF Documents Split PDF Pages into a New Document Decrypt Input as Necessary (Password Required) Encrypt Output as Desired Burst a PDF Document into Single Pages Report on PDF Metrics, including Metadata and Bookmarks Uncompress and Re-Compress Page Streams Repair Corrupted PDF (Where Possible) Pdftk is also an example of how to use a library of Java classes in a stand-alone C++ program. Specifically, it demonstrates how GCJ and CNI allow C++ code to use iText's (itext-paulo) Java classes.

Portupgrade is a tool to upgrade installed packages via ports or packages. You can upgrade installed packages without having to reinstall depending or dependent packages. It can automatically trace dependency chains up and down upgrading packages recursively. This package also includes the following utilities: portinstall: Helps you install new ports in a handy way. portsvnweb: Instantly lets you browse change history via SVNweb. portversion: Replaces pkg_version(1) and helps you upgrade packages with portupgrade(1). (runs much faster) portsclean: Cleans ports workdir's, unreferenced distfiles, old and orphan shared libraries, and stale packages. portsdb: Creates binary database from the ports INDEX. ports_glob: Expands ports globs. pkg_deinstall: Wraps pkg_delete(1) and provides additional features. pkg_fetch: Fetches packages from a remote site. pkg_glob: Expands package globs. pkg_which: Checks which package a file came from quickly. pkgdb: Manages and searches the package database. pkgdu: Display a disk usage for installed packages.