README - v0.24.b12, 30-SEP-2007

Contents

  1. What is QNetwatch?

  2. Installation

  3. Command line arguments / user privileges

  4. Dynamic DNS check

  5. IP packet sniffer and analyzer

  6. Connection monitor

  7. GUI style plugins

  8. Bugs and restictions

  9. How to create diffs and install patches

  10. Supported platforms

  11. How to port

  12. Contact

  13. Contributing

  14. License and copyright

  15. Usage warning

1. What is QNetwatch?

QNetwatch is a cross-platform network traffic monitor built around the Qt GUI toolkit and some OS dependant libraries which are handled by a wrapper API (an abstraction layer).

Originally, QNetwatch was designed as a simple Qt frontend to display some status information and the load for a given network interface. Meanwhile, lots of hopefully nice surrounding features have been added over time.

There is a built-in libpcap-based IP packet sniffer for simple network analysis. A companioning packet analyzer will help debugging network protocols by also interpreting the raw packet data.

QNetwatch also has a connection monitor that can be used to track local connections (to and from 'localhost'), to view the status of masqueraded connections (Linux systems only for now, useful on firewalls) and to watch locally running servers (or daemons).

For a list of supported platforms, see section 10. A short description about how to port QNetwatch to other platforms can be found in section 11.

2. Installation

Software requirements

Remarks

A supported platform

additional requirements, see section 10

Qt 3.3.3, 3.3.4, 3.3.5

http://www.trolltech.com/

GNU make 3.8+

http://www.fsf.org/

libpcap 0.8+

http://www.tcpdump.org

How to build and install QNetwatch

Uncompress and untar the source distribution archive:

# bzip2 -d qnetwatch-<version>.tar.bz2
# tar xvf qnetwatch-<version>.tar

Make sure that the environment is setup correctly:

# cd qnetwatch
# export QTDIR=/your/qt/installation/directory
# export LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH

Now you should change the passphrase which will be used for encryption. You need to remember it for later updates, otherwise QNetwatch will not be able to decrypt any stored passwords and thus you'll have to reenter them each time you install a new version. Anyway, it is extremely important to change the passphrase, otherwise your passwords could be decrypted with the default key, because it's well-known.

Edit the Makefile, find the KEY definition and change it:

# vi Makefile
...
ifndef KEY
KEY = tH1sIsAg00DpAsspHra5E
endif
...

Note that you could also change the passphrase by supplying it on the gmake command line. The phrase itself is not stored in the binary or elsewhere, but used to generate the seed for the crypto-algorithm. Passphrases containing white-space characters are allowed, but need to be quoted, of course.

Now you are ready to run the build process:

# gmake

If you have an SMP system, you should better run gmake in jobserver mode, this is completely safe and much faster. For example:

# gmake -j3

(replace "3" with "#CPUs + 1")

After QNetwatch has been compiled and linked completely, become superuser (root) and run

# gmake install

That's it, basically.

However, you might experience problems when linking, which depend on the Qt library and how is was built. The default linkage for QNetwatch assumes that Qt was built with thread support ("-thread" parameter on the configure command line of Qt!). If this isn't the case and you only have a single-threaded library, QNetwatch will fail to link. Don't worry, you don't need to repeat the whole step of rebuilding Qt from source (it's very time-consuming, even on high-end hardware). Just run gmake with the MT option set to 0:

# gmake -j3 MT=0

Note that it's recommended to use the multi-threaded variant of Qt. The GUI will work much more responsive, and on SMP/NUMA systems you will be able to fully utilize the additional performance.

Please see top of Makefile for a complete list of available gmake command line options.

How to use distcc, icecream and/or ccache to speed up compilation

This requires a trick for setting up qmake correctly to make it create the right makefile for a pre-processor command to be used. QNetwatch's build system supports this with the optional gmake flag CXXPP.

distcc / ccache:

Assuming distcc was setup correctly to spread compilation jobs, simply use the following gmake command line and have fun:

# export DISTCC_HOSTS="host1 host2 host3"
# gmake -j6 CXXPP="distcc g++" install

