October 1999 - openSUSE ISDN (Deutsch)

SuSE6.1, i4l-Update Gebuehrenberechnung
by Klaus Moysich 10 Oct '99

10 Oct '99

Ich bekomme meine Gebuehrenberechnung nicht hin. In /var/log/messages wird beim Verbindungsaufbau in der CHARGE-Meldung der richtige Provider ausgegeben. Beim Verbindungsende ist in der HANGUP-Meldung das Feld DM aber leer, bzw. steht da Inf. In isdn.log wird auch kein Betrag angegeben. Und zu allem Unglueck stuerzt isdnrep mit Segmentation fault ab. Aus den READMEs und man-pages werde ich nicht viel schlauer. Es scheint mir, dass sie andere Versionen von isdnlog und den Config-Files behandeln. Ausserdem finde ich in de.alt.comm.isdn4linux immer wieder Hinweise auf rates-de.dat. Diese Datei gibt es bei mir aber gar nicht. Wie kann ich mir helfen? Auszug aus /var/log/messages: ----------------------------- CHARGE: Wochenende (Sonntag), CityCall, DM 0.040/Min, Takt 1/1CityCall, DM 0.040/Min, Takt 1/1 HANGUP (DM Inf 0:02:06 I= 15.0Kb O= 5.8Kb) Auszug aus /var/log/isdn.log: ----------------------------- datum|meineMSN|019102345|126|12645|939511031|-1|O|16|15316| 5899|3.2|7|0|0.121|DM|Inf| 33| 1| Ich habe das i4l-Update fuer SuSE 6.1 mit YaSt installiert und meinen Provider folgendermassen konfiguriert: callerid.conf: -------------- [MSN] NUMBER = 7923153 # Ich selbst ALIAS = pepito [MSN] NUMBER = 019102345 ALIAS = 1und1 SI = 7 ZONE = 1 INTERFACE = ippp0 tarif.dat: ---------- P:33,1=1und1 G:01.01.1999 C:Name: 1 und 1 I:019102345 Z:1,1/1 T:*=0.04 tarif.conf: ----------- P:33=1 ----------------- Klaus Moysich Wilhelm-Dresing-Str. 10 D 44229 Dortmund Fon: +49 231 731053

3 2

IPX ueber IPPP
by Michael Stumpf 09 Oct '99

09 Oct '99

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo Liste(n), ich habe folgendes "Problem" : - --------------- ----------------- Novell Netz 1 | <-> Linux R1 <=ISDN=> Linux R2 <-> | Novell Netz 2 | - --------------- ----------------- Wie bringe ich die beiden Linux-Rechner dazu, IPX/SPX zu routen ? ipxrip hab ich installiert, ipxd hab ich gestartet. er erstellt auch automatisch die entsprechenden IPX-Interfaces fuer das lokale Novell-Netz. (ncpmount funktioniert fuer den lokalen Server) Bei den ISDN-Parametern habe ich folgendes geändert. I4L_ENCAP_2="ethernet" und in /etc/ppp/options.ippp1 steht ein +ipx Nach einer Anwahl zwischen beiden Rechnern tut sich leider ueberhaupt nichts. Nach einiger Zeit schlaegt dann der HUPTIMEOUT zu und es wird aufgelegt... Wie was wo muß ich nun bei den ISDN-Parametern zusaetzlich angeben... Zusatzfrage : Gibt es irgendwo (Url, Buch) eine vernünftige Erklaerung zu IPX-Netzen, Routing, RIP/SAP, etc.. ? cu Michael -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.0.2i iQA/AwUBN/+ycU5aMkHNl+cPEQLaeQCfUG2rHKkUFs/2zcFHOceN5F6JDzsAn10q bgxDLeKkv7/JAYejmAPKteeS =8aXp -----END PGP SIGNATURE-----

1 0

Internetzugang mit Fritz!Card Classic
by Novomaxx 09 Oct '99

09 Oct '99

