6490 repeater mode

noob_noob

Mitglied
Mitglied seit
1 Sep 2016
Beiträge
234
Punkte für Reaktionen
6
Punkte
18
Code:
<a id="wds2" name="" class="menu_item show selected" target="" href="/?sid=xyz1234neundrölf123amp;lp=wds2" onclick="return false;" style="order: 90;" role="link" aria-hidden="false">Repeater</a>

ist, wenn ich nicht irre, der aufruf um ne box im repeater mode zu betreiben... wie? bring ich das der 6490 bei, das dieser button dauerhaft im webif erscheint ? :confused: ich weiss, geht dauerhaft nur über änderungen der zu flashen firmware. es gibt ja diesen schönen git von fesc der dropbear einbaut. darüber müsste sich doch die fw auch vor dem packen modifizieren lassen, wenn man es anhält. aber: was muss da geändert werden ...
ich möchte die 6490 als reinen dvb-c tuner im lan haben... per wlan. ( kommentare zur performance -> /dev/null )
 
Zuletzt bearbeitet:
Moins


Probier mal: "http://fritz.box/?lp=wds2"
...und log dich mal ein.
 
lande ich auf der startseite ...
auf der 7490 öffnet es mir die gewünschte seite...

da das auf der 6490 failt, stocher ich mal blind in der suppe... die lua scripte dazu fehlen. nur: welche sind das? muss doch möglich sein, die aus ner z.b. 7490 fw rauszuholen und dort einzubinden... testweise mount -bind ...

weiterer stolperstein könnte der auf dem x86 laufende wland/hostapd sein ... aber: versuch macht kluch! ;)
 
Zuletzt bearbeitet:
Einfach default Route per telnet löschen und eigene setzten.bei Bedarf noch dns in die resolv.conf
ähm, :confused:
wenn die 6490 nicht repeater spielt, was soll ich das die default route auf der kiste neu definieren? ich hab kein lan kabel zwischen meinem netz und dem ort, wo der dvb-c anschlus ist ... aber mein wlan reicht dorthin. ergo: soll die 6490 main wlan repeaten, auf ihren lan buchsen mein lan ausspucken. repeater mode wie andere fritzboxen auch...
mein wlan ist in 10.16.0.0/12 während die 6490 bei mir am lan port auf 192.168.178.0/24 läuft. ( derzeit ) fritz.box habe ich durch die jeweilige ip der box ersetzt... falls das gemeint war.
 
Zuletzt bearbeitet:
6490
Schuss ins Grüne: x86? Hat doch eine eigene IP, oder?
:?: "http://192.168.178.254/lp=wds"
...würde mich belustigen wenn das funktioniert.
 
Zuletzt bearbeitet:
Für mich ist ein Repeater immer per Lan angebunden

Kannst du mal bitte erläutern warum ein WLAN-Repeater immer mit Ethernet-Kabel verbunden werden sollte? Das macht doch keinen Sinn, das wäre ja dann kein Repeater sondern ein AP.
Und wie würde man deine Vorstellung mit WLAN-Repeatern umsetzen die keinen LAN-Anschluss haben?
 
Genau das wollte ich auch schon monieren.
...aber da steht nix von: Kabel

Und so wie er es schrieb stimmt es.
...kann aber leicht missverstanden werden.
:rolleyes:

:doktor: Lustig, weil das Gehirn bei LAN gleich das Kabel mit rein assoziiert.
(Hatte den entsprechenden Post schon geschrieben, als es mir auffiel.)
 
Zuletzt bearbeitet:
Code:
 find / -name wd*.lua
/usr/www/avm/wds2_final.lua
/usr/www/avm/wlan/wds.lua
/usr/www/avm/wlan/wds2.lua
/var/remote/usr/www/avm/wds2_final.lua
/var/remote/usr/www/avm/wlan/wds.lua
/var/remote/usr/www/avm/wlan/wds2.lua
die scripte sind vorhanden. wie ruf ich die nun auf? bzw binde die so ein, das das webif die buttons anzeigt?
 
Was ist eigentlich Dein Ziel ... willst Du die Einstellungen im GUI sehen oder den Effekt der Einstellungen nutzen?

Bei letzterem solltest Du erst einmal in den Lua-Dateien nachsehen, welche Auswirkungen eine Änderung der Einstellungen hat und diese dann von Hand ändern.

Erst wenn das zum erwünschten Ergebnis führt und die 6490 tatsächlich ein virtuelles WLAN-Interface als STA einrichten sollte, dann braucht man ja das GUI wirklich. Das Problem dürfte aber schon da losgehen, wo sich dann die "WAN-Verbindung" für den "dsld" auf dem ARM-Core hinter dem x86-Core (und dem dort arbeitenden WLAN) befindet ... ich lasse mich aber gerne überraschen, wenn es tatsächlich funktionieren sollte.

