BitSwitcher - neue Firmware für Speedport W500V

Habe das Problem gelöst.
Damit er Änderungen, die per ssh gemacht wurden auch speichert, muss ich über das Webinterface ebenfalls eine Änderung machen, dann klappts.
 
Stabilität?

Ich bin sehr interessiert an der Speedport W500V Bitswitcher Lösung. Was mir Sorge macht, ist jedoch obiger Kommentar:
mJOHm schrieb:
Aktueller Stand der Dinge ist momentan, dass mein WLAN nur eine gewisse Zeit lang nach dem Reboot funktioniert und dass auch nicht immer.

Ich brauche die VOIP Funktionalität nicht. Es geht mir ausschließlich darum, einen DSL Router, den ich manipulieren kann, mit WLAN einzusetzen.

Das System muß via Internet von mir wartbar sein, da ich es bei einer Freundin einsetzen werde, die selber völlig EDV-illiterat ist.

Voraussetzung ist, daß das System stabil läuft.

Ich wäre dankbar für Kommentare.
 
@Jochen

dein Problem war einfach nur dass du nach Änderungen im NVRAM ein 'nvram commit' absetzen musst damit die Änderungen persistent gespeichert werden. Deshalb hast du auch den Effekt beobachtet dass nach Änderungen über das Webinterface deine Änderungen erhalten blieben, da die cgi-Skripte natürlich ein 'nvram commit' machen.
Also demnächst mal die Dokumentation richtig lesen, da ist darauf eindeutig hingewiesen.
 
@noadsl
probiers doch einfach mal aus. Bei mir läuft WLAN ohne Probleme, sowohl im Client mode mittels custom_script und erst recht im AP-Modus über das Web-Interface. Voip kannst du ja abschalten wenn du es nicht brauchst und wartbar ist der Router natürlich per SSH oder telnet von außen.
 
Aktueller Stand der Dinge ist momentan, dass mein WLAN nur eine gewisse Zeit lang nach dem Reboot funktioniert und dass auch nicht immer.

Also mittlerweile funktioniert mein WLAN, man sollte halt nicht gerade den mixed mode b und g verwenden und nen Kanal < 11, dann tut's.

Das raustelefonieren funktioniert leider immer noch nicht. Hat niemand dasselbe Problem?
 
Zuletzt bearbeitet von einem Moderator:
neues Release BitSwitcher-Image 0.3.0

25. September 2008: BitSwitcher-Image 0.3.0

*stark überarbeitetes und erweitertes Web-Interface
*es ist eine 1MB große, beschreibbare JFFS2-Partion verfügbar
*es gibt ein Image mit OpenVPN und RADIUS-Server
*und vieles mehr…

Changelog

*Das Überwachungs- und Konfigurations-Tool von Broadcom cfm wurde entfernt und durch eine Reihe von Skripten und zusätzlichen Programmen ersetzt. Dadurch ist nun ca. 1MB des Flash frei.
*Der freie Flash-Speicher wird mit einer JFFS2-Partition genutzt. Damit steht nun eine ca. 1MB (im OpenVPN+RADIUS-Image hat ein ca. 448kB) große beschreibbare Partion zur Verfügung.
*nvram-Tool kann die Daten im NVRAM komprimieren (LZO)
* Alle Start-Skripte und CGI-Skripte wurden an die cfm-freie Umgebung angepasst.
*Das Layout des Web-Interface wurde modifiziert.
*Das Web-Interface wurde erweitert um:
oIndex
oSystem Settings (Date & Time, System passwort, Custom script, Reboot, Firmware update)
oNetwork Settings (Wireless LAN, DSL/WAN, Dynamic DNS, Firewall)
oPhone Settings (Phone options, Emergency call, Dail rules, Quick dail, Incoming calls, Outgoing calls)
oStatus (Connections, System utilization, WAN status, DSL status, DHCP)
oInformationen (About, Router information)
oPlugins
*Zu den neuen CGI-Skripten wurden ebenfalls die korrespondierenden Start-Skripte und ggf. Hilfsapplikationen (z.B. fwupdate für das Firmware update) ergänzt.
*Es wurde die Möglichkeit geschaffen, das Web-Interface mit Plugins zu erweitern. Plugins können in der JFFS2-Partition gespeichert werden. Flashen ist nicht nötig!
*Ein Portknocking Daemon (tportknockd) ist nun auch im Image enthalten.
*Es ist ein Image mit OpenVPN und/oder mit RADIUS-Server verfügbar. Das Image ohne OpenVPN und RADIUS besitzt eine ca. 1MB große JFFS2-Partition. Das Image mit OpenVPN hat eine ca. 448kB, das Image mit RADIUS hat eine ca. 576kB und das Image mit OpenVPN+RADIUS eine ca. 448kB große JFFS2-Partition.
*Iperf wurde hinzugefügt
*Einige Programme die vom cfm genutzt wurden, wurden ebenfalls entfernt.
 
