File: README.interfaces

package info (click to toggle)
iptraf-ng 1:1.1.4-6
  • links: PTS, VCS
  • area: main
  • in suites: bullseye, buster, sid, stretch
  • size: 2,856 kB
  • ctags: 1,289
  • sloc: ansic: 11,913; makefile: 367; sh: 31; awk: 1
file content (64 lines) | stat: -rw-r--r-- 2,623 bytes parent folder | download | duplicates (7)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
============================================================================
Supported Interface Information
as of version 2.8, July 2002
----------------------------------------------------------------------------

IPTraf has been slowly improving with its interface support since its
first release.  IPTraf currently supports the following types of links:

Local loopback
Ethernet (10 and 100 Mbps)
SLIP and variants
Asynchronous PPP over analog telephone lines
Synchronous PPP over digital ISDN lines
ISDN using raw IP encapsulation
ISDN using Cisco-HDLC encapsulation
FDDI (now includes Ethernet-emulating interfces)
Frame Relay FRAD/DLCI interfaces (new as of IPTraf 2.5.0)
PLIP (Parallel Line IP)
Token Ring
DVB satellite-receive interfaces
SBNI long-range modem interfaces
Wireless LAN interfaces
Free s/WAN logical interfaces
IPsec logical interfaces
Some tunnelling interfaces
Some bridging interfaces

ADDITIONAL INTERFACE SUPPORT

As much as I would like to support every concievable interface in
existence, we know that's just not possible.  I myself do not have a lot
of interface types.  However, that does not mean I'm unwilling to support
more.

So here's the deal.  If you'd like me to include support for a new type of
interface I will need this information as much as possible:

* Resulting link type in spkt_family after a recvfrom() on a (PF_PACKET,
  SOCK_RAW) socket (ARPHRD_ETHER, ARPHRD_PPP, etc).
* Standard interface name for the type of network medium (eth0, eth1,
  ppp0, etc) after the recvfrom() mentioned above.
* Packet structure.  How many bytes are there in its data-link header
  (with Ethernet, there are 14, with FDDI, 21) as returned by recvfrom on
  a (PF_PACKET, SOCK_RAW) socket?
* Pointers to other sources of information if possible.  This is necessary
  for cases like ISDN, which claim to be ARPHRD_ETHER, but have completely
  different frame structures, so I needed the appropriate ioctl()
  information.  Token Ring packets may have a RIF structure or not.  These
  factors need to be taken into consideration.

Then finally, if you come up with a request for support for a new
interface, I'd really like an offer to have it tested, obviously, since I
do not have the interface myself (for example, my country is primarily
leased-line territory, and ISDN is only starting, and it isn't even in my
city yet).  If I do not receive an offer to test, then support cannot be
included.

Patches, even quick-and-dirty ones, are very much welcome.

All information and patches will be fully credited in the CHANGES file.

Looking forward to serving you.

-- Gerard <riker@seul.org>