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.
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.
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:
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!
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
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.
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.
See
TODO!
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!
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.
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
...
c) Create a corresponding `uname`.pro and `uname`.cfg files in your new arch/`uname` directory:
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
Help
and contributions are very much appreciated. Following are the most
important
areas where we need your support:
beta testing, bug hunting
documentation
ports to other platforms
translations (application and docs)
additional image sets
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.
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.
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.