Hi!

Hier mal ein kleiner Statusreport.
Ich habe gestern auf die 0.3.0 gewechselt. Nach dem ersten Schock das die DSL Verbindung nicht aufgebaut wird(standard=off) klappte aber fast alles gut. Es scheinen eine ganze Menge neuer Einstellmöglichkeiten dazu gekommen zu sein die vorher nur über Scripte zu ermöglichen waren.

Leider ist das Webinterface recht träge geworden und verharrt sehr oft beim speichern bei "please wait, transfer data" so das man den Menüpunkt nochmals auswählen muss.

Voip hab ich noch gar nicht benutzen können da ich bei Proxi/Registrar IP "sipgate.de" nicht eintragen kann sondern BS dort eine IP-Adresse verlangt. War das vorher auch schon so? Kann mich nicht mehr wirklich erinnern und wenn ja welche IP muss da rein?

Ansonsten sieht das schon sehr gut aus und ich freue mich das es dieses Projekt gibt.
 
So weitere Erkenntnisse.

Leider scheint dort noch was mit dem Routing oder ähnlicem nicht zu stimmen.

Ich habe reproduzierbar das Problem das ich mich weder bei MSN/Hotmail noch bei WOW anmelden kann. Auch scheint es so zu sein das der Webseitenaufbau doch recht träge wird(BB ok).
Mit einem anderen Modem geht es einwandfrei.

Lippton
 
@Lippton

Bei Registrar-IP muss wirklich eine IP-Adresse stehen, da dies an das Binary 'vodsl' übergeben wird, welches an dieser Stelle keinen Hostnamen akzeptiert. Deshalb vorher mal den Registrar-Namen, z.B. unter Windows mit 'nslookup sipgate.de' o.ä. auflösen und die IP direkt eintragen. Sipgate und andere VOIP-Einstellungen sind auch unter http://bitswitcher.sourceforge.net/doku.html#ata dokumentiert.

Das das Webinterface bei 'please wait, transfer data' verharrt sollte eigentlich nicht passieren. Ich habe aber auch schon beobachten können das offensichtlich die Broadcom-Treiber (Module) manchmal Probleme beim rein- und rausladen haben. Beispielsweise beim WLAN hängt der Router manchmal, weil sich das Modul 'wl.ko' nicht entladen lässt. Dies ist leider durch Broadcom-Programmierer verursacht und lässt sich nur mit einem Neustart beheben. Also falls es hängt stimmt irgendwas nicht und man sollte am Besten nochmal Neustarten.

Der träge Seitenaufbau könnte vielleicht mit den Firewall-Einstellungen zusammen hängen. Ich würde mal versuchen das Filtering abzuschalten: Firewall->General settings->Firewall off.
Ins Internet sollte man trotzdem kommen. Wenns dann besser ist, wieder einschalten und die Parameter Maximum Connections, TCP-timeout und UDP-timeout kleiner machen. Das sollte Speicher und Rechenzeit beim Tracking der aktiven Verbindungen einsparen und vielleicht gehts
dann besser. Zum Einloggen bei Hotmail und WoW kann ich grad nix sagen. Ich werds aber mal untersuchen und Bescheid geben wenn ich was raus finde.
 
@IP-Meister

Danke für deine Hilfe!
Der Sipaccount läuft nun wieder, hatte wohl nen grösseres Brett vor dem Kopf.

Behäbigen Seitenaufbau hatte ich noch nicht wieder, werde dann aber mal die Firewall wieder abschalten. Mit dem Problem bei WOW und Hotmail bewirkt das abschalten der Firewall aber keine Änderung.
 
Hallo!

Ich möchte an dieser stelle auch ein wenig Feedback geben und ein paar Fragen stellen.

Erstmal vielen Dank für die geniale Firmware, das hat mein Speedport vorm Mülleimer bewahrt ;-)