Ansonsten bringt Dir ja nun ein sichtbares GUI ohnehin wenig, wenn die damit zu tätigenden Einstellungen gar nicht den gewünschten Effekt haben sollten.
 
letztendlich den effekt nutzen. da mir aber das lesen der lua scripte nicht viel aufschlus ergibt da ich es stumpf nicht verstehe dachte ich daran das vom webinterface "übersetzen" zu lassen.
 
Zuletzt bearbeitet:
Schau Dir die "wlan.cfg" der 7490 an (insb. die "STA_"-Einträge, das sind diejenigen, wo das betreffende Gerät seinerseits als "station" und nicht als "access point" (AP) arbeitet, wie es beim Zugriff auf das "originale" WLAN der Fall ist) und versuche die für die 6490 zu adaptieren. Allerdings werden aus dieser Datei dann erst beim Start des WLANs die endgültigen Konfigurationsdateien generiert, die findet man aber in den Support-Daten und da sieht man dann auch, welchen Effekt eine geänderte Einstellung in der "wlan.cfg" hat. Auch da kann man dann die 7490 und die 6490 halbwegs miteinander vergleichen. Jedenfalls bewirken alle Einstellungen im GUI auch nur Änderungen in den Dateien in /var/flash und eigentlich werden alle beim WLAN betroffenen Dateien auch in der Export-Datei ausgegeben, so daß man das Ergebnis einer Einstellung im GUI auch über die Export-Datei erreichen kann und wenn es dann schon nicht funktionieren will, braucht man für das GUI gar nicht erst weiter zu suchen.
 
:heul:
exportdatei 7490 6.60 ( eingreichtet als repeater ), aus der die wlan einstellungen in die 6490 mit 6.62 importiert. ( nur die wlan-settings ) führen zum reboot und danach nicht mehr leuchtenden wlan led sowie nur durch zurücksetzen der box wieder aktivierbarem wlan.
das war schon mal nen satz mit x... war wohl nix.
ich verusch es nochmal unter der 6.24. da lef das wlan doch noch auf dem arm, oder???
 
Ich habe auch nichts davon geschrieben, daß Du die Einstellungen einfach importieren solltest (na gut, den Versuch war es vielleicht wert) ... es geht um das Verstehen, was die Einstellungen bewirken (notfalls testet man das, wenn der Name der Einstellung zweideutig ist) und dann um die gezielte Änderung der Einstellung in der wlan.cfg der 6490.

Wenn Du das WLAN auf dem ARM-Core zum Laufen kriegen solltest, wird es Dir beim (vernünftigen) DVB-C-Streamen aber vermutlich auch wenig helfen ... der ARM-Core ist ziemlich lahm. AVM wird sich etwas dabei gedacht haben, wenn man dort den Aufwand getrieben hat, das WLAN auf den x86-Core zu schieben ... das ist ja nicht so ganz simpel, weil bei den anderen Modellen eben alles auf einem System arbeitet. Die Daten müßten dann auch erst noch vom x86-Core auf den ARM-Core geschafft werden, damit sie übers WLAN gesendet werden können ... alles Punkte, die man berücksichtigen muß und die (in meinen Augen und auch nur in der Theorie, nicht durch Messungen belegt) das als schlechte Idee erscheinen lassen.

Wie heftig der Unterschied bei der Performance ist, kann Dir schon jeder mit einem Telnet-Zugang auf beiden Kernen sagen ... im Vergleich zum x86-Core dauert schon das Login auf dem ARM-Core eine halbe Ewigkeit und da ist ja nun wirklich noch nichts los. Das gilt bei mir sogar dann, wenn der ARM-Core sich gar nicht um die DOCSIS-Anbindung kümmern muß, denn die Box arbeitet auch im "LAN1"-Modus - wenn da wirklich noch die DOCSIS-Daemons etwas zu tun bekommen, wird das vermutlich noch schlimmer.
 
Was mich mal interessieren würde:
Wie sind die beiden Cores denn verbunden? Kommunizieren die intern über IP? Der x86 hat ja seine eigene IP Adresse auf der .254. Oder können die intern über einen Bus oder gemeinsamen Speicher kommunizieren?
Das NAS scheint mir ja auf dem x86 zu laufen, was man meiner Meinung nach auch merkt, da der Zugriff etwas schneller ist als bei den DSL-Boxen.

Ansich mal eine interesante Architektur. Gibts irgendwo ein cat /proc/cpuinfo von den beiden Cores? Über den x86 hab ich nicht wirklich viel finden können.
 
Atom
Code:
# cat /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 53
model name      : Intel(R) Atom(TM) CPU  652   @ 1.20GHz
stepping        : 8
cpu MHz         : 1200.057
cache size      : 256 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm arat dts tpr_shadow vnmi flexpriority
bogomips        : 2400.11
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 53
model name      : Intel(R) Atom(TM) CPU  652   @ 1.20GHz
stepping        : 8
cpu MHz         : 1200.057
cache size      : 256 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
apicid          : 1
initial apicid  : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm arat dts tpr_shadow vnmi flexpriority
bogomips        : 2399.94
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

