retronetworking
/
isdn4k-utils
12
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Compare commits

merge into: retronetworking:master
Branches Tags
retronetworking:master
retronetworking:cvsimport
retronetworking:capiconn
retronetworking:isdnlog-tbr-last_lnx22
retronetworking:v0_1_12
retronetworking:isdnlog-4_70
retronetworking:isdnlog-4_68
retronetworking:v3_2p3
retronetworking:v3_1pre1
retronetworking:v3_1beta6
retronetworking:v3_1beta1
retronetworking:eftp4linux-0_0_11
retronetworking:T2-1-126/2-0-35
retronetworking:isdnutils_2_2b1
retronetworking:isdn4k-utils-2_1b1
retronetworking:release_2_0_0_B3
retronetworking:release_2_0_0_B2
...
pull from: retronetworking:cvsimport
Branches Tags
retronetworking:master
retronetworking:cvsimport
retronetworking:capiconn
retronetworking:isdnlog-tbr-last_lnx22
retronetworking:v0_1_12
retronetworking:isdnlog-4_70
retronetworking:isdnlog-4_68
retronetworking:v3_2p3
retronetworking:v3_1pre1
retronetworking:v3_1beta6
retronetworking:v3_1beta1
retronetworking:eftp4linux-0_0_11
retronetworking:T2-1-126/2-0-35
retronetworking:isdnutils_2_2b1
retronetworking:isdn4k-utils-2_1b1
retronetworking:release_2_0_0_B3
retronetworking:release_2_0_0_B2

No commits in common. "master" and "cvsimport" have entirely different histories.
master ... cvsimport

690 changed files with 128885 additions and 183290 deletions
Show Stats Expand all files Collapse all files

28
.gitignore vendored
View File

@ -1,28 +0,0 @@
#
# NOTE! Don't add files that are generated in specific
# subdirectories here. Add them in the ".gitignore" file
# in that subdirectory instead.
#
# NOTE! Please use 'git ls-files -i --exclude-standard'
# command after changing this file, to see if there are
# any tracked files which get ignored after the change.
#
# Normal rules
#
.deps
.libs
*.la
*.lo
*.o
*.o.*
*.a
*.s
*.so
*.so.dbg
*.i
*.lst
*~
autom4te.cache
ChangeLog
config.log

43
gpl-2.0.txt → COPYING
View File

@ -1,12 +1,13 @@
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
675 Mass Ave, Cambridge, MA 02139, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
@ -15,7 +16,7 @@ software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Lesser General Public License instead.) You can apply it to
the GNU Library General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
@ -55,8 +56,8 @@ patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
@ -110,7 +111,7 @@ above, provided that you also meet all of these conditions:
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
@ -168,7 +169,7 @@ access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
@ -225,7 +226,7 @@ impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
@ -255,7 +256,7 @@ make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
@ -277,9 +278,9 @@ YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
END OF TERMS AND CONDITIONS
Appendix: How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
@ -291,7 +292,7 @@ convey the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
Copyright (C) 19yy <name of author>
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
@ -303,16 +304,16 @@ the "copyright" line and a pointer to where the full notice is found.
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.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
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., 675 Mass Ave, Cambridge, MA 02139, USA.
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) year name of author
Gnomovision version 69, Copyright (C) 19yy name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
@ -335,5 +336,5 @@ necessary. Here is a sample; alter the names:
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Lesser General
library. If this is what you want to do, use the GNU Library General
Public License instead of this License.

4
FAQ/.cvsignore Normal file
View File

@ -0,0 +1,4 @@
config.*
*.html
*.txt
Makefile

226
FAQ/_example/config.txt
View File

@ -1,113 +1,113 @@
From: Torsten Hentschel <Torsten.Hentschel@DInet.de> Subject: Re: Now i found something else to wonder about.. (was: Re: options files) To: isdn4linux@hub-wue.franken.de
Date: Thu, 24 Oct 1996 22:47:17 +0200 (MET DST) Sender: owner-isdn4linux@hub-wue.franken.de Reply-To: isdn4linux@hub-wue.franken.de
Hello Emil & Mogens!
> Hello Mogens,
>
> You wrote:
> > isdnctrl addif ippp0
> > isdnctrl pppbind ippp0
> > ifconfig ippp0 193.89.84.10 p-t-p 193.89.84.11
---
> > route add -net 194.192.159.0 metric 1 netmask 255.255.255.224 ippp0
> > ipppd user XXX1 /dev/ippp0 193.89.84.10:193.89.84.11 file
> > /etc/ppp/options.ippp0
>
> > isdnctrl addif ippp1
> > isdnctrl pppbind ippp1
> > ifconfig ippp0 193.89.84.10 p-t-p 193.89.84.13
--- why do you repeat the ifconfig?
probably it should be "ippp1" here?
> > route add -net 192.168.1.0 metric 1 netmask 255.255.255.0 ippp1
> > ipppd user XXX2 /dev/ippp1 193.89.84.10:193.89.84.11 file
> > /etc/ppp/options.ippp1
>
> Compare the two ifconfig commands, they are for the same interface.
> And AFAIK the two interfaces need different ip-adresses.
With this I do not agree. It is simply possible to give two interfaces the same local ip address. You may even establish two routes on them. But only the first one found in the routing table will be used by the kernel. So the other route won't have any effect.
Configuring two interfaces with the same local IP address does make sense if you want to use as less IP adresses as possible (very honorable as long as IPv6 is not common practice).
An interface IP-Adress is used by the kernel to give outgoing packets (not the forwarded packets) a sender IP address within the IP header.
To make the IP address 193.89.84.10 (as used in the above example) pingable I would suggest the following (changes ar marked at the right margin):
| ifconfig dummy0 193.89.84.10 # module has to be loaded before | route add -host 193.89.84.10 # only to have 193.89.84.10 reachable
# all the time
isdnctrl addif ippp0
| ifconfig ippp0 down # to make it exclusively bindable
isdnctrl pppbind ippp0
| ifconfig ippp0 193.89.84.10 p-t-p 193.89.84.11 up | route add -host 193.89.84.11 metric 1 ippp0 | route add -net 194.192.159.0 metric 1 \ | netmask 255.255.255.224 gw 193.89.84.11
ipppd user XXX1 /dev/ippp0 193.89.84.10:193.89.84.11 \
file /etc/ppp/options.ippp0
isdnctrl addif ippp1
| ifconfig ippp1 down # to make it exclusively bindable
isdnctrl pppbind ippp1
| ifconfig ippp1 193.89.84.10 p-t-p 193.89.84.13 up | route add -host 193.89.84.13 metric 1 ippp0 | route add -net 192.168.1.0 metric 1 \ | netmask 255.255.255.0 gw 193.89.84.13
ipppd user XXX2 /dev/ippp1 193.89.84.10:193.89.84.11 \
file /etc/ppp/options.ippp1
You may even try the following to "emulate" cisco's dialer rotary group where you may put several BRIs (basic rate interfaces = ISDN S0 [gr.]) into one netmask. Therefore the example would look like (changes aren't marked any more; completely different):
#!/bin/bash
# assuming, we are using a network of
# 193.89.84.0/255.255.255.240
# for a dial up server where
# 193.89.84.1 is the IP for the server and
# 193.89.84.2-14 are the addresses for remote interfaces.
ifconfig dummy0 193.89.84.1 # module has to be loaded before
route add -host 193.89.84.1 # only to have 193.89.84.1 reachable
# all the time
USER_ippp0="XXX1"
RMTNET_ippp0=194.192.159.0
RMTMSK_ippp0=255.255.255.224
USER_ippp1="XXX2"
RMTNET_ippp1=192.168.1.0 # masquerading is great!
RMTMSK_ippp1=255.255.255.0
USER_ippp2="XXX3"
RMTNET_ippp2="" # you may leave 'em blank
RMTNET_ippp2="" # if there is no remote net
[...] # fill out to your needs
for x in 2 3 4 5 6 7 8 9 10 11 12 13 14
do
IFNAME="ippp$[$x-2]"
isdnctrl addif $IFNAME
ifconfig $IFNAME down # to make it exclusively bindable
isdnctrl pppbind $IFNAME
ifconfig $IFNAME 193.89.84.1 netmask 255.255.255.240 up
route add -host 193.89.84.$x metric 1 $IFNAME
eval NET="\${RMTNET_${IFNAME}}"
eval MSK="\${RMTNET_${IFNAME}}"
if [ -n "$NET" -a -n "$MSK" ]
then
route add -net $NET metric 1 netmask $MSK gw 193.89.84.$x
fi
eval USER="\${USER_${IFNAME}}"
ipppd user "$USER" /dev/$IFNAME 193.89.84.1:193.89.84.$x \
file /etc/ppp/options.$IFNAME
done
No warranty, it's untested.
But please yell at me (politely) if I'm wrong.
Regards,
Torsten
--
/\ Delta Internet GmbH / \ DI Delta Internet GmbH von-Siemens-Str. 12 /____\ Netzwerkdienst & Vertrieb 59757 Arnsberg
ALLES NUR AUS LINUX Tel. +49 2932 916 132 Fax 191 --------------------------------------------------- To remove yourself from this mailing list send email to majordomo@hub-wue.franken.de containing "unsubscribe isdn4linux <your_email_address>" in the message body [-vg]
From: Torsten Hentschel <Torsten.Hentschel@DInet.de> Subject: Re: Now i found something else to wonder about.. (was: Re: options files) To: isdn4linux@hub-wue.franken.de
Date: Thu, 24 Oct 1996 22:47:17 +0200 (MET DST) Sender: owner-isdn4linux@hub-wue.franken.de Reply-To: isdn4linux@hub-wue.franken.de
Hello Emil & Mogens!
> Hello Mogens,
>
> You wrote:
> > isdnctrl addif ippp0
> > isdnctrl pppbind ippp0
> > ifconfig ippp0 193.89.84.10 p-t-p 193.89.84.11
---
> > route add -net 194.192.159.0 metric 1 netmask 255.255.255.224 ippp0
> > ipppd user XXX1 /dev/ippp0 193.89.84.10:193.89.84.11 file
> > /etc/ppp/options.ippp0
>
> > isdnctrl addif ippp1
> > isdnctrl pppbind ippp1
> > ifconfig ippp0 193.89.84.10 p-t-p 193.89.84.13
--- why do you repeat the ifconfig?
probably it should be "ippp1" here?
> > route add -net 192.168.1.0 metric 1 netmask 255.255.255.0 ippp1
> > ipppd user XXX2 /dev/ippp1 193.89.84.10:193.89.84.11 file
> > /etc/ppp/options.ippp1
>
> Compare the two ifconfig commands, they are for the same interface.
> And AFAIK the two interfaces need different ip-adresses.
With this I do not agree. It is simply possible to give two interfaces the same local ip address. You may even establish two routes on them. But only the first one found in the routing table will be used by the kernel. So the other route won't have any effect.
Configuring two interfaces with the same local IP address does make sense if you want to use as less IP adresses as possible (very honorable as long as IPv6 is not common practice).
An interface IP-Adress is used by the kernel to give outgoing packets (not the forwarded packets) a sender IP address within the IP header.
To make the IP address 193.89.84.10 (as used in the above example) pingable I would suggest the following (changes ar marked at the right margin):
| ifconfig dummy0 193.89.84.10 # module has to be loaded before | route add -host 193.89.84.10 # only to have 193.89.84.10 reachable
# all the time
isdnctrl addif ippp0
| ifconfig ippp0 down # to make it exclusively bindable
isdnctrl pppbind ippp0
| ifconfig ippp0 193.89.84.10 p-t-p 193.89.84.11 up | route add -host 193.89.84.11 metric 1 ippp0 | route add -net 194.192.159.0 metric 1 \ | netmask 255.255.255.224 gw 193.89.84.11
ipppd user XXX1 /dev/ippp0 193.89.84.10:193.89.84.11 \
file /etc/ppp/options.ippp0
isdnctrl addif ippp1
| ifconfig ippp1 down # to make it exclusively bindable
isdnctrl pppbind ippp1
| ifconfig ippp1 193.89.84.10 p-t-p 193.89.84.13 up | route add -host 193.89.84.13 metric 1 ippp0 | route add -net 192.168.1.0 metric 1 \ | netmask 255.255.255.0 gw 193.89.84.13
ipppd user XXX2 /dev/ippp1 193.89.84.10:193.89.84.11 \
file /etc/ppp/options.ippp1
You may even try the following to "emulate" cisco's dialer rotary group where you may put several BRIs (basic rate interfaces = ISDN S0 [gr.]) into one netmask. Therefore the example would look like (changes aren't marked any more; completely different):
#!/bin/bash
# assuming, we are using a network of
# 193.89.84.0/255.255.255.240
# for a dial up server where
# 193.89.84.1 is the IP for the server and
# 193.89.84.2-14 are the addresses for remote interfaces.
ifconfig dummy0 193.89.84.1 # module has to be loaded before
route add -host 193.89.84.1 # only to have 193.89.84.1 reachable
# all the time
USER_ippp0="XXX1"
RMTNET_ippp0=194.192.159.0
RMTMSK_ippp0=255.255.255.224
USER_ippp1="XXX2"
RMTNET_ippp1=192.168.1.0 # masquerading is great!
RMTMSK_ippp1=255.255.255.0
USER_ippp2="XXX3"
RMTNET_ippp2="" # you may leave 'em blank
RMTNET_ippp2="" # if there is no remote net
[...] # fill out to your needs
for x in 2 3 4 5 6 7 8 9 10 11 12 13 14
do
IFNAME="ippp$[$x-2]"
isdnctrl addif $IFNAME
ifconfig $IFNAME down # to make it exclusively bindable
isdnctrl pppbind $IFNAME
ifconfig $IFNAME 193.89.84.1 netmask 255.255.255.240 up
route add -host 193.89.84.$x metric 1 $IFNAME
eval NET="\${RMTNET_${IFNAME}}"
eval MSK="\${RMTNET_${IFNAME}}"
if [ -n "$NET" -a -n "$MSK" ]
then
route add -net $NET metric 1 netmask $MSK gw 193.89.84.$x
fi
eval USER="\${USER_${IFNAME}}"
ipppd user "$USER" /dev/$IFNAME 193.89.84.1:193.89.84.$x \
file /etc/ppp/options.$IFNAME
done
No warranty, it's untested.
But please yell at me (politely) if I'm wrong.
Regards,
Torsten
--
/\ Delta Internet GmbH / \ DI Delta Internet GmbH von-Siemens-Str. 12 /____\ Netzwerkdienst & Vertrieb 59757 Arnsberg
ALLES NUR AUS LINUX Tel. +49 2932 916 132 Fax 191 --------------------------------------------------- To remove yourself from this mailing list send email to majordomo@hub-wue.franken.de containing "unsubscribe isdn4linux <your_email_address>" in the message body [-vg]

