Leidiges Thema - DSL mit Debian 3.0 - keine Rettung?

[Johnny]

Hey ...

ich bekomme unter Debian 3.0 keine DSL Verbindung zustande. Habe jetzt den ganzen Mittag rumgesurft um dem Fehler auf die schliche zu kommen ... aber nichts gefunden.

Ich habe seit 4 Jahren ein DSL Router unter Suse 6.4 laufen, will ihn jetzt aber neu aufsetzen mit Debian 3.0. Doch Leider will daraus nichts werden.

Anstatt Verbindung herzustellen bringt er "LCP: timeout sending Config-Requests" Meldung im syslog:

Code: Alles auswählen

#pon dsl-provider

May 16 18:49:46 venus pppd[366]: pppd 2.4.1 started by root, uid 0
May 16 18:49:46 venus pppd[366]: Using interface ppp0
May 16 18:49:46 venus pppd[366]: Connect: ppp0 <--> /dev/pts/1
May 16 18:50:17 venus pppd[366]: LCP: timeout sending Config-Requests
May 16 18:50:17 venus pppd[366]: Connection terminated.
May 16 18:50:17 venus pppd[366]: Exit.

So nun mal zu den Infos:

Ich hab den Kernel vom kernel-image-2.4.18-bf2.4 laufen. Die beiden RealTek RTL8139 Netzwerkkarten laufen normal mit dem 8139too modul.

Code: Alles auswählen

#ifconfig

eth0      Link encap:Ethernet  HWaddr 00:E0:7D:AF:**:**
          inet addr:192.168.2.22  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1776 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2261 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:175253 (171.1 KiB)  TX bytes:219565 (214.4 KiB)
          Interrupt:10 Base address:0xc000

eth1      Link encap:Ethernet  HWaddr 00:30:84:0C:**:**
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:52 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:3120 (3.0 KiB)  TX bytes:1484 (1.4 KiB)
          Interrupt:12 Base address:0xe000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

Verbindung wurde erfolgreich konfiguriert mit pppoeconf.

dsl-provider:

Code: Alles auswählen

#pty "pppoe -I eth1 -T 80"
pty "pppoe -I eth1 -T 80 -m 1452"
#pty "pppoe -I eth1 -T 80 -m 1412"
noauth
defaultroute
user "00...24#0001@t-online.de"
usepeerdns

Das Modem ist OK. LAN/eth1 Verbindung zum Modem auch:

Code: Alles auswählen

#pppoe -A -I eth1

Access-Concentrator: STGX11-erx
Got a cookie: 5a 99 ea d4 78 b4 b3 5f e3 4f 82 f6 42 0b ** **
--------------------------------------------------
AC-Ethernet-Address: 00:90:1a:10:**:**
--------------------------------------------------

Das Problem muss in der Software stecken.

Ich habe gelesen das man verschiedene module braucht, pppoe pppox habe ich nichts bei mir gefunden und deswegen nachinstalliert.(ich hoffe richtig) Die beiden Kernelmodule habe ich mir einfach von http://www.li.nux.org.uk/debianmodules.html geholt.

Das sieht nun so aus:

Code: Alles auswählen

#lsmod

Module                  Size  Used by    Not tainted
ppp_async               6464   0  (unused)
pppoe                   6752   0  (unused)
pppox                   1080   1  [pppoe]
ppp_synctty             4960   0  (autoclean)
ppp_generic            18728   0  (autoclean) [ppp_async pppoe pppox ppp_synctty]
slhc                    4432   0  (autoclean) [ppp_generic]

Ich weiß nicht weiter ... ich hoffe jemand kann mir helfen

[Bert]

Hast Du pppoeconf zum Einrichten verwendet? Damit funktioniert es eigentlich immer ganz gut. Module brauchst Du keine zusätzlichen. Debian und der Standardkernel bringen alles notwendige mit.

[chimaera]

willkommen auf df.de..

Verbindung wurde erfolgreich konfiguriert mit pppoeconf.

http://www.adsl4linux.de/howtos/rp-pppo ... DIST=Deb30

[Johnny]

Danke für den Link.
Bin eben nochmal alles mit der "Konfigurations-Anleitung von Hand" durchgegangen. Alles richtig ... aber geht immer noch nicht. DSL-Modem reset brachte auch nichts.

Noch zwei sachen zur Info:

Auszug vom syslog beim Verbindungsversuch:

Code: Alles auswählen

