Bugthread für gemoddete Speedport

meilon · 28 Mai 2007

Hallo!

Das soll jetzt der offizielle Bugthread für alle mit Problemen der ds-mod auf einem Speedport.

Ich persönlich habe aktuell Speedport W 701V, Firmware-Version 33.04.26ds-0.2.9_26-14 installiert und bisher follgende Probleme gehabt:

[fixed] Firmware auf den SP bekommen
[fixed] Auf WebUI kommen
[onIt]Wecker funktioniert nicht
[noticed]T-Online Zugangsdaten anzeige

[fixed] Firmware auf den SP bekommen
Für alle, die die Anleitung von dileks schon gelesen haben: Benutzt Knoppix, stellt die IP der Netzwerkkarte fest auf 192.168.178.20, näheres findet ihr unter Speed2Fritz Wiki eintrag.

[fixed] Auf WebUI kommen
Die meißten werden den Speedport vorher auf die Werkseinstellungen zurück gesetzt haben.
Wenn der Flash erfolgreich war, kam ich nicht beim ersten mal auf die Standard WebUI. Es wollte das Standardpasswort '0000' nicht akzeptieren. Nicht aufgeben! Irgendwann klappt es!
Wenn es dann geklappt hat, gleich das passwort auf etwas anderes ändern, das sollte sofortige Logins garantieren

[onIt]Wecker funktioniert nicht
Wie ich im Hauptthread für die aktuelle ds-mod Version angefragt habe, funktionier mein Wecker nicht. Ich kann beide Telefone untereinander Anrufen, aber der Wecker weckt nicht!
Syslogd im DS-MOD liefert mir follgendes

Code:

May 27 22:20:41 fritz user.err multid[674]: 0.0.0.0:2050: failed to send UDP-datagram to 192.168.180.1:53 - Network is unreachable (128)
May 27 22:20:42 fritz user.err multid[674]: 0.0.0.0:2050: failed to send UDP-datagram to 192.168.180.1:53 - Network is unreachable (128)
May 27 22:20:42 fritz user.err multid[674]: 0.0.0.0:2050: failed to send UDP-datagram to 192.168.180.2:53 - Network is unreachable (128)
May 27 22:20:43 fritz user.err multid[674]: 0.0.0.0:2050: failed to send UDP-datagram to 192.168.180.1:53 - Network is unreachable (128)
May 27 22:20:43 fritz user.err multid[674]: 0.0.0.0:2050: failed to send UDP-datagram to 192.168.180.2:53 - Network is unreachable (128)
May 27 22:20:45 fritz user.err multid[674]: 0.0.0.0:2050: failed to send UDP-datagram to 192.168.180.1:53 - Network is unreachable (128)
May 27 22:20:45 fritz user.err multid[674]: 0.0.0.0:2050: failed to send UDP-datagram to 192.168.180.2:53 - Network is unreachable (128)
May 27 22:20:49 fritz user.err multid[674]: 0.0.0.0:2050: failed to send UDP-datagram to 192.168.180.1:53 - Network is unreachable (128)
May 27 22:20:49 fritz user.err multid[674]: 0.0.0.0:2050: failed to send UDP-datagram to 192.168.180.2:53 - Network is unreachable (128)

hermann72pb meinte, dass das vorausgehende eingestellte Netzwerk 192.168.2.0 dafür verantworlich ist.

[noticed]T-Online Zugangsdaten anzeige
Wenn ich meine T-Online Zugangsdaten als "T-Online" eingebe, werden Sie nicht akzeptiert. Wenn ich allerdings "anderer Anbieter" auswähle und dort den ellen langen Code eingebe klappt es. Nur Springt die Anzeige wieder auf T-Online und der Code wird aufgesplittet und falsch dargstellt. Ist nur ein Darstellungsfehler, nicht so wichtig!

Jemand ideen?

MfG
meilon

hermann72pb · 28 Mai 2007

schau mal zu den Interfaces unter
http://www.ip-phone-forum.de/showthread.php?t=127480&highlight=failed+send+UDP-datagram
Es bringt dich zwar nicht direkt weiter, aber schlauer wirst du etwas. Und gib mal in die Suche "failed to send UDP-datagram". Es gab viele Treffer dazu. Zumindest bei mir.