142
FAQ/_example/ipfwadm.txt
View File

@ -1,71 +1,71 @@
From: Torsten Hentschel <Torsten.Hentschel@DInet.de> Subject: Re: IPFWADM
To: isdn4linux@hub-wue.franken.de
Date: Thu, 7 Nov 1996 11:03:15 +0100 (MET) Sender: owner-isdn4linux@hub-wue.franken.de Reply-To: isdn4linux@hub-wue.franken.de
Hallo!
Vielleicht kann ich helpfen ;-)
Zuerstmal lass mich wiederholen, ob ich Deine Frage richtig verstanden habe. Mal angenommen Du hast auf den drei Netzwerk- Karten jeweils ein Class-C -Netz und hast die Dinger so etwa wie folgt konfiguriert:
ifconfig eth0 194.77.88.7 netmask 255.255.255.0 broadcast 194.77.88.255
ifconfig eth1 194.77.89.4 netmask 255.255.255.0 broadcast 194.77.89.255
ifconfig eth2 194.77.90.2 netmask 255.255.255.0 broadcast 194.77.90.255
route add -net 194.77.88.0 eth0
route add -net 194.77.89.0 eth1
route add -net 194.77.90.0 eth2
In dieser Weise wuerde ja nun schlichtweg _alles_ von einem Interface zum anderen geroutet werden und Dein Rechner wie ein Gateway funktionieren.
Du willst, so habe ich es verstanden, aber nur einen ganz bestimmten Rechner zwischen den Interfaces "durchlassen" waehrend Dein "Gateway" aber selber alle Rechner erreichen kann und alle Rechner Dein "Gateway" erreichen koennen.
Nehmen wir mal an, der Rechner an eht0, der auf eth1 zugreifen koennen soll, habe die IP-Adresse 194.77.88.15.
Die professionelle Vorgehensweise ist dann:
- Ausschallten der FORWARDING-Funktion im Kernel
durch Neukompilieren
- Aufsetzen der folgenden Befehle für die Firewall:
ipfwadm -F -p deny # Routing zwischen den Interfaces
# erstmal generell verbieten
ipfwadm -I -p accept # Input auf allen Interfaces erlauben
# betrifft Pakete, die Dein Rechner
# auf seinen Interfaces empfaengt
ipfwadm -O -p accept # Output auf allen Interfaces erlauben
# betrifft alle Pakete, die Dein Rechner
# selber erzeugt hat und an jemanden
# senden will
ipfwadm -F -a accept -S 194.77.88.15/32 -D 194.77.90.0/24
# Zuletzt wird explizit das Forwarding
# zwischen dem Rechner auf eth0 und
# allen Rechnern auf eth2 erlaubt.
Wenn Du keinen neuen Kernel kompilieren willst, geht das auch mit eingeschaltetem Forwarding im Kernel. Das ist dann aber nicht so sicher, da man mit etwas Koepfchen die Firewall dann umgehen kann.
Keine Garantie. Das Zeugs habe ich nicht ausprobiert. Muesste aber so klappen. - Bitte korrigiert mich, wenn ich falsch liege.
Gruesse,
Torsten
> Ich habe ein rechner mit 3 netzkarten ( eth0..eth2 ). Jetzt will ich mit
> ipfwadm einen specielen rechner vom eth0 nach eth1 routen ( wie ein gateway ).
>
> Kann jemand mich helpfen?
>
>
> ---------------------------------------------------
> To remove yourself from this mailing list send
> email to majordomo@hub-wue.franken.de containing
> "unsubscribe isdn4linux <your_email_address>" in
> the message body [-vg]
>
--
http://www.DInet.de/
/\ von-Siemens-Str. 12
/ \ Delta Internet GmbH 59757 Arnsberg
/ \ Netzwerkdienst & Vertrieb Tel. +49 2932 91 61 32 /______\ Fax. +49 2932 91 61 91 --------------------------------------------------- To remove yourself from this mailing list send email to majordomo@hub-wue.franken.de containing "unsubscribe isdn4linux <your_email_address>" in the message body [-vg]
From: Torsten Hentschel <Torsten.Hentschel@DInet.de> Subject: Re: IPFWADM
To: isdn4linux@hub-wue.franken.de
Date: Thu, 7 Nov 1996 11:03:15 +0100 (MET) Sender: owner-isdn4linux@hub-wue.franken.de Reply-To: isdn4linux@hub-wue.franken.de
Hallo!
Vielleicht kann ich helpfen ;-)
Zuerstmal lass mich wiederholen, ob ich Deine Frage richtig verstanden habe. Mal angenommen Du hast auf den drei Netzwerk- Karten jeweils ein Class-C -Netz und hast die Dinger so etwa wie folgt konfiguriert:
ifconfig eth0 194.77.88.7 netmask 255.255.255.0 broadcast 194.77.88.255
ifconfig eth1 194.77.89.4 netmask 255.255.255.0 broadcast 194.77.89.255
ifconfig eth2 194.77.90.2 netmask 255.255.255.0 broadcast 194.77.90.255
route add -net 194.77.88.0 eth0
route add -net 194.77.89.0 eth1
route add -net 194.77.90.0 eth2
In dieser Weise wuerde ja nun schlichtweg _alles_ von einem Interface zum anderen geroutet werden und Dein Rechner wie ein Gateway funktionieren.
Du willst, so habe ich es verstanden, aber nur einen ganz bestimmten Rechner zwischen den Interfaces "durchlassen" waehrend Dein "Gateway" aber selber alle Rechner erreichen kann und alle Rechner Dein "Gateway" erreichen koennen.
Nehmen wir mal an, der Rechner an eht0, der auf eth1 zugreifen koennen soll, habe die IP-Adresse 194.77.88.15.
Die professionelle Vorgehensweise ist dann:
- Ausschallten der FORWARDING-Funktion im Kernel
durch Neukompilieren
- Aufsetzen der folgenden Befehle für die Firewall:
ipfwadm -F -p deny # Routing zwischen den Interfaces
# erstmal generell verbieten
ipfwadm -I -p accept # Input auf allen Interfaces erlauben
# betrifft Pakete, die Dein Rechner
# auf seinen Interfaces empfaengt
ipfwadm -O -p accept # Output auf allen Interfaces erlauben
# betrifft alle Pakete, die Dein Rechner
# selber erzeugt hat und an jemanden
# senden will
ipfwadm -F -a accept -S 194.77.88.15/32 -D 194.77.90.0/24
# Zuletzt wird explizit das Forwarding
# zwischen dem Rechner auf eth0 und
# allen Rechnern auf eth2 erlaubt.
Wenn Du keinen neuen Kernel kompilieren willst, geht das auch mit eingeschaltetem Forwarding im Kernel. Das ist dann aber nicht so sicher, da man mit etwas Koepfchen die Firewall dann umgehen kann.
Keine Garantie. Das Zeugs habe ich nicht ausprobiert. Muesste aber so klappen. - Bitte korrigiert mich, wenn ich falsch liege.
Gruesse,
Torsten
> Ich habe ein rechner mit 3 netzkarten ( eth0..eth2 ). Jetzt will ich mit
> ipfwadm einen specielen rechner vom eth0 nach eth1 routen ( wie ein gateway ).
>
> Kann jemand mich helpfen?
>
>
> ---------------------------------------------------
> To remove yourself from this mailing list send
> email to majordomo@hub-wue.franken.de containing
> "unsubscribe isdn4linux <your_email_address>" in
> the message body [-vg]
>
--
http://www.DInet.de/
/\ von-Siemens-Str. 12
/ \ Delta Internet GmbH 59757 Arnsberg
/ \ Netzwerkdienst & Vertrieb Tel. +49 2932 91 61 32 /______\ Fax. +49 2932 91 61 91 --------------------------------------------------- To remove yourself from this mailing list send email to majordomo@hub-wue.franken.de containing "unsubscribe isdn4linux <your_email_address>" in the message body [-vg]

