ISDN Einwahl, aber keine Verbindung zum Einwahl Server

[Frank G.]

Hallo zusammen,

ich hoffe, dass ich im richtigen Forum gelandet bin, ansonsten bitte verschieben :roll:

Mein Problem ist, dass ich zwar erfolgreich meine Fritzkarte PCI installieren konnte, eine Einwahl realisieren konnte, aber dennnoch keine Verbindung zum Einwahlserver bekomme.
Jedesmal wenn ich eingewählt bin, geht jeder Versuche, den Debian 3.0 Einwahl Server zu kontaktieren oder das Netzwerk dahinter, ins leere. Es kommt einfach kein Ping/SSH usw durch...
Die Standard Input, Output und Forwarding Regelen sind alle auf Accept, so das dieses Problem nicht mit Iptables zu tun haben sollte.

Woran könnte das liegen, dass ich mich zwar einwählen kann, aber keinerlei Verbindung zu dem Linuxrechner aufbauen kann?
Gruss
Frank

[mistersixt]

Was sagt denn nach dem Einwählen ein "ifconfig -a" bezüglich Deines ippp-Interfaces? Hast Du da eine sinnvolle IP-Adresse (poste mal hier rein)? Und zeig auch mal die Ausgaben von "netstat -rn" und "cat /etc/resolv.conf" !

Gruss, mistersixt.

[Snoopy]

hi und herzlich willkommen im forum

das kann sooooo vieles sein

was sagt den deine

Code: Alles auswählen

/var/log/messages

dazu ?

am besten loggst du dich als root user mal ne konsole ein und lässt dann einen

Code: Alles auswählen

tail -f /var/log/messages

laufen, dann kannst du in echtzeit sehen, was dein isdn evtl anmeckert

evtl meckert er nur die chargesum an

[Frank G.]

Hallo,
und danke für die Antwort :)

Meine messages sagt follgendes bei einem Verbindungsaufbau und einen -abbau, den ich selbst tätige, da ja kein Zugriff auf den Linux Rechner erfolgt:
Mar 18 15:51:25 Hop-ISDN ipppd[1253]: Local number: 30XXXX, Remote number: , Type: incoming
Mar 18 15:51:25 Hop-ISDN ipppd[1253]: PHASE_WAIT -> PHASE_ESTABLISHED, ifunit: 0, linkunit: 1, fd: 9
Mar 18 15:51:25 Hop-ISDN kernel: isdn_net: ippp0 connected
Mar 18 15:51:28 Hop-ISDN ipppd[1253]: Check_passwd called with user=XXXX
Mar 18 15:51:28 Hop-ISDN ipppd[1253]: MPPP negotiation, He: No We: No
Mar 18 15:51:28 Hop-ISDN ipppd[1253]: CCP enabled! Trying CCP.
Mar 18 15:51:28 Hop-ISDN ipppd[1253]: CCP: got ccp-unit 0 for link 1 (Compression Control Protocol)
Mar 18 15:51:28 Hop-ISDN ipppd[1253]: ccp_resetci!
Mar 18 15:51:28 Hop-ISDN ipppd[1253]: ccp_resetci!
Mar 18 15:51:44 Hop-ISDN ipppd[1253]: LCP terminated by peer (_M-|$M-E^@<M-Mt^@^@^@^@)
Mar 18 15:51:44 Hop-ISDN ipppd[1253]: Modem hangup
Mar 18 15:51:44 Hop-ISDN ipppd[1253]: Connection terminated.
Mar 18 15:51:44 Hop-ISDN ipppd[1253]: taking down PHASE_DEAD link 1, linkunit: 1
Mar 18 15:51:44 Hop-ISDN ipppd[1253]: closing fd 9 from unit 1
Mar 18 15:51:44 Hop-ISDN ipppd[1253]: link 1 closed , linkunit: 1
Mar 18 15:51:44 Hop-ISDN ipppd[1253]: reinit_unit: 1
Mar 18 15:51:44 Hop-ISDN ipppd[1253]: Connect[1]: /dev/ippp0, fd: 9
Mar 18 15:51:44 Hop-ISDN kernel: ippp0: remote hangup
Mar 18 15:51:44 Hop-ISDN kernel: ippp0: Chargesum is 0


Das Ifconfig -a, in verbundenen Zustand, sagt genau das selbe, wie einifconfig -a, im nicht verbundenen Zustand... sollte es da Unterschiede zwischen Verbunden und nicht verbunden geben?

