Suchergebnisse

Eine ordentliche Übersicht gibt's da nicht... Eine Möglichkeit ist, in der Verfügbarkeitskarte der Telekom mal rumzuklicken in der Umgebung deines Wohnsitzes - manchmal zeigen Nachbarstraßen plötzlich andere Funkzellen an. Eine zweite Möglichkeit ist, einen netten Teamie im TH-Forum zu fragen - da gibt's extra einen Thread zu - der gibt Dir dann mit etwas Glück alle Funkzellen in rund 10km Umkreis mit Entfernung und Richtung. War so frei, Dir den Thread zu finden: telekomhilft.telekom.de/t5/Tel……

Ich lass' manche Logfiles ab & an über ein tail -n X laufen ganz böse: könnt' man nicht das logfile als symbolischen Link für /dev/null anlegen? OK: 'log-level 1' dürfte der geradlinigste Weg sein... mfg, emkay

@raffaelo: bei 800er Zellen braucht man schon sehr viel Glück 1800er Zellen sind freigiebiger in der Zuteilung von Bandbreite - haben halt auch mehr Mit Außenantenne kann eine 1800er auch durchaus weiter entfernt sein - meine ist 9km weg und ich empfange sie nur durch Reflektion in dem Reihenhaus gegenüber... ist sehr von den örtlichen Gegebenheiten abhängig. mfg, emkay

Zitat von raffaelo: „Und Update 12er ? Ruhig drauf ?“ Ist ein Telefon-HotFix - tut nich weh, Einstellungen bleiben erhalten. Nur wenn Du ein Bootstrap gemacht hast, mußt Du das neu anlegen. (Telnet bleibt erhalten, USB-Stick auch - nur opt-ordner im rootfs und die Änderungen an der /etc/profile gehen verloren.) mfg, emkay EDIT: dann kam dein Login-Problem vom puren IPv4, dann funktioniert die Namensauflösung für speedport.ip nicht...

Moin @raffaelo! Oft kommt es zu Problemen beim Einloggen durch seltsame Passwörter - auch könntest Du's mal mit der IP statt speedport.ip (oder umgekehrt) versuchen. Auch pures IPv4 kann Probleme bei der lokalen Namensauflösung (also zB. speedport.ip, oder eigene) hervorrufen. Zusätzlich kann sich immer nur ein Client an der WebUI anmelden. Also nur ein Web-Browser oder ein Script (zB. l33tport) und auch Stricteds SPH-Control ist ein Client... genaueres lässt sich nich so ohne weiteres sagen. Wa…

@raffaelo: Du kannst den Fehler - der keiner is - nicht wirklich umgehen ==> Telekom-Anschlüsse sind echte IPv6-Anschlüsse, auf der Google-IPv6-Whitelist und schon der SPH selbst wird ohne Dein Zutun DNSv6-Anfragen auslösen. Mal von allen anderen Clients (inkl. Smartphones) abgesehen... mfg, emkay

Moin! Zitat von kronsi1980: „Was sagt ihr zu folgenden Fehlermeldungen?: 11.05.2016 21:07:19 DNSv6-Fehler: Der angegebene Domainname kann nicht von 2003:180:2:4000:0:1:0:53 aufgelöst werden. Fehler: Server failure (P008)“ Bedeutet nur, das es für den URL keine IPv6 gibt - das ist nur aus Sicht des DNSv6 ein Fehler, in der Praxis wird direkt danach dann der DNSv4 angefragt - und nur, wenn der den URL auch nicht auflösen kann, ist die Seite/Resource nicht erreichbar. Da immer noch sehr viele Webse…

Zitat von genevt: „Seit wann hat der HAAP was mit dem ppp256-Interface zu tun, außer dass er darüber erreichhar sein sollte?“ Weil alle 10 Minuten ein Abgleich mit dem HAAP durchgeführt wird - und dabei alles, was nich passt, wieder passend gemacht wird vielleicht? Nur mal so'ne Idee... Du kannst Dir aber gern die Mühe machen, das zu stracen - dann weißt Du's genau. Und übrigens geht's bei der ganzen Sache überhaupt nicht um die PPOE-Sitzung - nur um den Tunnel... mfg, emkay

