Suchergebnisse

Moin, nach nun nun ein paar Wochen mit Bootstrap ist heute etwas passiert das ich noch nicht ganz blicke.. Urplötzlich hat der Speedport den Dailyreboot nicht überlebt und scheint irgendwie zu hängen. Ich gehe stark davon aus irgendwo etwas kaputt gemacht zu haben, allerdings habe ich kein Plan wie ich den guten überhaupt erstmal wieder aus laufen kriegen - gibt's nen auto Firmware Update per USB, dass er beim bot macht? Die Lanports sind jedenfalls tot, ds/lte kommen auch nicht

Find ich ganz interessant, koennte mein l33tport-munin ein wenig erweitern, sofern das ganze rrdtool-faehig wird - im github von l33tport gibts ja schon aktuelle rrd-graphen fuer die bisherigen werde... da kann man gut abschauen: github.com/melle/l33tport/blob/master/rrdtool/createRRDBs.sh

Zitat von Heiko: „Hat der SPH bei euch schon mal bei manueller Prüfung ein Update gemeldet?“ Ja, Samstag

Zeitversatz spielte hier definitiv nicht Rolle - es lagen circa 12h zwischen dem Reconnect und den Screenshots - Effektiv habe ich auch nichts weiter rausgefunden, als die bereits bekannten Infos... Mich wunderts halt... Tunnel waren alle up... aber es ging einfach nichts mehr durch... Vielleicht tauchts nochmal auf, dann geh ich dem weiter nach...

Aktuell steht dort eine 3 - nach reboot. Nach einem erneuten --snr-Reconnect geht nun wieder traffic durch den DSL-Tunnel - Merke ich hier relativ flott, da mein lokaler DNS per Port-Umleitung auf DSL umgebogen ist... Und statt 11 ist der sync bei 15,7 von max 16,012 - mal schauen wie lange. Ich hatte damit ja schon vor der neusten Firmware gespielt, da war mir das nicht aufgefallen... Ich kann mir allerdings nicht vorstellen, was die Telefonie damit nun zu tun haben sollte, die sich ja als einz…

Nuja die Verbindung steht seit gestern Abend - ich denke nicht, dass ich zu schnell war wenn ich da heute Screenshots mache - aber vielleicht braucht er ja ein wenig um es zu checken Nein, kein Wrapper - noch bin ich nicht ganz zu frieden und experementiere mit dem xdslcmd directly. EDIT: Sehe gerade ein LastError: NoHybridAccessSupportforPPPAccessData - Sollte ich mir gedanken machen? :O EDIT2: Wie ich gemerkt habe geht er nach einem weiteren recon per hand wieder auf "online" - merkwuerdig ist…

Moin, ist schonmal jemanden aufgefallen, dass beim setzen des SNR per xdslcmd dscheinbar as WebUI ein wenig merkwuerdig wird und nicht mehr genau bestimmen mag ob verbunden oder nicht? (siehe Screenshots). Ist mir aufgefallen, da ich gerade ein paar eDNS Probleme anlysiere die scheinbar mit dem SPH auftauchen und ich daher mal Port 53 umgeleitet wird zum testen. Neuste Firmware ist aktuell sogar drauf - koennte auch daran liegen - hatte vorher nicht drauf geachtet.

Zitat von eMKay77: „EDIT: mit guter Leitung meinte ich eher Anschlüsse ohne RAM, also 16er und höher - dort könnte die Halbierung des SNR einen höheren Sync zur Folge haben - mit dem Risiko, mehr Fehler zu produzieren. Das Profil selbst bleibt dabei natürlich gleich.“ Und genau damit habe ich mal rumgespielt... Höchst interessant - ich konnte damit unseren Sync von 10mbit auf volle 16mbit anheben und habe relativ gute Fehlerzahlen bei meinen Tests erhalten (sprich relativ: nicht mehr als vorher …

Jaein - der eigentlich proxy laeuft unter tomb.home.silibum.local auf Port 81 im Root - nur der Proxy übern Apache halt nicht, aber ich ueberlege mir tatsaechlich nen CNAME ala dslr.home.silibum.de anzulegen, damit der aus dem root laufen kann und ich den redirect nicht brauche... Muss ich nochmal schauen, ist ja nicht verkehrt und frisst nichts... Mal schauen - Danke soweit, erstmal.

In der richtung hatte ich es vermutet, ja - ich bin nun auch ein wenig weiter: Hab da nochmal genau hingeschaut und musste festellen: Die JSONSource-URL ist nur bei DSL "brauchbar" für mein Fall: DSL: Quellcode (8 Zeilen) ARP: Quellcode (8 Zeilen) Rewritest Du die an der Stelle, oder sind die schon kacke im WebInterface himself? Ich gehe von himself aus und habe nun wie folgt geschummelt: Quellcode (1 Zeile) Das laeuft erstmal und macht das engineer auch per Proxylauffaehig, darf nun halt erstma…

Sehr sehr nettes Tool für den SPH. Hat sich inzwischen etabliert. Habe mir dazu noch nen kleines init-Script (gentoo / OpenRC) für unseren FileServer gebaut, somit steht mir der sphProxy im LAN zur Verfügung - Benötigt allerdings "forever" (npm install -g forever): Quellcode (20 Zeilen) Nachdem das damit super läuft habe ich das ganze noch ein wenig auf die Spitze getrieben: Über unseren DNS-Server fahre ich eine Subdomain als DynDNS (home.silibum.de) und habe somit immer ein Host für meinen Ans…