Hi,
Karsten Keil [mailto:kkeil@suse.de] schrieb am August 15, 2003 4:54 PM:
> Eigentlich muessten die Routen so schon aussreichen, wenn die
> Machinen im
> 192.168.28.0/24 netz diesen Rechner als default GW haben und
> das Routing
> zwischen den Interfaces erlaubt ist, hier kommen jetzt noch
> die Firewall
> Sachen ins Spiel.
Danke für die Tips!
Es funktioniert jetzt fast alles so, wie es soll.
Ich habe nur noch zusätzlich Masquerading eingerichtet.
Ein kleines Problem habe ich noch bemerkt:
Sobald der ISDN-Kanal disconnected wird, wird das
routing umgeschrieben.
In YaST2 über Konsole habe ich allerdings alles ausgeschaltet,
was das routing betreffen sollte (also das für ippp1).
Woran kann das denn noch liegen?
Grüsse,
Michael
----- Forwarded message from Karsten Keil <kkeil(a)suse.de> -----
Da Anfragen kamen, hier noch der fehlende Artikel zum Thread, der
versehentlich per PM rausging.
On Fri, Aug 15, 2003 at 04:23:39PM +0200, Michael Ludwig wrote:
>
> Hallo Karsten,
>
> danke für Deine Antwort,
>
> Karsten Keil [mailto:kkeil@suse.de] schrieb am August 15, 2003 3:56 PM:
> >
> > > "proxyarp" bringt leider auch nur eine Fehlermeldung, dass
> > die IP nicht
> > > aufgelöst werden konnte...
> > > "Cannot determine ethernet address for proxy ARP"
> >
> > proxyarp geht nur wenn die interface adresse zugeordnet
> > werden kann, deshalb
> > muss sie im selben netzwerk liegen und eindeutig bei mehreren
> > ethX sein.
> > Am Besten man verwendet für das IPPP Device die selbe Adresse
> > wie für das eth0.
> >
> > Proxy ARP ist eigentlich nur ein workaround, besser man setzt
> > gleich ein
> > richtiges Routing auf, d.h der default gateway des Netzwerks
> > hat eine Route
> > über diesen Einwahlrechner zu den remote clients.
> >
>
> Okay, also benötige ich das wohl nicht.
> Ich habe verschiedene Netze eingerichtet.
> eth0: das eigentliche Netzwerk, in dem Server & Clients laufen
> eth1: Karte für T-DSL
> ippp0: ISDN-Dial-out für Notfall
> ippp1: ISDN-Dial-in für "mobiles" arbeiten.
>
> Folgende Netze habe ich entsprechend:
>
> eth0: 192.168.28.1
> eth1: 192.168.34.1
> ippp0: DYNIP
> ippp1: 192.168.32.1
>
> wobei der angewähle Rechner die 192.168.32.200 zugewiesen bekommt.
>
> Mein routing sieht im Moment so aus:
>
> stargate:/ # route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use
> Iface
> 217.5.98.92 0.0.0.0 255.255.255.255 UH 0 0 0
> ppp0
> 192.168.32.200 0.0.0.0 255.255.255.255 UH 0 0 0
> ippp1
> 192.168.34.0 0.0.0.0 255.255.255.0 U 0 0 0
> eth1
> 192.168.28.0 0.0.0.0 255.255.255.0 U 0 0 0
> eth0
> 0.0.0.0 217.5.98.92 0.0.0.0 UG 0 0 0
> ppp0
> stargate:/ #
>
> Nun müsste ich, um proxyarp zu umgehen, verständlicherweise eine Route
> vom 32er-Netz ins Netz 0.0.0.0 erstellen.
> Meine Idee wäre nun:
>
> stargate:/ # route add -net 0.0.0.0 gw 192.168.28.1 netmask 0.0.0.0
> ippp1
> SIOCADDRT: Network is unreachable
>
> Um das routing vom dial-in-rechner korrekt laufen zu lassen.
> Aber da ist ja nun anscheinend ein Fehler drin.
>
>
> > Wenn der Rechner selbst das default GW ist, besteht keine
> > Notwendigkeit für ProxyARP.
>
>
> Ja, wie Du oben schon ähnlich geschrieben hast.
> Aber da jedes interface ein eigenes Netz hat, muss ja geroutet werden.
> Doch wieso nimmt er die route von oben nicht?
> Wo liegt mein Denkfehler?
0.0.0.0 ist kein gueltiges Netz, es ist die default route oder eine dummy
Addresse.
Eigentlich muessten die Routen so schon aussreichen, wenn die Machinen im
192.168.28.0/24 netz diesen Rechner als default GW haben und das Routing
zwischen den Interfaces erlaubt ist, hier kommen jetzt noch die Firewall
Sachen ins Spiel.
> Wähle ich mich ein, bekomme ich korrekt meine IP und den DNS Server
> (192.168.32.200 meine IP während ISDN-Dial-in und 192.168.28.1
> DNS-Server & GW)
> zugewiesen.
> Ich kann ich das GW auf der 192.168.28.1 anpingen, doch einen Rechner im
> Netz
> 192.168.28.0/24 leider nicht.
>
> Any hints??
ping vom remote laufen lassen.
1.
tcpdump -i ippp1 sollte die Pakete zeigen.
tcpdump -i eth0 auch (wenn nicht ist ip_forward nicht gesetzt oder die
firewall blocked).
Wenn die Pakete an eth0 sichtbar sind, aber keine Antwort, fehlt die
route auf den Rechnern an eth0 (oder ping gesperrt).
--
Karsten Keil
SuSE Labs
ISDN development
Hi ich hoffe erstmal das ich alles richtig gemacht habe ... Ist ja mein
erster Eintrag in der Liste :)
Nun zu meiner Frage :
Ich habe Suse 8.1 neuester Kernel
Ne Fritz Card PCI mit Capi Treiber
Installiert sind
Capi4hylafax
Capi4linux
Hylafax
Allerdings kann er nicht faxen :
Aug 12 14:51:38.85: [ 5287]: SESSION BEGIN 00000012 +49.9???.?????? Aug
12 14:51:38.85: [ 5287]: FAX FAX: JOB 12 DEST ???????????? COMMID
00000119 Aug 12 14:51:38.85: [ 5287]: Try to connect to fax number
???????????? in Hylafax mode on controller 1. Aug 12 14:51:38.85: [
5287]: Dial and starting transfer of TIFF-File docq/doc12.ps;30 with
normal resolution. Aug 12 14:51:43.85: [ 5289]: Connection dropped with
Reason 0x3301 (Protocol error layer 1 (broken line or B-channel removed
by signalling protocol)). Aug 12 14:51:43.85: [ 5287]: SESSION END
Die fragezeichen hab ich halt reingemacht um die nummer zu schützen :)
Kann mir bitte jemand helfen ? Habe keine Ahnung was da noch groß falsch
sein soll... Also doch das sieht man ja aber wo mein fehler liegt halt
...
Danke schonmal
Mit freundlichen Grüßen
Micha
~
Hallo Liste,
ich habe hier einen Hylafax-Server unter SuSE 8.1 mit zwei aktiven
AVM-B1-PCI
Karten mit folgenden installierten Paketen am Laufen:
capi4linux-2002.9.8-4
capi4hylafax-4.1.3-91
hylafax-4.1.3-127
k_deflt-2.4.19-74
Funktioniert alles super...bis auf xferfaxstats bzw. recvstats.
Ich habe ein paar Testfaxe verschickt und auch zugefaxt bekommen. Wenn ich
jetzt aber ein
'xferfaxstats -age 10 '
oder ein
'recvstats -age 10'
oder ein
xferfaxstats -since '01/01/2003 0:00'
ausführe,
bekomme ich nur das hier:
Sender Pages Time Pg/min Errs TypRate TypData
---------------------------------------------------------------------------------------
Total 0 0:00 0.0 0
Die Datei /var/spool/fax/etc/xferfaxlog ist jedoch mit Einträgen gefüllt.
(Wenn ich mir allerdings die Datei z.B. mit vi anschaue, wird ausser in der
ersten Zeile ein '^@' - Steuerzeichen am Anfang jeder Zeile
angezeigt.....ist das
normal?)
Mach ich da was falsch oder ist das Problem bekannt?
Merci,
Klaus.
--
COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test
--------------------------------------------------
1. GMX TopMail - Platz 1 und Testsieger!
2. GMX ProMail - Platz 2 und Preis-Qualitätssieger!
3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post
>> mich würde auch noch interessieren wie man den isdnlog abschalten kann?
> Im allgemeinen, in dem das man den Aufruf von isdnlog aus dem
> entsprechenden init-Skript entfernt. Wahrscheinlich gibt es bei SuSE
> aber eine einfachere Möglichkeit, dies zu tun; vielleicht findest in
> Yast eine entsprechende Option, mehr kann ich mangels SuSE-Installation
> nicht sagen. Der pragmatische Ansatz wäre, /usr/sbin/isdnlog
> umzubenennen, das könnte aber beim Systemneustart oder auch bei
> `rci4l_hardware restart' zu weiteren Ausfällen führen.
> Gruß Tobias
man kann i4l bei suse gar nicht ohne isdnlog installieren. im yast hab ich
nichts gefunden.
vielleicht weiß aber jemand ob es eine einfache möglichkeit gibt isdnlog
auszuschalten?
mfg
leo
hallo!
ich habe folgendes problem:
der isdnlog müllt mir dir /var/log/messages mit folgender meldung zu
* tei 127 calling ? with '' invalide lenght 106 complete frame ignored
die isdn karte hängt am internen s0 bus meiner tel-anlage. die meldung kommt
ca. alle 30 sekunden obwohl aber niemand telefoniert, wählt oder ein anruf
herein kommt.
woran könnte das liegen bzw. wie stellt man das ab?
mfg
leo
---------- Weitergeleitete Nachricht ----------
Subject: Re: [suse-isdn] Internet einwahl
Date: Donnerstag, 14. August 2003 09:19
From: Karsten Keil <kkeil(a)suse.de>
To: suse-isdn(a)suse.com
On Thu, Aug 14, 2003 at 03:30:35AM +0200, Manfred Lindtner wrote:
> Am Montag, 11. August 2003 06:49 schrieb Manfred Tremmel:
> > Am Sonntag, 10. August 2003 23:05 schrieb Manfred Lindtner:
aber wie kriege ich Kinternet dazu zum starten und
> wie komme ich ins Internet ohne Yastprozetur???????
Probier mal ob ein
rcsmpppd restart
hilft (danach bei kinternet mit rechter Maustaste Verbindung zum Server
wiederherstellen).
Karsten Keil
SuSE Labs
ISDN development
Das mit dem rcsmpppd restart geht ganz gut. Ich hätte es aber ganz gerne
vollautomatisch. Mit hinzufügen Programmknopf bekomme ich nur ein Zahnrad
angeboten und nach dem draufklicken den Stecker rechts unten danach kann ich
erst als root diese rcsmpppd restart machen. In welcher Datei muß ich was
ändern das das beim Start gleich geht????
-------------------------------------------------------
lässt sich der fehler nachvollziehen, oder war das einmalig? leider empfange ich nicht genügend faxe :(
mit dem alten kernel hatte ich das nicht.
gibts sonst abhilfe?
vielen dank im vorraus!
> -----Ursprüngliche Nachricht-----
> Von: Karsten Keil [mailto:kkeil@suse.de]
> Gesendet: Freitag, 15. August 2003 17:52
> An: suse-isdn(a)suse.com
> Betreff: Re: [suse-isdn] Kernel-Patch und c2faxrecv: Kernel died!
>
>
> On Fri, Aug 15, 2003 at 05:21:29PM +0200, Michael MR. Rundel wrote:
> > Hallo,
> >
> > hatte gerade kernel panic als meine SuSE8.1 mit c2faxrecv
> ein fax empfangen wollte. Laut Hylafax receive Agent muss
> wohl das fax noch angekommen sein, aber dann tot! Kernel died!!
> > kann mir jemand sagen, wo oder ob ich den kernel panic
> trace finde? dann würd ich den noch posten.
>
> Den findet man bei total freeze nur, wenn eine serielle
> Konsole angeschlossen ist
> oder wenn man spezielle debug features nutzt (z.B. das der
> panic auf eine
> floppy geschrieben wird).
>
> >
> > System:
> > capi4hylafax-4.1.3-91
> > hylafax-4.1.3-127
> >
> > k_deflt-2.4.19-340
> >
> > oder sollte ich einfach nur mein hylafax updaten?
> >
>
> Nein, hat nichts mit einem kernel Panic zu tun.
>
> --
> Karsten Keil
> SuSE Labs
> ISDN development
>
> --
> Um die Liste abzubestellen, schicken Sie eine Mail an:
> suse-isdn-unsubscribe(a)suse.com
> Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken
> Sie eine Mail an: suse-isdn-help(a)suse.com
>
>
Hallo,
hatte gerade kernel panic als meine SuSE8.1 mit c2faxrecv ein fax empfangen wollte. Laut Hylafax receive Agent muss wohl das fax noch angekommen sein, aber dann tot! Kernel died!!
kann mir jemand sagen, wo oder ob ich den kernel panic trace finde? dann würd ich den noch posten.
System:
capi4hylafax-4.1.3-91
hylafax-4.1.3-127
k_deflt-2.4.19-340
oder sollte ich einfach nur mein hylafax updaten?
achso ja: Fritz!Isdn Classic
Mit freundlichen Grüßen
Michael Rundel
Hallo,
ich habe ein Problem mit der Einrichtung eines Dial-In Zugangs.
Ich benutze die 8.2er und bin der Anleitung von
http://www.linuxnetmag.com/de/issue8/m8dialin1.html soweit gefolgt.
Ziel ist es, dass ich mich via ISDN in meinen SuSE-Rechner einwählen
kann und Zugang zu meinem Netz habe sowie über diese ISDN-Leitung auch
surfen kann (der SuSE-Rechner hat dann natürlich eine Internetverbindung
via eth1).
Yast2 bediene ich nur über Konsole (ssh), nicht grafisch, da kein X
installiert ist.
Ich weiss nicht, wie es sich im Normalfall verhalten soll, aber für
meine beiden ippp-interfaces erstellt yast2 immer nur eine
options-Datei.
Bei früheren Versionen von SuSE (7.2) kam bei mehreren interfacen
jeweils eine options.<interface> dazu.
Laut dem Artikel vom NetMag sollte ja eigentlich auch hier von YaST2
eine solche Datei angelegt werden.
In meinem Fall wäre das dann ja wohl die options.ippp1 eventuell
dahinter dann noch den Providernamen (options.ippp1.dialin).
Nur, wie schon gesagt, leider übernimmt yast2 das nicht und ich stehe
ohne diese Datei da.
Ändere ich in der /etc/ppp/options einen Eintrag (debug-modus aktivieren
z.B.), führt der pppd (?) alles korrekt aus und liefert debug-Meldungen,
natürlich erst nach einem restart des isdn-Systems mit rcisdn restart
sowie rcnetwork restart.
Lege ich die Datei /etc/ppp/options.ippp1 von Hand an, killt mir yast2
die Datei, bzw. SuSEconfig killt sie, sobald es aufgerufen wird.
Auch nach einem restart beider Dienste (isdn & network) wird die Datei
überhaupt nicht beachtet.
Zur Not habe ich nun in der Datei /etc/sysconfig/isdn/cfg-net1 den
Parameter
IPPPD_OPTIONS="noccp ms-dns 192.168.28.1 auth +pap +chap proxyarp"
gesetzt.
Damit läuft jetzt wenigstens die User-Authentifizierung.
"noccp" habe ich gesetzt, weil compression eh nicht klappt und nur
Fehlermeldungen beim connect bringt.
"proxyarp" bringt leider auch nur eine Fehlermeldung, dass die IP nicht
aufgelöst werden konnte...
"Cannot determine ethernet address for proxy ARP"
Allerdings bin ich der Meinung, proxyarp unbedingt zu benötigen, wie im
NetMag beschrieben ist, um die Routing Funktionalitäten herzustellen.
Hier noch ein paar Log-Auszüge mit der entsprechenden
proxyarp-Fehlermeldung.
Ist denke ich aber alles etwas weniger wichtig, denn wenn Ihr mir helfen
könntet, die Datei options.ippp1 endlich gelesen wird, hoffe ich schon
sehr viel weiter zu kommen.
Habe ich irgendetwas wichtiges vergessen?
Ich hoffe nicht, ansonsten fragt bitte nach.
Danke schon mal für Eure Hilfe!
Michael
============================================
Aug 10 13:31:08 stargate isdnlog: Aug 10 13:31:08 * Call to tei 127 from
20 on 22 RING (Data)
Aug 10 13:31:08 stargate isdnlog: Aug 10 13:31:08 Call to tei 70 from
20 on 22 CONNECT (Data)
Aug 10 13:31:08 stargate isdnlog: Aug 10 13:31:08 Call to tei 70 from
20 on 22 INTERFACE ippp1 called by 20
Aug 10 13:31:08 stargate kernel: ippp1: call from 20 -> 22 accepted
Aug 10 13:31:08 stargate isdnlog: Aug 10 13:31:08 tei 72 calling ? with
? Time:Sun Aug 10 13:30:00 2003
Aug 10 13:31:08 stargate isdnlog: Aug 10 13:31:08 tei 72 calling 22 with
? COLP 22
Aug 10 13:31:08 stargate isdnlog: Aug 10 13:31:08 tei 72 calling 22 with
? CONNECT
Aug 10 13:31:08 stargate isdnlog: Aug 10 13:31:08 Call to tei 70 from
20 on 22 INTERFACE ippp1 called by 20
Aug 10 13:31:08 stargate kernel: isdn_net: ippp1 connected
Aug 10 13:31:08 stargate ipppd[13872]: Local number: 22, Remote number:
, Type: incoming
Aug 10 13:31:08 stargate ipppd[13872]: PHASE_WAIT -> PHASE_ESTABLISHED,
ifunit: 1, linkunit: 0, fd: 7
Aug 10 13:31:08 stargate ipppd[13872]: MPPP negotiation, He: No We: No
Aug 10 13:31:08 stargate kernel: Received CCP frame from peer slot(1)
Aug 10 13:31:08 stargate kernel: [1/1].ccp-rcv[0]: 01 04 00 0a 12 06 00
00 00 01
Aug 10 13:31:08 stargate ipppd[13872]: local IP address 192.168.32.1
Aug 10 13:31:08 stargate ipppd[13872]: remote IP address 192.168.32.200
Aug 10 13:31:08 stargate ipppd[13872]: Cannot determine ethernet address
for proxy ARP
============================================