Edit: Und noch eine Bemerkung am rande, bevor du lange danach suchst oder falls du das nicht weiß: Port 53 UDP sind DNS-Anfragen. Dein Protokoll besagt also: Etwas will auf DNS zugreifen. Es geht aber nicht. Das kann echt mit ar7.cfg etwas zu tun haben. Denn dort werden alle Firewall- und Routing-Einstellungen gespeichert. Frag mal nach, ob dir jemand seine ar7.cfg postet. Und untersuche die Unterschiede wie im oben angegebenen Thread.

MfG

meilon · 28 Mai 2007

Vielen Dank, werde mich morgen mal darum kümmern!

olistudent · 28 Mai 2007

Hi.
Wie sieht das denn bei dir in der ar7.cfg aus?

Code:

servercfg {
        hostname = "(none)";
        dns1 = 192.168.180.1;
        dns2 = 192.168.180.2;
}

Kannst du den Darstellungsfehler im Webinterface nachvollziehen und mir sagen was ich patchen muss damit es stimmt?

MfG Oliver

meilon · 28 Mai 2007

Der Eintrag lautet genauso!

Ich habe aber mal meine ar7.cfg angehängt, keine Angst, alles gefährliche habe ich rausgelöscht.

Zum Webinterface: Das Problem muss sein, dass er bei der Darstellung erkennt, dass es sich um einen t-online Zugang handelt (wegen dem "@t-online.de" am Ende).
Das Javascript, welches den Code ja in die Boxen schreiben soll, scheint nicht zuverlässig zu laufen. Es erkennt zwar das "@t-online.de" am Ende, kann es aber nicht richtig zerschneiden und in die Boxen schreiben. Werde ich mir mal genauer anschauen.

Grüße

RalfFriedl · 28 Mai 2007

olistudent schrieb:
Wie sieht das denn bei dir in der ar7.cfg aus?

Code:

servercfg { hostname = "(none)"; dns1 = 192.168.180.1; dns2 = 192.168.180.2; }

Diese Einstellungen sind von Bedeutung, wenn man unter Internet / Zugangsdaten auswählt Internetzugang über LAN 1, Vorhandene Internetverbindung im Netzwerk mitbenutzen (IP-Client).
Wenn man über DSL oder PPPOE eine Internetverbindung herstellen will, werden zunächst die 192.168.180.1 und 192.168.180.2 in /etc/resolv.conf als nameserver eingetragen. Sobald eine Verbindung hergestellt ist, werden die Nameserver des Providers in /etc/resolv.conf eingetragen. Wenn also Meldungen kommen, daß 192.168.180.1:53 nicht erreichbar ist, ist entweder die Box nicht online, oder es wurde vom Provider kein DNS-Server übergeben (unwahrscheinlich).
Die vorläufigen Nameserver-Einstellungen für DSL oder PPOE Verbindung kommen nicht aus der ar7.cfg, sondern sind fest eingestellt in der Datei /etc/resolv.conf, die aus /var.tar extrahiert wird. Diese Adressen haben auch keine größere Bedeutung, da sie nach erfolgreicher Einwahl über DSL oder PPPOE überschrieben werden. Wichtig ist nur, daß diese Adressen verschieden von den Adressen der Box sind.
Das Web-Frontend stellt auch sicher, daß nicht eine Adresse aus dem Bereich 192.168.180.x/24 für die Box vergeben wird.

Code:

hilfe_ipsetting.html: Das gesamte IP-Netzwerk 192.168.180.0 ist für interne Zwecke reserviert.
ipform.js: Bitte verwenden Sie nicht das Subnetz 192.168.180/24. Wählen Sie eine andere IP-Adresse!

Allerdings wird anscheinend nicht verhindert, die Adresse 192.168.180.1 mit einer anderen Netmask als /24 zu verwenden, was vermutlich genauso schlimm wäre.

meilon · 28 Mai 2007

Stimmt, wie geschrieben, ist die Box nicht am Internet. Dachte es hätte etwas mit meinem Wecker zu tun. Nundenn, woran könnte es sonst liegen, dass der Wecker nicht gunktioniert? Untereinander kann ich Fon1 und Fon2 anrufen.

olistudent · 28 Mai 2007

