Ports Search

from the README: Passive OS fingerprinting is based on information coming from a remote host when it establishes a connection to our system. Captured packets contain enough information to identify the operating system. In contrast to active scanners such as nmap and QueSO, p0f does not send anything to the host being identified. For more information, read Spitzner's text at: http://www.enteract.com/~lspitz/finger.html . from the maintainer: Use of this program requires read access to the packet filtering device, typically /dev/bpf0. Granting such access allows the users who have it to put your Ethernet device into promiscuous mode and sniff your network. See http://www.infoworld.com/articles/op/xml/00/05/29/000529opswatch.xml if you do not understand how this can be harmful. Running p0f with no options will cause it to analyse packets intended for other hosts.

from the README: Passive OS fingerprinting is based on information coming from a remote host when it establishes a connection to our system. Captured packets contain enough information to identify the operating system. In contrast to active scanners such as nmap and QueSO, p0f does not send anything to the host being identified. For more information, read Spitzner's text at: http://www.enteract.com/~lspitz/finger.html . from the maintainer: Use of this program requires read access to the packet filtering device, typically /dev/bpf0. Granting such access allows the users who have it to put your Ethernet device into promiscuous mode and sniff your network. See http://www.infoworld.com/articles/op/xml/00/05/29/000529opswatch.xml if you do not understand how this can be harmful. Running p0f with no options will cause it to analyse packets intended for other hosts.

This package provides a suite of modules for managing NetApp's NAS devices, commonly referred to as "filers". This is the first public release of my NetApp Perl API, and although I consider the code to be very stable, the API should be considered experimental. The convention I will be following regarding non-compatible API changes is as follows. I'm using a major.minor.subminor release naming convention, and I will promise to NOT make non-backwards compatible changes between subminor releases. However, in order to allow the API to evolve, it is entirely possible that non-backwards compatible changes will be made between minor releases. IOW, the major.minor release numbers can be considered an API version. Any changes to 1.1.0, 1.1.2, etc. must be backwards compatible with the previous 1.1.* releases. There is no guarantee that 1.2.0 will be 100% backwards compatible, although such changes will be made only when justified. The author does not believe in infinite backwards compatibility.

Litecoin is a peer-to-peer Internet currency that enables instant payments to anyone in the world. It is based on the Bitcoin protocol but differs from Bitcoin in that it can be efficiently mined with consumer-grade hardware. Litecoin provides faster transaction confirmations (2.5 minutes on average) and uses memory-hard, scrypt-based mining proof-of-work algorithm to target the regular computers and GPUs most people already have. The Litecoin network is scheduled to produce 84 million currency units. One of the aims of Litecoin was to provide a mining algorithm that could run at the same time, on the same hardware used to mine bitcoins. With the rise of specialized ASICs for Bitcoin, Litecoin continues to satisfy these goals. It is unlikely for ASIC mining to be developed for Litecoin until the currency is widely used.

microdc is a command-line based Direct Connect client written in C by Oskar Liljeblad and designed to build and run on modern POSIX compatible systems. It uses GNU Readline library for user interaction. Despite the command-line user interface, microdc is quite user friendly and simple to use. microdc2 is a future improvement (fork) of the microdc based on Oskar's code version 0.11.0. After version 0.12.0 the project was renamed to microdc2 on Oskar's request. Features of microdc2 include: - Nearly full support of the original Direct Connect protocol - GNU Readline support for command line editing and history - Sensible tab-completion of commands, user names, local files, remote files, speed names, and connection names - One process per connection for optimal transfer rates - Small memory footprint

qBittorrent is the open source bittorrent client in C++/Qt that uses libtorrent-rasterbar. It aims to be a good alternative to all other bittorrent clients. qBittorrent is fast, stable and provides unicode support as well as many features. Features: - Well-integrated and extensible Search Engine - Simultaneous search in most famous BitTorrent search sites - Per-category-specific search requests (e.g. Books, Music, Movies) - All BitTorrent extensions: DHT, Peer Exchange, Full encryption, Magnet URI, uTP - Remote control through a Web user interface (nearly identical to the regular UI, all in Ajax) - Advanced control over trackers, peers, and torrents: queueing and prioritizing, content selection and prioritizing - UPnP/NAT-PMP port forwarding support - Available in ~25 languages (Unicode support) - uTorrent spoofing to bypass private trackers whitelisting - Advanced RSS support with download filters (inc. regex) - IP Filtering (eMule and PeerGuardian compatible)

A light-weight DHCP Relay Agent. Why not the ISC DHCP Relay Agent? - If your RA has multiple interfaces, you get multiple requests for each request: DHCPREQUEST for 10.199.14.216 from 00:10:dc:d1:e6:39 (foo) via 10.199.14.1 DHCPACK on 10.199.14.216 to 00:10:dc:d1:e6:39 (foo) via 10.199.14.1 DHCPREQUEST for 10.199.14.216 from 00:10:dc:d1:e6:39 (foo) via 10.10.3.5: wrong network. DHCPNAK on 10.199.14.216 to 00:10:dc:d1:e6:39 via 10.10.3.5 This RA sends only one request, coming with the IP address of the LAN the request came from. - If your RA has multiple interfaces, the outgoing interfaces to the WAN needs to be active in the DHCP relay otherwise answers are not picked up. This RA uses a unicast socket for returning answers. - If your RA has non-ethernet interfaces (GIF-tunnels for example, which VPN back to the central network), the answers are not picked up by the RA.

The nettest and nettestd commands invoke client and server programs that are used for timing data throughput of vari- ous methods of interprocess communication. For TCP and OSI connections, the nettest program establishes a connec- tion with the nettestd program, and then it does count writes of size bytes, followed by count reads of size bytes. For UDP, the nettest program performs only writes; reads are not performed. The nettestd program, if used with UDP connections, reads the data packets and prints a message for each data packet it receives. The number and size of the reads and writes may not correlate with the number and size of the actual data packets that are trans- ferred; it depends on the protocol that is chosen. If you append an optional k (or K) to the size, count, or bufsize value, the number specified is multiplied by 1024.

OpenNX is an open source drop in replacement for NoMachine's NX client. It is compatible to the original client in that it uses the same syntax for the session configuration files (.nxs files). OpenNX is distributed under the GNU Lesser Public License v2.1. OpenNX is written in C++ and uses the excellent wxWidgets toolkit. Compared to the original client, it also adds some additional features which improve usability: - Ability to use the OpenSC framework to enable SmartCard based authentication for the initial SSH connection. - Ability to use a variety of different proxy types. - Ability to fetch session configuration files via http (read only) - Ability to disable configuration controls by providing a read only configuration file. - Dynamic use of libsmbclient, libcups, libopensc and pulseaudio (no static dependencies). - Uses libjpeg-turbo for speed improvement (if available).

Net::Frame is a fork of Net::Packet. The goal here was to greatly simplify the use of the frame crafting framework. Net::Packet does many things undercover, and it was difficult to document all the thingies. Also, Net::Packet may suffer from unease of use, because frames were assembled using layers stored in L2, L3, L4 and L7 attributes. Net::Frame removes all this, and is splitted in different modules, for those who only want to use part of the framework, and not whole framework. Finally, anyone can create a layer, and put it on his CPAN space, because of the modularity Net::Frame offers. For an example, see Net::Frame::Layer::ICMPv4 on my CPAN space.