Using three of my x86 based systems at home, I was able to speed up compilation by more than 100% compared to compiling it only on my 2.4GHz P4 based laptop. Waiting more than two minutes (122s) compared to waiting less than one minute (49s) is a motivating argument :).

To use ccache, simply change "distcc g++" in the above command line to "ccache g++" and setup the environment variable CCACHE_PREFIX to combine both pre-processors:

# export CCACHE_PREFIX="distcc"
# export DISTCC_HOSTS="host1 host2 host3"
# gmake -j6 CXXPP="ccache g++" install

For the additional fun, you should not forget to also take a look at the cool distcc monitor (distccmon-gnome) while waiting for the build to finish :)...

icecc / ccache:

Using icecream for distributed compilation - a SuSE / Novell enhancement to distcc which includes a scheduler, better handles offline hosts and has an even cooler monitor (icemon) - works basically the same, with or without ccache:

# gmake -j6 CXXPP="icecc" install

or (with ccache)

# gmake -j6 CXXPP="ccache icecc" install

Note that you do not have to setup any environment variables for icecream. It finds its members all by its own (that is, within the local network) and automatically schedules jobs according to node performance and CPU count.

For an easy distribution-independent setup guide, see this howto:
http://wiki.kdenews.org/tiki-index.php?page=icecream

On a sysconfig controlled system like SuSE Linux, simply edit the config file (/etc/sysconfig/icecream in case of SuSE Linux), enable the iceream service for the desired run-levels (for example 3 and 5) and start it:

# chkconfig -s icecream 35
# /etc/init.d/icecream start

Do this on all nodes. Only ONE node has to run the scheduler (per icecream network).

Binary distribution

Alternatively, if you don't want to bother with all the hassle, you could try
to download a binary distribution if available for your platform. There is no guarantee that it will work, because it may require adoptions to your library paths and library versions. Anyway, the binary distribution already includes the shared libraries for libpcap - if applicable - and Qt which were used during the build. If possible, please use these libraries.

Also see LIBS.LDD (in the binary package) for a list of additionally required shared objects.

3. Command line arguments / user privileges

Usage: qnetwatch [interface | -h | -? | -v]
interface = eth0, eth1 etc.

If no interface name is specified on the command line, QNetwatch will either use the last interface (stored in the settings or registry) or if that is not available as well, it will use the first interface from a list returned by the kernel.

User privileges

Please note that some functionality may require special privileges to work properly. Depending on the underlying security scheme, this may simply mean root privileges.

This especially affects the sniffer, which will send out a warning if your effective user id is not equal to 0. The pcap library needs access to the driver layer of your OS, so it normally won't work otherwise (BTW, this is the same for other network analysis tools like tcpdump or ethereal).

Under Linux, for example, the connection monitor has similar restrictions, because it needs read access to /proc/net/ip_conntrack, which normally means root permission again.

However, keeping these restrictions in mind, QNetwatch can still be run as a "normal" user. No question.

Be warned that even if chmod'ing the executable to run with suid root permission will solve the problem, this is not a very good idea because of the following:

Use something like kdesu to temporarily get root. This is a much better and more secure solution which works fine with QNetwatch and Qt's settings mechanism.

4. Dynamic DNS check

The detailed interface information dialog not only allows you to watch the current interface status, configuration, traffic etc. but also contains a mechanism to check for correspondance of the (potentionally dynamic) IP address of the current interface with a specified hostname (DNS name).

This is most useful for dial-up connections to the internet, which are dynamically mapped to DNS names. There are several services of this sort available on the internet, one of the most popular (and free) dynamic DNS services is DynDNS.org. But there are others as well. If you are not yet using some kind of dynamic name to IP address mapping, but want or need to do so (for whatever reason - i.e. to run your own mail or web server), I advise you to visit http://www.dyndns.org/!

Regardless of the service itself, QNetwatch helps in determining if the DNS name to IP address mapping is in place, if you enter the hostname you want to check in the entry field right to the check box "Check for". After the specified countdown period, QNetwatch will try to resolve the name and change the color of the status/countdown button according to its result:

yellow unknown status (not checked yet or check (re)started)
red the current interface's IP address does NOT match the given DNS hostname (uuuh, what happend? :)
green the current interface's IP address DOES match the given DNS hostname (everything's fine :)

Additionally, the fully qualified domain name will be determined and displayed in the field "FQDN", if the status is "green". Most likely, this will be the same as the hostname you entered, but it MAY differ or even be empty, depending - for example - on your domain search order (local resolver configuration, on UNIX see /etc/resolv.conf, keyword "search") or other DNS pecularities.

Same basically holds for the CNAME (canonical name). To make it even more useful, there is a feature which allows for automatic corrective action if the DNS check fails. You have to specify a script or binary program to be called (probably incl. command line parameters) which will be spawned asynchronously when the status gets red.

Of course, it should be a program that somehow fixes (or tries to fix) the DNS mapping problem - like one of the DynDNS.org "clients" which update the information for your dynamic IP address automatically. But it could be anything else, if that is what you want. It's totally up to you - so don't expect any support if it doesn't work as desired!

Note that the external program is called only ONCE at a time, that is, if it's still running when the status is checked the next time, it will not be spawned again!

5. IP packet sniffer and analyzer

Utilizing the packet capture (pcap) library natively, the IP packet sniffer dialog basically works in a very similar way as tcpdump(1) does. In fact, the filter expression syntax is exactly the same (surprise, surprise! :), also their functionality is pretty much the same... but, although it may be a bit nicer to have it displayed in a GUI, in regard of completeness and correctness tcpdump(1) is way better and more mature.

A major difference is that QNetwatch does not yet fully support IPv6 and not know about too much protocol detail. This will sooner or later be fixed by the packet analyzer (see below), which is new since v0.24.b4.

Since v0.24.b6, the analyzer supports most of the important IPv4 protocols (IP, UDP, TCP, ICMP, ...) and should accurately honor all unsupported protocols as such.

If the capture parameter include data is enabled (the default), raw packet data can be viewed by expanding the respective entries. Each packet starts with a 14-byte MAC header, followed by the (assumed) IPv4 header. The rest is protocol dependend. For example, in case of TCP or UDP, the next 4 bytes make up the source and destination ports, but only in these cases. Following the protocol dependent header comes the effective data, if any...