eth0 Link encap:Ethernet HWaddr 00:10:4B:6F:D0:7D
inet addr:192.168.0.50 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:17747 errors:0 dropped:0 overruns:0 frame:0
TX packets:7384 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:14311141 (13.6 MiB) TX bytes:1690505 (1.6 MiB)
Interrupt:10 Base address:0xdc00

ippp0 Link encap:Point-to-Point Protocol
inet addr:192.168.10.1 P-t-P:192.168.10.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
RX packets:319 errors:0 dropped:0 overruns:0 frame:0
TX packets:153 errors:8 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:30
RX bytes:18304 (17.8 KiB) TX bytes:3608 (3.5 KiB)

lo der Übersicht wegen lass ich das mal hier weg :)

Wegen der routing funktionalität des Linux Rechners, habe ich dem Ippp0 Interface eine 192.168.10er Adresse verpasst, aber selbst wenn es eine Adresse aus dem selben adressierungs Bereich wie eth0 ist, klappt keine Verbindung.

Netstat -rn zeigte dies:
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.10.2 0.0.0.0 255.255.255.255 UH 40 0 0 ippp0
192.168.0.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0
0.0.0.0 192.168.0.59 0.0.0.0 UG 40 0 0 eth0

Der Rechner mit der 192.168.0.59 ist ein Gateway Rechner mit Flaterate zum Internet.

Ein cat /etc/resolv.conf ergibt den DNS Server der Telekom, welchen ich zum Pakete updaten der Debian Distri brauche:
nameserver 194.25.2.129

Alles in allem hab ich diese Dateien schon mal duchgesehen und keinen Fehler gefunden... logisch, sonst wäre ich jetzt nicht hier am schreiben ;)
Irgendwie kommt mir auch keine Idee, was mein Probelm lösen könnte bzw wo der Fehler liegt. War schon am überlegen, Debian nochmal neu aufzusetzen :lol:
... was aber in endeffekt auch nur eine gebastelte Lösung wäre. Es muss ja schliesslich an etwas liegen. Hoffe es findet jemand einen Lösungsansatz :)

Gruss ins Wochenende
Frank

[Snoopy]

hi

bitte überprüfe mal die einstellung in der <device.ippp0> bei folgendem punkt:

Code: Alles auswählen

# CHARGEHUP FUNCTION
# chargehup name on|off
# Turn on or off hangup before next charge info for interface name. This
# can only be used if the ISDN provider transmits charge info during and
# after the connection. If set to on, the driver will close the
# connection just before the next charge info will  be received if the
# interface is inactive.
# isdnctrl chargehup ${device} on

