Hi @all,
habe ein RIESEN Problem !!
Habe folgende Meldung beim Verbinden mit dem Internet:
SuSE Meta pppd (smpppd), Version 0.78 on btxdtagde.
wwwoffle not is running
Selection of interface/provider "dsl0"/"DSL provider" succeeded.
Starting connection. (2002-11-17 21:38:56 CET)
pppd: Plugin pppoe.so loaded.
pppd: PPPoE Plugin Initialized
pppd: Plugin passwordfd.so loaded.
pppd: Sending PADI
Waiting for PADO. Please check your setup and try again
Habe eine Standard Realtek82x Karte und eine LAN Karte OnBoard. Ich kann machen was ich will, DSL funzt nicht !!
Habe bereits seit Stunden gegoogelt und hier auch die Suche benutzt. So wirklich hilfreich sind die anderen Themen, welche dieses Thema betrifft, leider nicht !!!
Folgendes habe ich bereits gemacht:
1. SuSe neu installiet
2. OnmBoard Karte deaktiviert
3. Seit Stunden alle möglichen Verbindungen getestet. ( Einmal mit IP einmal ohne usw. )
Anscheinend ist es ein Problem welches mit dem ACPI zu tun hat. Zumindest ist das unter SuSe beschrieben. Hilft aber auch nicht weiter !!!
Es handelt sich anscheinend auch um ein Standardproblem, da es in sehr vielen Foren besprochen wird und bisher eigentlich keine Richtige Lösung bei rausgekommen ist !!!
EDIT:
1. Die Benutzerdaten stimmen
2. Die richtige Netzwerkkarte ist gewählt ( Habe auch die andere Testweise im Bios deaktiviert )
3. Mit keinen der beiden Karten funzt es !!
4. Mit der SuSe 8.0 Version hat es auf anhieb einwandfrei funktioniert !!!
Hat noch jemand eine Idee ???
THX für euere Mühe
T-DSL unter SuSe8.2
-
Descartes
Re: T-DSL unter SuSe8.2
>
> pppd: Sending PADI
> Waiting for PADO. Please check your setup and try again
>
Was für ein Glück für Dich, dass ich gerade heute morgen im Internet über einen passenden Artikel gestolpert bin.
Auf <<a href="http://www.ruhr.de/home/nathan/FreeBSD/ ... html#DEBUG>" target="_blank"><!--auto-->http://www.ruhr.de/home/nathan/FreeBSD/ ... <!--auto--> wird zwar das ganze für FreeBSD beschrieben, aber zumindest die Fehlerbilder und -suche unterscheiden sich ja nicht sonderlich.
<blockquote><hr>
Der erste Schritt ist, auf dem für PPPoE genutzen Ethernet-Interface tcpdump(1) zu starten. Um Probleme durch einen nicht vorhandenen oder falsch konfigurierten Namenserver auszuschließen, sollte man tcpdump(1) immer mit dem Parameter -n starten:
# tcpmdump -ni PPPoE-Interface
Das PPPoE-Interface ist das Interface, an dem das DSL Modem hängt.
Nun startet man in der zweiten Shell einen T-DSL Verbindungsbaufbau:
In der tcpdump(1)-Shell sollte der Aufbau der PPPoE-Verbindung erscheinen. Im Original steht jede der Meldung in einer überlangen Zeile, die jeweils mit einem timestamp beginnt. Um die Lesbarkeit zu verbessern, wurden die timestamps entfernt.
PPPoE PADI [Service-Name] [Host-Uniq UTF8] ...(1)...
PPPoE PADO [Service-Name] [Host-Uniq UTF8] [AC-Name "DTMC11-nrp1"] [AC-Cookie UTF8] ...(2)...
PPPoE PADR [Service-Name] [AC-Cookie UTF8] [AC-Name "DTMC11-nrp1"] [Host-Uniq UTF8] ...(3)...
PPPoE PADS [ses 0x5620] [Service-Name] [AC-Cookie UTF8] [AC-Name "DTMC11-nrp1"] [Host-Uniq UTF8] ...(4)...
PPPoE [ses 0x5620] LCP ConfReq [...] ...(5)...
Erklärung:
...(1)...Unser Rechner schickt per Broadcast eine Inquiry, er sucht einen PPPoE-Server.
...(2)...Der Access Concentrator der Telekom schickt als Antwort eine Service-Offer an uns. Es ist theoretisch möglich, daß hier mehr als eine Antwort kommt, sobald es mehr als einen Anbieter gibt.
...(3)...Unser Rechner schickt jetzt einen Service-Request an den Access-Concentrator.
...(4)...Der Access-Concentrator eröffnet eine PPPoE-Session mit uns und weißt ihr die Nummer 0x5260 zu.
...(5)...Ab hier wird PPPoE schon als Transportmedium genutzt. Bei einem Modem würde jetzt die LED "Carrier Detect" leuchten. Diese Zeile enthält übrigens den Start des PPP-Handshakes.
Wenn die Sequenz PADI, PADO, PADR, PADS durchläuft, und danach das PPP-Handshake beginnt, ist die Verbindung zur Telekom in Ordnung.
Wenn kein PADI erscheint, sollte man die Netzwerkkarte, die Verbindung zum NTBBA prüfen und die device-Zeile der ppp.conf prüfen. Das Problem kann zwar auch durch den NTBBA verursacht werden, aber das ist extrem selten.
<b>Wenn auf das PADI kein PADO folgt, liegt der Fehler sehr wahrscheinlich bei Telekom. Dann hilft nur noch der Anruf bei der Störungsstelle.</b>
Folgt auf das PADO kein PADR, ist irgendwas im Kernel ganz böse kaputt. Dieses Problem wurde bisher nur in ganz bestimmten Versionen von 5.0-current auf und war die Folge eines Fehlers in der Netgraph-Node ng_ether(4).
Folgt auf das PADR kein PADS, liegt das Problem wahrscheinlich auch bei der Telekom. Dieser Fall scheint in der Praxis aber noch nie aufgetreten zu sein.
<hr></blockquote>
<blockquote><hr>
Eines der häufigeren Probleme ist, daß auf unsere PADI kein PADO folgt:
PPPoE PADI [Service-Name] [Host-Uniq UTF8]
PPPoE PADI [Service-Name] [Host-Uniq UTF8]
PPPoE PADI [Service-Name] [Host-Uniq UTF8]
[ca. 10 Mal, danach ist Stille]
Es gibt leider mehrere verschiedene Gründe für diesen Zustand. Zunächst sollte man die eigene Verkabelung testen und den NTBBA kurzzeitig komplett entkabeln. Wenn sich dann immer noch nichts tut, hilft nur der Griff zum Telefonhörer und der Anruf bei der Störungsstelle der Telekom.
<hr></blockquote>
> pppd: Sending PADI
> Waiting for PADO. Please check your setup and try again
>
Was für ein Glück für Dich, dass ich gerade heute morgen im Internet über einen passenden Artikel gestolpert bin.
Auf <<a href="http://www.ruhr.de/home/nathan/FreeBSD/ ... html#DEBUG>" target="_blank"><!--auto-->http://www.ruhr.de/home/nathan/FreeBSD/ ... <!--auto--> wird zwar das ganze für FreeBSD beschrieben, aber zumindest die Fehlerbilder und -suche unterscheiden sich ja nicht sonderlich.
<blockquote><hr>
Der erste Schritt ist, auf dem für PPPoE genutzen Ethernet-Interface tcpdump(1) zu starten. Um Probleme durch einen nicht vorhandenen oder falsch konfigurierten Namenserver auszuschließen, sollte man tcpdump(1) immer mit dem Parameter -n starten:
# tcpmdump -ni PPPoE-Interface
Das PPPoE-Interface ist das Interface, an dem das DSL Modem hängt.
Nun startet man in der zweiten Shell einen T-DSL Verbindungsbaufbau:
In der tcpdump(1)-Shell sollte der Aufbau der PPPoE-Verbindung erscheinen. Im Original steht jede der Meldung in einer überlangen Zeile, die jeweils mit einem timestamp beginnt. Um die Lesbarkeit zu verbessern, wurden die timestamps entfernt.
PPPoE PADI [Service-Name] [Host-Uniq UTF8] ...(1)...
PPPoE PADO [Service-Name] [Host-Uniq UTF8] [AC-Name "DTMC11-nrp1"] [AC-Cookie UTF8] ...(2)...
PPPoE PADR [Service-Name] [AC-Cookie UTF8] [AC-Name "DTMC11-nrp1"] [Host-Uniq UTF8] ...(3)...
PPPoE PADS [ses 0x5620] [Service-Name] [AC-Cookie UTF8] [AC-Name "DTMC11-nrp1"] [Host-Uniq UTF8] ...(4)...
PPPoE [ses 0x5620] LCP ConfReq [...] ...(5)...
Erklärung:
...(1)...Unser Rechner schickt per Broadcast eine Inquiry, er sucht einen PPPoE-Server.
...(2)...Der Access Concentrator der Telekom schickt als Antwort eine Service-Offer an uns. Es ist theoretisch möglich, daß hier mehr als eine Antwort kommt, sobald es mehr als einen Anbieter gibt.
...(3)...Unser Rechner schickt jetzt einen Service-Request an den Access-Concentrator.
...(4)...Der Access-Concentrator eröffnet eine PPPoE-Session mit uns und weißt ihr die Nummer 0x5260 zu.
...(5)...Ab hier wird PPPoE schon als Transportmedium genutzt. Bei einem Modem würde jetzt die LED "Carrier Detect" leuchten. Diese Zeile enthält übrigens den Start des PPP-Handshakes.
Wenn die Sequenz PADI, PADO, PADR, PADS durchläuft, und danach das PPP-Handshake beginnt, ist die Verbindung zur Telekom in Ordnung.
Wenn kein PADI erscheint, sollte man die Netzwerkkarte, die Verbindung zum NTBBA prüfen und die device-Zeile der ppp.conf prüfen. Das Problem kann zwar auch durch den NTBBA verursacht werden, aber das ist extrem selten.
<b>Wenn auf das PADI kein PADO folgt, liegt der Fehler sehr wahrscheinlich bei Telekom. Dann hilft nur noch der Anruf bei der Störungsstelle.</b>
Folgt auf das PADO kein PADR, ist irgendwas im Kernel ganz böse kaputt. Dieses Problem wurde bisher nur in ganz bestimmten Versionen von 5.0-current auf und war die Folge eines Fehlers in der Netgraph-Node ng_ether(4).
Folgt auf das PADR kein PADS, liegt das Problem wahrscheinlich auch bei der Telekom. Dieser Fall scheint in der Praxis aber noch nie aufgetreten zu sein.
<hr></blockquote>
<blockquote><hr>
Eines der häufigeren Probleme ist, daß auf unsere PADI kein PADO folgt:
PPPoE PADI [Service-Name] [Host-Uniq UTF8]
PPPoE PADI [Service-Name] [Host-Uniq UTF8]
PPPoE PADI [Service-Name] [Host-Uniq UTF8]
[ca. 10 Mal, danach ist Stille]
Es gibt leider mehrere verschiedene Gründe für diesen Zustand. Zunächst sollte man die eigene Verkabelung testen und den NTBBA kurzzeitig komplett entkabeln. Wenn sich dann immer noch nichts tut, hilft nur der Griff zum Telefonhörer und der Anruf bei der Störungsstelle der Telekom.
<hr></blockquote>
-
MUpper
Re: T-DSL unter SuSe8.2
Ok nach ewigem testen habe ich es nun herausgefunden. Liegt an der ACPI Ansteuerung !!
Einfach im Bootmanager eingeben:
pci=noacpi ( Dieser Parameter schaltet das PCI IRQ-Routing vom neuen ACPI-System aus )
Und schon funktioniert es einwandfrei
Vielleicht hilft es ja dem einen oder anderen weiter, der das Problem auch hat !!
Einfach im Bootmanager eingeben:
pci=noacpi ( Dieser Parameter schaltet das PCI IRQ-Routing vom neuen ACPI-System aus )
Und schon funktioniert es einwandfrei
Vielleicht hilft es ja dem einen oder anderen weiter, der das Problem auch hat !!
-
Descartes
Re: T-DSL unter SuSe8.2
Haben die Nürnberger Deppen (Tschuldigung, aber es muss mal so gesagt werden) denn aus SuSE 8.1 nichts gelernt und schon wieder den Distributions-Standardkernel mit ACPI Unterstützung gebaut?
Man fasst es nicht.
Bereits mit SuSE 8.1 gab es Probleme, weil der darin enthaltene Standardkernel Probleme verursacht hat. Auch damals war die Ursache, dass der Kernel mit ACPI Unterstützung gebaut wurde und scheinbar ettliche Mainboard noch immer nicht 100%ig mit ACPI zu Wege kommen (oder aber, der Linux Kernel kann kein gescheites ACPI?).
Bei RedHat hat man in den letzten Betas (8.1.9x) ebenfalls den Kernel mit ACPI Unterstützung gebaut, allerdings wurde während der Beta-Phase deutlich, dass es *mit* ACPI mehr Probleme gibt. Deswegen wurde der Kernel der aktuellen (bzw. demnächst erscheinenden) RedHat 9 wieder *ohne* ACPI Unterstützung kompiliert. Wer ACPI benötigt, kann sich ja bei Bedarf seinen Kernel selber backen.
Man fasst es nicht.
Bereits mit SuSE 8.1 gab es Probleme, weil der darin enthaltene Standardkernel Probleme verursacht hat. Auch damals war die Ursache, dass der Kernel mit ACPI Unterstützung gebaut wurde und scheinbar ettliche Mainboard noch immer nicht 100%ig mit ACPI zu Wege kommen (oder aber, der Linux Kernel kann kein gescheites ACPI?).
Bei RedHat hat man in den letzten Betas (8.1.9x) ebenfalls den Kernel mit ACPI Unterstützung gebaut, allerdings wurde während der Beta-Phase deutlich, dass es *mit* ACPI mehr Probleme gibt. Deswegen wurde der Kernel der aktuellen (bzw. demnächst erscheinenden) RedHat 9 wieder *ohne* ACPI Unterstützung kompiliert. Wer ACPI benötigt, kann sich ja bei Bedarf seinen Kernel selber backen.