Capture dumps can optionally be written to and/or read from file. The latter will cause the sniffer to work in "offline capture mode" and thus disable live capture. The value of the interface name will in this case be set to dump to reflect dump reading. The dump itself can come from any system and is missing information about the captured interface. However, the datalink type (shown in the interface name's tooltip) will be setup correctly from the information in the dump file.

The dump file format is compatible to tcpdump(1), so you can exchange dumps between either program. Use editcap(1) to convert from many other packet dump formats.

Please note that the "Len" column of the sniffer output shows the overall length of the packet, including MAC, IP and protocol header as well as the effective data. Timestamps are shown in local time format, followed by the microsecond time: hh:mm:ss.microseconds.

Packet analyzer

Regardless of the afore mentioned restrictions, any packet can be analyzed in more detail by activating the packet analyzer and selecting the desired packet within the sniffer output. The analyzer will then split the packet's information in multi-layer header information and the data itself. The analysis is displayed in a tree, showing each part's "interpreted" and "RAW data" items.

If you click on an interpreter item in the analyzer tree, the corresponding parts of raw data will be underlined in the "RAW data" item. Additionally, an [I] will be displayed in the upper left corner of the data view to indicate this.

Note that the analyzer requires captured data to be included (which is the default).

Filter expression syntax

The dialog should be quite self-explanatory... the only exception is the filter expression, which is compiled into a Berkeley Packet Filter (BPF) program and passed to the underlying driver or protocol stack. The following syntax explanation has originally been taken from tcpdump(1).

A filter expression consists of one or more primitives. Primitives usually consist of an id (name or number) preceded by one or more qualifiers. There are three different kinds of qualifiers:

type qualifiers say what kind of thing the id name or number refers to. Possible types are host, net and port. E.g., `host foo', `net 128.3', `port 20'. If there is no type qualifier, host is assumed.

dir qualifiers specify a particular transfer direction to and/or from id. Possible directions are src, dst, src or dst and src and dst. E.g., `src foo', `dst net 128.3', `src or dst port ftp-data'. If there is no dir qualifier, src or dst is assumed. For `null' link layers (i.e. point to point protocols such as slip) the inbound and outbound qualifiers can be used to specify a desired direction.

proto qualifiers restrict the match to a particular protocol. Possible protos are: ether, fddi, tr, ip, ip6, arp, rarp, decnet, tcp and udp. E.g., `ether src foo', `arp net 128.3', `tcp port 21'. If there is no proto qualifier, all protocols consistent with the type are assumed. E.g., `src foo' means `(ip or arp or arp) src foo' (except the latter is not legal syntax), `net bar' means `(ip or arp or rarp) net bar' and `port 53' means `(tcp or udp) port 53'.

In addition to the above, there are some special `primitive' keywords that don't follow the pattern: gateway, broadcast, less, greater and arithmetic expressions. All of these are described below.

More complex filter expressions are built up by using the words `and', `or' and `not' to combine primitives. E.g., `host foo and not port ftp and not port ftp-data'.

To save typing, identical qualifier lists can be omitted. E.g., `tcp dst port ftp or ftp-data or domain' is exactly the same as `tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain'.

Allowable primitives are:

dst host host

True if the IPv4/v6 destination field of the packet is host, which may be either an address or a name.

src host host

True if the IPv4/v6 source field of the packet is host.

host host

True if either the IPv4/v6 source or destination of the packet is host.

Any of the above host expressions can be prepended with the keywords, ip, arp, rarp, or ip6 as in "ip host host" which is equivalent to "ether proto ip and host host". If host is a name with multiple IP addresses, each address will be checked for a match.

ether dst ehost

True if the ethernet destination address is ehost. Ehost may be either a name from /etc/ethers or a number (see ethers(3N) for numeric format).

ether src ehost

True if the ethernet source address is ehost.

ether host ehost

True if either the ethernet source or destination address is ehost.

gateway host

True if the packet used host as a gateway. I.e., the ethernet source or destination address was host but neither the IP source nor the IP destination was host. Host must be a name and must be found both by the machine's host-name-to-IP-address resolution mechanisms (host name file, DNS, NIS, etc.) and by the machine's host-name-to-Ethernet-address resolution mechanism (/etc/ethers, etc.). (An equivalent expression is "ether host ehost and not host host" which can be used with either names or numbers for host / ehost.) This syntax does not work in IPv6-enabled configurations at this moment.

dst net net

True if the IPv4/v6 destination address of the packet has a network number of net. Net may be either a name from /etc/networks or a network number (see networks(4) for details).

src net net

True if the IPv4/v6 source address of the packet has a network number of net.

net net

True if either the IPv4/v6 source or destination address of the packet has a network number of net.

net net mask netmask

True if the IP address matches net with the specific netmask. May be qualified with src or dst. Note that this syntax is not valid for IPv6 net.

net net/len

True if the IPv4/v6 address matches net with a netmask len bits wide. May be qualified with src or dst.

dst port port

True if the packet is ip/tcp, ip/udp, ip6/tcp or ip6/udp and has a destination port value of port. The port can be a number or a name used in /etc/services (see tcp(4P) and udp(4P)). If a name is used, both the port number and protocol are checked. If a number or ambiguous name is used, only the port number is checked (e.g., dst port 513 will print both tcp/login traffic and udp/who traffic, and port domain will print both tcp/domain and udp/domain traffic).

src port port

True if the packet has a source port value of port.

port port

True if either the source or destination port of the packet is port.

Any of the above port expressions can be prepended with the keywords, tcp or udp, as in "tcp src port port" which matches only tcp packets whose source port is port.

less length

True if the packet has a length less than or equal to length. This is equivalent to "len <= length".

greater length

True if the packet has a length greater than or equal to length. This is equivalent to "len >= length".

ip proto protocol

True if the packet is an IP packet (see ip(4P)) of protocol type protocol. Protocol can be a number or one of the names icmp, icmp6, igmp, igrp, pim, ah, esp, vrrp, udp, or tcp. Note that the identifiers tcp, udp, and icmp are also keywords and must be escaped via backslash (\). Note that this primitive does not chase the protocol header chain.

ip6 proto protocol

True if the packet is an IPv6 packet of protocol type protocol. Note that this primitive does not chase the protocol header chain.

ip6 protochain protocol

True if the packet is IPv6 packet, and contains protocol header with type protocol in its protocol header chain. For example, ip6 protochain 6 matches any IPv6 packet with TCP protocol header in the protocol header chain. The packet may contain, for example, authentication header, routing header, or hop-by-hop option header, between IPv6 header and TCP header. The BPF code emitted by this primitive is complex and can not be optimized by BPF optimizer code, so this can be somewhat slow.

ip protochain protocol

Equivalent to ip6 protochain protocol, but this is for IPv4.

ether broadcast

True if the packet is an ethernet broadcast packet. The ether keyword is optional.

ip broadcast

True if the packet is an IP broadcast packet. It checks for both the all-zeroes and all-ones broadcast conventions, and looks up the local subnet mask.

ether multicast

True if the packet is an ethernet multicast packet. The ether keyword is optional. This is shorthand for `ether[0] & 1 != 0'.

ip multicast

True if the packet is an IP multicast packet.

ip6 multicast

True if the packet is an IPv6 multicast packet.

ether proto protocol

True if the packet is of ether type protocol. Protocol can be a number or one of the names ip, ip6, arp, rarp, atalk, aarp, decnet, sca, lat, mopdl, moprc, iso, stp, ipx, or netbeui. Note these identifiers are also keywords and must be escaped via backslash (\).

decnet src host

True if the DECNET source address is host, which may be an address of the form ``10.123'', or a DECNET host name.

decnet dst host

True if the DECNET destination address is host.

decnet host host

True if either the DECNET source or destination address is host.

ip, ip6, arp, rarp, atalk, aarp, decnet, iso, stp, ipx, netbeui

Abbreviations for: "ether proto p" where p is one of the above protocols.

lat, moprc, mopdl

Abbreviations for: "ether proto p" where p is one of the above protocols.

vlan [vlan_id]

True if the packet is an IEEE 802.1Q VLAN packet. If [vlan_id] is specified, only true if the packet has the specified vlan_id. Note that the first vlan keyword encountered in expression changes the decoding offsets for the remainder of expression on the assumption that the packet is a VLAN packet.

tcp, udp, icmp

Abbreviations for: "ip proto p or ip6 proto p" where p is one of the above protocols.

iso proto protocol

True if the packet is an OSI packet of protocol type protocol. Protocol can be a number or one of the names clnp, esis, or isis.

clnp, esis, isis

Abbreviations for: "iso proto p" where p is one of the above protocols.

expr relop expr

True if the relation holds, where relop is one of >, <, >=, <=, =, !=, and expr is an arithmetic expression composed of integer constants (expressed in standard C syntax), the normal binary operators [+, -, *, /, &, |], a length operator, and special packet data accessors. To access data inside the packet, use the following syntax:

proto [ expr : size ]

Proto is one of ether, fddi, tr, ppp, slip, link, ip, arp, rarp, tcp, udp, icmp or ip6, and indicates the protocol layer for the index operation. (ether, fddi, tr, ppp, slip and link all refer to the link layer.) Note that tcp, udp and other upper-layer protocol types only apply to IPv4, not IPv6 (this will be fixed in the future). The byte offset, relative to the indicated protocol layer, is given by expr.

Size is optional and indicates the number of bytes in the field of interest; it can be either one, two, or four, and defaults to one. The length operator, indicated by the keyword len, gives the length of the packet.

For example, `ether[0] & 1 != 0' catches all multicast traffic. The expression `ip[0] & 0xf != 5' catches all IP packets with options. The expression `ip[6:2] & 0x1fff = 0' catches only unfragmented datagrams and frag zero of fragmented datagrams. This check is implicitly applied to the tcp and udp index operations. For instance, tcp[0] always means the first byte of the TCP header, and never means the first byte of an intervening fragment.

Some offsets and field values may be expressed as names rather than as numeric values. The following protocol header field offsets are available: icmptype (ICMP type field), icmpcode (ICMP code field), and tcpflags (TCP flags field).

The following ICMP type field values are available: icmp-echoreply, icmp-unreach, icmp-sourcequench, icmp-redirect, icmp-echo, icmp-routeradvert, icmp-routersolicit, icmp-timxceed, icmp-paramprob, icmp-tstamp, icmp-tstampreply, icmp-ireq, icmp-ireqreply, icmp-maskreq, icmp-maskreply.

The following TCP flags field values are available: tcp-fin, tcp-syn, tcp-rst, tcp-push, tcp-push, tcp-ack, tcp-urg.

Primitives may be combined using:

Negation has highest precedence. Alternation and concatenation have equal precedence and associate left to right.

If an identifier is given without a keyword, the most recent keyword is assumed For example, "not host vs and ace" is short for "not host vs and host ace" which should not be confused with "not ( host vs or ace )".

Examples:

To print all packets arriving at or departing from sundown:

host sundown

To print traffic between helios and either hot or ace:

host helios and ( hot or ace )

To print all IP packets between ace and any host except helios:

ip host ace and not helios

To print all traffic between local hosts and hosts at Berkeley:

net ucb-ether

To print all ftp traffic through internet gateway snup:

gateway snup and (port ftp or ftp-data)

To print traffic neither sourced from nor destined for local hosts (if you gateway to one other net, this stuff should never make it onto your local net).

ip and not net localnet

To print the start and end packets (the SYN and FIN packets) of each TCP conversation that involves a non-local host:

tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet

To print IP packets longer than 576 bytes sent through gateway snup:

gateway snup and ip[2:2] > 576

To print IP broadcast or multicast packets that were not sent via ethernet broadcast or multicast:

ether[0] & 1 = 0 and ip[16] >= 224

To print all ICMP packets that are not echo requests/replies (i.e., not ping packets):

icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply

6. Connection monitor

The connection monitor - available since v0.24.b4 - tracks online connections to and from the host QNetwatch is running on. This is shown in the Local connections tab.

If the wrapper API for the target host's OS supports masquerading (like under Linux, for example), all masqueraded connections are shown in the Masq connections tab. This is most likely only the case if the host system is configured as a masquerading firewall or router.

A list of current server daemons, either TCP or UDP, running on and accepting connections to the system is displayed in the Local servers tab.

In case of local and masqueraded connections, there is a context menu (right mouse button) that can be used to generate a BPF filter expression for the sniffer (see section 5). This enables you to easily trace one or more connections with the sniffer.

7. GUI style plugins

Since v0.24.b6 QNetwatch supports additional GUI style plugins. Plain Qt- and KDE-styles are supported, you only need to make sure that the plugin paths (see Settings->Plugin paths) are setup correctly for QNetwatch to find them.

Note that a valid plugin path MUST contain a sub-directory called "styles" where the "<style>.so" shared objects reside.

Style plugins can for example be found at http://www.kde-look.org.

Note: you need to restart QNetwatch after installation of new plugin styles.

8. Bugs and restrictions

See TODO!

9. How to create diffs and install patches

This information is mainly for developers.

Creating a unified diff:

# diff -urN qnetwatch-<old_version> qnetwatch-<new_version>\
> qnetwatch-<old_version>-<new_version>.patch

Don't forget to do a "gmake clean", or even better "gmake dist", before
creating a patch!

Patching the older version:

# cd qnetwatch-<old_version>
# patch -p1 < qnetwatch-<old_version>-<new_version>.patch

Note that GNU diff/patch is required!

10. Supported platforms

QNetwatch has been ported to and tested on the following platforms, using the shown APIs, CMDs, FILEs and COMPILERs:

PLATFORM API, CMD, FILE COMPILER STATUS, REMARKS
Linux
2.6.x
x86, x86_64
API: netdevice
API: pcap
CMD: /bin/netstat
FILE: /proc/net/dev
FILE: /proc/net/ip_conntrack
g++ 3.x.x
g++ 4.x.x
OK
SunOS
5.8, 5.9
sun4u
API: kstat
API: pcap
g++ 2.95.x
g++ 3.x.x
OK
no masq support
no cmon support
CYGWIN_NT
5.1
i686
API: wpcap g++ 3.x.x EXPERIMENTAL
compile/link ok
no network info
FreeBSD
5.4, 6.0
i386
API: pcap g++ 3.x.x EXPERIMENTAL
compile/link ok
no network info

Note that the listed APIs, CMDs and FILEs are REQUIREMENTS needed to support the specific platform - it won't work (correctly) without.

If you try it on other platforms than the ones listed here, successfully or not, please drop me a note so I can report it (see section 12 for contact information).

Also note that QNetwatch will use a generic (or dummy/null) interface, if it does not know how to handle the specific OS type. This way QNetwatch will not give you any real information about your interfaces' states or the traffic, but you should be able to compile and link it at least.

11. How to port

a) Study the generic API layer:

ifinfo.h
ifinfo.cpp

b) Create a new directory below arch/ with the exact OS name; put all your OS dependant files there:

# mkdir -p arch/`uname`

b) Pick one of the existing OS wrappers as a sample code base:

arch/Linux/ifinfo_Linux.h
arch/Linux/ifinfo_Linux.cpp
arch/SunOS/ifinfo_SunOS.h
arch/SunOS/ifinfo_SunOS.cpp
arch/CYGWIN_NT/ifinfo_CYGWIN_NT.h
arch/CYGWIN_NT/finfo_CYGWIN_NT.cpp
arch/FreeBSD/ifinfo_FreeBSD.h
arch/FreeBSD/finfo_FreeBSD.cpp
...


Store your results under arch/`uname`.

c) Create a corresponding `uname`.pro and `uname`.cfg files in your new arch/`uname` directory:


arch/Linux/Linux.cfg
arch/Linux/Linux.pro
arch/SunOS/SunOS.cfg
arch/SunOS/SunOS.pro
arch/CYGWIN_NT/CYGWIN_NT.cfg
arch/CYGWIN_NT/CYGWIN_NT.pro
arch/FreeBSD/FreeBSD.cfg
arch/FreeBSD/FreeBSD.pro
...

d) Edit ifinfo.h and add your OS to the SysInterfaceInfo macros at the end.

e) Edit macros.h and add your OS to the WRAPPER_ definitions.

f) Try to build it :).

Hope I didn't forget anything of major importance... anyway, I'd be glad to receive your patches. See section 9 for patch creation instructions.

12. Contact

Author mail:
rene.reucher@batcom-it.net

Project URL:
http://www.batcom-it.net/index.php?option=com_content&task=view&id=17&Itemid=57

13. Contributing

Help and contributions are very much appreciated. Following are the most important areas where we need your support:

If you think you can help us in one or more of the afore mentioned areas, please contact rene.reucher@batcom-it.net.

See CREDITS for a list of contributers.

14. License and copyright

QNetwatch - Network Monitor
Copyright (C) 2003 - 2005, R. Reucher, BATCOM IT Services, Germany, All Rights Reserved

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the license, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

See COPYING.

15. Usage warning

The sniffer's ability to spy clear text usernames and passwords leads to the fact that this information can potentionally be misused. This is NOT the intention of the authors, and if you are in a productive enterprise environment you are adviced to tell your users that you are (for example) able to spy their passwords.

In any case, the following applies, if you intend to use QNetwatch (the "SOFTWARE"):

BY USING THIS SOFTWARE YOU AGREE YOU WILL USE IT FOR LAWFUL PURPOSES ONLY AND WILL NOT MISUSE THE SOFTWARE, FOR EXAMPLE TO GAIN UNAUTHORIZED ACCESS!

However, the sniffer needs root permission to capture packets, so you as a system administrator shouldn't be worried... as long as you don't enable suid root permission on the binary (which is a bad idea anyway). See section 3 for a discussion about user privileges.