% Syncronized to German version: NOT IN SYNC

\section{Alternative packet filter configuration}

\configlabel{NEW\_FW\_CONFIG}{NEWFWCONFIG}

Using the new packet filter configuration, the tables of the packet filter
can be individually configured. For every table, there is a particular list,
i.e. one for the input table (\var{INPUT\_LIST\_x}), one for the forwarding
table (\var{FORWARD\_LIST\_x}) and one for the postrouting tbale, where the
masquerading takes place (\var{MASQUERADE\_LIST\_x}). Because of the
experimental character, the follwing configuration variables are not yet
contained within the default configuration. You will have to add them
yourself.

The entry in one of those lists consists basically of an Action ({\em
ACCEPT, DROP, REJECT oder MASQUERADE}) that can be restricted using several
conditions. Those conditions are connected with the properties of the
packet involved. A packet contains information about its source (which
host did send the packet), its target (to which host and which application
the packet was addressed) and others. Conditions can be related to one of
the following properties of the packet:

\begin{itemize}
\item source (source IP, source port or both)
\item target (target IP, target port or both)
\item protocol
\item interface, on which the packet was received or will be send to
\item MAC address of the host the packet originiates from
\item status of the packet or the connection the packet relates to
\end{itemize}

If a packet is received, the entries (resp. the generated rules) are
processed from the top and the first action is executed where all conditions
match. If no rule matches, the default action is executed. It can be defined
for (almost) every table.

The entry has the following format. Please remember, that all restrictions
are optional.

\begin{example}
\begin{verbatim}
restriction{0,} [[source] [destination]] action [BIDIRECTIONAL]
\end{verbatim}
\end{example}


\subsection{Actions of the packet filter}