Hallo allerseits, Aus irgendeinem Grund komm ich mit SuSE 6.2 nicht online. Ich hab eine Fritz!Card-Classic und eine Realtek RTL 8029, welche beide korrekt konfiguriert sind, eingebaut. Auch bei ipppd d�rfte eigentlich alles in Ordnung sein(jaja, irren ist menschlich). Hier erstmal der Auszug vom Einwahlversuch mit isdnctrl: Oct 9 22:51:56 Shadow isdnlog: Oct 09 22:51:56 tei 65 calling +49 /191700, Germany with +49 2104/809182, Mettmann Normal call clearing (User) Oct 9 22:51:56 Shadow kernel: ippp0: remote hangup Oct 9 22:51:56 Shadow kernel: ippp0: Chargesum is 0 Oct 9 22:51:56 Shadow kernel: ippp, open, slot: 0, minor: 0, state: 0000 Oct 9 22:51:56 Shadow kernel: ippp_ccp: allocating reset data structure Oct 9 22:51:56 Shadow isdnlog: Oct 09 22:51:56 tei 65 calling +49 /191700, Germany with +49 2104/809182, Mettmann HANGUP ( 0:00:04 I=209.0 b O=174.0 b) Oct 9 22:51:56 Shadow ipppd[89]: Modem hangup Oct 9 22:51:56 Shadow ipppd[89]: Connection terminated. Oct 9 22:51:56 Shadow ipppd[89]: taking down PHASE_DEAD link 0, linkunit: 0 Oct 9 22:51:56 Shadow ipppd[89]: closing fd 7 from unit 0 Oct 9 22:51:56 Shadow ipppd[89]: link 0 closed , linkunit: 0 Oct 9 22:51:56 Shadow ipppd[89]: reinit_unit: 0 Oct 9 22:51:56 Shadow ipppd[89]: Connect[0]: /dev/ippp0, fd: 7 Und hier die Ausgabe von ifconfig: Ippp0 Link encap:Point-to-Point Protocol Inet addr:192.168.0.99 P-t-P:195.182.96.29 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MTU:1500 Metric:1 RX packets: 143 errors:0 dropped:0 overruns:0 frame:0 TX packets: 156 errors:12 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:30 Danke erstmal f�r�s Lesen und ich hoffe, Ihr k�nnt mir helfen. Bis dann Markus ===== __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com

1 0

Re: [suse-isdn] bei DoD+Dyn IP te lnet möglich!?
by Leopold Toetsch 09 Oct '99

09 Oct '99

Hi, -----Original Message----- From: Juergen Braukmann <juergen.braukmann(a)ruhr-west.de> To: SuSE ISDN-Liste <suse-isdn(a)suse.com> Date: Samstag, 09. Oktober 1999 10:57 Subject: Re: [suse-isdn] bei DoD+Dyn IP te lnet möglich!? >ja. Das meinte ich. IP auf Halde legen und dann ein script draus machen. >Umgekehrte Reihenfolge. Zu der etwas komplizierten extern Script eine Anmerkung ( sleep 30m ; ipchains -D output -s $LOCALIP -j DENY ) & ist einfacher und uebersichtlicher. >> > > Du kannst Dir sicher fuser und kill ansehen, falls Du >> > > ernsthaftes Interesse hast :> "fuser -n tcp $PORT" gibt Dir >> > > eine PID, IIRC kann fuser wohl auch gleich Signale versenden. Dazu gibt's von mir eine Perlscript auf http://www.toetsch.at/de/tips/linux/99/38.htm Hat bei mir einmal einen haengenden fetch (v. leafnode) entfernt. Holt sicher per netstat offene Verbindungen, stellt mit fuser & ps fest, wer der Uebeltaeter, und killed dann optional das Programm. Comments/Testers welcome. leo

1 0

Zeit-Beschraenkung bei SuSE 6.2??
by freddy.krueger＠t-online.de 09 Oct '99

09 Oct '99

Hallo Liste, nach genau 30Minuten wird die Verbindung getrennt, egal ob Daten übertragen werden oder nicht. Das Problem trat bei vorigen SuSE Ditsris nicht auf. Hab ich da was übersehen??? Cu Freddy

1 0

Internet-Probleme seit Kernel 2.2 Update
by Matthias Walliczek 09 Oct '99

09 Oct '99

Hallo Liste, irgendwie scheint mir der 2.2 Kernel nicht wohlgesonnen zu sein. Es funktioniert zwar alles bestens, nur das Internet nicht mehr... Doch der Reihe nach: Da ich gehört hatte, daß der 2.2-Kernel besonders für Server einen Performance-Gewinn bringt, hatte ich das auf meinem SuSE 6.0 Server mal probeweise 2.2.3 installiert. Anschließend gab es zu meiner Überraschung zunächst keine Probleme, doch der Internet-Zugang funktionierte nicht mehr: Ich erreichte per ping, http, ftp, ... nur noch den PPP-Server von meinem Provider (Internet-Verbindung per ISDN). Ich ging damals davon aus, daß mal vielleicht die neueren ISDN-Utils bräuchte und wartete ab, bis SuSE 6.1 herauskam. Aber auch damit gibt es den gleichen Fehler; und mit dem 2.0-Kernel funktioniert es problemlos. Wo liegt der Fehler? Bye, Matthias