@RalfFriedel
Sollte da jetzt nicht was anderes stehen, wenn ich dich richtig verstanden habe? Box ist über DSL (PPPOE) im Netz.

Code:

/var/mod/root $ cat /etc/resolv.conf
nameserver 192.168.180.1
nameserver 192.168.180.2
/var/mod/root $ nslookup fritz.box
Server:  192.168.180.1
Address: 192.168.180.1
Name:    fritz.box
Address: 192.168.1.2 fritz.box
/var/mod/root $

Oder hat das was mit dnsmasq zu tun?

MfG Oliver

RalfFriedl · 28 Mai 2007

Ich habe für den SpeedPort W900V zunächst mit Speed2Fritz das Web-Frontend geändert. Das ist schon mal eine wesentliche Verbesserung gegenüber dem Auslieferungszustand.
Da ds-mod für den W900V nur das original Web-Frontend zur Auswahl anbietet, habe ich das Ergebnis von Speed2Fritz unter dl/fw_Speedport_W_900V.34.04.21.image abgelegt, damit funktioniert dann alles bestens, also Web-Frontend von AVM und ds-mod.

Reset auf Werkseinstellungen war bei mir nicht nötig. Ich habe jedoch später aus anderen Gründen die Einstellungen zurückgesetzt, danach konnte ich mich mit "0000" direkt wieder anmelden.

Firmware Update:
Um die Firmware auf die Box zu bekommen, verwende ich ein SUSE 10.1 Linux-System mit dem dort bereits vorhandenen lukemftp-1.5.

Vorbereitung:
Als root folgende Kommandos ausführen:
Wenn der Rechner häufiger neu gestartet wird, kann man die Zeilen auch in ein init-Skript setzen.

Code:

# Adresse aus dem Bereich 192.168.178.0/24 setzen
# (falls nicht bereits eingestellt)
ip addr add 192.168.178.2/24 dev eth0
# optional: festen ARP-Eintrag
arp -s 192.168.178.1 XX:XX:XX:XX:XX:XX

wobei XX:XX:XX:XX:XX:XX die MAC-Adresse der Box ist. Der ARP-Eintrag ist nicht unbedingt notwendig, verhindert aber, daß Meldungen wir "host not reachable" kommen, wenn man nachher versucht, die Box anzusprechen, bevor sie reagiert.
Dann unter dem Benutzer, mit dem man auch das ds-mod erzeugt, die Datei ~/.netrc mit folgendem Inhalt erstellen bzw. folgende Zeilen anhängen:

Code:

machine 192.168.178.1
login adam2
password adam2
macdef init
binary
quote MEDIA FLSH
put build/modified/firmware/var/tmp/kernel.image mtd1
quote REBOOT
bye

# oben eine Leerzeile lassen

Die Leerzeile hinter bye ist wichtig. Noch mit

Code:

chmod 600 ~/.netrc

die Zugriffsrechte ändern, sonst wird die Datei nicht verwendet.

Firmware aktualisieren:
Jetzt Box neu starten und innerhalb von 5 Sekunden folgendes Kommando eingeben:

Code:

ftp 192.168.178.1

Alternativ auch Box ausschalten, FTP starten, dann Box einschalten geht auch, wenn man den ARP-Eintrag gesetzt hat.
Dann ca. eine Minute warten und die Firmware ist auf der Box. Nochmal ca. eine Minute warten, und die Box sollte wieder ansprechbar sein.
Wenn man im ds-mod mit make eine neue Firmware erstellt hat, liegt das Image (nicht die TAR-Datei) unter build/modified/firmware/var/tmp/kernel.image. Diese Datei wird per FTP an die Box übertragen.
Die ganzen Kommandos, die man sonst immer wieder von Hand eintippen müßte, stehen in der ~/.netrc und werden automatisch ausgeführt.

RalfFriedl · 28 Mai 2007

meilon schrieb:
Nun denn, woran könnte es sonst liegen, dass der Wecker nicht funktioniert? Untereinander kann ich Fon1 und Fon2 anrufen.