May 16 21:51:39 venus kernel: CSLIP: code copyright 1989 Regents of the University of California
May 16 21:51:39 venus kernel: PPP generic driver version 2.4.1
May 16 21:51:39 venus pppd[377]: pppd 2.4.1 started by root, uid 0
May 16 21:51:39 venus kernel: eth1: Setting half-duplex based on auto-negotiated
 partner ability 0000.
May 16 21:51:39 venus pppd[377]: Serial connection established.
May 16 21:18:46 venus pppd[337]: using channel 1
May 16 21:18:46 venus pppd[337]: Using interface ppp0
May 16 21:18:46 venus pppd[337]: Connect: ppp0 <--> /dev/pts/1
May 16 21:18:46 venus pppoe[338]: PADS: Service-Name: ''
May 16 21:18:46 venus pppoe[338]: PPP session is 7051
May 16 21:18:47 venus pppd[337]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3695ac74>]
May 16 21:18:47 venus pppd[337]: rcvd [proto=0x7eff] 7d 23 c0 21 7d 21 99 7d 20 7d 32 7d 21 7d 24 7d 25 d4 7d 23 7d 24 c0
 23 7d 25 7d 26 7d 3c 7d 37 ...
......(x mal wiederholt)
May 16 21:19:14 venus pppd[337]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3695ac74>]
May 16 21:19:15 venus pppd[337]: rcvd [proto=0x7eff] 7d 23 c0 21 7d 21 a2 7d 20 7d 32 7d 21 7d 24 7d 25 d4 7d 23 7d 24 c0
 23 7d 25 7d 26 7d 3c 7d 37 ...
May 16 21:19:17 venus pppd[337]: LCP: timeout sending Config-Requests
May 16 21:19:17 venus pppd[337]: Connection terminated.
May 16 21:19:17 venus pppd[337]: Waiting for 1 child processes...
May 16 21:19:17 venus pppd[337]:   script pppoe -I eth1, pid 338
May 16 21:19:17 venus pppoe[338]: read (asyncReadFromPPP): Input/output error
May 16 21:19:17 venus pppoe[338]: Sent PADT
May 16 21:19:17 venus pppd[337]: Script pppoe -I eth1 finished (pid 338), status = 0x1
May 16 21:19:17 venus pppd[337]: Exit.

Wenn kein Verbindung zum DSL Modem besteht dann bekommt man kein "rcvd [proto=0x7eff] 7d 23 c0 21 7d 21 a2 7d 20 7d 32 7d 21 7d 24 7d 25 d4 7d 23 7d 24 c0
23 7d 25 7d 26 7d 3c 7d 37 ..." Also gibt es eine Verbindung. Ist vielleicht nur die Benutzerkennung falsch? Hab ich zwar mehrmals überprüft und direkt vom alten Router übernommen aber... gibt es eine andere Fehlermeldung bei Falscher Kennung/PW ?

Ich denke es ist normal das pppd die Netzwerkkarte als half-duplex einbaut und nicht als full-deplex!?

Und pppd läd von alleine folgende Module dabei:
ppp_synctty
ppp_generic
slhc

[pdreker]

Hmmm... Ich habe zwar leider keinen genauen Tipp, aber irgendwie versteht Dein Router die Gegenstelle nicht. An den Stellen mit den ganzen Hex Zahlen sollte eigentlich sowas wie "Rcvd: LCP ConfNACK: ... (ähnlich wie in den ConfReq Zeilen)". Aus irgendeinem Grund kommt bei Dir nur "Gemüse" an, was dann natürlich das Aushandeln der Verbindungsparameter verhindert...

Patrick

[Arne2002]

könnte das mit der MTU zusammenhängen?
spontaner gedanke, wahrscheinlich vollig falsch,aber nen versuch wars wert

[Johnny]

Nein hat nichts mit MTU zu tun, das einwählen sollte unabhängig von der MTU funktionieren.

Danke für eure Aufmerksamkeit ... aber ich habe eben den fehler gefunden:

Code: Alles auswählen

Invalid GRE packets transmitted by server
Symptom: GRE packets are emitted by the client, GRE packets are returned by the server, but the client makes no sense of them, reporting in the debug log the following asynchronous PPP packet:

rcvd [proto=0x7eff] 7d 23 c0 21 7d 21 7d 21 7d 20 7d 39 7d 22 ...]
 
Diagnosis: you may be running pppd with the sync option, with a version of the GRE-to-PPP gateway that will recognise sync mode, but the server is returning asynchronous responses.

Solution: turn off sync and try again.

Kurz gesagt es stand "sync" in /etc/ppp/options. Bin mir gerade nicht sicher wie das da hingekommen ist

Gefunden habe ich das in einem schicken PPTP Client Diagnosis HOWTO

Danke trotzdem