ipcop, dns srv problem

[zoRRen]

hi,
hab mal wieder ein _kleines_ problem mit meinem cop.
heute hat sich mein cop, nach 14 tägiger session, reconnected. allerdings konnte ich weder seiten öffnen, mails abrufen oder sonstiges. telefon war auch tot, was mir absolut nicht gefallen hat.

nur stand im webinterface, dass die verbindung steht:

Aktuelles Profil: xpirio
Verbunden (0d 0h 8m 43s) - xpirio
IP-Adresse: **.***.***.**
IPCop's Hostname: **-***-***-***-adsl-klg.xpirio.net

so wie immer. sollte eigentlich funzen, hat es aber nicht.
habe die verbindung getrennt, manueller reconnect, gleiches ergebnis.

hab dann bei den einwahloptionen die dns wahl von manuell (ja, ich hab dort die richtigen dns server von xpirio eingetragen) auf automatisch umgestellt.
manueller reconnect, inet funzt einwandfrei.

danach noch einmal verbindung manuell unterbrochen, reconnect (dns einstellungen blieben auf automatisch), kein inet

dns wieder auf manuell gestellt -> inet funzt Oo

--

um das ganze zusammenzufassen:
wenn der cop die verbindung unterbricht, macht er zwar nen reconnect und es steht auch dass er verbunden ist. aber ich hab kein inet, kein seitenaufbau, keine verbindung zum mailserver möglich, fritzbox kann rufnummer nicht registrieren...

sobald ich dann bei den dns einstellungen von automatisch auf manuell bzw. von manuell auf automatisch umschalte, funktionierts wieder...

ich blick nicht mehr durch, finds nur extrem lästig, da das telefon im fall des falles nicht funktioniert...

bin für jede hilfe dankbar!

[lordpeng]

womöglich bezieht er einfach falsche dns einträge, kannst eigentlich einfach verifizieren obs wirklich am dns liegt in dem du irgendeine externe ip anpingst

wenn dem so ist, einfach die /etc/hosts (oder woauchimmer ipcop seine dns einträge haben will) schreibschützen ...

[zoRRen]

das schreibtschützen der hosts datei hat leider nichts genüzt.
hab nochmal alle einstellungen am cop überprüft, auch am modem sind alle einstellungen so wie sie sein sollten.

werde heute mal alternative dns srv probieren einzutragen...
hätte vll. sonst noch jemand nen vorschlag bzw. nen hinweis auf was ich achten sollte?

merci

[zid]

die nameserver für dnsmasq stehen in /var/ipcop/red/resolv.conf. was spuckt
# cat /var/ipcop/red/resolv.conf
aus, wenn's nicht geht.

was steht in den loggings?
du könntest off gehen,
#tail -f /var/log/messages | grep dnsmasq\\[
machen und danach wieder die verbindung aufbauen.
dann sollten auf d. konsole ca. solche meldungen auftauchen:
...
...dnsmasq[pid]: reading /var/ipcop/red/resolv.conf
...dnsmasq[pid]: using nameserver ip.von.name.server1#53
...dnsmasq[pid]: using nameserver ip.von.name.server2#53
...
ist das der fall?

[lordpeng]

hast du schon versucht eine ip im internet anzupingen bzw. mit nslookup händisch einen hostnamen aufzulösen?

[zid]

ich glaub, jetzt is er out. dabei hätte mich das wirklich interessiert. kann dieses "verhalten" einfach nicht reproduzieren.

[zoRRen]

hab jetzt zeit gefunden, mich der sache endlich anzunehmen. vorweg, es funktioniert jetzt alles einwandfrei!

die resolv.conf zeigte mir immer die selben dns server an:
195.16.224.2
195.16.224.3

sind komischweise andere als die, die mir mit den zugangsdaten gesendet wurden:
195.16.241.140
195.16.241.141

es funktionieren beide paare, allerdings, wie oben beschrieben gab es immer das selbe problem mit dem neuverbinden und den dns einstellungen zwischen automatisch und manuell.

hab jetzt via putty im setup bei den adresseinstellungen für rot auch das feld standardgateway (10.0.0.138 war std. bei diesem punkt... die felder für die dns server hab ich von anfang an im setup leer gelassen) geleert und siehe da... nach jedem reconnect hat der cop jetzt die verbindung und läuft tadellos!

beim webinterface unter -einwahl- sind die dns server manuell gesetzt (140, 141), die zusätzlichen pptp einstellungen auf statisch und als router ip 10.0.0.138

kann mir das nicht wirklich erklären

[arthur_dent]

Ho Zorren,

falls das nochmal passieren sollte, probier bitte mal, ob di externe IP Adressen noch pingen kannst und wenn das noch geht, ob die die nameserver von xpirio pingen kannst.

Es kann durch atm routing aenderrungen im TA Netz abundzu auch mal zu problemen kommen, indem nach dem reconnect Pakete aus bestimmten Netzen nichtmehr wieder richtig zurueck geroutet werden.

Das liegt daran, dass die DSL Endpunkte an mehreren stellen terminieren und uebergeben werden. Dein Account kann sich zwar ueberall authentifizieren, und bekommt auch einen connect, jedoch wird das Netz, nach dem terminieren in dem du bist, eventuell anders geroutet, da aufgrund deines Standortes, erwartet wird, dass der connect an einer ganz anderen Stelle terminiert wird.

Man sieht in diesem fall dan z. B. die anfragen an den Nameserver zwar noch auf dem Nameserver ankommen, jedoch geht die antwort erstmal in eine komplett falsche Richtung.

lg,

Andi

[zid]

hallo zoRRen,

danke für deine antwort. ganz klar ist mir dieses flip-flop verhalten auch nicht.
möglicherweise 2 konkurrenzierende defaultrouten.
hab' jetzt leider keinen 18er cop installiert sondern nur 11er und da geht die sache wegen einer falschen abfrage in rc.red ganz schief, wenn du e. gateway (z.b. 10.0.0.138) beim setup angibst. in diesem fall setzt rc.red für verbindungstyp "STATIC" (das ist o.k.) *und* "PPTP" eine defaultroute über dieses gateway und der pppd ersetzt sie bei der einwahl nicht durch die route über d. peer- die bekannte option "replacedefaultroute" von suse gibt's beim cop nicht, sodaß man in diesem fall immer off ist (kein flip-flop verhalten). in den logs meldet der pppd dann zwar : "...not replacing existing default route to eth1...", das muß man aber zu deuten wissen. anscheinend hat's da änderungen in rc.red gegeben, muß ich mir mal anschauen.
die dns-server werden von ip-up gesetzt. wennst "manuell" eingestellt hast, dann liest ip-up die datei /var/ipcop/ppp/settings, bei auto werden die vom provider gelieferten server-ips genommen. ip-up schreibt die ips nach /var/ipcop/red/dns1(2) und startet updatered, das wiederum aus dns1(2) liest, nach /var/ipcop/red/resolv.conf überträgt und dnsmasq startet. dnsmasq liest aus /var/ipcop/resolv.conf. d.h. es sollte da keine probs geben, wenn die defaultroute stimmt.

lg