Ich habe bereits mit v0.2.1 ein wenig experimentiert und bin jetzt auf die 0.3.0 umgestiegen. Ziel ist es die Box als WLAN-ATA in einem vorhandenen Netzwerk zu betreiben, die betreffenden Ports werden vom Router weitergeleitet.

Leider klappt der WLAN client-Modus mit WPA-PSK bei mir nicht out-of-the-box über das Webinterface. Da ich das ganze aber schon bei v0.2.1 probiert und diesen Thread fleißig verfolgt habe, hatte ich auch schon den Verursacher des Problems gefunden: Das nas-binary. Scheinbar klappt mit den Parametern die vom dafür vorgesehenen script übergeben werden die Authentifizierung nicht, oder aber man muss nas generell erst einmal starten, killen und wieder starten.

Ein eine kleine custom_script.sh brachte die Lösung:
Code:
#!/bin/sh

#little script to fix a bug in wireless client mode, works for WPA-PSK only

#all webinterface-parameters need to be set correctly

wlctl disassoc

if (pidof nas); then
    kill -TERM `pidof nas`
    sleep 1
    if (pidof nas); then
        kill -KILL `pidof nas`
    fi
fi

nas -i wl0 -S -m 4 -g `nvram get wl_wpa_gtk_rekey` -s `nvram get wl_essid` -w 2 -k `nvram get wl_wpa_psk` & 
sleep 2

wlctl join `nvram get wl_essid` [key `nvram get wl_wpa_psk`] amode wpapsk

Damit wäre die wireless-bridge einsatzbereit, nun zum ATA:

Nach setzen aller Parameter klappt die Registrierung bei Sipgate schonmal und ich kann telefonieren.
Aber wenn ich mich bei Sipgate einlogge und checke mit welcher IP das Speedport registriert wurde, steht da immer die lokale IP der Box. Eigentlich nicht verwunderlich, das broadcom vodsl-binary wurde ja auch nicht zu diesem Einsatzzweck entwickelt und registriert sich wohl automatisch mit der IP-Adresse der in den Parametern angebenen Schnittstelle.

Jetzt meine Frage: (Wieso) Funktioniert es trotzdem?
Wenn nicht meine WAN-IP zur Registrierung bei Sipgate verwendet wird, sollten ja prinzipiell keine Pakete bei mir ankommen, oder?
Die meisten ATA's werden ja wohl hinter einem nat-router laufen... Bräuchte ich dann zwingend einen Router mit SIP-Proxy drauf um das mit Bitswitcher hinzubekommen?

Ich hatte sowas schon mit der v0.2.1 am laufen, da gings auch, nur ist da die Verbindung in der Regel nach so ca. 15min zusammengebrochen. Einen solchen "Langzeittest" habe ich jetzt mit der v0.3.0 noch nicht durchgeführt.

Die plötzlichen Verbindungsabbrüche habe ich eben auf das lokale-IP-Problem geschoben. Falls es wirklich daher kommt, gibts da noch einen anderen Lösungsansatz als einen SIP-Proxy im Router, zb. einen auf dem Speedport, der sich die WAN-IP mittels STUN-Server holt? Oder kann man vodsl irgendwie eine andere IP "unterjubeln", die man sich mittels script besorgt?

Vielen Dank schonmal!

Gruß,

Martin
 
Moin,
Erstmal besten Dank an die Macher dieser Firmware, ist echt klasse :)

Nun habe ich aber ein Problem: Hab das RADIUS+OPENVPN-Image drauf, läuft auch.

Aber jetzt versuche ich, meinen Speedport als VPN-Client einzusetzen. Die Verbindung kommt zustande, aber das wars auch schon, es kommen keine Pings durch und schließlich bricht die Verbindung wegen Timeouts ab. Im Web-Interface sind Pings im WAN aktiviert, aber selbst bei deaktivierter Firewall kommen keinerlei Pings durch. Hat irgendjemand eine Idee? Danke :)
 
mal ein kleines update zu meinem letzten post:

hhm, schande über mein haupt, scheinbar wird bei sipgate doch meine WAN-IP registriert (ist nur etwas verwirrend gestaltet und zeigt an anderer stelle eban auch die lokale ip an), also klappt das problemlos solange man die ports im nat-router freigibt und ein STUN-server wird erst von nöten wenn man keine ports freigeben kann? Hab jetzt mal ein 45min-telefonat geführt welches einwadfrei geklappt hat, jetzt steht als nächstes ein uptime-test an. Bei der v0.2.1 hat sich mein speedport reproduzierbar nach 9-10tagen uptime aufgehangen, mal sehen ob das mit der 0.3.0 auch weg ist, das wär schon top. Ach ja, und ein sehr merkwürdes Verhalten beobachte ich noch: Hin und wieder fährt der Router nach einem neustart zwar hoch, ist aber weder zu pingen noch sonst irgendwie zu erreichen. da hilft dann nur ein weiterer neustart..
 
@Lippton

In Punkto WoW versuch doch mal die von Blizzard vorgeschlagenen TCP-Ports: 3724 und 6881-6999 im Port-Forwarding einzutragen. Vielleicht löst es das Problem, weil es eigentlich nur an irgendwelchen Ports liegen kann.

@martin_muc

Das 'nas'-Problem kann ich leider nicht nachvollziehen, da bei mir die Verbindung bisher immer sofort geklappt hat. Ich hatte allerdings mal am Ziel-AP mal WPA-/WPA2-PSK mixed eingestellt und am Targa/Speedport nur WPA2-PSK. Da wurde dann auch keine Verbindung aufgebaut. Schau doch mal ob das vielleicht bei dir auch so ein Problem sein könnte und stelle am Speedport mal exakt das gleiche wie am Ziel-AP ein. Desweiteren schaue auch mal ob du den gleichen Kanal wie am AP eingestellt hast.

Zum Hängen beim Starten kann ich leider auch nix sagen, da kann man nur seriell den Bootvorgang überwachen um dem Problem auf den Grund zu kommen. Zum Dauertest kann der zeitgesteuerte Reboot Abhilfe schaffen. Hier kannst du z.B. immer Nachts einen Reboot durchführen lassen.

@LordPlatin

Zwecks OpenVPN müsstest du mal kurz erläutern welche Art von VPN-Verbindung du aufbaust. Ist es eine geroutete Punkt-zu-Punkt Verbindung (tun-Interface) oder ein Ethernet-Tunnel (tap-Device)? In beiden Fällen solltest du prinzipiell den VPN-Port per Portforwarding auf die lokale IP des Routers forwarden. Ausserdem muss natürlich das virtuelle Device, egal ob tun- oder tap-Device eine IP-Adresse bekommen und in der Firewall frei gegeben werden, z.B. 'iptables -A INPUT -i tap0 -j ACCEPT;iptables -A OUTPUT -o tap0 -j ACCEPT'. Aber wie gesagt du müsstest erstmal noch ein paar Worte zu deine VPN-Konfiguration verlieren.
 
@Lippton

In Punkto WoW versuch doch mal die von Blizzard vorgeschlagenen TCP-Ports: 3724 und 6881-6999 im Port-Forwarding einzutragen. Vielleicht löst es das Problem, weil es eigentlich nur an irgendwelchen Ports liegen kann.

Hiho!