ich hatte das bei mir einfach auskommentiert (mit #)
aber das hier sollte ebenfalls eine möglichkeit des parameters sein

Code: Alles auswählen

# CHARGEHUP FUNCTION
#  chargehup name on|off
# Turn on or off hangup before next charge info for interface name. This
# can only be used if the ISDN provider transmits charge info during and
# after the connection. If set to on, the driver will close the
# connection just before the next charge info will  be received if the
# interface is inactive.
isdnctrl chargehup ${device} off

einfach die chargehup funktion auf <off> stellen

und dann einfach nochmal eine einwahl probieren

Code: Alles auswählen

isdnctrl dial ippp0

danach evtl trennen

Code: Alles auswählen

isdnctrl hangup ippp0

[Frank G.]

Hallo,

half leider nichts.
Einwählen kann ich mich ja, es wird auch nichts vorzeitig getrennt... nur bekomme ich keinen Connect zu dem Einwahlserver bzw dem LAN dahinter.
Rein ISDN-mäsig sollte alles ok sein, der Fehler muss irgendwie netzwerktechnisch sein. Nur leider finde ich ihn nicht.
Danke für Eure Hilfe, aber ich werd die Debiankiste heute wohl nochmal installieren. Tritt der Fehler dann wieder auf, steh ich hier wieder stramm

[Frank G.]

Hallo nochmals.

Nach dem ich eine zeitlang nicht dazu kam mich um das Problem zu kümmern, habe ich nun die Zeit gefunden und stehe wieder vor einem Problem:
Mittlerweile kann ich mich zwar auf den Linux Rechner einwählen, sprich die Einwahlproblematik ist überwunden, jedoch komme ich nach einer Einwahl nicht in das Netzwerk hinter dem Linux Rechner.

Der Linux Rechner ist in das LAN integriert und auch im LAN erreichbar unter der IP 192.168.0.1/255.255.255.0. Das ISDN Device ist vom LAN aus ebenfalls erreichbar unter:

Code: Alles auswählen

ippp0     Link encap:Point-to-Point Protocol  
          inet addr:192.168.1.1  P-t-P:192.168.1.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          RX packets:634 errors:0 dropped:0 overruns:0 frame:0
          TX packets:395 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:30 
          RX bytes:43449 (42.4 KiB)  TX bytes:35191 (34.3 KiB)

Die Einwahl von aussen auf den Linux Rechner mittels ISDN klappt nun auch wunderbar:

Code: Alles auswählen

May 13 15:25:28 debian kernel: isdn_net: call from 3342XXXXXX,7,0 -> XXXXXX
May 13 15:25:28 debian ipppd[1935]: Local number: XXXXXX, Remote number: , Type: incoming
May 13 15:25:28 debian ipppd[1935]: PHASE_WAIT -> PHASE_ESTABLISHED, ifunit: 0, linkunit: 0, fd: 8
May 13 15:25:28 debian kernel: isdn_net: ippp0 connected
May 13 15:25:29 debian ipppd[1935]: MPPP negotiation, He: No We: No
May 13 15:25:29 debian ipppd[1935]: CCP enabled! Trying CCP. 
May 13 15:25:29 debian ipppd[1935]: CCP: got ccp-unit 0 for link 0 (Compression Control Protocol)
May 13 15:25:29 debian ipppd[1935]: ccp_resetci! 
May 13 15:25:29 debian ipppd[1935]: ccp_resetci! 
May 13 15:25:29 debian ipppd[1935]: local  IP address 192.168.1.1
May 13 15:25:29 debian ipppd[1935]: remote IP address 192.168.1.2

Nach dem die Einwahl abgeschlossen ist, kann ich mich auch mit dem Linux Server mittels SSH oä verbinden. Wahlweise mit der IP der LAN Seite, der 192.168.0.1, oder der IP des ISDN Devices, der 192.168.1.1.
Allerdings ist es mit nicht möglich eine Verbindung zu den Rechnern im LAN aufzubauen.
Zuerst dachte ich, dass es wohl ein Roting Problem ist, jedoch ist Forwarding eingeschaltet:

Code: Alles auswählen

debian:~# sysctl net.ipv4.ip_forward
net/ipv4/ip_forward = 1

Code: Alles auswählen

debian:~# iptables -L -nv
Chain INPUT (policy ACCEPT 13 packets, 1498 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  654 64644 ACCEPT     all  --  eth0   *       0.0.0.0/0            0.0.0.0/0          
  128 12558 ACCEPT     all  --  ippp0  *       0.0.0.0/0            0.0.0.0/0          

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  eth0   *       0.0.0.0/0            0.0.0.0/0          
   22  1490 ACCEPT     all  --  ippp0  *       0.0.0.0/0            0.0.0.0/0          
    0     0 ACCEPT     all  --  *      eth0    0.0.0.0/0            0.0.0.0/0          
    0     0 ACCEPT     all  --  *      ippp0   0.0.0.0/0            0.0.0.0/0          
    0     0 ACCEPT     all  --  *      *       10.0.0.0/24          192.168.0.0        

Chain OUTPUT (policy ACCEPT 13 packets, 1498 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  394  301K ACCEPT     all  --  *      eth0    0.0.0.0/0            0.0.0.0/0          
   57  6004 ACCEPT     all  --  *      ippp0   0.0.0.0/0            0.0.0.0/0 

Die Test Firewall:

Code: Alles auswählen

$IPTABLES -P INPUT ACCEPT
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -P FORWARD ACCEPT

Dann kontrollierte ich mittels "ipconfig" die Daten auf den Winrechner, mit dem ich mich einwähle und stiess auf folgendes:

Code: Alles auswählen

PPP-Adapter  "Windows - XXXXXX":

        Verbindungsspezifisches DNS-Suffix:
        IP-Adresse. . . . . . . . . . . . : 192.168.1.2
        Subnetzmaske. . . . . . . . . . . : 255.255.255.255
        Standardgateway . . . . . . . . . : 192.168.1.2

Die vergebene IP Adresse und der vergebene Standardgateway sind identisch, was mich etwas stutzig macht. Kann dies schon der Fehler sein?
Allerdings fand ich bis jetzt noch keine Möglichkeit unter den Linux ISDN Konfigurationen den Standardgateway zu ändern.

Ich weiss momentan echt nicht mehr, woran es liegen kann, das ich zwar auf den Linux Server zugreifen kann, aber nicht auf das dahinter liegende LAN.
Hoffe das mir jemand von Euch weiterhelfen kann...