2 2

Re: Re: Subject: [suse-isdn] bei DoD+Dyn IP te lnet möglich!?
by kai 09 Oct '99

09 Oct '99

Hallo Sven, auch erstmal DANKE! On Thu, 30 Sep 1999 14:30:15 +0200, Sven Marth wrote: >Ziel muß es also sein eine Regel aufzusetzen, welche nach dem >automatischen Beenden einer Verbindung alle ausgehenden >Verbindungswünsche mit der, bis dahin gültigen, jetzt aber nicht mehr >gültigen Absender-IP abweist (REJECT ALL) und nach bestimmter Zeit >(30 min dürften reichen) wieder gelöscht wird. >Weiterführende Literatur hierzu findest Du z.B. unter >http://www.little-idiot.de das hört sich prinzipiell noch besser an...da muß ich wohl denn noch reinarbeiten, um mir solch eine Regel zusammenzubasteln um die in ip-down einzufügen. ...bin ich denn der Einzige mit solchen Problemen? Gibts die Regel(n) nicht schon fertig (auf die schnelle hab ich der "idiot"-doku nichts gefunden)? MfG Kai Gülzau

4 7

Wie Verbindung schließen ???
by Markus Koellner 08 Oct '99

08 Oct '99

Hi Liste, ich habe ein kleines Problem, wie wohl viele hier :-)) Nachdem ich mein Netzwerk von Suse 6.0 auf Suse 6.2 aufgerüstet habe, bekomme ich ständig unerwünschte Verbindungen ins Internet. Ich habe eine Dial on Demand Verbindung, das Routing funktioniert auch perfekt, nur der Proxy-Server macht probleme. Nachdem ich im Internet gesurft habe und die Verbindung automatisch geschlossen wird, wie gewünscht, werden vom Proxy-Server, der ein eigener rechner in meinem Netz ist, in 2min-Abständen eine Verbindung aufgebaut. Der Proxy scheint nicht mitzubekommen, daß die Verbindung schon beendet ist und versucht immerwieder zu dem letzten Webserver, den ich im Internet besucht habe eine Verbindung aufzubauen. Dies habe ich durch die messages-Datei rausbekommen, da dort immer auf dem Port 80 anfragen an den letzten Webserver gestellt werden. Der Proxy scheint also noch eine Verbindung (Socket ?) offen zu haben. Wie kann ich das abstellen ??? Ich habe die Squid-Version 2.2.Stable3. Ist das Problem bekannt und eventuell mit einem Update gelöst ? Mit freundlichen Grüßen Markus _________________________________ Markus Köllner

1 0

ISDN / Kernel 2.2.7 / extrem hohe ping Zeiten
by Michael Stumpf 08 Oct '99

08 Oct '99

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo Liste(n), ich habe hier leider immernoch das Problem, daß "sporadisch" die ping-Zeiten zur Gegenstelle (Mobilcom) in astronomische Groessen steigen. Sporadisch bedeutet, dass bei mir zu Hause das Problem erst nach ca. 10x Einwaehlen und einem Tag uptime aufgetreten ist. (Gestern abend) Ich bemerkte auch, dass zu diesem Zeitpunkt unter "top" 80% System!-Time keine Seltenheit waren. Und heute frueh funktionierte es einwandfrei (ohne Neustart, etc. ...System lief einfach weiter). An den Firewall-Regeln kann es nicht liegen, denn ein Accept in In- und Output duerfte wohl nicht soviel Prozessorlast im Kernel verursachen ! Das Problem war ja schon laenger Gespraechsstoff ... gibt es da einen abschliessenden Bugfix ? (oder auch einen vorlaeufigen !?) System: Linux Kernel 2.2.7 (von SuSE 6.1 - CD) ISDN subsystem Rev: 1.72/1.62/1.82/1.45/1.12/1.2 loaded Hardware: mehrere Rechner! vom 486/66 bis zum P200MMX, unterschiedliche ISDN-Karten Hilfesuchend ! cu Michael -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.0.2i iQA/AwUBN+8C7k5aMkHNl+cPEQI9ugCeKRopHiGRM6ehOKrw1H64N9AAXvAAoIB7 W067bt/03MUHVeFr2z/nTeru =3Ozv -----END PGP SIGNATURE-----

2 1

AW: [suse-isdn] bei DoD+Dyn IP te lnet möglich!?
by Burghardt, Axel 08 Oct '99

08 Oct '99