Wenn die Box gar keine Zeit eingestellt hat, also mit 01.01.2000 startet, sagt die Web-Oberfläche direkt, daß die Box keine Zeit eingestellt hat und bietet auch keine Möglichkeit an, den Wecker zu aktivieren.
Es kann sein, daß die Weck-Funktion beim W701V nur dann ausführt wird, wenn die die Box Verbindung zu einem Zeit-Server im Internet hat.
Bei meinem W900V ist dies nicht notwendig, ich habe es gerade ausprobiert, da kommt der Anruf auch mit manuell gesetzter Zeit.
Für die Anrufe untereinander wird keine aktuelle Zeit benötigt.
Ich vermute, daß die Box sich mit der Zeit nicht ganz im klaren ist.
Hast Du ISDN-Telefone angeschlossen? Wenn ja, zeigen diese die richtige Zeit an?
Kann es sein, daß sich die Box unmotiviert neu startet? In diesem Fall würde sie die aktuelle Uhrzeit verlieren.

RalfFriedl · 28 Mai 2007

olistudent schrieb:
Sollte da jetzt nicht was anderes stehen, wenn ich dich richtig verstanden habe? Box ist über DSL (PPPOE) im Netz.
Oder hat das was mit dnsmasq zu tun?

Meiner Meinung nach sollte nach dem Verbindungsaufbau in /etc/resolv.conf die Adressen der DNS-Server stehen. Ich habe meine Box derzeit auf Vorhandene Internetverbindung im Netzwerk mitbenutzen (IP-Client) stehen, da trägt sie mir die manuell eingestellten DNS-Server in die Datei ein. Ob das etwas mit dnsmasq zu tun hat, weiß ich nicht. Ich vermute, daß multid für das Ändern der /etc/resolv.conf zuständig ist.
Wird multid deaktiviert, wenn dnsmasq verwendet wird? Die Aufgaben scheinen recht ähnlich zu sein.

Ein nslookup auf fritz.box sagt nichts über die DNS-Funktion aus, da nslookup anscheinend auch die Datei /etc/hosts verwendet. Ich habe es gerade bei mir ausprobiert, ich bekomme für fritz.box die Adresse aus /etc/hosts der angezeigt, auch wenn ich dort eine ganz andere Adresse eintrage. Trotzdem zeigt nslookup die Adresse des DNS-Servers, auch wenn dieser nicht verwendet wird.
Interessanter wäre nslookup auf einen externen Namen.

olistudent · 28 Mai 2007

Das sieht auch nicht anders aus:

Code:

/var/mod/root $ nslookup [URL="http://www.google.de"]www.google.de[/URL]
Server:  192.168.180.1
Address: 192.168.180.1
Name:    [URL="http://www.google.de"]www.google.de[/URL]
Address: 72.14.221.99 fg-in-f99.google.com
Name:    [URL="http://www.google.de"]www.google.de[/URL]
Address: 72.14.221.147 fg-in-f147.google.com
Name:    [URL="http://www.google.de"]www.google.de[/URL]
Address: 72.14.221.104 fg-in-f104.google.com
Name:    [URL="http://www.google.de"]www.google.de[/URL]
Address: 72.14.221.103 fg-in-f103.google.com
/var/mod/root $

Aber wenn du IP-Client hast, dann könnte das anders sein. Ich meine, dass das bei mir in diesem Modus auch so war.

MfG Oliver

RalfFriedl · 28 Mai 2007

olistudent schrieb:
Das sieht auch nicht anders aus: ...

Kannst Du mit strace feststellen, ob wirklich der DNS-Server 192.168.180.1 verwendet wird?

olistudent · 28 Mai 2007

Sieht so aus:

Code:

/var/mod/root $ strace -o strace.log -s 200 nslookup [URL="http://www.google.de"]www.google.de[/URL] > /dev/null 2>&1
/var/mod/root $ cat strace.log |grep 180
read(3, "nameserver 192.168.180.1\nnameserver 192.168.180.2\n", 4096) = 50
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.180.1")}, 16) = 0
send(3, "\0\2\1\0\0\1\0\0\0\0\0\0\0011\003180\003168\003192\7in-addr\4arpa\0\0\f\0\1", 44, 0) = 44
recv(3, "\0\2\201\203\0\1\0\0\0\1\0\0\0011\003180\003168\003192\7in-addr\4arpa\0\0\f\0\1\300\22\0\6\0\1\0\0\0<\0A\10prisoner\4iana\3org\0\nhostmaster\froot-servers\300FwT\267\340\0\0\7\10\0\0\3\204\0\t:\200\0\t:\200", 512, 0) = 121
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.180.2")}, 16) = 0
send(3, "\0\3\1\0\0\1\0\0\0\0\0\0\0011\003180\003168\003192\7in-addr\4arpa\0\0\f\0\1", 44, 0) = 44
recv(3, "\0\3\205\203\0\1\0\0\0\0\0\0\0011\003180\003168\003192\7in-addr\4arpa\0\0\f\0\1", 512, 0) = 44
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.180.1")}, 16) = 0
send(3, "\0\4\1\0\0\1\0\0\0\0\0\0\0011\003180\003168\003192\7in-addr\4arpa\0\0\f\0\1", 44, 0) = 44
recv(3, "\0\4\201\203\0\1\0\0\0\1\0\0\0011\003180\003168\003192\7in-addr\4arpa\0\0\f\0\1\300\22\0\6\0\1\0\0\0<\0A\10prisoner\4iana\3org\0\nhostmaster\froot-servers\300FwT\267\340\0\0\7\10\0\0\3\204\0\t:\200\0\t:\200", 512, 0) = 121
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.180.2")}, 16) = 0
send(3, "\0\5\1\0\0\1\0\0\0\0\0\0\0011\003180\003168\003192\7in-addr\4arpa\0\0\f\0\1", 44, 0) = 44
recv(3, "\0\5\205\203\0\1\0\0\0\0\0\0\0011\003180\003168\003192\7in-addr\4arpa\0\0\f\0\1", 512, 0) = 44
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.180.1")}, 16) = 0
send(3, "\0\6\1\0\0\1\0\0\0\0\0\0\0011\003180\003168\003192\7in-addr\4arpa\0\0\f\0\1", 44, 0) = 44
recv(3, "\0\6\201\203\0\1\0\0\0\1\0\0\0011\003180\003168\003192\7in-addr\4arpa\0\0\f\0\1\300\22\0\6\0\1\0\0\0<\0A\10prisoner\4iana\3org\0\nhostmaster\froot-servers\300FwT\267\340\0\0\7\10\0\0\3\204\0\t:\200\0\t:\200", 512, 0) = 121
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.180.2")}, 16) = 0
send(3, "\0\7\1\0\0\1\0\0\0\0\0\0\0011\003180\003168\003192\7in-addr\4arpa\0\0\f\0\1", 44, 0) = 44
recv(3, "\0\7\205\203\0\1\0\0\0\0\0\0\0011\003180\003168\003192\7in-addr\4arpa\0\0\f\0\1", 512, 0) = 44
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.180.1")}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.180.1")}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.180.1")}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.180.1")}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.180.1")}, 16) = 0
write(1, "Server:  192.168.180.1\nAddress: 192.168.180.1\n\nName:    [URL="http://www.google.de\nAddress"]www.google.de\nAddress[/URL]: 72.14.221.99 fg-in-f99.google.com\nName:    [URL="http://www.google.de\nAddress"]www.google.de\nAddress[/URL]: 72.14.221.103 fg-in-f103.google.com\nName:    [URL="http://www.google"]www.google[/URL]"..., 317) = 317
/var/mod/root $

MfG Oliver

RalfFriedl · 28 Mai 2007

Hallo Oliver

Sieht aus, als käme tatsächlich eine Antwort von 192.168.180.1. Kann es sein, daß der Nameserver wirklich diese Adresse hat? Vielleicht aufgrund des dnsmasq?

Code:

connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.180.1")}, 16) = 0
send(3, "\0\2\1\0\0\1\0\0\0\0\0\0\0011\003180\003168\003192\7in-addr\4arpa\0\0\f\0\1", 44, 0) = 44
recv(3, "\0\2\201\203\0\1\0\0\0\1\0\0\0011\003180\003168\003192\7in-addr\4arpa\0\0\f\0\1\300\22\0\6\0\1\0\0\0<\0A\10prisoner\4iana\3org\0\nhostmaster\froot-servers\300FwT\267\340\0\0\7\10\0\0\3\204\0\t:\200\0\t:\200", 512, 0) = 121

olistudent · 28 Mai 2007

Ich hab den dnsmasq jetzt beendet und der multid spuckt beim Start folgendes aus:

Code:

multid: dns: 0.europe.pool.ntp.org: query
multid: dns: 0.europe.pool.ntp.org: 213.215.33.210 ttl=1453 from 192.168.180.1.
multid: sending SNTP request to server 0.europe.pool.ntp.org (213.215.33.210)

MfG Oliver

derheimi · 29 Mai 2007

RalfFriedl schrieb:
Sieht aus, als käme tatsächlich eine Antwort von 192.168.180.1. Kann es sein, daß der Nameserver wirklich diese Adresse hat? Vielleicht aufgrund des dnsmasq?

Nein, dnsmasq bindet sich wirklich nur an die lokal vorhandenen Adressen. Die 192.168.180.x/24-Adressen werden über zwei extra Routing-Einträge auf das DSL-Device geschickt, ich vermute, der dsld macht damit ein spezielles Masquerading und schickt die Pakete zu einem Upstream-Server. Daher sieht es so aus, als würde unter dieser Adresse ein DNS-Server laufen.

drivingsouth · 8 Jun 2007

Was hier nicht funktioniert:
1)
Unter "Netzwerkgeräten" werden nur verbundene WLAN Geräte angezeigt, jedoch keine Geräte am LAN Anschluß