Das half nicht, hätte mich aber auch gewundert da diese Ports meines Wissens nach nur für den Updater(peer2peer) gebraucht werden. Ich habe eben wieder auf die 0.2.1-1 gewechselt und nun auch keine Probleme mehr. Sollte also tatsächlich am 0.3.0 Image liegen.:(

Lippton
 
Glück Auf!

Habe gerade die neue FW installiert, werde mich jetzt erst mal tiefer damit beschäftigen. Was mir aber auffällt: die Englische Beschreibung hat an einigen stellen noch kleine Fehler, z.B.:

STP is used by bridges or switches and protects your LAN from network loops but sends STP datagrams every
few seconds through the whole network. If your LAN is certainly loop free, disable this to avoid senseless traffic.

Oder:
Dial settings
>> Emergency call
>> Dial rules
>> Quick dial

Heute Nachmittag bekomme ich noch einen SP 500V (ohne WLAN), da probiere ich mich auch mal daran. Hat schon jemand die FW damit getestet?

UPDATE:
Bitswitcher 0.3.0_OPENVPN_RADIUS funktioniert auf dem SP500V. Das einzige Problem dabei: Ich bekomme beim Aufruf des Web-IF regelmäßig Kernel-Oops auf der Konsole. Scheinbar wird jedesmal stumpf das wlctl aufgerufen, obwohl gar kein wlan da ist:
Code:
CPU 0 Unable to handle kernel paging request at virtual address c00ac000, epc == c00ac000, ra == 8011ee78
Oops in arch/mips/mm/fault.c::do_page_fault, line 167[#1]:
Cpu 0
$ 0   : 00000000 00000000 c00ac000 00000004
$ 4   : 80f61000 80196b0c 80f61000 00000000
$ 8   : ffffffff 0000000a 00000000 666f2063
$12   : 80337238 fffffffd 0000000a ffffffff
$16   : 80f61000 80f99f18 80f61000 00001000
$20   : 10003168 00000000 80f99f30 80c45f18
$24   : 00000000 00000000                  
$28   : 80c44000 80c45e20 00000000 8011ee78
Hi    : 00000000
Lo    : 00000000
epc   : c00ac000     Tainted: P  
ra    : 8011ee78 Status: 1000fc03    KERNEL EXL IE 
Cause : 00800008
BadVA : 80f99f18
PrId  : 00029107
Modules linked in: ipt_MASQUERADE iptable_filter iptable_nat ip_conntrack ip_tables endpointdd bcm_enet bcmprocfs blaadd atmapi
Process ifconfig (pid: 317, threadinfo=80c44000, task=802f4640)
Stack : 80f9f960 0000000d 80f61800 00000000 00000000 00000000 00000000 00000000
        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        00000000 00000000 00000000 800618c4 80f99f18 00000239 8008b554 8008b370
        00000000 8006a90c 80ab9d80 00030002 00000000 00000003 00000000 00000004
        fffffff7 80c17a60 00001000 80c45f18 10003168 00000025 00000000 00000000
        ...
Call Trace: [<800618c4>]  [<8008b554>]  [<8008b370>]  [<8006a90c>]  [<8006b65c>]  [<800c53a8>]  [<8006b8f4>]  [<80062ce4>]  [<8001a788>] 

Code: (Bad address in epc)

Ansonsten läuft das ganze soweit, etwas instabil wirkt noch die Interaktion von Webinterface und System. Im großen und ganzen aber schon mal gute Arbeit! Danke! Da sind die Kisten jetzt doch noch zu etwas nütze.

_.-=: MFG :=-._
 
Zuletzt bearbeitet:
@Lippton

Wegen Webseiten und WoW bin ich gerade am Testen. Hab leider kein DSL und hab deshalb mal das WLAN-Interface als WAN-If in der Firewall deklariert. Da gabs weder mit Webseiten noch mit WoW Probleme. Kann also nur vermuten das es nicht an der Firewall oder am NAT liegt sondern irgendwie mit der PPP-Einwahl zusammenhängt. Wie gesagt ich geb´n Update wenn ich was rausfinde.

@MrMcCrash
Schöne Hinweise bis jetzt, die Rechtschreibfehler werden sicher berücksichtigt. Wegen 'wlctl' kann natürlich keiner Ahnen das ein Userspace Tool nen Kernel-Oops auslöst nur weil das wl-Modul nicht geladen ist.
BS war aber bisher auch nicht für den normalen 500V gedacht. Vielleicht lässt sich ja die Board-Version zur Laufzeit ermitteln und man kann im Web-Interface und den Startscripten dann dynamisch drauf reagieren um solche Meldungen zu vermeiden.
 
@IP-Meister

Fein! Freue mich wenn es da Neuigkeiten gibt. Kann es auch gerne vorab testen da ich eh noch nen zweite Router als Backup habe.
 
So, habe mal etwas weiter getestet.

Beide Geräte (Speedport 500V und Speedport W500V) laufen bisher stabil. bis auf die Kernel-Oops auf dem 500V (ohne WLAN) sind erstmal keine Fehler aufgetreten. Habe auf beiden Geräten jetzt SSH und OpenVPN konfiguriert und laufen. Die Geräte sind bei mir am vorhandenen Netzwerk angebunden, laufen also ohne WLAN, DSL, VoIP etc.

Ich werde das ganze mal weiter testen und berichten.

EDIT:
Was mir noch fehlen könnte: Avahi als ZeroConf/Bonjour Server/Client

_.-=: MFG :=-._
 
Zuletzt bearbeitet:
Danke

Freu mich über die neue Firmware.
Hat alle meine Probleme die ich bisher hatte beseitigt.
Wollte mich nur kurz bei den Entwicklern bedanken.
Kann Bitswitcher nur weiterempfehlen. :schleime:
 
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.