298
FAQ/_howto/dns.txt
View File

@ -1,149 +1,149 @@
From: Philippe Le Foll <phillf@iu-vannes.fr> Subject: Re: Namesserver Config
To: isdn4linux@hub-wue.franken.de
Date: Wed, 30 Oct 1996 19:09:10 +0100 (MET) Sender: owner-isdn4linux@hub-wue.franken.de Reply-To: isdn4linux@hub-wue.franken.de
I send to some people a small set of shell and example in order to set up a local name server on a Linux box.
I translate in aproximative english the README, which should in any case be easier to read that the french version.
Some people ask be for seting this in an ftp site unfortunately my university did not open yet an anonymous ftp.
phillf@iu-vannes.
Author: Philippe Le Foll: 30-oct-96
e-mail: phillf@iu-vannes.fr
All these shells are coming from Rennes Hight Brittany University they generate from /etc/hosts the DNS database, I modify them in order to run on my linux box.
(c) This is public program and you use them at your own risk
they will probably not run without some adaptation to your site.
All this example refer to the following configuration ------------------------------------------------------------
---------------
| to Internet |
--------------
|
|
dial-out/PPP
(dynamic IP number)
|
|
+------------------------+ +----------------------------+
| | | |
| DNS server | | DNS slave |
| Linux 2.x | | Linux or NT |
| name: bisig | | name fridu |
| | | |
| pppd [IP] | | |
| leafnode [news] | | Netcape [html+news+mail] |
| harvest [html cache]| | Eudora [mail] |
| popd [mail] | | |
| metahtml [local http]| | |
+------------------------+ +----------------------------+
200.200.200.1 200.200.200.1
| | +----------------------------------------------|---------------------------+
Unregistered 200.200.200" network, "domain sene.bzh"
Note:
1) This configuration give to all Slaves computer the impression
to be officially onto Internet without really be registrated.
2) It allows to run a cache even when INTERNET dial-up connection
is down.
3) It obviously read news during the night, but this is an other story.
To Do in order to install DNS
------------------------------
If you are running a DNS at home like me you probably have to choose for an unregistrated domain name as me.
Running on an official Internet network does not change anything except that you don't have to worry about your name and your net number.
- If you don't want to place your DNS data base in
/var/etc/named/DNS you will have to hack the shell
almost everything is hard coded
- create the destination directory /var/etc/named/DNS
- Copy all etc/*header* file in /var/etc/named/DNS then
adapt them to your site [here: network is 200.200.200].
- Allow named to start at boot time, for this remove comment
before named lines in /etc/rc.d/rc.inet2
- copy etc/named.boot file in /etc adapt it to your site
primary & forwarders lines syntax is:
PRIMARY myDomainename [here sene.bzh] headerPathName [here:sene.bzh.header.db]
FORWARDERS IP_NUMBER for your DNS parent [usually your provider].
example
primary sene.bzh /var/etc/named/DNS/sene.bzh.header.db
forwarders 194.51.217.1 194.51.3.49
- Normally /etc/resolv.conf is not mandatory, nevertheless
I place my local domain name in with the following line.
domain sene.bzh
- .cache directive refer to a standard file that you should have no
trouble with. Syntax is:
cache . /var/etc/named/DNS/named.root
NOTE: You can retrieve a more update named.root file true FTP
FTP.RS.INTERNIC.NET. (But for this named should work !!!)
- Build/update your /etc/hosts file. WARNING: all your local hosts
should have as main name host.YourDomainName INCLUDING localhost.YourDomainName
[see example in etc/hosts]
- Generate your DNS data base, this is the only thing you should have to
do at each /etc/hosts change. In fact this job is done automatically
with the following shell, syntax
make_db YourDomainName [ex: make_db sene.bzh]
make_in-addr.arpa Net_Value.._in-addr.arpa [ex: make_in-addr.arpa 200.200.200._in-addr.arpa]
nota: These two commands should generate you the two following files
YourDomainName.db & Net_Value.in-addr.arpa.db
in /var/etc/named/DNS. Both file are include from your
header.db files.
- If you have secondary computers that use your local server,
just write the two following line in there /etc/resolv.conf
domain sene.bzh [where sene.bzh is your domaineName]
nameserver 200.200.200.1 [where 200.200.200.1 is your local DNS]
WARNING: NameServer should be an IP number and not a symbolic name
and this even if it is declare in your /etc/hosts.
- It is now time to start your name server, by just typing in:
named
- Check your name server is effectively working
dnsquery -h your_host_name
WARNING: Even if your dialup line with INTERNET is broken your
name server should answer you. The only time it should
timeout is when you type in a wrong name, it with case it
should try reaching a forwarder.
Good Luck
Kenavo
phillf@iu-vannes.fr
ps: Sorry for the English, if someone want to set it up in real english
I will be please to replace my own README with a better one.
--------------------------------------------------- To remove yourself from this mailing list send email to majordomo@hub-wue.franken.de containing "unsubscribe isdn4linux <your_email_address>" in the message body [-vg]
From: Philippe Le Foll <phillf@iu-vannes.fr> Subject: Re: Namesserver Config
To: isdn4linux@hub-wue.franken.de
Date: Wed, 30 Oct 1996 19:09:10 +0100 (MET) Sender: owner-isdn4linux@hub-wue.franken.de Reply-To: isdn4linux@hub-wue.franken.de
I send to some people a small set of shell and example in order to set up a local name server on a Linux box.
I translate in aproximative english the README, which should in any case be easier to read that the french version.
Some people ask be for seting this in an ftp site unfortunately my university did not open yet an anonymous ftp.
phillf@iu-vannes.
Author: Philippe Le Foll: 30-oct-96
e-mail: phillf@iu-vannes.fr
All these shells are coming from Rennes Hight Brittany University they generate from /etc/hosts the DNS database, I modify them in order to run on my linux box.
(c) This is public program and you use them at your own risk
they will probably not run without some adaptation to your site.
All this example refer to the following configuration ------------------------------------------------------------
---------------
| to Internet |
--------------
|
|
dial-out/PPP
(dynamic IP number)
|
|
+------------------------+ +----------------------------+
| | | |
| DNS server | | DNS slave |
| Linux 2.x | | Linux or NT |
| name: bisig | | name fridu |
| | | |
| pppd [IP] | | |
| leafnode [news] | | Netcape [html+news+mail] |
| harvest [html cache]| | Eudora [mail] |
| popd [mail] | | |
| metahtml [local http]| | |
+------------------------+ +----------------------------+
200.200.200.1 200.200.200.1
| | +----------------------------------------------|---------------------------+
Unregistered 200.200.200" network, "domain sene.bzh"
Note:
1) This configuration give to all Slaves computer the impression
to be officially onto Internet without really be registrated.
2) It allows to run a cache even when INTERNET dial-up connection
is down.
3) It obviously read news during the night, but this is an other story.
To Do in order to install DNS
------------------------------
If you are running a DNS at home like me you probably have to choose for an unregistrated domain name as me.
Running on an official Internet network does not change anything except that you don't have to worry about your name and your net number.
- If you don't want to place your DNS data base in
/var/etc/named/DNS you will have to hack the shell
almost everything is hard coded
- create the destination directory /var/etc/named/DNS
- Copy all etc/*header* file in /var/etc/named/DNS then
adapt them to your site [here: network is 200.200.200].
- Allow named to start at boot time, for this remove comment
before named lines in /etc/rc.d/rc.inet2
- copy etc/named.boot file in /etc adapt it to your site
primary & forwarders lines syntax is:
PRIMARY myDomainename [here sene.bzh] headerPathName [here:sene.bzh.header.db]
FORWARDERS IP_NUMBER for your DNS parent [usually your provider].
example
primary sene.bzh /var/etc/named/DNS/sene.bzh.header.db
forwarders 194.51.217.1 194.51.3.49
- Normally /etc/resolv.conf is not mandatory, nevertheless
I place my local domain name in with the following line.
domain sene.bzh
- .cache directive refer to a standard file that you should have no
trouble with. Syntax is:
cache . /var/etc/named/DNS/named.root
NOTE: You can retrieve a more update named.root file true FTP
FTP.RS.INTERNIC.NET. (But for this named should work !!!)
- Build/update your /etc/hosts file. WARNING: all your local hosts
should have as main name host.YourDomainName INCLUDING localhost.YourDomainName
[see example in etc/hosts]
- Generate your DNS data base, this is the only thing you should have to
do at each /etc/hosts change. In fact this job is done automatically
with the following shell, syntax
make_db YourDomainName [ex: make_db sene.bzh]
make_in-addr.arpa Net_Value.._in-addr.arpa [ex: make_in-addr.arpa 200.200.200._in-addr.arpa]
nota: These two commands should generate you the two following files
YourDomainName.db & Net_Value.in-addr.arpa.db
in /var/etc/named/DNS. Both file are include from your
header.db files.
- If you have secondary computers that use your local server,
just write the two following line in there /etc/resolv.conf
domain sene.bzh [where sene.bzh is your domaineName]
nameserver 200.200.200.1 [where 200.200.200.1 is your local DNS]
WARNING: NameServer should be an IP number and not a symbolic name
and this even if it is declare in your /etc/hosts.
- It is now time to start your name server, by just typing in:
named
- Check your name server is effectively working
dnsquery -h your_host_name
WARNING: Even if your dialup line with INTERNET is broken your
name server should answer you. The only time it should
timeout is when you type in a wrong name, it with case it
should try reaching a forwarder.
Good Luck
Kenavo
phillf@iu-vannes.fr
ps: Sorry for the English, if someone want to set it up in real english
I will be please to replace my own README with a better one.
--------------------------------------------------- To remove yourself from this mailing list send email to majordomo@hub-wue.franken.de containing "unsubscribe isdn4linux <your_email_address>" in the message body [-vg]

584
FAQ/_howto/masquerade.txt
View File

@ -1,292 +1,292 @@
Date: Tue, 29 Oct 1996 03:57:50 +0000 (GMT) From: Rainer May <r_may@khavi.desaster.heide.de> X-Sender: r_may@kahvi.desaster.heide.de To: isdn4linux@hub-wue.franken.de
Subject: i4l und Masquerading
X-Flags: MN
Sender: owner-isdn4linux@hub-wue.franken.de Reply-To: isdn4linux@hub-wue.franken.de
Nachdem ich leichtsinnig genug irgendwo mal verkuendet hatte, dass ich hier ein LAN hinter einem Linux-Server mit i4l bei meinem Provider einspeise, platzte mein Postfach aus den Naehten. Bevor ich alles immer wieder aufs Neue abtippe, hab' ich das Procedere in einer Art FAQ aufgeschrieben.
Vielleicht interessiert sich ja wer dafuer. Wer den Text in irgendwelche Webpages aufnehmen, ausdrucken und aufs Klo haengen oder sonstwas damit machen will, meinen Segen hat er.
Rainer
###########################
isdn4linux und IP-Masquerading im LAN
-------------------------------------
Problem: "Ich habe ein lokales Netzwerk (LAN), in dem Rechner
der verschiedensten Plattformen - Win95, Win311, NT,
Amiga (AmiTCP) und MacIntosh (MacTCP) - ueber einen
Linux-Router mit der Aussenwelt verbunden werden
sollen. In der Linux-Maschine steckt eine ISDN-
Karte. Von meinem Provider bekomme ich dynamisch
eine IP-Adresse zugewiesen, wenn die Verbindung auf-
gebaut wird. Nun moechte ich aber nicht nur vom
Linux-Router direkt, sondern von jedem Rechner im
LAN ins Internet kommen. Wie?"
Loesung: "Die meiste Arbeit ist auf Linux-Seite zu erledigen.
Zunaechst einmal braucht man einen Kernel mit ein-
gebautem IP-Forwarding und Masquerading. D.h., bei
"make config" muessen folgende Fragen mit "Y" be-
antwortet werden:
Prompt for development and/or incomplete code/drivers Y
Enable loadable module support Y
Networking support Y
Network firewalls Y
TCP/IP networking Y
IP: forwarding/gatewaying Y
IP: firewalling Y
IP: masquerading Y
PPP (point-to-point) support (wenn PPP zum Provider) Y
SLIP (serial line) support Y
Ethernet (10 or 100Mbit) (oder Arcnet oder ...) Y
ISDN support [1] M
Support synchronous PPP (wenn ipppd benutzt wird) Y
HiSax SiemensChipSet driver support M
(dann den HiSax fuer die ISDN Karte waehlen)
Anschliessend den Kernel wie ueblich mit "make dep",
"make clean", "make zImage", "make modules" und
"make modules_install" bauen.
Auf das Installieren von PPP und der ISDN-Treiber
wird an anderer Stelle ausfuehrlich eingegangen.
Hier geht es weiter, wenn folgende Voraussetzungen
erfuellt sind:
* Das ISDN-Subsystem laeuft, d.h., von Linux aus
kann eine Verbindung zum Provider hergestellt
werden.
* Das lokale Netzwerk (Ethernet usw.) laeuft auch,
vorzugsweise unter Verwendung "freier" IP-
Adressen (z.B. 192.168.xx.xx), und der Linux-Host
kann von allen anderen Rechnern im LAN erreicht
werden (z.B. per ping).
Nun gilt es, zweierlei zu erreichen:
* Zugriffe von einem beliebigen Rechner im LAN
auf eine nicht-lokale IP-Adresse sollen den
Linux-Router veranlassen, eine Verbindung zum
Provider aufzubauen; und
* Der Linux-Router soll zwar die Rechner im LAN
mit dem Provider verbinden, diesem gegenueber
aber verheimlichen, dass nicht der Router
selbst Empfaenger/Absender der entsprechenden
IP-Pakete ist.
Beginnen wir mit dem zweiten Punkt. Dieses "Ver-
heimlichen" hat nichts damit zu tun, dass man
seinen Provider hintergehen will (obwohl man auf
diese Weise auch selbst Provider spielen und
seine Kunden klammheimlich ueber _einen_ billigen
"Privat-Zugang" ins Internet bringen kann), son-
dern mit technischen Notwendigkeiten. Denn nur
das Interface des Linux-Rechners, das die Verbin-
dung zum Provider herstellt, bekommt von diesem
eine IP-Adresse verpasst, die der Provider auch
kennt. Traegt z.B. der Router im LAN die lokale
IP-Adresse 192.168.1.1, und ein anderer Rechner
die 192.168.1.2, dann kennt der Provider diese
Adressen ja nicht. Er weist z.B. dem PPP-Inter-
face des Routers die Adresse 123.234.345.99 zu -
und nur bei Paketen aus dem Internet, die an
diese Nummer adressiert sind, weiss er auch, an
wen er die Pakete schicken soll. Daher muss der
Router Pakete von anderen Rechnern im LAN "mas-
kieren" - mit seiner eigenen, dynamisch zugewie-
senen Adresse (und dabei natuerlich Buch darueber
fuehren, was an wen von wem kam, um die Antwort-
Pakete richtig zuzustellen).
Zum Glueck ist diese Funktion in den Linux-Kernel
=>2.0.0 schon eingebaut (s.o.) - sie nennt sich
"IP-Masquerading". Vereinfacht ausgedrueckt geht
das so:
Ein LAN-Rechner schickt ein Paket ab, das neben
IP-Nummer und Ziel-Port des Empfaengers auch die
"Absender-Adresse" in Form einer IP-Nummer und
eines Antwort-Ports traegt. Der maskierende
Router nun ersetzt die Absender-IP durch seine
eigene und den Ruecksende-Port durch einen freien
aus seinem Fundus. Unter dieser "freien" Port-
nummer werden die originalen Absender-Daten ge-
speichert. Kommt nun ein Antwort-Paket aus dem
Internet an diesen Port, werden dessen Empfaenger-
Adresse und -Port mit der gespeicherten Ruecksende-
Adresse ueberschrieben und an den LAN-Rechner wei-
tergeleitet. Paket fuer Paket.
Leicht einsehbar ist uebrigens, dass dieses Verfahren
nur mit Diensten funktioniert, bei denen auch eine
Ruecksende-Adresse angegeben wird. Dazu gehoeren
u.a. telnet, http, ftp, irc (eingeschraenkt), nicht
aber Echo (ping).
Zurueck zur Praxis. Damit das Masquerading auch
bei FTP und IRC funktioniert, werden zunaechst
zwei Module geladen:
/sbin/modprobe ip_masq_ftp
/sbin/modprobe ip_masq_irc
Dann werden die Forward-Rules des Kernel zum
Masquerading gezwungen:
/sbin/ipfwadm -F -a m -P all -S 192.168.123.0/24 -D 0.0.0.0/0 -b [2]
In diesem Beispiel werden im LAN die IP-Adressen
192.168.123.1 bis 192.168.123.254 benutzt. Legen
wir zur Vereinfachung fest, der Linux-Router habe
dabei die Adresse 192.168.123.1
Obige Zeile bewirkt, dass IP-Pakete, die von
192.168.123.x ausgehen und an wenauchimmer gerichtet
sind, maskiert werden. Das hat den Nachteil, dass
auch innerhalb des LAN fleissig drauflosmaskiert
wird, was man aber durch Einfuegen weiterer Rules
vermeiden kann. "man ipfwadm" sei hier zur Lektuere
empfohlen.
Das "Verstecken" des LAN vor dem Provider haben wir
nun erreicht. Jetzt gilt es, bei Bedarf einen auto-
matischen Verbindungsaufbau zu erzwingen.
Dafuer ist es zunaechst noetig, die anderen Rechner
im LAN dazu zu bringen, alle fuer "Ausserhalb" be-
stimmten IP-Pakete an den Linux-Router zu uebergeben
und diesem die Weiterleitung zu ueberlassen.
Nichts leichter als das: Sowohl bei den verschiedenen
Windows-Versionen, als auch beim AmiTCP und beim
MacTCP gibt es in der Konfiguration den Stichwort
"Default-Gateway" oder nur "Gateway". Hier ist die
_lokale_ IP-Adresse des Routers einzutragen (denn
die spaetere Adresse, die vom Provider kommt, ist
ja erstens noch nicht bekannt und aendert sich zwei-
tens bei jedem Anruf).
Letzter Schritt ist dann, das "dial-on-demand" ein-
zurichten. In Verbindung mit isdn4linux gibt es dafuer
zwei Moeglichkeiten:
* Man verwendet synchrones PPP fuer die Verbindung
zum Provider, also den "ipppd". Dann ist nichts
weiter zu tun als dafuer zu sorgen, dass immer
die Default-Route des Routers auf das entsprechende
ipppx-Interface weist. Vorsicht: Beim Verbindungs-
abbau loescht der Kernel diese Route! Sie muss
also z.B. in der Datei /etc/ppp/ip-down neu gesetzt
werden.
Das Risiko bei diesem Verfahren sind Programme auf
den LAN-Rechnern, die mehr oder weniger regelmaessig
Nameserver-Requests, Keepalive-Pakete oder ARP-
Broadcastings erzeugen - dann stellt naemlich der
Router jedesmal eine Verbindung zum Provider her.
Die Telekom wird's danken.
Uebrigens kann es passieren, dass manche aus dem
LAN initiierte Verbindungen recht lange auf Antwort
warten. Ich weiss nicht, ob Kernel oder ipppd das
"ausloesende" Paket verschlucken, oder die Antwort
darauf unterschlagen; ich weiss aber, dass es
hilft, z.B. bei Netscape wenige Sekunden nach
Anforderung der ersten Seite auf den "roten Knopf"
zu druecken und die Seite nochmals anzufordern.
Wie bereits erwaehnt: Die Konfiguration des ipppd
wird an anderer Stelle ausfuehrlicher und kompeten-
ter erklaert, als ich es koennte [3]
* Benutzt man asynchrones ppp oder gar SLIP/CSLIP
fuer die Verbindung zum Provider, kann man das
Programm "diald" [4] verwenden. Es bietet zudem
den Vorteil, extrem stark konfigurierbar zu sein;
so kann man z.B. festlegen, dass zwischen 0900
und 1200 grundsaetzlich keine Verbindung aufgebaut
wird, dass Nameserver-Anfragen eine Verbindung zwar
nicht aufbauen, aber offenhalten koennen u.v.m.
Wer sich mit diesen Konfigurationsmoeglichkeiten
nicht herumschlagen mag, braucht das indes auch
nicht - die Default-Konfiguration kann man ohne
Gefahr fuer Leib und Geldboerse uebernehmen :-)
So. Wenn jetzt das Masquerading eingerichtet wurde.
Wenn der Linux-Router auf allen LAN-Rechnern als
Gateway eingetragen wurde. Wenn ein "ping abc.edu",
eingetippt auf der Console des Routers, eine Verbin-
dung zum Provider aufbaut. _Dann_ sollte damit auch
fuer alle Rechner im LAN der Weg ins Internet frei sein.
Troubleshooting:
Problem: "Alles schoen und gut. Aber wenn ich z.B. von der
W95-Kiste aus mit Netscape eine Seite aufrufe,
bekomme ich als Antwort nur "unknown host" Loesung: "Was ist denn auf der "Win95-Kiste" als Nameserver
eingetragen? Sofern auf dem Router kein eigener
NS laeuft, muss natuerlich auf allen LAN-Rechnern
der NS des Providers eingetragen sein."
Problem: "Die Adressen werden jetzt aufgeloest, aber statt
der gewuenschten Seite bekomme ich die Meldung
"no route to host"!"
Loesung: "Bitte pruefen:
* Ist auf dem LAN-Rechner der Linux-Router als
Gateway eingetragen (manche "Betriebssysteme"
muss man komplett resetten, bevor Sie da eine
Aenderung mitbekommen)?
* Liegt auf dem Router die Default-Route auf dem
"Bereitschafts-Interface" zum Provider (z.B.
auf ippp0 bei synch. PPP, oder auf sl0 bei
diald (auch wenn die "echte" Verbindung nachher
per ppp0 geht - diald benutzt ein SLIP-Interface
als "Tuerklingel") ?
* Erzwingt der Provider die Verwendung von Proxies?
Dann muessen die IP-Adressen der Provider-Proxies
auch in den entsprechenden Programmen der LAN-
Rechner eingetragen sein!
Problem: "Warum sind bei diesem FAQ keine ausfuehrlichen
Beispielscripte fuer ipppd, diald usw.?" Loesung: "Weil dies eine FAQ ist und keine eierlegende
Wollmilchsau. Ein Beispiel fuer diald haengt
trotzdem hinten dran."
Problem: "Was muss ich fuer diese supertolle FAQ bezahlen?" Loesung: "Wenn es nach meiner Frau ginge, mindestens 250
Mark - so hoch veranschlagt sie den Abend, den ich
mit Schreiben verbrachte und der ihr daher entging.
Da es aber nicht nach meiner Frau geht, sondern nach
mir ;-), steht die FAQ unter GPL. Kost' also nix."
################################################################
[1] Wer mag, kann die ISDN-Treiber natuerlich auch direkt in den
Kernel einbauen, anstatt sie als Module zu verwenden.
[2] Das Programm ipfwadm gibt es per Anon-FTP als
ftp://ftp.xos.nl/pub/linux/ipfwadm/ipfwadm-2.3.0.tar.gz
[3] Bernhard Hailer hat das Ganze auf seinen www-Seiten sehr
ausfuehrlich und verstaendlich beschrieben. Die URL ist
http://www.chemie.uni-muenchen.de/ac/boehm/beh.html
################################################################
Beispielscripte fuer die Verwendung von isdn4linux mit diald. Die verbindung zum provider wird per X75 aufgebaut, das Protokoll ist dann PPP, ohne PAPpy/CHAPpy usw. Ein einfacher Login. Und Telefonnummer, Name sowie Passwort sind natuerlich gefaelscht :-)
-------------------
# zuerst wird - gleich beim Booten - diald "scharf gemacht" #
# /etc/rc.d/rc.diald
/usr/sbin/diald /dev/ttyI4 -m ppp local 192.168.90.9 remote 192.168.90.1 \
defaultroute dynamic modem crtscts lock connect "chat -v -f \
/etc/ppp/chat.provider"
#
-------------------
#
# /etc/ppp/chat.provider
#
TIMEOUT 240 "" AT&E1234 OK ATD047110815 ogin: Puser sword: topsecret #
-------------------
--------------------------------------------------- To remove yourself from this mailing list send email to majordomo@hub-wue.franken.de containing "unsubscribe isdn4linux <your_email_address>" in the message body [-vg]
Date: Tue, 29 Oct 1996 03:57:50 +0000 (GMT) From: Rainer May <r_may@khavi.desaster.heide.de> X-Sender: r_may@kahvi.desaster.heide.de To: isdn4linux@hub-wue.franken.de
Subject: i4l und Masquerading
X-Flags: MN
Sender: owner-isdn4linux@hub-wue.franken.de Reply-To: isdn4linux@hub-wue.franken.de
Nachdem ich leichtsinnig genug irgendwo mal verkuendet hatte, dass ich hier ein LAN hinter einem Linux-Server mit i4l bei meinem Provider einspeise, platzte mein Postfach aus den Naehten. Bevor ich alles immer wieder aufs Neue abtippe, hab' ich das Procedere in einer Art FAQ aufgeschrieben.
Vielleicht interessiert sich ja wer dafuer. Wer den Text in irgendwelche Webpages aufnehmen, ausdrucken und aufs Klo haengen oder sonstwas damit machen will, meinen Segen hat er.
Rainer
###########################
isdn4linux und IP-Masquerading im LAN
-------------------------------------
Problem: "Ich habe ein lokales Netzwerk (LAN), in dem Rechner
der verschiedensten Plattformen - Win95, Win311, NT,
Amiga (AmiTCP) und MacIntosh (MacTCP) - ueber einen
Linux-Router mit der Aussenwelt verbunden werden
sollen. In der Linux-Maschine steckt eine ISDN-
Karte. Von meinem Provider bekomme ich dynamisch
eine IP-Adresse zugewiesen, wenn die Verbindung auf-
gebaut wird. Nun moechte ich aber nicht nur vom
Linux-Router direkt, sondern von jedem Rechner im
LAN ins Internet kommen. Wie?"
Loesung: "Die meiste Arbeit ist auf Linux-Seite zu erledigen.
Zunaechst einmal braucht man einen Kernel mit ein-
gebautem IP-Forwarding und Masquerading. D.h., bei
"make config" muessen folgende Fragen mit "Y" be-
antwortet werden:
Prompt for development and/or incomplete code/drivers Y
Enable loadable module support Y
Networking support Y
Network firewalls Y
TCP/IP networking Y
IP: forwarding/gatewaying Y
IP: firewalling Y
IP: masquerading Y
PPP (point-to-point) support (wenn PPP zum Provider) Y
SLIP (serial line) support Y
Ethernet (10 or 100Mbit) (oder Arcnet oder ...) Y
ISDN support [1] M
Support synchronous PPP (wenn ipppd benutzt wird) Y
HiSax SiemensChipSet driver support M
(dann den HiSax fuer die ISDN Karte waehlen)
Anschliessend den Kernel wie ueblich mit "make dep",
"make clean", "make zImage", "make modules" und
"make modules_install" bauen.
Auf das Installieren von PPP und der ISDN-Treiber
wird an anderer Stelle ausfuehrlich eingegangen.
Hier geht es weiter, wenn folgende Voraussetzungen
erfuellt sind:
* Das ISDN-Subsystem laeuft, d.h., von Linux aus
kann eine Verbindung zum Provider hergestellt
werden.
* Das lokale Netzwerk (Ethernet usw.) laeuft auch,
vorzugsweise unter Verwendung "freier" IP-
Adressen (z.B. 192.168.xx.xx), und der Linux-Host
kann von allen anderen Rechnern im LAN erreicht
werden (z.B. per ping).
Nun gilt es, zweierlei zu erreichen:
* Zugriffe von einem beliebigen Rechner im LAN
auf eine nicht-lokale IP-Adresse sollen den
Linux-Router veranlassen, eine Verbindung zum
Provider aufzubauen; und
* Der Linux-Router soll zwar die Rechner im LAN
mit dem Provider verbinden, diesem gegenueber
aber verheimlichen, dass nicht der Router
selbst Empfaenger/Absender der entsprechenden
IP-Pakete ist.
Beginnen wir mit dem zweiten Punkt. Dieses "Ver-
heimlichen" hat nichts damit zu tun, dass man
seinen Provider hintergehen will (obwohl man auf
diese Weise auch selbst Provider spielen und
seine Kunden klammheimlich ueber _einen_ billigen
"Privat-Zugang" ins Internet bringen kann), son-
dern mit technischen Notwendigkeiten. Denn nur
das Interface des Linux-Rechners, das die Verbin-
dung zum Provider herstellt, bekommt von diesem
eine IP-Adresse verpasst, die der Provider auch
kennt. Traegt z.B. der Router im LAN die lokale
IP-Adresse 192.168.1.1, und ein anderer Rechner
die 192.168.1.2, dann kennt der Provider diese
Adressen ja nicht. Er weist z.B. dem PPP-Inter-
face des Routers die Adresse 123.234.345.99 zu -
und nur bei Paketen aus dem Internet, die an
diese Nummer adressiert sind, weiss er auch, an
wen er die Pakete schicken soll. Daher muss der
Router Pakete von anderen Rechnern im LAN "mas-
kieren" - mit seiner eigenen, dynamisch zugewie-
senen Adresse (und dabei natuerlich Buch darueber
fuehren, was an wen von wem kam, um die Antwort-
Pakete richtig zuzustellen).
Zum Glueck ist diese Funktion in den Linux-Kernel
=>2.0.0 schon eingebaut (s.o.) - sie nennt sich
"IP-Masquerading". Vereinfacht ausgedrueckt geht
das so:
Ein LAN-Rechner schickt ein Paket ab, das neben
IP-Nummer und Ziel-Port des Empfaengers auch die
"Absender-Adresse" in Form einer IP-Nummer und
eines Antwort-Ports traegt. Der maskierende
Router nun ersetzt die Absender-IP durch seine
eigene und den Ruecksende-Port durch einen freien
aus seinem Fundus. Unter dieser "freien" Port-
nummer werden die originalen Absender-Daten ge-
speichert. Kommt nun ein Antwort-Paket aus dem
Internet an diesen Port, werden dessen Empfaenger-
Adresse und -Port mit der gespeicherten Ruecksende-
Adresse ueberschrieben und an den LAN-Rechner wei-
tergeleitet. Paket fuer Paket.
Leicht einsehbar ist uebrigens, dass dieses Verfahren
nur mit Diensten funktioniert, bei denen auch eine
Ruecksende-Adresse angegeben wird. Dazu gehoeren
u.a. telnet, http, ftp, irc (eingeschraenkt), nicht
aber Echo (ping).
Zurueck zur Praxis. Damit das Masquerading auch
bei FTP und IRC funktioniert, werden zunaechst
zwei Module geladen:
/sbin/modprobe ip_masq_ftp
/sbin/modprobe ip_masq_irc
Dann werden die Forward-Rules des Kernel zum
Masquerading gezwungen:
/sbin/ipfwadm -F -a m -P all -S 192.168.123.0/24 -D 0.0.0.0/0 -b [2]
In diesem Beispiel werden im LAN die IP-Adressen
192.168.123.1 bis 192.168.123.254 benutzt. Legen
wir zur Vereinfachung fest, der Linux-Router habe
dabei die Adresse 192.168.123.1
Obige Zeile bewirkt, dass IP-Pakete, die von
192.168.123.x ausgehen und an wenauchimmer gerichtet
sind, maskiert werden. Das hat den Nachteil, dass
auch innerhalb des LAN fleissig drauflosmaskiert
wird, was man aber durch Einfuegen weiterer Rules
vermeiden kann. "man ipfwadm" sei hier zur Lektuere
empfohlen.
Das "Verstecken" des LAN vor dem Provider haben wir
nun erreicht. Jetzt gilt es, bei Bedarf einen auto-
matischen Verbindungsaufbau zu erzwingen.
Dafuer ist es zunaechst noetig, die anderen Rechner
im LAN dazu zu bringen, alle fuer "Ausserhalb" be-
stimmten IP-Pakete an den Linux-Router zu uebergeben
und diesem die Weiterleitung zu ueberlassen.
Nichts leichter als das: Sowohl bei den verschiedenen
Windows-Versionen, als auch beim AmiTCP und beim
MacTCP gibt es in der Konfiguration den Stichwort
"Default-Gateway" oder nur "Gateway". Hier ist die
_lokale_ IP-Adresse des Routers einzutragen (denn
die spaetere Adresse, die vom Provider kommt, ist
ja erstens noch nicht bekannt und aendert sich zwei-
tens bei jedem Anruf).
Letzter Schritt ist dann, das "dial-on-demand" ein-
zurichten. In Verbindung mit isdn4linux gibt es dafuer
zwei Moeglichkeiten:
* Man verwendet synchrones PPP fuer die Verbindung
zum Provider, also den "ipppd". Dann ist nichts
weiter zu tun als dafuer zu sorgen, dass immer
die Default-Route des Routers auf das entsprechende
ipppx-Interface weist. Vorsicht: Beim Verbindungs-
abbau loescht der Kernel diese Route! Sie muss
also z.B. in der Datei /etc/ppp/ip-down neu gesetzt
werden.
Das Risiko bei diesem Verfahren sind Programme auf
den LAN-Rechnern, die mehr oder weniger regelmaessig
Nameserver-Requests, Keepalive-Pakete oder ARP-
Broadcastings erzeugen - dann stellt naemlich der
Router jedesmal eine Verbindung zum Provider her.
Die Telekom wird's danken.
Uebrigens kann es passieren, dass manche aus dem
LAN initiierte Verbindungen recht lange auf Antwort
warten. Ich weiss nicht, ob Kernel oder ipppd das
"ausloesende" Paket verschlucken, oder die Antwort
darauf unterschlagen; ich weiss aber, dass es
hilft, z.B. bei Netscape wenige Sekunden nach
Anforderung der ersten Seite auf den "roten Knopf"
zu druecken und die Seite nochmals anzufordern.
Wie bereits erwaehnt: Die Konfiguration des ipppd
wird an anderer Stelle ausfuehrlicher und kompeten-
ter erklaert, als ich es koennte [3]
* Benutzt man asynchrones ppp oder gar SLIP/CSLIP
fuer die Verbindung zum Provider, kann man das
Programm "diald" [4] verwenden. Es bietet zudem
den Vorteil, extrem stark konfigurierbar zu sein;
so kann man z.B. festlegen, dass zwischen 0900
und 1200 grundsaetzlich keine Verbindung aufgebaut
wird, dass Nameserver-Anfragen eine Verbindung zwar
nicht aufbauen, aber offenhalten koennen u.v.m.
Wer sich mit diesen Konfigurationsmoeglichkeiten
nicht herumschlagen mag, braucht das indes auch
nicht - die Default-Konfiguration kann man ohne
Gefahr fuer Leib und Geldboerse uebernehmen :-)
So. Wenn jetzt das Masquerading eingerichtet wurde.
Wenn der Linux-Router auf allen LAN-Rechnern als
Gateway eingetragen wurde. Wenn ein "ping abc.edu",
eingetippt auf der Console des Routers, eine Verbin-
dung zum Provider aufbaut. _Dann_ sollte damit auch
fuer alle Rechner im LAN der Weg ins Internet frei sein.
Troubleshooting:
Problem: "Alles schoen und gut. Aber wenn ich z.B. von der
W95-Kiste aus mit Netscape eine Seite aufrufe,
bekomme ich als Antwort nur "unknown host" Loesung: "Was ist denn auf der "Win95-Kiste" als Nameserver
eingetragen? Sofern auf dem Router kein eigener
NS laeuft, muss natuerlich auf allen LAN-Rechnern
der NS des Providers eingetragen sein."
Problem: "Die Adressen werden jetzt aufgeloest, aber statt
der gewuenschten Seite bekomme ich die Meldung
"no route to host"!"
Loesung: "Bitte pruefen:
* Ist auf dem LAN-Rechner der Linux-Router als
Gateway eingetragen (manche "Betriebssysteme"
muss man komplett resetten, bevor Sie da eine
Aenderung mitbekommen)?
* Liegt auf dem Router die Default-Route auf dem
"Bereitschafts-Interface" zum Provider (z.B.
auf ippp0 bei synch. PPP, oder auf sl0 bei
diald (auch wenn die "echte" Verbindung nachher
per ppp0 geht - diald benutzt ein SLIP-Interface
als "Tuerklingel") ?
* Erzwingt der Provider die Verwendung von Proxies?
Dann muessen die IP-Adressen der Provider-Proxies
auch in den entsprechenden Programmen der LAN-
Rechner eingetragen sein!
Problem: "Warum sind bei diesem FAQ keine ausfuehrlichen
Beispielscripte fuer ipppd, diald usw.?" Loesung: "Weil dies eine FAQ ist und keine eierlegende
Wollmilchsau. Ein Beispiel fuer diald haengt
trotzdem hinten dran."
Problem: "Was muss ich fuer diese supertolle FAQ bezahlen?" Loesung: "Wenn es nach meiner Frau ginge, mindestens 250
Mark - so hoch veranschlagt sie den Abend, den ich
mit Schreiben verbrachte und der ihr daher entging.
Da es aber nicht nach meiner Frau geht, sondern nach
mir ;-), steht die FAQ unter GPL. Kost' also nix."
################################################################
[1] Wer mag, kann die ISDN-Treiber natuerlich auch direkt in den
Kernel einbauen, anstatt sie als Module zu verwenden.
[2] Das Programm ipfwadm gibt es per Anon-FTP als
ftp://ftp.xos.nl/pub/linux/ipfwadm/ipfwadm-2.3.0.tar.gz
[3] Bernhard Hailer hat das Ganze auf seinen www-Seiten sehr
ausfuehrlich und verstaendlich beschrieben. Die URL ist
http://www.chemie.uni-muenchen.de/ac/boehm/beh.html
################################################################
Beispielscripte fuer die Verwendung von isdn4linux mit diald. Die verbindung zum provider wird per X75 aufgebaut, das Protokoll ist dann PPP, ohne PAPpy/CHAPpy usw. Ein einfacher Login. Und Telefonnummer, Name sowie Passwort sind natuerlich gefaelscht :-)
-------------------
# zuerst wird - gleich beim Booten - diald "scharf gemacht" #
# /etc/rc.d/rc.diald
/usr/sbin/diald /dev/ttyI4 -m ppp local 192.168.90.9 remote 192.168.90.1 \
defaultroute dynamic modem crtscts lock connect "chat -v -f \
/etc/ppp/chat.provider"
#
-------------------
#
# /etc/ppp/chat.provider
#
TIMEOUT 240 "" AT&E1234 OK ATD047110815 ogin: Puser sword: topsecret #
-------------------
--------------------------------------------------- To remove yourself from this mailing list send email to majordomo@hub-wue.franken.de containing "unsubscribe isdn4linux <your_email_address>" in the message body [-vg]

222
FAQ/_howto/pppbind.txt
View File

@ -1,111 +1,111 @@
Date: Sat, 19 Oct 1996 02:21:45 +0200
X-Sender: sw0001@aixrs1.hrz.uni-essen.de To: isdn4linux@hub-wue.franken.de
From: Matthias Hessler <hessler@wi-inf.uni-essen.de> Subject: RE: options files
Sender: owner-isdn4linux@hub-wue.franken.de Reply-To: isdn4linux@hub-wue.franken.de
At 17:57 18.10.1996 +0200, you wrote:
>Matthias Hessler <hessler@wi-inf.uni-essen.de> ha escrito a
>isdn4linux@hub-wue.franken.de:
>
>> well, isdnctrl does not quite assign interface ipppx to /dev/ipppx by
>> default (e.g. interface ippp3 to /dev/ippp3). I'm not entirely sure how
>it
>> does its assignements, but I think it takes interface ipppx and binds it
>to
>> the first available /dev/ipppx, starting x with 0 and counting up (e.g.
>your
>> interface ippp3 gets bound to /dev/ippp0 because there is an ipppd
>already
>> waiting there)
>> Which leads to your problem: you want interface ippp3 _exclusively_ bound
>to
>> /dev/ippp3 because you want only your ipppd configured for /dev/ippp3
>> answering all the traffic from your interface ippp3.
>
>Hi Matthias
>
>Ok; for clarifying scripts (and my concepts :) I name net interfaces
>isdn0..isdn3, but when I try to launch ipppd, it tells me there must be at
>least ippp0 configured (???) Does it means i have to configure interfaces
>twice (one time for ipppX and other for isdnX)?
No.
Here is what happened: You named your net interfaces isdn0..isdn3 and did not use the pppbind option. Now isdnctrl has no clue that it should connect those interfaces to any /dev/ippp* .
If you name your net interfaces ippp0..ippp3, then isdnctrl _automatically_ recognizes (by the name of those interfaces) that those should be connected to the /dev/ippp* . It does it (if I'm not wrong about that default behavior) when data arrives by connecting a net interface to the first available /dev/ippp* .
Let's say if data arrives on net interface ippp3, it tries to connect it to /dev/ippp0, if that is available. If not (already another connection going on?), it tries /dev/ippp1, and so on.
As you have two ipppd's with different options running that is not what you want, because you can never tell in advance which data will be answered by which ipppd.
No matter how the name of your net interfaces is, if you use the "isdnctrl pppbind" option, you can tell isdnctrl to _always_ connect some netinterface with some /dev/ippp* . E.g.:
isdnctrl pppbind isdn3 2
tells isdnctrl to always put data from net interface isdn3 to /dev/ippp2.
That is very handy, if you want to have a special ipppd lurking on /dev/ippp2 that should get all that traffic from isdn3.
Isdnctrl acts like a switch board.
Default behaviour (using net interfaces ippp0 and ippp1): =========================================================
Kernel---------+
| |
Net interface ippp0 ippp1 (isdnctrl addif ippp*)
| |
| |
Isdnctrl (by default, to next available device
=> no isdnctrl pppbind necessary)
| |
| |
Device /dev/ippp0 /dev/ippp1 /dev/ippp2 /dev/ippp3
| | | |
ipppd ipppd ipppd ipppd
Default behaviour (using net interfaces isdn0, isdn1, isdn2, isdn3): ====================================================================
Kernel------+----------+----------+
| | | | Net interface isdn0 isdn1 isdn2 isdn3 (isdnctrl addif ippp*)
isdnctrl (no connection from isdn* to any /dev/ippp*,
because: name of net interface is not "ippp*")
Device /dev/ippp0 /dev/ippp1 /dev/ippp2 /dev/ippp3
| | | |
ipppd ipppd ipppd ipppd
Behavior using "isdnctrl pppbind" (A):
======================================
Kernel------+----------+----------+
| | | | Net interface isdn0 isdn1 isdn2 isdn3 (isdnctrl addif isdn*)
|
| Isdnctrl +-------+ (isdnctrl pppbind isdn3 2)
|
| Device /dev/ippp0 /dev/ippp1 /dev/ippp2 /dev/ippp3
| | | |
ipppd ipppd ipppd ipppd
Behavior using "isdnctrl pppbind" (A):
======================================
Kernel------+----------+----------+
| | | | Net interface isdn0 isdn1 isdn2 isdn3 (isdnctrl addif isdn*)
|
| Isdnctrl +-------+ (isdnctrl pppbind isdn2 1)
|
|
Device /dev/ippp0 /dev/ippp1 /dev/ippp2 /dev/ippp3
| | | |
ipppd ipppd ipppd ipppd
I hope that's correct. Please correct me if I'm wrong...
Bye,
Matthias
**************************************************************** Matthias Heßler Email: hessler@wi-inf.uni-essen.de Gelsenkirchener Str. 67 Tel. : 0201-8915964 45141 Essen Fax. : 0201-8915965 ****************************************************************
--------------------------------------------------- To remove yourself from this mailing list send email to majordomo@hub-wue.franken.de containing "unsubscribe isdn4linux <your_email_address>" in the message body [-vg]
Date: Sat, 19 Oct 1996 02:21:45 +0200
X-Sender: sw0001@aixrs1.hrz.uni-essen.de To: isdn4linux@hub-wue.franken.de
From: Matthias Hessler <hessler@wi-inf.uni-essen.de> Subject: RE: options files
Sender: owner-isdn4linux@hub-wue.franken.de Reply-To: isdn4linux@hub-wue.franken.de
At 17:57 18.10.1996 +0200, you wrote:
>Matthias Hessler <hessler@wi-inf.uni-essen.de> ha escrito a
>isdn4linux@hub-wue.franken.de:
>
>> well, isdnctrl does not quite assign interface ipppx to /dev/ipppx by
>> default (e.g. interface ippp3 to /dev/ippp3). I'm not entirely sure how
>it
>> does its assignements, but I think it takes interface ipppx and binds it
>to
>> the first available /dev/ipppx, starting x with 0 and counting up (e.g.
>your
>> interface ippp3 gets bound to /dev/ippp0 because there is an ipppd
>already
>> waiting there)
>> Which leads to your problem: you want interface ippp3 _exclusively_ bound
>to
>> /dev/ippp3 because you want only your ipppd configured for /dev/ippp3
>> answering all the traffic from your interface ippp3.
>
>Hi Matthias
>
>Ok; for clarifying scripts (and my concepts :) I name net interfaces
>isdn0..isdn3, but when I try to launch ipppd, it tells me there must be at
>least ippp0 configured (???) Does it means i have to configure interfaces
>twice (one time for ipppX and other for isdnX)?
No.
Here is what happened: You named your net interfaces isdn0..isdn3 and did not use the pppbind option. Now isdnctrl has no clue that it should connect those interfaces to any /dev/ippp* .
If you name your net interfaces ippp0..ippp3, then isdnctrl _automatically_ recognizes (by the name of those interfaces) that those should be connected to the /dev/ippp* . It does it (if I'm not wrong about that default behavior) when data arrives by connecting a net interface to the first available /dev/ippp* .
Let's say if data arrives on net interface ippp3, it tries to connect it to /dev/ippp0, if that is available. If not (already another connection going on?), it tries /dev/ippp1, and so on.
As you have two ipppd's with different options running that is not what you want, because you can never tell in advance which data will be answered by which ipppd.
No matter how the name of your net interfaces is, if you use the "isdnctrl pppbind" option, you can tell isdnctrl to _always_ connect some netinterface with some /dev/ippp* . E.g.:
isdnctrl pppbind isdn3 2
tells isdnctrl to always put data from net interface isdn3 to /dev/ippp2.
That is very handy, if you want to have a special ipppd lurking on /dev/ippp2 that should get all that traffic from isdn3.
Isdnctrl acts like a switch board.
Default behaviour (using net interfaces ippp0 and ippp1): =========================================================
Kernel---------+
| |
Net interface ippp0 ippp1 (isdnctrl addif ippp*)
| |
| |
Isdnctrl (by default, to next available device
=> no isdnctrl pppbind necessary)
| |
| |
Device /dev/ippp0 /dev/ippp1 /dev/ippp2 /dev/ippp3
| | | |
ipppd ipppd ipppd ipppd
Default behaviour (using net interfaces isdn0, isdn1, isdn2, isdn3): ====================================================================
Kernel------+----------+----------+
| | | | Net interface isdn0 isdn1 isdn2 isdn3 (isdnctrl addif ippp*)
isdnctrl (no connection from isdn* to any /dev/ippp*,
because: name of net interface is not "ippp*")
Device /dev/ippp0 /dev/ippp1 /dev/ippp2 /dev/ippp3
| | | |
ipppd ipppd ipppd ipppd
Behavior using "isdnctrl pppbind" (A):
======================================
Kernel------+----------+----------+
| | | | Net interface isdn0 isdn1 isdn2 isdn3 (isdnctrl addif isdn*)
|
| Isdnctrl +-------+ (isdnctrl pppbind isdn3 2)
|
| Device /dev/ippp0 /dev/ippp1 /dev/ippp2 /dev/ippp3
| | | |
ipppd ipppd ipppd ipppd
Behavior using "isdnctrl pppbind" (A):
======================================
Kernel------+----------+----------+
| | | | Net interface isdn0 isdn1 isdn2 isdn3 (isdnctrl addif isdn*)
|
| Isdnctrl +-------+ (isdnctrl pppbind isdn2 1)
|
|
Device /dev/ippp0 /dev/ippp1 /dev/ippp2 /dev/ippp3
| | | |
ipppd ipppd ipppd ipppd
I hope that's correct. Please correct me if I'm wrong...
Bye,
Matthias
**************************************************************** Matthias Heßler Email: hessler@wi-inf.uni-essen.de Gelsenkirchener Str. 67 Tel. : 0201-8915964 45141 Essen Fax. : 0201-8915965 ****************************************************************
--------------------------------------------------- To remove yourself from this mailing list send email to majordomo@hub-wue.franken.de containing "unsubscribe isdn4linux <your_email_address>" in the message body [-vg]

274
FAQ/_howto/vbox_sound.txt
View File

@ -1,137 +1,137 @@
X-Sender: dekay@xplor.ipf.de
References: <m0vIIrY-000LHmC@scorpio.in-berlin.de> from "Gernot Zander" at Oct 29, 96 07:26:08 pm
Date: Wed, 30 Oct 1996 19:05:55 +0200
To: isdn4linux@hub-wue.franken.de, michael@abadonna.franken.de From: Darko Krizic <dekay@ipf.de>
Subject: Sounds erzeugen für vgetty/vboxgetty Cc: maze@frankfurt.netsurf.de
Sender: owner-isdn4linux@hub-wue.franken.de Reply-To: isdn4linux@hub-wue.franken.de
Ich möchte hier ein paar Erfahrungen mit vboxgetty zusammenzählen, insbesondere im Zusammenhang mit dem Erzeugen von Messages (Sounds)
Sound-Format
------------
Das Format ADPCM-4 generiert beim Aufzeichnen wesentlich kleinere Dateien als die Formate uLaw oder aLaw, deswegen ist dieses Format vorzuziehen.
Vorteil von uLaw ist allerdings, daß es dem au-Format entspricht und so direkt mit cat sound.au >/dev/audio angehört werden kann, allerdings gibt es zwei Probleme:
- Das ist nur interessant für Leute, die auch am Linux-Rechner sitzen und dieser eine Soundkarte besitzt. Viele Leute verwenden den Linux-Rechner als "echten" Server, der weder Monitor noch Soundkarte hat.
- Die aufgezeichneten Samples haben einen sehr schwachen Pegel, den man theoretisch mit
autopvf <x.msg | pvfamp 5 | pvftoau >x_laut.msg
verstärken könnte, allerdings muß man sich dann sowieso mit den pvf-Tools befassen und kann dann auch gleich auf ADPCM-4 umsteigen.
Aufzeichen über Telefon
-----------------------
Wie in der i4l-FAQ beschrieben ist es ohne Probleme möglich sich selbst auf den Anrufbeantworter zu sprechen und die entsprechende Datei in das Verzeichnis /var/spool/vobx/<user>/incoming/standard.msg zu kopieren.
Allerdings ist die Qualität bei weitem nicht ausreichend, unter anderem, weil sich am Anfang und Ende Geräusche oder Pausen befinden.
Selbst Dateien generieren
-------------------------
Ich habe einen Macintosh, der unter anderem die Möglichkeit bietet, Sound von Audio-CDs ohne Verluste per SCSI auf die Festplatte zu kopieren und nachträglich auf andere Samplegeschwindigkeit und Bitbreite zu konvertieren, z.B. "16bit, 44kHz -> 8bit, 22kHz". Desweiteren kann ich mit dem Mikrofon Sounds und am Ende alle Sounds manipulieren und mixen. Die beste Voraussetzungen für verrückte Ansagen.
Das Format, das der Macintosh verarbeitet ist AIFF. Dieser Standard wird auch von SGI und anderen namhaften Herstellern verwendet, allerdings konnte ich unter Linux kein Programm finden, das dieses Format versteht. Auf dem Macintosh gibt es allerdings das Programm "SoundApp", welches nach und von Suns .au konvertieren und ADPCM wenigstens abspielen kann. Anmerkung: Dummerweise nennt SoundApp das au-Format "NeXT", weil dieses Format dort verwendet wird, allerdings habe ich lange gebraucht, um herauszufinden, daß es dasselbe wie au ist.
Ich nehme mal an, daß unsere Windows-Freunde ähnliche Fähigkeiten haben.
Das Windows-Hausformat nennt sich WAV. Auch dieses Format kennen die PVF-Tools nicht, aber ich denke mal, daß es unter Windows ähnliche Werkezeuge gibt, die sogar ADPCM-4 generieren können.
Ich weiß nicht, wie man unter Linux Sounds aufzeichnen kann und welches Format diese haben, allerdings wird es wohl Sun-AU-Format haben, so daß der weitere Text auf für Linux-Benutzer interessant ist.
Sounds für vboxgetty konvertieren
---------------------------------
Wie bereits oben beschrieben, empfehle ich den Betrieb mit ADPCM-4. Bei mgetty befindet sich die pvf-Toolsammlung, welche Soundformate konvertieren und manipulieren kann, allerdings gab es Probleme mit den Formaten, die vboxgetty generiert hatte (ADPCM-4). Gegen dieses Problem gibt es Patches, allerdings enthält die neuste Version von mgetty (0.99 Okt02 und wahrscheinlich auch ein paar ältere) bereits die Programme "zyxeltopvf" und "pvftozyxel[234]", mit welchen genau diese Formate konvertiert werden können.
Mein Macintosh liefert die Sounds 22254Hz. Um daraus einen entsprechenden Sound in ADPCM-4 zu generieren verwende ich folgende Kommendozeile:
autopvf <standard.au \
| pvfspeed 2.73 \
| pvfamp 0.2 \
| pvftozyxel4 >standard.msg
autopvf konvertiert dan au-Sound nach pvf. pvfspeed ändert die Samplingrate auf 8000 (22554 / 8000 = 2.73), damit die Geschwindigkeit wieder stimmt.
pvfamp 0.2 senkt den Pegel auf 20%, weil der Sound sonst total verzerrt klingt, schließlich kennt das Telefon nur Frequenzen zwischen 300 und 3000Hz. Zuletzt legt pvftozyxel4 den Sound im richtigen Format ab.
Dadurch, daß weder Rauschen noch Klacken zu hören sind, klingen so generierte Ansagen einfach klasse. Wer etwas mit Sound-Manipulationsprogrammen spielen kann, der kann tolle Effekte generieren, allerdings sollte man damit wegen des beschränten Frequenzbandes echt sparsam umgehen, sonst versteht der Anrufende nichts.
Nachbarbeiteitung von aufgezeichneten Nachrichten ------------------------------------------------- Ich möchte, daß meine Nachrichten in ein auf dem Macintosh abspielbaren Format konvertiert werden und an eine e-mail an mich attached werden sollen. Ich konvertiere den Sound nach au mit folgenden Befehlen:
zyxeltopvf <sound.pvf \
| pvfamp 5
| pvfcut 0.2 0.2 \
| pvftoau 8000 >sound.au
zyxeltopvf konvertiert den aufgezeichneten Sound nach pvf und pvfamp verstärkt diesen auf das fünffache, weil der Pegel (s.ganz.o) sehr schwach ist. pvfcut schneidet 0.2 Sekunden vorne und hinten ab, weil man hinten z.B. das Auflegen des Telefons hört. Scheinbar zeichnet vboxgetty schon auf, während der Beep-Ton abgespielt wird, weil dieser ganz am Anfang zu hören ist. Die 8000 nach dem pvtoau ist sehr wichtig, weil diese sorgt, daß die Frequenz in den au-Header geschrieben wird, damit das abspielende Programm auch die richtige Rate spielt!
Namen des Anrufenden in der Mail
--------------------------------
vboxgetty kennt den Namen des Anrufenden, während es die Nachricht aufzeichnet, dummerweise wird dieser Name nicht an das Programm "-p /usr/local/vbox/new_voice" mit übergeben. Ich habe deswegen einen (very dirty) hack von vboxgetty erzeugt, welches als 4ten Parameter den Namen an new_voice übergibt, damit ist es möglich, daß das Subject der generierten Mail aussieht wie "Voice from Darko Krizic" oder zumindest "Voice from Unknown". Da bei internationalen Calls zumindest die Landeskennung übergeben wird, kann eine Nachricht aus USA ein Subject wie "Voice from USA" haben.
Ich bitte hiermit den Autor von vbox selbst die Änderungen zu machen.