Ports 搜索

Icinga is an enterprise grade open source monitoring system which keeps watch over networks and any conceivable network resource, notifies the user of errors and recoveries and generates performance data for reporting. Scalable and extensible, Icinga can monitor complex, large environments across dispersed locations. Icinga is a fork of Nagios and is backward compatible. That said, Nagios configurations, plugins, and addons can all be used with Icinga. Though Icinga retains all the existing features of its predecessor, it builds on them to add many long awaited patches and features requested by the user community.

Kismet is an 802.11 layer2 wireless network detector, sniffer, and intrusion detection system. Kismet will work with any wireless card which supports raw monitoring (rfmon) mode, and can sniff 802.11a, 802.11b, and 802.11g traffic. Kismet identifies networks by passively collecting packets. In addition to standard networks, it can detect (and given time, decloak) hidden networks, and infer the presence of nonbeaconing networks via data traffic. Capture sources that are known to be supported: Atheros, Prism2, WSP100, Drone, wtapfile, pcapfile. Kismet also supports radiotap headers and should work with current FreeBSD systems.

This module supports the ability to retrieve data from several different models of TL1 devices. Explictly supported devices include the following: * Cisco ONS15327 * Cisco ONS15454 * Cisco ONS15808 * Nortel OME 6500 * Nortel HDXc * Ciena CoreDirector * Infinera DTC * Fujitsu FLASHWAVE 7500 Each specifically supported device has its own GRNOC::TL1::Device module, which sets the default port and prompt used for that device. They also may each export their own unique commands on top of what is already provided in GRNOC::TL1::Device. Raw commands and output can be sent and received, or output can be parsed via the parse function, or by calling a function for that device.

SEND is the implementation of RFC3971 Secure Neighbor Discovery (SEND). SEND cryptographically secures the IPv6 neighbor discovery protocol, countering the threats discussed in RFC3756 (IPv6 Neighbor Discovery (ND) Trust Models and Threats). The implementation is a new version of DoCoMo's SEND (send_0.2) that was implemented completely in user space. Novelty in send_0.3 is the native SEND API that avoids the need for the use of netgraph and BPF, which makes send_0.3 portable over different BSD platforms and significantlly more efficient. Also included in the distribution are implementations of RFC3972 Cryptographically Generated Addresses (CGAs) and RFC3779 X.509 Extensions for IP Addresses and AS Identifiers.

GTK based Gnutella client which supports the standard Gnutella operations. Search, download, file sharing, bandwidth limiting, host caching, as well as some basic statistics. Now with enhanced features, such as PARQ queueing, PFSP, DHT, push-proxies, UPnP, NAT-PMP and others, making it a stable and fully functional graphical gnutella client for *nix systems. An excellent way to find that hidden file on the internet that you know exists but standard search engines do not seem to carry. IRC: #gtk-gnutella on freenode.net

KTorrent是一个KDE下的BitTorrent客户端。它的主要特点是： o 下载torrent文件 o 上传速度限制 o 使用Bittorrent下载网站的搜索引擎来进行Internet搜索 o UDP的Tracker o 使用UPnP进行端口转发 o IP阻止插件 o 导入部分或全部下载 o 支持分布式哈希表 o 协议加密 o 带宽调度 o 目录扫描，自动加载目录中的torrent o 可以添加tracker到torrent中 o 对多文件的torrent，进行文件优先顺序设置

Unworkable is a BSD-licensed BitTorrent implementation for UNIX written from-scratch in C. It uses libevent for scalable asynchronous networking and the mmap() system call for local data access. Some of the goals of the project include (in no particular order) high code quality, efficiency, simplicity and security. Unworkable is still in an early stage of development, and is far behind most other BitTorrent implementations. However, it is usable for some basic things and the source code is quite minimal(4,000 lines of C compared to rTorrent's 40,000+ of C++).

It all started when we got some new routers, which told me the following when trying to upload configuration or download images from it: The TFTP server doesn't support the blocksize option. My curiousity was triggered, it took me some reading of RFCs and other documentation to find out what was possible and what could be done. Was plain TFTP very simple in its handshake, TFTP with options was kind of messy because of its backwards capability: The first packet returned could either be an acknowledgement of options, or the first data packet. Going through the source code of src/libexec/tftpd and going through the code of src/usr.bin/tftp showed that there was a lot of duplicate code, and the addition of options would only increase the amount of duplicate code. After all, both the client and the server can act as a sender and receiver. At the end, it ended up with a nearly complete rewrite of the tftp client and server. It has been tested against the following TFTP clients and servers: - Itself (yay!) - The standard FreeBSD tftp client and server - The Fedora Core 6 tftp client and server - Cisco router tftp client - Extreme Networks tftp client It supports the following RFCs: RFC1350 - THE TFTP PROTOCOL (REVISION 2) RFC2347 - TFTP Option Extension RFC2348 - TFTP Blocksize Option RFC2349 - TFTP Timeout Interval and Transfer Size Options RFC3617 - Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP) It supports the following unofficial TFTP Options as described at http://www.compuphase.com/tftp.htm: blksize2 - Block size restricted to powers of 2, excluding protocol headers rollover - Block counter roll-over (roll back to zero or to one) From the tftp program point of view the following things are changed: - New commands: "blocksize", "blocksize2", "rollover" and "options" - Development features: "debug" and "packetdrop" If you try this tftp/tftpd implementation, please let me know if it works (or doesn't work) and against which implementaion so I can get a list of confirmed working systems.

Snort 2.9 introduces the DAQ, or Data Acquisition library, for packet I/O. The DAQ replaces direct calls to PCAP functions with an abstraction layer that facilitates operation on a variety of hardware and software interfaces without requiring changes to Snort. It is possible to select the DAQ type and mode when invoking Snort to perform PCAP readback or inline operation, etc. The DAQ library may be useful for other packet processing applications and the modular nature allows you to build new modules for other platforms.

JGroups is a toolkit for reliable multicast communication. (Note that this doesn't necessarily mean IP Multicast, JGroups can also use transports such as TCP). It can be used to create groups of processes whose members can send messages to each other. The main features include: * Group creation and deletion * Joining and leaving of groups * Membership detection and notification about joined/left/crashed members * Detection and removal of crashed members * Sending and receiving of member-to-group messages (point-to-multipoint) * Sending and receiving of member-to-member messages (point-to-point)