Actions can be the following:
\begin{description}
\item[ACCEPT] Accepts the packet
\item[DROP] Drop the packet (the sender will only realize, that he does
  not receive any response - but he won't get an error message either!)
\item[REJECT] Reject the packet (the sender will be notified)
\item[MASQUERADE] Masquerade the packet (replace the  sender IP of the
  packet with the own IP of the interface and make sure, responds for this
  connection are forwarded to the right host; this action is only valid
  in \var{MASQUERADE\_LIST})
\item[SNAT] Replace the sender IP of the packet with the static IP
  that has been defined for SNAT (for all packets that relate to the
  connection currently looked at; this action is only valid
  in \var{MASQUERADE\_LIST})

\end{description}


\subsection{Restrictions for the rules}

Restrictions can be defined using the conditions described below.
You can always specify 'any' if you do not want to restrict a rule, but
something has to be specified or you want to specifies something.
Restrictions can be defined in any order, if they have a prefix.
For source and target IPs however this is not true. They have to be
specified directly in front of the action. The other restrictions have to
be defined ealier.

\subsubsection{Restricting the source and the target}

Every packet contains a source and a target; in form of a tuple of an
IP address and a port each. The source and/or the target can be used
for a restriction. You can specify the source/target like this:

\begin{tabular}[h!]{lp{8cm}}
{\bf ip}          & a simple IP address\\
{\bf network}     & a network of the form ip/netmask \\
{\bf port[-port]} & a port or a port-range\\
{\bf ip[/netmask]:port[-port]} & ip/network-address combined with a
                                 port(-range)\\
\end{tabular}

So it could look like this: {\em '192.168.6.2 any DROP'}.

If two of those specifications are supplied, the first will be interpreted
as source, the second as target. So in this example we drop packets from
the host with the IP address 192.168.6.2, independent from the target.

If only one specification is supplied, it will be decided based on the
value wheter a source or target is meant. The decision is pretty simple:
\begin{itemize}
\item If a port specification is supplied, the target is meant.
\item Otherwise the source is meant.
\end{itemize}

So if we would want to write the above example a little shorter, we
could simply use {\em '192.168.6.2 DROP'}. There is no port, so the
condition is valid for the source - the host the packet originated from.

If we want to allow communication with the sshd, we can use {\em 'any
  any:22 ACCEPT'} (Accept packets from any host to any host's port 22)
or shorter {\em '22 ACCEPT'}. Only a port is supplied, so me mean the
target and thus packets targetted port 22.

To simplify the rules, you can append {\em BIDIRECTIONAL} to the action -
the rule is then valid for both communication directions. Rules will be
generated, where the source and target IP are exchanged. The rest is
identical.

{\bf Examples:}
  \begin{tabular}{lp{8cm}}
    '127.0.0.1 ACCEPT' & Allow local (source 127.0.0.1) communication \\
    'any 192.168.12.1 DROP & Packets addressed to 192.168.12.1
    are dropped \\
    '22 ACCEPT' & Packets addressed to port 22 (sshd) are accepted
  \end{tabular}

\subsubsection{Restrictions on the interface}

Restrict the interface the packet was received on or is send out to.
The format looks like this: \begin{bf}if:\end{bf}\begin{em}in\end{em}\begin{bf}:\end{bf}\begin{em}out\end{em}

You cannot restrict the incoming interface on the input list (the
package won't leave the router any more), in the masquerade list
(postrouting) you will not be able to restrict the outgoing interface,
as the information about it is not available any more. Only on the
forward list you will be able to restrict both.

Possible values for {\em in} or {\em out}:

    \begin{itemize}
    \item lo (loopback Interface, local communication on the router)
    \item eth0 - eth9
    \item br0 - br9
    \item circuit\_0 - circuit\_99
    \item ip\_eth\_0 - ip\_eth\_99
    \item pppoe (the pppoe device)
    \item any
    \end{itemize}


\subsubsection{Restrictions on the protocol}

Restricts the protocol, that this packet may belong to. The format is like
this:
\begin{bf}prot:\end{bf}\begin{em}protcol\end{em}
or
\begin{bf}prot:\end{bf}\begin{em}icmp\end{em}\begin{bf}:\end{bf}\begin{em}icmp-type\end{em}.

\begin{em}protcol\end{em} can be one of the following values:

\begin{itemize}
\item tcp
\item udp
\item icmp

  If you use icmp, you can specify an additional name for the icmp-type,
  e.g. prot:icmp:echo-request.

\item numerical value of the protocol ID
\item any
\end{itemize}


\subsubsection{Restricting the MAC address}

Using \begin{bf}mac:\end{bf}\begin{em}mac addr\end{em} the MAC address
can be restricted.

\subsubsection{Restrictions based on the status of a packet}

The packet filter used with fli4l collects information on the status
of connections. You can use this information to filter packets. For example,
let only packets pass, that belong to an established connection. A connection
status can be:

\begin{description}
\item[INVALID] Packet does not belong to any active connection.
\item[ESTABLISHED] Packet belongs to a connection, where packets have
  already been transferred in both directions.
\item[NEW] Packet has created a new connection or belongs to a connection,
  where packets have not already been transferred in both directions.
\item[RELATED] Packet creates a new connection, but relates somehow to an
  existing connection (ftp, e.g., creates a seperate connection for the
  actual data transfer).
\end{description}

For a more detailed explanation of the different connection statuses see\\
\link{http://www.sns.ias.edu/\%7Ejns/security/iptables/iptables\_conntrack.html}.

The statuses have to be specified like this:
\begin{bf}state:\end{bf}\begin{em}state(s)\end{em}. If you want to specify
multiple statuses, they have to be seperated by commas. For example, if you
want to let only packets pass belonging to an already established connection
you would have to write (for input and forwarding):
\begin{bf}state:\end{bf}\begin{em}ESTABLISHED,RELATED\end{em}


\subsection{The configuration of the packet filter}

Essentially, the packet filter is configure unsing three lists:

\begin{itemize}
\item input list
\item forward list
\item masquerade list
\end{itemize}

The configuration is activated by setting \var{NEW\_FW\_CONFIG}='yes'.

\subsubsection{The input list}

Using the input list you can configure, who will be allowed to access the
router. If no rule from the input list matches, the default policy decides,
what should happen to the packet and the log variable will decide, wheter
an entry will be written to the syslog.

The parameters used are restricted by two rules:
\begin{itemize}
\item {\em MASQUERADE} and {\em SNAT} cannot be specified as action
\item an interface restriction will only be able to restrict the incoming
  interface.
\end{itemize}

\begin{description}
\config{INPUT\_POLICY}{INPUT\_POLICY}{INPUTPOLICYNEW}

This variable describes the default policy, that is used when no other
rule matches. Possible values are:

\begin{itemize}
\item ACCEPT (not recommended)
\item REJECT
\item DROP (not recommended)
\end{itemize}

\config{INPUT\_ACCEPT\_DEF}{INPUT\_ACCEPT\_DEF}{INPUTACCEPTDEF}

If this variable is set to 'yes', two default rules are generated.
The first one allows local communication ('if:lo:any ACCEPT') and the
second one accepts packets that belong to a established connection.
If in doubt, say 'yes' here.


\config{INPUT\_LOG}{INPUT\_LOG}{INPUTLOG}

Defines, wheter rejected packets should be written to the syslog.

\configlabel{INPUT\_LIST\_x}{INPUTLISTx}
\config{INPUT\_LIST\_N INPUT\_LIST\_x}{INPUT\_LIST\_N}{INPUTLISTN}

List of rules that describe which packages should be accepted or rejected
by the router.

\end{description}

\subsubsection{The forward list}

The forward list is used to configure, which packets should be forwarded
by the router. If no rule from the forward list matches, the default policy
will decide what will happen to the packet and the log variable will decide,
wheter or not an entry to the syslog will be written.

There are two restrictions on the used parameters:
\begin{itemize}
\item {\em MASQUERADE} and {\em SNAT} can not be specified as action.
\item {\em REJECT} can not (yet) be specified as action.
\end{itemize}

\begin{description}
\config{FORWARD\_POLICY}{FORWARD\_POLICY}{FORWARDPOLICY}

The default policy is used, if no other rule matches. Possible values:

\begin{itemize}
\item ACCEPT
\item DROP
\end{itemize}

\config{FORWARD\_ACCEPT\_DEF}{FORWARD\_ACCEPT\_DEF}{FORWARDACCEPTDEF}

Defines, wheter the router will accept packets that belong to established
connections. If this variable is set to 'yes', fli4l generates a rules,
that have this status.

\config{FORWARD\_LOG}{FORWARD\_LOG}{FORWARDLOG}

Defines, wheter rejected packets should cause an entry to the system log.

\configlabel{FORWARD\_LIST\_x}{FORWARDLISTx}
\config{FORWARD\_LIST\_N FORWARD\_LIST\_x}{FORWARD\_LIST\_N}{FORWARDLISTN}

List of rules, that describe, which packet the router should forward or
reject.

\end{description}

\subsubsection{The masquerading list}

The masquerading list defines, which packets the router should masquerade.
If none of the masquering list's rules match, the packets are forwarded
unmasqueraded.

There are variants when using masquerading. The first one for interfaces
that are assigned an IP at dial in ({\em MASQUERADE}) and for interfaces
with a static IP ({\em SNAT}). The last exspects additional parameters:
\begin{itemize}
\item the IP, that you want the packet to have as source. This can be
  specified as
  \begin{itemize}
  \item IP address (SNAT:1.2.3.4),
  \item IP range   (SNAT:1.2.3.4-1.2.3.10),

  \item or as interface name, whose IP address should be the
    source(SNAT:ip:eth\_x).
  \end{itemize}
\item an a port range, the packet should originate from (this is normally
  not necessary, as the kernel can select the ports itself). The port range
  is simply appended, for example like this:
  SNAT:ip\_eth\_1:4000-8000.
\end{itemize}


There are two restrictions to the used parameters:
\begin{itemize}
\item {\em DROP} can not be specified as action.
\item {\em REJECT} can not be specified as action.
\end{itemize}

\begin{description}

\configlabel{MASQUERADE\_LIST\_x}{MASQUERADELISTx}
\config{MASQUERADE\_LIST\_N MASQUERADE\_LIST\_x}{MASQUERADE\_LIST\_N}{MASQUERADELISTN}

List of the rules, that describe, which packets the router should
masquerade (or forward unmasqueraded). If you want specific packets not
to be masqueraded, you can specify an accept-rule prior to the masquerade
rule.

\end{description}


\subsection{Examples}

Following some examples for the new configuration.


\subsubsection{the fli4l default configuration}

The fli4l default configuration looks like this, if you omit all
deactivated options:

\begin{example}
\begin{verbatim}
    MASQ_NETWORK='192.168.6.0/24' # networks to masquerade (e.g. our LAN)
    INPUT_POLICY='REJECT'         # policy for input chain: reject or drop
    FORWARD_DENY_PORT_N='1'       # no. of ports to reject/deny forwarding
    FORWARD_DENY_PORT_1='137:139 reject'  # drop/reject forwarding of netbios
    DENY_ICMP='no'                # deny icmp (ping): yes or no
    PACKETFILTER_LOG='no'         # log access to rejected/denied ports
\end{verbatim}
\end{example}

If you take these options and the assumptions made in the packet filter
section togheter, a translation to the new scheme looks like this:

\begin{example}
\begin{verbatim}
    INPUT_POLICY='REJECT'
    INPUT_ACCEPT_DEF='yes'
    INPUT_LOG='no'
    INPUT_LIST_N='1'
    INPUT_LIST_1='192.168.6.0/24 ACCEPT'
\end{verbatim}
\end{example}

This results in
\begin{itemize}
\item hosts from the LAN being able to access the router (rule 1),
\item local communication on the router to be allowed
  (\var{INPUT\_ACCEPT\_DEF}),
\item packets that belong to established connections being accepted
  (\var{INPUT\_ACCEPT\_DEF}),
\item everything else being rejected (\var{INPUT\_POLICY}),
\item but not being written to the system log.
\end{itemize}

The forward list looks similar. Only packets from the LAN and packets
belonging to established connections shoudl be forwarded. Netbios packets
are dropped.

\begin{example}
\begin{verbatim}
    FORWARD_POLICY='REJECT'
    FORWARD_ACCEPT_DEF='yes'
    FORWARD_LOG='no'
    FORWARD_LIST_N='2'
    FORWARD_LIST_1='137-139 DROP'
    FORWARD_LIST_2='192.168.6.0/24 ACCEPT'
\end{verbatim}
\end{example}

You can see, that the order the rules are listed in, is important: First,
netbios packets are dropped - then, packets from the LAN arre accepted.

Now the local network can communicate with the router. The packets are
forwarded. What's still missing is masquerading, that is necessary for
accessing the internet from a private network:

\begin{example}
\begin{verbatim}
    MASQUERADE_LIST_N='1'
    MASQUERADE_LIST_1='192.168.6.0/24 MASQUERADE'
\end{verbatim}
\end{example}

For this simple case, the original configuration looks much easier.
This changes, when you use the remaining options:

\begin{itemize}
\item trusted nets
\item route network
\item white list
\item black list
\end{itemize}


\subsubsection{Trusted Nets}

If we want different local subnets, that can freely and unmasqueradedly
communicate with each other, we have to make sure, packets between these
networks are neither dropped nor masqueraded. In the original configuration,
this can be done by listing them in \var{TRUSTED\_NETS}. In the new
configuration, we just add a rule or modify the already existing ones.

Supposing, the subnets are 192.168.6.0/24 and 192.168.7.0/24 and DSL over
pppoe is used. The configuration would then look like the following:

\begin{example}
\begin{verbatim}
    FORWARD_POLICY='REJECT'
    FORWARD_ACCEPT_DEF='yes'
    FORWARD_LOG='no'
    FORWARD_LIST_N='3'
    FORWARD_LIST_1='192.168.6.0/24 192.168.7.0/24 ACCEPT BIDIRECTIONAL'
    FORWARD_LIST_2='137-139 DROP'
    FORWARD_LIST_3='192.168.6.0/23 ACCEPT'

    MASQUERADE_LIST_N='2'
    MASQUERADE_LIST_1='192.168.6.0/24 192.168.7.0/24 ACCEPT BIDIRECTIONAL'
    MASQUERADE_LIST_2='192.168.6.0/23 MASQUERADE'
\end{verbatim}
\end{example}

The first rule makes sure, packets between the subnets are forwarded without
further checking. The third rule make sure, both subnets can access the
internet. The first rule of the MASQ list makes sure that the communication
between the subnets will not be masqueraded. Alternatively, we could
just define all outgoing packets via the pppoe device should be masqueraded:

\begin{example}
\begin{verbatim}
    MASQUERADE_LIST_N='1'
    MASQUERADE_LIST_1='if:any:pppoe MASQUERADE'
\end{verbatim}
\end{example}

In the same way, the filtering of the ports could have been restricted to the
pppoe device. It would look like this:

\begin{example}
\begin{verbatim}
    FORWARD_POLICY='REJECT'
    FORWARD_ACCEPT_DEF='yes'
    FORWARD_LOG='no'
    FORWARD_LIST_N='2'
    FORWARD_LIST_1='if:any:pppoe 137-139 DROP'
    FORWARD_LIST_2='192.168.6.0/23 ACCEPT'

    MASQUERADE_LIST_N='1'
    MASQUERADE_LIST_1='if:any:pppoe MASQUERADE'
\end{verbatim}
\end{example}

Outbound packets on the pppoe device that are addressed to the ports
137-139 are dropped (rule 1), all other packets from the subnet
192.168.6.0/23 are forwarded (rule 2).

\subsubsection{Route Network}

If we add a network 10.0.0.0/24 (e.g. a dial in network, we want to
communicate unmasqueraded with and the ports 137-139 should be dropped.
This would look like this:

\begin{example}
\begin{verbatim}
    FORWARD_POLICY='REJECT'
    FORWARD_ACCEPT_DEF='yes'
    FORWARD_LOG='no'
    FORWARD_LIST_N='4'
    FORWARD_LIST_1='192.168.6.0/24 192.168.7.0/24 ACCEPT BIDIRECTIONAL'
    FORWARD_LIST_2='137-139 DROP'
    FORWARD_LIST_3='192.168.6.0/23 ACCEPT'
    FORWARD_LIST_4='10.0.0.0/24 ACCEPT'

    MASQUERADE_LIST_N='2'
    MASQUERADE_LIST_1='10.0.0.0/24 ACCEPT BIDIRECTIONAL'
    MASQUERADE_LIST_2='192.168.6.0/23 MASQUERADE'
\end{verbatim}
\end{example}

\begin{itemize}
\item Rule 1 allow the communication between the subnets
  192.168.6.0/24 and 192.168.7.0/24
\item Rule 2 dropps ports 137-139
\item Rule 3 and 4 forwards packets from the subnets 192.168.6.0/24,
  192.168.7.0/24 and 10.0.0.0/24. The other direction is already included
  in \var{FORWARD\_\-ACCEPT\_\-DEF}='yes'.
\item Rule 1 of the masq list makes sure, packets from the subnet
  10.0.0.0/24 are not masqueraded.
\end{itemize}

Alternatively you could specify:

\begin{example}
\begin{verbatim}
    MASQUERADE_LIST_N='1'
    MASQUERADE_LIST_1='if:any:pppoe MASQUERADE'
\end{verbatim}
\end{example}

Only outbound packets on the pppoe interface are masqueraded.

\subsubsection{Blacklists, Whitelists}

Blacklists (a host from this list is disallowed something) and
whitelists (a host from this list is allowed something) are implemented
similary. Rules are defined, that are very specific at the beginning and
get more and more general towards the end.
When you use a blacklist, at the beginning there are rules, that disallow
something and at the end there are rules, that allow something to all the
ones not yet mentioned.
When you use a whitelist it's just the other way around.
A simple example: All host from the subnet 192.168.6.0/24 but host 12
are allowed to access the internet as long they don't try to communicate
with port 137-139:

\begin{example}
\begin{verbatim}
    FORWARD_POLICY='REJECT'
    FORWARD_ACCEPT_DEF='yes'
    FORWARD_LOG='no'
    FORWARD_LIST_N='3'
    FORWARD_LIST_1='192.168.6.12 DROP'
    FORWARD_LIST_2='137-139 DROP'
    FORWARD_LIST_3='192.168.6.0/23 ACCEPT'

    MASQUERADE_LIST_N='1'
    MASQUERADE_LIST_2='192.168.6.0/24 MASQUERADE'
\end{verbatim}
\end{example}

Only host 12 is allowed to access the internet (but not on ports...), all
other are only allowed to communicate locally with another subnet:

\begin{example}
\begin{verbatim}
    FORWARD_POLICY='REJECT'
    FORWARD_ACCEPT_DEF='yes'
    FORWARD_LOG='no'
    FORWARD_LIST_N='3'
    FORWARD_LIST_1='192.168.6.0/24 192.168.7.0/24 ACCEPT BIDIRECTIONAL'
    FORWARD_LIST_2='137-139 DROP'
    FORWARD_LIST_3='192.168.6.12 ACCEPT'

    MASQUERADE_LIST_N='1'
    MASQUERADE_LIST_1='if:any:pppoe MASQUERADE'
\end{verbatim}
\end{example}

You could continue endlessly \ldots

\section{TBD: Nullmodemkabel (weitere weiter unten!)}


    To be able to use the optional program packets PPP and IMODEM you
    will need a Nullmodemkabel.

    It has to have at least 7 strands. Following the pin assignment:

\begin{example}
%\begin{verbatim}
%                      female                   female
%                    9pol  25pol             25pol   9pol
%
%                     3      2 -------------- 3        2
%                     2      3 -------------- 2        3
%                     7      4 -------------- 5        8
%                     8      5 -------------- 4        7
%                     4     20 -------------- 6,8    6,1
%                   6,1    6,8 -------------- 20       4
%                     5      7 -------------- 7        5
%\end{verbatim}
%\end{example}
\begin{verbatim}

TBD: viel :)
Stift-  Buchsen-                     Buchsen-  Stift-
    leiste                                leiste
25pol     9pol                        9pol     25pol

     8 +- 1                             1  -+    8
       |                                    |
     3 |  2 ------------\ /------------ 2   |    3
       |                 X                  |
     2 |  3 ------------/ \------------ 3   |    2
       |                                    |
   20  +- 4                             4  -+   20
       |                                    |
    7  |  5 --------------------------- 5   |    7
       |                                    |
    6  +- 6                             6  -+    6
                                                                                                                                                             
    4  +- 7                             7  -+    4
       |                                    |
    5  +- 8                             8  -+    5


\end{verbatim}
\end{example}


    Bei 25-poligen Steckern muss also eine Brücke zwischen Pin 6 und
    8, bei 9-poligen Steckern zwischen 6 und 1 gelötet werden.


    \marklabel{SERIALCONSOLE}{\section{Serielle Console}}

    fli4l can be run without monitor or keyboard. One of the drawbacks is,
    that you won't be able to notice error message because not all messages
    can be piped through the syslog interface.

    One possibility is to redirect the messages from the console to a PC or
    a classical Terminal using the serial interface. The configuration is
    done using the variables \var{SER\_CONSOLE}, \var{SER\_CONSOLE\_IF} and
    \var{SER\_CONSOLE\_RATE}.

    
    Rechner mit älteren Mainboards/Karten unterstützen keine höheren 
    Geschwindigkeiten als 38400 Bd. Deshalb sollte man es zunächst mit
    höchstens 38400 Bd probieren, bevor man sich an höhere Geschwindigkeiten 
    heranwagt. Da lediglich Text-Ausgaben über die Console gehen, sind höhere 
    Geschwindigkeiten eigentlich auch gar nicht notwendig.

    Sämtliche Meldungen, die normalerweise auf der Console ausgegeben werden,
    werden nun auf die serielle Schnittstelle gelenkt - auch die Meldungen
    des Bootvorgangs!

    Als Kabel zum Terminal oder PC mit Terminalemulation kommt ein 
    Nullmodemkabel zum Einsatz. Ich rate aber davon ab, ein Standard-
    Nullmodemkabel zu verwenden, weil dort normalerweise auch die Handshake-
    Leitungen verdrahtet sind. Ist das Terminal bzw. der PC abgeschaltet 
    (oder die Terminalemulation nicht geladen), kann es bei Verwendung eines 
    Standard-Nullmodemkabels zu einem Hangup von fli4l kommen!

    Deshalb ist hier eine spezielle Verdrahtung notwendig, um fli4l auch mit 
    abgeschaltetem Terminal betreiben zu können. Es wird dafür ein 3-adriges 
    Kabel benötigt, wobei einige Kontakte an den Steckern gebrückt werden 
    müssen.

\begin{verbatim}
                      female                   female
                    9pol  25pol             25pol   9pol
                     3      2 -------------- 3        2
                     2      3 -------------- 2        3
                     7      4 -+          +- 5        8
                               |          |
                     8      5 -+          +- 4        7
                     6      6 -+          +- 6        6
                               |          |
                     1      8 -+          +- 8        1
                               |          |
                     4     20 -+          +- 20       4
                     5      7 -------------- 7        5
\end{verbatim}



    \section{Programme}
    
    Um Platz auf der Diskette zu sparen, wird unter anderem das Paket
    ``BusyBox'' verwendet. Das Programm ist ein einzelnes Exceutable,
    welches die Standard-Unix-Programme

\begin{example}
\begin{verbatim}
        basename, busybox, cat, chgrp, chmod, chown, cp, cut, date, dd,
        df, dirname, expr, grep, gunzip, hostname, insmod, kill, killall,
        ln, ls, lsmod, mkdir, mount, mv, nslookup, ping, ps, reboot, rm,
        rmmod, sleep, sync, tar, tr, umount, zcat
\end{verbatim}
\end{example}
    
    nachbildet. Zumeist sind es jedoch ``minimalistische''
    Implementationen, welche nicht den vollen Funktionsumfang
    abdecken, aber vollauf den bescheidenen Anforderungen von fli4l
    genügen.
    
    BusyBox steht unter GPL und ist als Source komplett erhältlich
    unter

    \link{http://www.busybox.net/}
    
    Ich habe teilweise den BusyBox-Source anpassen müssen. Näheres
    dazu findet man in src/README.
    
    Desweiteren wurden einige Programme aus der SuSE-5.3-Distribution
    durch kleinere Versionen aus tomsrtbt ersetzt. Das sind:

\begin{example}
\begin{verbatim}
        /bin/ash
        /sbin/route
\end{verbatim}
\end{example}
    
    Vielen Dank an dieser Stelle an Christoph Peus, der mir den Wink
    gab und auch direkt die Programme als Attachment mitschickte :-)

    \section{Andere i4l-Tools}
    
    Es gibt für isdn4linux viele weitere Tools, die auch fli4l
    bereichern würden. Das Problem ist leider der Platz! Bestimmt wäre
    isdnlog als Tool zum Berechnen der Online-Gebühren wesentlich
    geeigneter, jedoch ist isdnlog einfach zu fett!
    
    imond braucht weniger als 10\% des Platzes, übernimmt dabei Monitoring,
    Controlling und LC-Routing, wenn auch nicht alles ganz perfekt
    ist.

    \section{Shell und weitere Kommandos}
    
    Am Ende des Bootvorgangs von fli4l findet man auf der Konsole eine
    Shell vor. Aus Platzgründen jedoch die wesentlich schlankere ash statt
    der bekannten bash.  Viel kann bzw. soll man sowieso nicht eintippen
    (falls überhaupt eine Tastatur angeschlossen ist, siehe ``Sonstiges'').
    
    Der Befehl ``help'' listet die eingebauten Kommandos der ash auf.
    Die busybox-Programme zeigt der Befehl ``busybox'' an.  Weitere
    Programme befinden sich in /sbin, /usr/sbin, /bin, /usr/bin und
    /usr/local/bin.  Folgendes Shellkonstrukt zeigt diese Programme an:

\begin{example}
\begin{verbatim}
                ( IFS=:; ls ${PATH%.} )
\end{verbatim}
\end{example}


    \section{Fehlersuche}
    
    Hilfreich bei der Fehlersuche sind natürlich einmal die
    Console-Outputs.  Diese rauschen aber oft einfach so durch, dass
    man gar nicht mehr mitlesen kann. Hinweis: Mit SHIFT-BILD-RAUF
    kann man zurück-, mit SHIFT-BILD-RUNTER wieder vorblättern.

    Auch proc-Dateien können bei der Fehlersuche helfen. z.B. gibt der
    Befehl

\begin{example}
\begin{verbatim}
                cat /proc/interrupts
\end{verbatim}
\end{example}
    
    die von den Treibern verwendeten Interrupts aus - nicht die
    tatsächlich von der Hardware belegten!

    Weitere interessante Dateien unter /proc sind devices, dma,
    ioports, kmsg, meminfo, modules, uptime, version und pci (falls
    der Router einen PCI-Bus hat).
    
    Meist liegt ein Verbindungsproblem bei ipppd vor, insbesondere bei
    der Authentifizierung. Dann helfen oft die Variablen

\begin{example}
\begin{verbatim}
        OPT_SYSLOGD='yes'
\end{verbatim}
\end{example}

    bzw.

\begin{example}
\begin{verbatim}
        ISDN_CIRC_x_DEBUG='yes'
\end{verbatim}
\end{example}

    in config.txt weiter.


    \section{Fehler im Zusammenhang mit Festplatten/CompactFlashs}
    
    {\bf Problem:}

    \begin{itemize}
    \item der Router erkennt die Festplatte überhaupt nicht.
    \end{itemize}

    Mögliche Ursachen:

    \begin{itemize}
    \item das \var{OPT\_\-HDDRV} wurde nicht konfiguriert und damit fehlen dem
      Router die Treiber für den HD-Controller
    \item Platte ist falsch in BIOS eingetragen.
    \item der IDE-Controller ist defekt oder abgeschaltet.
    \item es wird bei der Installation die falsche Platte angegeben
      (z.B. wird eine Festplatte am zweiten IDE-Kanal als hdc oder
      hdd angesprochen)
    \item der IDE-Controller wird nicht von fli4l unterstützt. Aktuelle 
      UDMA-Controller benötigen spezielle Treiber, die in fli4l 
      nicht enthalten sind
    \end{itemize}

    {\bf Problem:}
    \begin{itemize}
    \item die Installation bricht ab
    \item nach einem Remote-Update des opt.tgz bootet der Router nicht
      mehr
    \item es gibt Fehlermeldungen beim Partitionieren oder Formatieren
      der Festplatte
    \end{itemize}

    Mögliche Ursachen:
    \begin{itemize}
    \item bei neuen Ultra-DMA-Festplatten könnte es an zu langen oder
      ungeeigneten IDE-Kabeln liegen
    \item bei älteren Festplatten ist die Einstellung der
      Transferrate/PIO-Mode im Bios oder auf dem Controler evtl. zu
      schnell für die Platte.
    \item ungeigneter IDE-Chipsatz
    \end{itemize}

    Bemerkungen:
    \begin{itemize}
    \item wenn der Router nur nicht mehr vom Netzwerk aus ansprechbar
      ist und man die Notfalloption zusätzlich installiert hat, kann
      man vor Ablauf der Wartezeit den Router mit der Reset-Tase neu
      starten (oder einfach aus- und einschalten). Dann wird mit der
      Notfall-Version gestartet und man kann ein korrigiertes opt.tgz
      aufspielen.
    \end{itemize}


    {\bf Problem:}
    \begin{itemize}
    \item der Router arbeitet nach der Installation auf Festplatte
      nicht mehr so wie nach der Installation auf Diskette
    \end{itemize}

    Mögliche Ursache:
    \begin{itemize}
    \item es werden soviele Pakete benutzt, daß die Resourcen des
      Rechners nicht ausreichen (zuwenig RAM, CPU, andere Hardwareprobleme)
    \end{itemize}

    Bemerkungen:
    \begin{itemize}
    \item gerade bei Verwendung einer Swap-Partition ist die
      einwandfreie Funktion der Festplatte und des Controllers sehr
      wichtig.
    \end{itemize}


    {\bf Problem:}
    \begin{itemize}
    \item nach der Installation bootet fli4l nicht von Festplatte
    \end{itemize}
    
    Mögliche Ursache:
    \begin{itemize}
    \item falls nur noch die Buchstaben LI erscheinen, war auf der Festplatte
    vorher Linux mit LILO installiert. Es sind noch Reste vom LILO im 
    Master-Boot-Record zu finden. Mit einer DOS-Bootdisk und dem Befehl 
    ``fdisk /mbr'' kann man diese Reste entfernen.
    \item wenn der Bootvorgang von einem CF-Modul fehlschlägt sollte man prüfen
    ob das CF-Modul im Bios mit LBA oder LARGE erkannt wurde. Die richtige 
    Einstellung für Module unter 512MB ist NORMAL oder CHS. 
    \end{itemize}


    {\bf Problem:}
    \begin{itemize}
    \item am Router erscheinen Fehlermeldungen ``hda: lost
      interrrupt''
    \item nach einiger Betriebsdauer treten Filesystemfehler auf bis
      hin zu kaputten Partitionstabellen, was eine Neuinstallation
      notwendig macht.
    \end{itemize}

    Mögliche Ursache:
    \begin{itemize}
    \item im BIOS wurde die Platte zu schnell eingestellt oder die Hardware
      ist schon mit dem geringfügigen Tuning des \var{OPT\_\-HDTUNE} überfordert.
      In diesem Fall hilft wohl nur den Parameter \var{HDTUNE\_\-PERFORMANCE} auf 
      'no' zu stellen und die einstellung im BIOS zu verlangsamen.
    \end{itemize}

    Bemerkungen:
    \begin{itemize}
    \item generell sollte man bei \var{OPT\_\-HDTUNE} aufpassen, daß man seine
      Hardware nicht überfordert. Der Startvorgang des Routers ist
      auch auf der langsamsten Festplatte ohne jegliches Tuning noch
      viel schneller als der Start von einer Diskette!
    \end{itemize}


    \section{Literaturhinweise}

    \begin{itemize}
    \item Computer Networks, Andy Tanenbaum
    \item TCP/IP Netzanbindung von PCs, Craig Hunt
    \item TCP/IP, Kevin Washburn, Jim Evans, Verlag: Addison-Wesley, \\ISBN: 3-8273-1145-4
    \item TCP/IP Netzanbindung von PCs, ISBN 3-930673-28-2, 69,- DM
    \item TCP/IP Netzwerk Administration, ISBN 3-89721-110-6, 79,- DM
    \item Linux-Anwenderhandbuch, ISBN 3-929764-06-7, 59,- DM
    \item TCP/IP IM DETAIL
    \item \link{http://www.nickles.de/stories/stories.php3?displaypage=1\&category=14\&story=0005\&story\_id=112}
    \item Oder generell das Linuxanwenderhandbuch von Lunetix unter\\
      \link{http://lhb.lunetix.de/LHB/ online} ;-)
    \item Einführung in die Linux-Firewall:
      \link{http://www.little-idiot.de/firewall}
    \end{itemize}


    \section{Sonstiges}
    
    Bei mir stand bisher der fli4l-Router im Keller, an dem noch nicht
    mal eine Tastatur angeschlossen war (geschweige denn ein Monitor
    :-). Mittlerweile steht er wieder direkt neben meinem
    Entwicklungsrechner. Grund: Wegen der stetigen Weiterentwicklung
    an fli4l muss ich natürlich öfter mal etwas ausprobieren. Da wurde
    ich langsam das viele Laufen leid\ldots
    
    Trotzdem ist im Normalfall keine Tastatur nötig. Einige
    schilderten mir sogar, dass es auch ohne VGA-Karte funktioniert,
    wenn man noch mehr Strom sparen möchte. Jedoch muss man im
    Rechner-BIOS zumindest den Tastatur-Check abschalten, damit die
    Kiste beim Booten nicht stehenbleibt. Ohne VGA-Karte sollte man
    generell sämtliche Fehlerchecks im BIOS abschalten (""Halt on No
    Error""). Wird jedoch eine neuere VGA-Karte verwendet, an der kein
    Monitor angeschlossen ist, kann der Rechner beim Booten ein
    paarmal tuten. Der Boot-Vorgang wird dann aber normalerweise
    fortgesetzt.

    \section{Keine Gewähr und Haftung}
    
    Natürlich kann ich für das gesamte fli4l-Paket oder für Teile
    davon keine Gewähr dafür übernehmen, dass es überhaupt
    funktioniert oder dass irgendeine Dokumentation in diesem
    Verzeichnis oder einem der Unterverzeichnisse korrekt ist.

    Auch ist jede Haftung meinerseits wegen evtl. entstandender
    Schäden oder Kosten ausgeschlossen !!!

    \section{D. wie ``Danke''}

    Zunächst erst einmal Dank an Carsten Cerny, der die Webpage

    \link{http://www.fli4l.de}
    
    betreut. Dort findet man Support, Download der aktuellen Software,
    eine Newsgroup und vieles mehr. Es lohnt sich auf jeden Fall,
    dort reinzuschauen!

    Ganz besonders möchte ich mich natürlich bei denen bedanken, die
    eigene Programmpakete oder Dokumentation beigesteuert bzw.
    übernommen haben.


    \newcommand{\member}[3]{#1 (\emph{#2}) & \email{#3}\\}

    Das fli4l-Team bilden (in alphabetischer Reihenfolge):

    \begin{tabular}{ll}
      \member{Arwin Vosselman} {LZS-Kompression}           {arwin@xs4all.nl}
      \member{Carsten Cerny} {Homepage \& fliwiz}           {carsten.cerny@cc13.com}
      \member{Christian Karner} {PPTP-Package}             {christian.karner@aon.at}
      \member{Christoph Peus} {Imodem- und VBOX-Package}   {cp@uni-wh.de}
      \member{Florian Zierer} {Wunschliste}                {florian@ziererweb.de}
      \member{Frank Meyer} {Der eigentliche fli4l}         {frank@fli4l.de}
      \member{Gerrit Kaiser} {Logo}                        {gk@epassage.de}
      \member{Gerrit Lammert} {HTML-Dokumentation}         {gerrit@fli4l.de}
      \member{Hans-Joerg Grabner} {imonc}                  {ximonc@gmx.at}
      \member{Harald Schäfer} {HDD-Support}                {harald@fli4l.de}
      \member{Jürgen Bauer} {LCD-Package \& fliwiz}        {jb@idowa.de}
      \member{Kai-Christian Arndt} {SCSI}                  {kai-christian.arndt@gmx.de}
      \member{Kees Blokland} {english translation}         {kees@blokland.net}
      \member{Marcus Klein} {Problemfeedback}              {marcus1@marcus1.de}
      \member{Matthias Grammel} {english translation}      {matt.grammel@t-online.de}
      \member{Louis Reinard} {CompactFlash}                {louee@compuserve.com}
      \member{Nico Wallmeier} {Imonc}                      {nico@fli4l.de}
      \member{Oliver Dawid} {uclibc}                        {od@fet.uni-hannover.de}

      \member{Steffen Peiser} {FAQ}                        {stpeiser@chefmail.de}
      \member{Stefan Strigler} {ML \& NG}                  {zeank@zedat.fu-berlin.de}
      \member{Thomas Bork} {Samba}                         {knuffelmail@gmx.de}
      \member{Thorsten Pohlmann} {Mini-httpd}              {pohlmann@tetronik.com}
      \member{Tobias Gruetzmacher} {Mini-httpd}            {tobias@portfolio16.de}
      \member{Tom Raschel} {IPX}                           {tom64@freenet.de}
      \member{Ulf Lanz} {LCD}                              {ulf.lanz@t-online.de>}
    \end{tabular}

    Ich hoffe, daß diese Liste zukünftig noch etwas länger wird ;-)

    Seit einiger Zeit wird die Support-Mailingliste (erreichbar über
    das Support-Formular auf www.fli4l.de) stärker frequentiert. Als
    tatkräftige Verstärkung des Support-Teams sind hier zu nennen:

    \newcommand{\person}[2]{#1 & \email{#2}\\}

    \begin{tabular}{ll}
      \person{Arno Behrends}                               {arno@fli4l.de}
      \person{Georg Neis}                                  {georg.neis@gmx.de}
      \person{Nicole Hornung}                              {nicole.hornung@epost.de}
      \person{Stefan Krister}                              {stefan.krister@keimfarben.de}
    \end{tabular}
    
    Zur Zeit wird auch ein Team für Öffentlichkeitsarbeit gebildet.
    Engagiert sind hier:

    \begin{tabular}{ll}
      \member{Christa MacNelly} {Präsentationen}           {ChristaMN@gmx.de}
      \member{Fabian Woelk} {Newsletter}                   {fawel@gmx.de}
      \member{Frank Lang} {allgemein}                      {des919@gmx.de}
      \member{Günter Brauer} {allgemein}                   {gbzzr1100@t-online.de}
      \member{Michael Pahle} {Newsletter}                  {michael.pahle@t-online.de}
      \member{Paul H.} {allgemein}                         {Inquisitor@surfnett.de}
    \end{tabular}
    
    Außerdem Dank an die vielen fli4l-User, die Anregungen gegeben
    haben oder Beta-Tester spielten und mir Ihre Erfahrungen
    mitteilten, insbesondere an (in alphabetischer Reihenfolge):

    \begin{tabular}{ll}
      \person{Albrecht Ihlenfel}           {100.11788@germanynet.de}
      \person{Alexander Levenetz}          {al64@bigfoot.com}
      \person{Andreas Schildbach}          {andreas@schildba.ch}
      \person{Eric Wolzak}                 {linux\_user@gmx.de}
      \person{Frank Kluge}                 {frank.kluge@t-online.de}
      \person{Joachim Kipka}               {j.kipka@t-online.de}
      \person{Lothar Engel}                {engel@mail.in-kestert.de}
      \person{Martin Schulze}              {schulze@fs.is.uni-sb.de}
      \person{Michael Bierwirth}           {m.bierwirth@gmx.net}
      \person{Ralf Steck}                  {rsteck@die-textwerkstatt.de}
      \person{Robert W. Kuhn}              {robert@vermtech.de}
      \person{Steffen Peiser}              {stpeiser@chefmail.de}
      \person{Stephanos Baglatzis}         {SBaglatzis@mh2.mannex.de}
      \person{Tobias Hofmann}              {tobias.hofmann@medien.uni-weimar.de}
      \person{Wenzel Kappenhagen}          {WKappenhagen@IhrPartner.de}
      \person{Wolfgang Struhalla}          {struhalla@heimhaus.de}
    \end{tabular}

    und viele weitere User aus der fli4l-ML.

    
    Seit einiger Zeit hat fli4l nun auch seine eigenen Sponsoren, die
    mit Ihrer (Hardware-)Spende die Weiterentwicklung von fli4l
    unterstützen. Dabei handelt es sich um Adapter, CompactFlash und
    Ethernetkarten.

    Zu nennen sind hier (in alphabetischer Reihenfolge):

    \begin{tabular}{ll}
      \person{Christopher Stärkel}         {tiger08@staerkel.de}
      \person{Detlef Reichelt}             {drcux@uni.de}
      \person{Heiko Dross}                 {Heiko.Dross@t-online.de}
      \person{Joachim Kipka}               {j.kipka@t-online.de}
      \person{Jürgen Baue}r                {jb@idowa.de}
      \person{Louis Reinard}               {louee@compuserve.com}
      \person{Steffen Peiser}              {stpeiser@chefmail.de}
      \person{Stephanos Baglatzis}         {SBaglatzis@mh2.mannex.de}
      \person{Tom Klopfer}                 {tk@mzm.de}
      \person{Wenzel Kappenhagen}          {WKappenhagen@IhrPartner.de}
    \end{tabular}

    
    Auch ist mittlerweile die Eintragung von fli4l als Wort-/Bildmarke
    beantragt (aber noch nicht abgeschlossen). Folgende fli4l-Anwender
    (neben einigen, die nicht genannt werden wollten :) haben
    geholfen, das dafür nötige Geld zusammen zu bekommen:

    \begin{tabular}{ll}
      \person{Arno Behrends}               {arno@fli4l.de}
      \person{Christa Mac Nelly}           {ChristaMN@gmx.de}
      \person{Christian Holpert}           {usenet.christian@holpert.de}
      \person{Christian Wiebel}            {cw@v-graphix.de}
      \person{Christoph Sternberg}         {cslist@gmx.de}
      \person{Fabian Woelk}                {fawel@gmx.de}
      \person{Hans-Jürgen Mahnke}          {ibmahnke@gmx.de}
      \person{Heiko Becker}                {heiko@shruuf.de}
      \person{Ingo Roessler}               {roessler@gmx.de}
      \person{Jens Lehnen}                 {jens@anLehnen.com}
      \person{Juergen Schneider}           {jsffm@web.de}
      \person{Klaus-Ruediger Ludwig}       {Klaus-Ruediger.Ludwig@t-online.de}
      \person{Matthias Sennewald}          {matthias@sennewald.org}
      \person{Michael Mücke}               {Michael.Muecke@web.de}
      \person{Michael Schiele}             {mike@netmate.de}
      \person{Nicole Hornung}              {nicole.hornung@epost.de}
      \person{Norbert Bebensee}            {NB.Foto-DV@online.de}
      \person{Olaf Hahn}                   {DL9ABN@ao-hahn.de}
      \person{Oliver Walter}               {OWB@gmx.de}
      \person{Owen Menck}                  {Owen.Menck@metagroup.com}
      \person{Paul Hogrefe}                {paul@innovacomputer.de}
      \person{Ralf Brederlow}              {mail@bsm-technik.de}
      \person{Robert Kuhn}                 {robert@vermtech.de}
      \person{Stefan Böhm}                 {s.boehm@gmx.li}
      \person{Stefan Mende}                {stefan@mendedigital.de}
      \person{Suitbert Schönleber}         {SSchoenleber@t-online.de}
      \person{Thomas Vollmar}              {tvo@gmx.net}
      \person{Vincent de Groot}            {VdeGroot@gmx.net}
    \end{tabular}

    Dankeschön!

    \section{Feedback}

    Kritik, Feedback und Zusammenarbeit ist jederzeit willkommen.
    
    Gerade weil für fli4l-Router meist ältere Hardware eingesetzt
    wird, kann es immer wieder mal zu Problemen kommen. Um möglichst
    viele erfolgreich eingesetzte Hardware-Konstellationen zu
    beschreiben, wurde auf der fli4l-Homepage ein Formular hinterlegt,
    wo jeder seine verwendete Hardware angeben kann. Diese
    Informationen können anderen fli4l-Usern bei Problemen mit der
    Hardware weiterhelfen, denn es gibt immer wieder Probleme mit den
    PC-Karten bzgl. I/O-Adressen, Interrupts und so weiter.
    
    Auch kann man Informationen/Problembeschreibungen in der
    fli4l-Mailingliste (neuerdings auch als Newsgroup verfügbar) mit
    anderen fli4l-Usern austauschen.  Dies hat auch einen enormen
    Vorteil: es horchen andere mit, die das Problem evtl. schon selbst
    hatten und auch mittlerweile eine Lösung gefunden haben.  Die
    nötigen Informationen zum Anmelden findet man ebenso auf der
    fli4l-Homepage.
    
    Da ich selber mit Zuschriften so stark belastet bin, daß ich kaum
    noch selber antworten kann, bitte ich, zur
    Problemfindung/Erfahrungsaustausch vornehmlich die oben
    beschriebenen Möglichkeiten auszunutzen.


    Viel Spaß mit fli4l!

    Frank Meyer, \email{frank@fli4l.de}