2)
Unter "Ereignissen" werden keine Ereignisse angezeigt.

3)
Telefonie->Internettelefonie->Erweiterte Einstellungen
Die Einstellung Standortangaben springt immer auf "Anderes Land" zurück und die Vorwahlziffern sind auf "er" gesetzt.
Jedoch scheint die Einstellung zu funktionieren, denn Gespräche im Ortsnetz können ohne Vorwahl geführt werden.

spambin · 16 Jun 2007

Hi,

bei dem Problem mit der Anmeldung (Kennwort falsch) habe ich festgestellt, daß ich den Router nach dem Laden der Werkseinstellungen und dem anschließenden Reboot einmal aus und wieder einschalten muss, bevor er das Standard-Kennwort "0000" akzeptiert.

Vielleicht hilft's ja dem Einen oder Anderen.

meilon · 11 Jul 2007

spambin schrieb:
Hi,

bei dem Problem mit der Anmeldung (Kennwort falsch) habe ich festgestellt, daß ich den Router nach dem Laden der Werkseinstellungen und dem anschließenden Reboot einmal aus und wieder einschalten muss, bevor er das Standard-Kennwort "0000" akzeptiert.

Vielleicht hilft's ja dem Einen oder Anderen.

Bei mir leider nicht!

Meine /var/log/mod_load.log

Code:

Loading /var/flash/ds_mod...done.
Loading passwords...done.
Loading hosts...2000-01-01 01:00:08 ar7cfgctl: FactoryDefault=/etc/default/tcom/ar7.cfg (ar7)

2000-01-01 01:00:08 ar7cfgctl: load_config(ar7): factory default loaded
2000-01-01 01:00:08 ar7cfgctl: FactoryDefault=/etc/default/tcom/ar7.cfg (ar7)

2000-01-01 01:00:08 ar7cfgctl: load_config(ar7): factory default loaded
2000-01-01 01:00:08 ar7cfgctl: FactoryDefault=/etc/default/tcom/ar7.cfg (ar7)

2000-01-01 01:00:08 ar7cfgctl: load_config(ar7): factory default loaded
done.
Loading config...done.
Loading modules...done.

Beim vorherigen DS-Mod waren die FactoryDefaults einen Ordner höher: /etc/default/ar7.cfg
in der neuen ar7.cfg steht jetzt zB. bei Webui im Password "0000", damit komme ich aber nicht hinein.

Wäre es möglich für den aktuellen DS-Mod einen Patch bereit zu stellen, der richtige Werkseinstellungen besitzt, die von Anfang an funktionieren?

Würde mich als Tester bereitstellen, da mein W 701V nur ein zweitgerät zum testen ist, welches nichtmal was gekostet hat

meilon

Bugthread für gemoddete Speedport

Neuer User

IPPF-Promi

Neuer User

IPPF-Urgestein

Neuer User

Anhänge

IPPF-Urgestein

Neuer User

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

IPPF-Urgestein

Mitglied

Neuer User

Neuer User

Neuer User

Statistik des Forums