On 30.Okt 2002 - 15:48:44, Peter Blancke wrote: > Am 30.10.2002 14:48:47, Andreas Pakulat schrieb: > > > > On 30.Okt 2002 - 14:16:22, Christoph Maurer wrote: > > > Am Mit, 30 Okt 2002 schrieb Andreas Pakulat: > > > > > > > > [ISDN macht nach fetchmail und nachfolgendem isdnctrl hangup > > > > ippp0 wieder Leitung auf] > > > > > > > Bist Du sicher, da� das von innen kommt, [...] > > > > Ja, bin sicher das das von innen kommt, weil n�mlich der > > Verbindungsaufbau schon vollautomatisch geschieht. Ich hole z.B. > > per cronjob und folgendem Skript alle halbe Stunde mails ab: > > isdnctrl dial ippp0 > > fetchmail > > isdnctrl hangup ippp0 > > Spendiere doch mal _unmittelbar_ nach dem Hangup-Befehl den Befehl > > netstat --inet -n > > und zeige die Ausgabe her.
Proto Recv-Q Send-Q Local Address Foreign Address
State
tcp 9168 0 139.30.25.138:34256 80.232.38.131:80
CLOSE_WAIT
udp 0 0 127.0.0.1:32772 127.0.0.1:32772
VERBUNDEN
Das ist zu lesen immer! Auch wenn dialmode auf manual und restart
gemacht.
isdnctrl hangup ippp0 && netstat --inet -n | tee /tmp/netstat
ippp0 hung up
Aktive Internetverbindungen (ohne Server)
Proto Recv-Q Send-Q Local Address Foreign Address
State
tcp 9168 0 139.30.25.138:34256 80.232.38.131:80
CLOSE_WAIT
udp 0 0 127.0.0.1:32772 127.0.0.1:32772
VERBUNDEN
Und das ist nach hangup!
> > Da meine IPPP Devices nicht auf ankommende Anrufe
> > reagieren ist also der Fehler garantiert in meinem System.
>
> Natuerlich reagieren die nicht auf ankommende Daten und von einem
> Dialin-System ist keine Rede.
>
> Vermutlich sind aber nach dem Fetchmail irgendwelche Verbindungen
> noch nicht geschlossen (Anzeige unter o. a. Befehl TIME_WAIT) und
> die fuehren moeglicherweise wieder zur Anwahl.
Im Moment habe ich dialmode auf manual. Sobald ich das zum Testen
umstelle im device.ippp0 und isdnutils restarte geht nach ein paar
Sekunden die Verbindung an! Soweit ich das verstehe kann da eigentlich
kein TIME_WAIT oder �hnliches sein.
Mir ist nochwas aufgefallen, in kern.log wird ja isdn mitgeloggt und da
steht folgendes:
Oct 30 17:05:03 debian kernel: OPEN: 192.168.1.2 -> 192.168.0.1 ICMP
Oct 30 17:05:03 debian kernel: ippp0: dialing 1 019161...
Oct 30 17:05:06 debian kernel: isdn_net: ippp0 connected
Oct 30 17:05:06 debian kernel: isdn_ppp_poll: minor: 128
Kurz nachdem isdnutils restart und dialmode wieder auf auto.
192.168.1.2 ist das localIP von ippp0 in der device.ippp0 und mit
192.168.0.1 hantiere ich hier eigentlich gar nicht.
> Brauchst Du Dial-On-Demand? Alternativ koenntest Du naemlich die
> Anwahl auf "manual" stellen.
Jaein, wenn ich das Problem nicht beheben kann muss ich wohl auf
Dial-On-Demand verzichten. W�rde aber lieber mit arbeiten - wenn man fix
mal was im Netz gucken will muss man sonst immer das dialin veranlassen.
> > Werde aber vielleicht mal das Samba ausmachen und gucken was dann
> > passiert.
>
> Zeige lieber mal die Zeile "interfaces=..." in der smb.conf her.
Hier die Zeile:
interfaces = 192.168.1.1/255.255.255.0
Und das ist meine eth0 (die einzige im PC!) die ipppx Devices liegen auf
192.168.1.2 ...
--
M�tter haben immer recht, das ist ein ungeschriebenes
Gesetz seit Jahrmillionen.
-- Klaus Knopper
msg23232/pgp00000.pgp
Description: PGP signature