s.u. Gruss Axel >-----Ursprüngliche Nachricht----- >Von: Juergen Braukmann [mailto:juergen.braukmann@ruhr-west.de] >Gesendet am: Donnerstag, 7. Oktober 1999 23:17 >An: SuSE ISDN-Liste >Betreff: Re: [suse-isdn] bei DoD+Dyn IP te lnet möglich!? > >Gerhard Sittig wrote: >> >> On Thu, Oct 07, 1999 at 12:04 +0200, Peter Bossy wrote: >> > >> > Deine Lösung bietet sicherlich schon mal einen guten Ansatz. >> > Aber was macht man wenn man durch Zufall bei der nächsten >> > Anwahl die gleiche IP zugewiesen bekommt? >> >> Das waere ein dummer Zufall. Aber man kann ja in ip-down ALLES >> zur gerade verfallenen IP blockieren und im ip-up die eben >> erhaltene IP freischalten (egal ob vorher gehabt oder nicht). >> > >Stimmt. Diese Runde gehr an Gerhard. ;-)) >Also die IP irgendwo sichern (vorher, ip-down) > >> > Gibt es nicht eine Möglichkeit offene IP-Verbindungen komplett >> > aus dem IP-Stack zu entfernen? >> >> Du kannst Dir sicher fuser und kill ansehen, falls Du ernsthaftes >> Interesse hast :> "fuser -n tcp $PORT" gibt Dir eine PID, IIRC >> kann fuser wohl auch gleich Signale versenden. >> > >Du meinst, wenn ein socket offen ist gibt es irgendwo noch >einen prozess >der nur darauf wartet mit kill -9 gemeuchelt zu werden??? >Und danach ist Ruhe?? Das kann man doch im ip-down "erledigen" >(doppeldeutig!) > >> > > [ ... ip-down mit "ipchains -A" und "sleep 30m; ipchains >-D" ... ] >> >> Kann man da nicht einfach at benutzen? In etwa so (ungetestet): >> >> ... >> ipchains -A output -s $LOCALIP -j DENY >> echo "ipchains -D output -s $LOCALIP -j DENY" | at now + 30 min >> ... >> >> Das hat den Nebeneffekt, dass die Aktion und ihre Ruecknahme >> unmittelbar beieinander stehen. Manche halten sowas fuer >> uebersichtlicher :) Vielleicht muss man noch zur Mailvermeidung >> die Ausgabe nach /dev/null schicken. Und wenn die ipchains-Regel >> von einem folgenden ip-up schon zurueckgenommen wurde, macht der >> at-Jobs eben effektiv nichts mehr und schadet nicht weiter. Wie wäre es denn, anstelle derartiger "wüster" Konstrukte ;-) die einschränkende Grundhaltung zu implementieren? Es werden nur die Verbindungen nach draussen mit Quell-IP $LOCALIP erlaubt. Alles andere (von innen nach aussen über ippp0) wird nicht mit DENY abgewürgt, sondern via REJECT zurückgewiesen. Alles Illegale von aussen nach innen wird jedoch mit DENY geblockt. Was auf jeden Fall verhindert werden sollte ist, dass die Regelbasis bei häufigem Verbindungsauf-/abbau (z.B. beim Surfen mit kurzem Timeout von 30 Sekunden) anwächst, wenn für jede $LOCALIP eine neue DENY- Regel in ppp-down aufgesetzt wird. Das wird im obigen Vorschlag durch die Zeitsteuerung zwar eingeschränkt, lässt sich dennoch nicht ganz verhindern und ermöglicht bei einem angenommenen Timeout von 30 Sekunden theoretisch bis zu 60 DENY-Regeln, die alle ein wenig in der Luft hängen, weil sie in keinem Skript stehen. Dies halte ich persönlich für unschön. Ist aber eher Geschmackssache. Das ganze erinnert mich übrigens an das Problem mit den Verbindungen im Zustand FIN_WAIT1, die bei mir für viele unerwünschte Verbindungs- aufbauten beim Surfen gesorgt haben. Ich habe das über die RECJECTs gelöst. Nach ca. 15 Minuten verschwinden die nicht mehr existenten Verbindungen mit nicht mehr vorhanderner Quell-IP dann endlich. Laut SuSE Support ist das übrigens ein Fehler im Kernel, der wohl auch in 2.2.12 noch nicht behoben ist. >> > >"hält" das ip-down script dann nicht an?? >sorry klar, at. Ziehe Frage zurück. :) >besser als meine variante. ;) > >> virtually yours - Gerhard Sittig >

1 0