Damit man es auch wieder beenden kann, doch mal als Script:Shell-Script (7 Zeilen) Das Script schickt sich selbst in den Hintergrund - und kann per killall einfach wieder gekillt werden. mfg, emkay EDIT: Nachtrag ==> man muß dabei beachten, daß der LTE-Tunnel ohne den DSL-Tunnel nicht aufgebaut wird... Der LTE-Tunnel muß also schon stehen, wenn man den DSL-Tunnel killt.

@genevt: naja, vom HAAP sprach hier ja auch niemand. Eventuell könnte man auch das gre1-Interface killen, wenn man's sieht... (müsste dann aber auch regelmäßig passieren) Übrigens ist mit dem Einzeiler oben IPv6 nicht zerstört - ppp256 hat ja noch die 2. interne IPv6. Nur die externe, welche für den Tunnel wichtig ist, wird entfernt. Ich sah das als einfachste Lösung an -- gibt aber bestimmt auch noch andere mfg, emkay

...also eher so:Quellcode (1 Zeile) ==> immer noch ein Einzeiler mfg, emkay EDIT: hab'mal oben aus 10 Sekunden eine gemacht - sonst wird eventuell der Tunnel doch mal für 1-2 Sekunden aktiv...

Moin Leutz! Wegen @Jingoros Hartnäckigkeit habe ich mal nach einer harten Lösung für Bonding-Probleme gesucht... also den DSL-Tunnel zerlegen, damit alles direkt über LTE geht. Und da ich Einzeiler mag...Quellcode (1 Zeile) Damit entfernt man die IPv6 vom DSL-Interface und der Tunnel bricht zusammen. Danach läuft alles, was nicht durch besondere Regelungen auf DSL geroutet ist, nur noch über LTE. Telefon sollte allerdings weiterhin funktionieren. Also für Leute wie @Jingoro, welche DSL nur für T…

Wie gesagt - meine Clients nutzen alle den SPH selbst als DNS. (ist die Vorgabe) Trotzdem tippe ich mal darauf, das es durch die Bridge irgendwelche Probleme mit den SPH-RAs gibt. Eine andere halbwegs logische Erklärung fällt mir da nicht ein. Liegen denn die Clients hinter dem Netgear und die direkt am SPH im selben Netz? Sonst könnt's da eng werden ohne PD. mfg, emkay

Naja, die DNSv6-Server sind ja kein Problem - kann man schnell testen: trag' bei einem Client hinter der Bridge den SPH manuell als Haupt-DNS-Server ein. Wenn's hilft, weißt Du wo der Fehler liegt. mfg, emkay EDIT: Heiko hat nicht ganz Unrecht - wenn Du vorher eine Prefix-Delegation zum Netgear hattest ---> das geht nicht so einfach. Alles hinter dem Netgear muß sich bezüglich IPv6 auf den SPH beziehen, und nicht auf den Netgear.

Moin @Yoshi! Eigentlich fast klar: wenn IPv6 am SPH klappt aber hinter der Netgear-Wlan-Bridge nicht --> liegt der Fehler in der Bridge Eventuell werden da ICMPv6 gefiltert... Ich selbst hab' bei mir mittlerweile dem SPH einfach die RAs verboten - und nutze nun extern nur noch IPv4, weil's stabiler ist. (der SPH selbst nutzt noch IPv6 und auch die Clients können intern (localhost) noch IPv6 nutzen) mfg, emkay

Moin Leutz! Ich hab' ja schon lange 'nen OpenSSH am laufen - aber da nervt das ssh (sshd läuft prima), weil es ein Debian-Build ist --> man muß also bei allen Binaries die Libraries vorladen... Da ich aber eh kürzlich endlich OpenSSL nativ für den SPH kompillieren konnte (aktuelle Version mit letzten BugFixes - brauchte ich für OpenVPN), müsste ich jetzt auch OpenSSH nativ bauen können. Werd' ich demnächst in Angriff nehmen. Entweder nach OpenVPN - oder eben gerade dafür, weil OpenVPN recht schö…