26774
12.03.2006, aktualisiert am 13.03.2006
4514
9
0
Suse 10 - externe MySQL Problme mit D-Link Router
Moins.
Bescheuertes Problem: Ich mache jetzt seit vierTagen mit einem neuen D-Link 664T Router rum. Ganz der Neuling bin ich auch nicht mehr, aber hier gebe ich echt den Löffel ab:
Es funktioniert alles hervorragend, Top-Verteilung, Top-Einrichtung , alles klar.
Ich habe für Programmierarbeiten einen kleinen Konstruktions-Webserver in Betrieb - auf Suse 10.
Auf diesem Server werden nur PHP-Skripte geparst, die Daten kommen direkt von der Kundendatenbank auf dem entfernten Server.
Seit ich den D-Link dran habe, verbinden sich meine MySQL-Scripte nicht mehr mit den Datenbanken[ " mysl_connection lost" ]. Ich hatte vorher einen Zyxel-Router - da war das nie ein Problem - aber nach 5 1/2 jahren wollte ich mal die Technik updaten, jetzt habe ich den Salat [ *Flenn - früher war alles besser*].
Ich habe auch schon alles mögliche versucht mit Regeln und Forwarding - nichts.
Um mal eine Gegenprobe zu haben, habe ich folgendes gemacht:
ich habe auf einem anderen Rechner (WIndows) einfach mal den Apachefriends MiniServer aufgesetzt. Von hier aus funktioniert es wie gewohnt, DB-Inhalte werden abgefragt, Miniserver parst PHP, fertig.
Was mich stutzig macht:
[*] Testrechner Windows -> funktioniert
[*] Testrechner Suse 10 -> funktioniert nicht
Kann das was mit NAT zu tun haben ? (kenne ich mich überhaupt nicht mit aus).
Über den Windows Rechner bekomme ich auch über telnet Kontakt [ also 'TELENET www.myHost.de 3306'] mit der üblichen Ausgabe von Server OS und bischen kryptischen Werten.
Von SUSE aus kommt nichts. Aber: voller Internetzugang, Browser, Email, FTP was ich grade will. Nur: er verbindet die DB-Connect Scripte nicht .
Am Router habe ich für keinen von beiden Rechner eine Konf vorgenommen.
Gibt es irgendeine Idee , was das sein kann?
Bescheuertes Problem: Ich mache jetzt seit vierTagen mit einem neuen D-Link 664T Router rum. Ganz der Neuling bin ich auch nicht mehr, aber hier gebe ich echt den Löffel ab:
Es funktioniert alles hervorragend, Top-Verteilung, Top-Einrichtung , alles klar.
Ich habe für Programmierarbeiten einen kleinen Konstruktions-Webserver in Betrieb - auf Suse 10.
Auf diesem Server werden nur PHP-Skripte geparst, die Daten kommen direkt von der Kundendatenbank auf dem entfernten Server.
Seit ich den D-Link dran habe, verbinden sich meine MySQL-Scripte nicht mehr mit den Datenbanken[ " mysl_connection lost" ]. Ich hatte vorher einen Zyxel-Router - da war das nie ein Problem - aber nach 5 1/2 jahren wollte ich mal die Technik updaten, jetzt habe ich den Salat [ *Flenn - früher war alles besser*].
Ich habe auch schon alles mögliche versucht mit Regeln und Forwarding - nichts.
Um mal eine Gegenprobe zu haben, habe ich folgendes gemacht:
ich habe auf einem anderen Rechner (WIndows) einfach mal den Apachefriends MiniServer aufgesetzt. Von hier aus funktioniert es wie gewohnt, DB-Inhalte werden abgefragt, Miniserver parst PHP, fertig.
Was mich stutzig macht:
[*] Testrechner Windows -> funktioniert
[*] Testrechner Suse 10 -> funktioniert nicht
Kann das was mit NAT zu tun haben ? (kenne ich mich überhaupt nicht mit aus).
Über den Windows Rechner bekomme ich auch über telnet Kontakt [ also 'TELENET www.myHost.de 3306'] mit der üblichen Ausgabe von Server OS und bischen kryptischen Werten.
Von SUSE aus kommt nichts. Aber: voller Internetzugang, Browser, Email, FTP was ich grade will. Nur: er verbindet die DB-Connect Scripte nicht .
Am Router habe ich für keinen von beiden Rechner eine Konf vorgenommen.
Gibt es irgendeine Idee , was das sein kann?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 27982
Url: https://administrator.de/contentid/27982
Ausgedruckt am: 22.11.2024 um 16:11 Uhr
9 Kommentare
Neuester Kommentar
Hi,
so, wie Du das beschreibst, würde ich auf ein Firewall Problem tippen, bleibt nur die Frage,
ob es die Firewall von SuSE ist oder die im Router eingebaute.
Ich würde aber, da der telnet nach "draussen" vom Windows Rechner aus auch nicht
funktioniert, eher auf den Router tippen, schau Dir mal folgende Seite an,
die ist zwar für den D-Link 604T, dürfte aber bei Deinem Modell ähnlich sein (für den 664T gab
es leider nichts auf dieser Seite):
http://www.portforward.com/english/routers/port_forwarding/Dlink/DSL-G6 ...
Alternativ kannst Du Deinen Linux Rechner (also dessen lokale IP) mal in die DMZ des Routers
testweise eintragen, wenn es dann klappt, liegt das Problem am DSL Router, ansonsten
ist bei der SuSE FIrewall noch was falsch eingestellt.
Gruß
cykes
so, wie Du das beschreibst, würde ich auf ein Firewall Problem tippen, bleibt nur die Frage,
ob es die Firewall von SuSE ist oder die im Router eingebaute.
Ich würde aber, da der telnet nach "draussen" vom Windows Rechner aus auch nicht
funktioniert, eher auf den Router tippen, schau Dir mal folgende Seite an,
die ist zwar für den D-Link 604T, dürfte aber bei Deinem Modell ähnlich sein (für den 664T gab
es leider nichts auf dieser Seite):
http://www.portforward.com/english/routers/port_forwarding/Dlink/DSL-G6 ...
Alternativ kannst Du Deinen Linux Rechner (also dessen lokale IP) mal in die DMZ des Routers
testweise eintragen, wenn es dann klappt, liegt das Problem am DSL Router, ansonsten
ist bei der SuSE FIrewall noch was falsch eingestellt.
Gruß
cykes
[ *Flenn - früher war alles besser*].
Never change a running system 
Prüf mal die SuseFirewall. Daran könnte es schon hängen. Für weitergehende Analysen müsste ich schon genau wissen, wie das Netz aussieht, also was wo steht.
Aber in den meisten Fällen blockt die Susefirewall.
versuch mal einen Traceroute auf die DB-Kiste abzusetzen:
traceroute -p 3306 dbserver
Wenn Du Zugriff auf den Kundenserver hast, guck mal in den Logs, ob überhaupt Zugriffsversuche stattfinden.
Auch tcpdump kann hilfreich sein:
tcpdump -w logfile.dmp host dbserver
Das angelegte Logfile kannst Du dann z.B. mit ethereal auswerten. Hier erkennst Du dann, was genau an Paketen hin- und herfliegt.
Ein Problem, das ich einmal mit der Verbindung zu einem MySQL-Server hatte, war die Zeit, die der Client für den Verbindungsaufbau benötigte. Als ich den Timeout auf über 10 Sekunden(!) gesetzt hatte, klappte die Verbindung dann. Ich habe, gerade weil es sich um ein temporäres Problem handelte, nicht weiter nach Gründen dafür gesucht, vermute aber, dass es sich um Schwierigkeiten handelte, die mit der Fragmentierung der IP-Pakete zu tun hatten. Dann würde die Anpassung des MTU-Wertes des Linux-Rechners an die Größe, die durch den Router bei der Online-Verbindung benutzt wird, wahrscheinlich Abhilfe schaffen.
Hoffe, wenigstens eine dieser Ideen bringt Dich weiter ;)
Gruss
Stefan
traceroute -p 3306 dbserver
Wenn Du Zugriff auf den Kundenserver hast, guck mal in den Logs, ob überhaupt Zugriffsversuche stattfinden.
Auch tcpdump kann hilfreich sein:
tcpdump -w logfile.dmp host dbserver
Das angelegte Logfile kannst Du dann z.B. mit ethereal auswerten. Hier erkennst Du dann, was genau an Paketen hin- und herfliegt.
Ein Problem, das ich einmal mit der Verbindung zu einem MySQL-Server hatte, war die Zeit, die der Client für den Verbindungsaufbau benötigte. Als ich den Timeout auf über 10 Sekunden(!) gesetzt hatte, klappte die Verbindung dann. Ich habe, gerade weil es sich um ein temporäres Problem handelte, nicht weiter nach Gründen dafür gesucht, vermute aber, dass es sich um Schwierigkeiten handelte, die mit der Fragmentierung der IP-Pakete zu tun hatten. Dann würde die Anpassung des MTU-Wertes des Linux-Rechners an die Größe, die durch den Router bei der Online-Verbindung benutzt wird, wahrscheinlich Abhilfe schaffen.
Hoffe, wenigstens eine dieser Ideen bringt Dich weiter ;)
Gruss
Stefan
Also erstmal 'Danke' für die regen Beiträge. Ich habe alleine dadurch schon wieder eine Menge gelernt, auch wenn das Problem nicht gelöst ist.
@cykes: Das ist ein Missverstaändnis: von Windows aus geht es ja, das ist ja das seltsame.
Folgendes habe ich versucht:
<li>SuSE Firewall abgeschaltet</li>
<li>Router resettet /neu eingerichtet</li>
<li>SuSE IP-Adresse (lokale) in DMZ eingetragen</li>
<li>MTU 1454 des Routers bei MTU SuSE eingetragen (inklusive Neustart)</li>
Hilft alles nicht.
Von Windows aus gehts, von Suse aus nicht [ ] -> echt spinnert.
Ich wede Morgen auf jeden Fall mal die D-Link Hotline befragen, aber erfahrungsgemäss wird das nichts bringen.
Bin aber nach wie vor für "jedes technische Experiment " zu haben.
Das kleine Netzwerk ist nicht kompliziert:
Router: 192.168.1.1
Switch1 ->
Erster Rechner im ersten Stock (Frau): 192.168.1.2
Zweiter Rechner im ersten Stock (Sohn): 192.168.1.3
Up-Link in den zweiten Stock -> Kabel an Hauswand hoch []
Switch 2 ->
Rechner 1 (Arbeitsplatz/Windows) : 192.168.1.10
Rechner 2 (Verwaltung/Server -> SuSE Linux) -> 192.168.1.11
Und noch ein paar virtuelle Server/Umgebungen, die sind jetzt aber nicht wichtig.
Die 192.168.1.11 ist das Problemkind
@cykes: Das ist ein Missverstaändnis: von Windows aus geht es ja, das ist ja das seltsame.
Folgendes habe ich versucht:
<li>SuSE Firewall abgeschaltet</li>
<li>Router resettet /neu eingerichtet</li>
<li>SuSE IP-Adresse (lokale) in DMZ eingetragen</li>
<li>MTU 1454 des Routers bei MTU SuSE eingetragen (inklusive Neustart)</li>
Hilft alles nicht.
Von Windows aus gehts, von Suse aus nicht [
] -> echt spinnert.Ich wede Morgen auf jeden Fall mal die D-Link Hotline befragen, aber erfahrungsgemäss wird das nichts bringen.
Bin aber nach wie vor für "jedes technische Experiment " zu haben.
Das kleine Netzwerk ist nicht kompliziert:
Router: 192.168.1.1
Switch1 ->
Erster Rechner im ersten Stock (Frau): 192.168.1.2
Zweiter Rechner im ersten Stock (Sohn): 192.168.1.3
Up-Link in den zweiten Stock -> Kabel an Hauswand hoch [
]Switch 2 ->
Rechner 1 (Arbeitsplatz/Windows) : 192.168.1.10
Rechner 2 (Verwaltung/Server -> SuSE Linux) -> 192.168.1.11
Und noch ein paar virtuelle Server/Umgebungen, die sind jetzt aber nicht wichtig.
Die 192.168.1.11 ist das Problemkind
Hi,
mal ganz allgemein, funktionieren irgendwelche Zugriffe vom Linux Server aus auf das Internet
zufällig auch nicht. Zum Beispiel SuSE Update oder ähnliches?
Die IPs der Rechner sind alle statisch eingetragen in der jeweiligen Netzwerkkonfiguration,
sprich die Rechner bekommen die IPs nicht per DHCP?
Das Standardgateway und der DNS ist bei allen Maschinen die IP des D-Link Routers?
Es könnte halt auch an der DNS Auflösung liegen, kannst Du gut testen, in dem Du vom Linux Server per IP und nicht per Namen auf den externen DB Server zugreifst ....
Gruß
cykes
mal ganz allgemein, funktionieren irgendwelche Zugriffe vom Linux Server aus auf das Internet
zufällig auch nicht. Zum Beispiel SuSE Update oder ähnliches?
Die IPs der Rechner sind alle statisch eingetragen in der jeweiligen Netzwerkkonfiguration,
sprich die Rechner bekommen die IPs nicht per DHCP?
Das Standardgateway und der DNS ist bei allen Maschinen die IP des D-Link Routers?
Es könnte halt auch an der DNS Auflösung liegen, kannst Du gut testen, in dem Du vom Linux Server per IP und nicht per Namen auf den externen DB Server zugreifst ....
Gruß
cykes
Alle "Standard" Verbindungen gehen. SuSE Update geht nicht.
Ich habe zwischenzeitlich das hier gefunden (Auszug):
"Fazit:
Das ist definitiv ein Bug in der Firmware vom D-Link. Und zwar verwirft der Router ausgehende IP-Packete, wenn im IP-Header das TOS-Feld (bzw. neu-denglisch: "Differential Services Codepoint") auf 0x10 gesetzt ist. Genau das trifft sowohl für telnet als auch ssh zu. (0x10 heisst minimum-delay, was üblicherweise für interactive-sevices immer verwendet wird.) Interessanterweise werden eingehende Packete mit diesem Wert korrekt durchgelassen. Ziemlich strange"
Komplett (hochinteressant) -> http://forum.dlink.de/topic.asp?TOPIC_ID=31419
Genau diesen Thread bekommt mein Händler Morgen früh unter die Nase - nebst Gerät.
Das Gerät arbeitet nämlich falsch und ich kauf nicht zum Neupreis Fehlerware oder Beta-Versionen.
VERY SPECIAL THANKS TROTZEDM FÜR DIE TOP-HILFE!
Grüsse: Krawallo
Ich habe zwischenzeitlich das hier gefunden (Auszug):
"Fazit:
Das ist definitiv ein Bug in der Firmware vom D-Link. Und zwar verwirft der Router ausgehende IP-Packete, wenn im IP-Header das TOS-Feld (bzw. neu-denglisch: "Differential Services Codepoint") auf 0x10 gesetzt ist. Genau das trifft sowohl für telnet als auch ssh zu. (0x10 heisst minimum-delay, was üblicherweise für interactive-sevices immer verwendet wird.) Interessanterweise werden eingehende Packete mit diesem Wert korrekt durchgelassen. Ziemlich strange"
Komplett (hochinteressant) -> http://forum.dlink.de/topic.asp?TOPIC_ID=31419
Genau diesen Thread bekommt mein Händler Morgen früh unter die Nase - nebst Gerät.
Das Gerät arbeitet nämlich falsch und ich kauf nicht zum Neupreis Fehlerware oder Beta-Versionen.
VERY SPECIAL THANKS TROTZEDM FÜR DIE TOP-HILFE!
Grüsse: Krawallo
Dann versuch doch erstmal die Firmware upzugraden, den Händler kannst Du dafür nicht in die Pflicht nehmen, aber wenns ein guter ist, macht er dir auch das Firmware-Update.
Es gibt zu dem Teil nur eine Firmware. Datum: 08/2004 V1A.
Und die ist ja drauf.
Und die ist ja drauf.
Also Nachtrag:
Ich habe den D-Link zurückgebracht. Ich habe mir alternativ einen Netgear DG834GB geholt und siehe da: einwandfrei.
Danke [!] an alle, die sich einen Kopp zu dem obigen Problem gemacht haben.
Ich habe den D-Link zurückgebracht. Ich habe mir alternativ einen Netgear DG834GB geholt und siehe da: einwandfrei.
Danke [!] an alle, die sich einen Kopp zu dem obigen Problem gemacht haben.