Arm
Code:
cat /proc/cpuinfo 
Processor       : ARMv6-compatible processor rev 4 (v6b)
BogoMIPS        : 449.74
Features        : swp half thumb fastmult edsp java 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 4

Hardware        : puma6
Revision        : 05e1
Serial          : 0000000000000000
 
Es gibt mehrere Möglichkeiten der Kommunikation ... einmal eine "mailbox", deren Treiber man in den veröffentlichten Quellen findet. Ansonsten kommunizieren die Prozessoren auch über IP-Verbindungen (der ARM-Core mountet z.B. einige Verzeichnisse des x86-Core per NFS, gleichzeitig gibt es einen AVM-Daemon (ptestd - eigentlich ein "Abfallprodukt" aus der Produktion, wo die produzierten Boxen beim Ausgangstest bzw. der Finalisierung mit einem "Server" kommunizieren, Rudimente davon kann man sich heute noch in der S42-ptest ansehen), der eine Kommunikation ermöglicht), dabei werden jedoch nicht die "offiziellen" IP-Adressen verwendet, sondern die 169.254.1.1 und 169.254.1.2 - die NFS-Freigaben sind auch darauf beschränkt und auch die "hosts.allow" beschränkt die Kommunikation der Dienste, die dort liegende Einstellungen berücksichtigen, auf den "localhost" (127.0.0.1) und das Netz 169.254.1.0/30.

Ansonsten gibt es genug andere Threads, wo auch solche Informationen wie die Ausgabe von /proc/cpuinfo schon mal aufgeführt wurden (irgendwann in der Zeit um Weihnachten 2014 startet das). Die Annahme, daß der x86-Core das NAS steuert, ist richtig ... bei der 6490 ergibt es auch einen gewaltigen Unterschied im Durchsatz, ob man die NAS-Funktionen unter der .1 oder der .254 (bzw. der jeweiligen Adressen der Cores, die sind ja nicht fix und hängen von der konfigurierten Maske ab) benutzt. Steht aber auch alles schon irgendwo im IPPF ...

- - - Aktualisiert - - -

Ich habe gerade mal nachgesehen ... es hat den Anschein, daß AVM den Intel-Treiber (arch/arm/mach-avalanche/puma6/arm_atom_mbx) für die "mailbox" gar nicht verwendet; jedenfalls kann ich keine entsprechenden Kernel-Symbole bei der 06.62 finden und ich will jetzt nicht beschwören, daß/ob ich den bei einer älteren Firmware für die 6490 oder bei einem anderen Puma6-Gerät gesehen habe.

Aber ein weiterer Treiber, der die Kommunikation auch ermögllicht (arch/arm/mach-avalanche/puma6/aep_drv) ist auch bei AVM im System vorhanden.
 
lsmod und rpc lsmod ist auch interessant...
schon krass was avm da so alles auf dem x86 macht...
dann mal über http://freetz.org/ticket/2862 nachgedacht ... ;)
 
Zuletzt bearbeitet:
Hallo,

ich wollte jetzt nochmal nachfragen ob es in die Richtung schon eine Lösung gibt? Ich selber habe auch eine 6490 mit DVB-C Funktion, die als DVB-C Tuner für mein Netzwerk/HTPC dienen soll, habe nur leider auch die örtlichen Gegebenheiten, dass meine Fernseherdose deutlich weg von meinem Netzwerk ist. Wenn sich also die 6490 in ein vorhandes WLAN einbinden lassen könnte und dann zum streamen des DVB-C Signals genutzt werden könnte, wäre das natürlich ein super Sache.

MfG
Borstel86
 
Warum ziehst Du es nicht andersherum auf ... die FRITZ!Box spannt halt (weiterhin im Router-Mode, bei LAN1 ohne großen zusätzlichen Stromverbrauch) ihr eigenes WLAN auf und dort kann man das TV-Programm dann auch empfangen. Wenn das jetzt zu einem noch weiter entfernten Client gelangen muß, dann muß eben eine WLAN-Bridge her (L2-transparent, sonst gibt es ab dort nur noch einen Stream, weil die Box pro Client-IP nur einen Stream liefert), die wieder das WLAN der 6490 per Ethernet weiterleitet ... dann zwei "nebeneinanderliegende" Netzsegmente verwendet (so daß man z.B. mit einer /23-Maske auf den Clients beide abdecken kann und nur jeweils die richtige Route braucht) und es sollte eigentlich funktionieren. Woran klemmt's denn genau?
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
244,696
Beiträge
2,216,700
Mitglieder
371,316
Neuestes Mitglied
realbluethunder
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.