[HOWTO] 7170 mit UMTS Stick

Da ich so schnell kein ungelocktes Huawei Modem bekomme, habe ich den ZTE noch mehrmals in die Hand genommen und an diverse Machinen hin- und hergestöpselt.
Die SIM selbst, habe ich im Handy ausprobiert, funktioniert bestens. Es ist also keine Sperre vom ISP im Spiel.
Der Ubuntu Maverick mag den Stick scheinbar nicht mit dieser SIM, obwohl der Stick zum PLDT-Plan mitgeliefert wurde! Stecke ich eine SUN-Sim rein, dann wählt er sich auf dem Maverick problemlos ein. Also Stick ist scheinbar ok!

Es ist mir auch gelungen das option.c script zu ändern bevor es kompiliert wird. Nicht mit Control+C, wie es der Vorgänger gemacht hat, aber immerhin gelungen.
Diesmal werden auch die selben Treiber geladen, wie bei den Vorpostern zu sehen.
Auch beim Einwählen habe ich einen Fortschritt errungen, aber keinen Durchbruch.

Code:
/var/mod/root/fritzextern # ./init.sh 
/var/mod/root/fritzextern # ./connect.sh 
AT&F
OK
ATE1
OKEinwahl....
AT+CGDCONT=1,"IP","weroam"
OK
ATD*99#
CONNECTchat:  Jan 01 08:05:10 CONNECT 3600000
Serial connection established.
using channel 1
Using interface ppp0
Connect: ppp0 <--> /dev/ttyUSB2
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x25bf9821> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x13 <asyncmap 0x0> <auth chap MD5> <magic 0x14fb2da> <pcomp> <accomp>]
sent [LCP ConfAck id=0x13 <asyncmap 0x0> <auth chap MD5> <magic 0x14fb2da> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x25bf9821> <pcomp> <accomp>]
rcvd [LCP DiscReq id=0x14 magic=0x14fb2da]
rcvd [CHAP Challenge id=0x1 <806212cba82901240ee755c8e2aeb47f>, name = "UMTS_CHAP_SRVR"]
sent [CHAP Response id=0x1 <5c2604fc674a1357212120faf746998f>, name = "pldt@weroam"]
rcvd [CHAP Success id=0x1 ""]
CHAP authentication succeeded
CHAP authentication succeeded
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Modem hangup
Connection terminated.

Einmal hatte ich auch mehr Zeilen bekommen:
Code:
CHAP authentication succeeded
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
rcvd [IPCP ConfNak id=0x1 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Modem hangup
Connection terminated.

Das ist jetzt ein rein technisches Problem.
Warum die Verbindung nach erfolgreicher Authentifizierung reisst, kann mehrere Ursachen haben, wenn ich hier http://pptpclient.sourceforge.net/howto-diagnosis.phtml#lcp_no_network_protocols richtig gelesen habe.

Warum komme ich mit meinem Handy ins ISP-Netzwerk und hier nicht?
 
Der Link bezieht sich auf Probleme mit PPP über PPTP.
Hier wird anscheinend die Verbindung getrennt, nachdem schon PPP-Pakete ausgetauscht wurden und die Anmeldung erfolgreich war.
 
Ich vermute, dass der Provider anhand der Modem-Kennung IMEI die Verbindung trennt. Mit anderen SIM-Cards geht es ja. Also nicht den Kopf zerbrechen, warum das jetzt so ist, und die anderen Sticks bei mir, Huawei E153 und Huawei E1552 mit customized Firmware bekomme ich nicht gecrackt.
Wir müssen ja irgendwie weiterkommen bei mir.

Ich schrieb, dass ich mit meinem Handy (Nokia E51) ohne Probleme mit der PLDT-SIM surfen kann. Und genau DA wollte ich ansetzen.
Genau! -> Das Handy per USB-Kabel an die Box ran.

Mein Maverick kriegt das zwar hin...
Code:
[136771.280046] usb 5-1: new full speed USB device using uhci_hcd and address 2
[136771.579678] cdc_acm 5-1:1.10: ttyACM0: USB ACM device
[136771.591259] cdc_acm 5-1:1.12: ttyACM1: USB ACM device
[136771.593215] usbcore: registered new interface driver cdc_acm
[136771.593219] cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters
[136771.626471] NET: Registered protocol family 35
[136771.712913] usbcore: registered new interface driver cdc_ether
[136771.768791] usbcore: registered new interface driver cdc_phonet
[136771.769375] usbcore: registered new interface driver rndis_host
[136771.920067] usbcore: registered new interface driver rndis_wlan
aaaaaber....
Ohne cdc-acm Kernel-Modul wird das bei Freetz nix!

Ich weiss jetzt, dass die ausgewählten Module unter "make kernel-menuconfig" nicht automatisch ins Image gelangen, aber selbst beim Eintrag in die kernel/config.in

config FREETZ_MODULE_cdc-acm
bool "cdc-acm.ko"
select FREETZ_MODULE_usbcore
default y

spuckt das "make" danach einen Fehler aus:
./.config: line 387: FREETZ_MODULE_cdc-acm=y: command not found

Da ist es sehr ärgerlich, wenn man mit der Entwicklungsumgebung sonst nicht viel am Hut hat, dass man kaum weiss, was man in die "fwmod_custom" reinschreiben soll, oder die Sache sonst ins Image bekommen kann.

Das cdc-acm.ko ist ja schon mal da, unter...
freetz-1.1.4/kernel/modules-8mb_26-04.80/drivers/usb/class/cdc-acm.ko

Um die Fehlermeldung los zu werden lösche ich im .config die Zeile 387 und entferne den Eintrag im Config.in !
Und dann?
 
Der Eintrag sollte so aussehen:
Code:
config FREETZ_MODULE_cdc_acm
bool "cdc-acm.ko"
default n
Gruß
Oliver
 
Da ist es sehr ärgerlich, wenn man mit der Entwicklungsumgebung sonst nicht viel am Hut hat, dass man kaum weiss, was man in die "fwmod_custom" reinschreiben soll, oder die Sache sonst ins Image bekommen kann.
Was will uns dieser Satz sagen?

In den Konfig-Namen dürfen keine Minus-Zeichen verwendet werden. Nimm statt dessen einen Unterstrich.
 
Ha! Leute, ich liebe euch!
Hier ein dmesg-Ausschnitt, eine SUN- und eine PLDT-Connection, sowie ein Ping-Test mit PLDT.
Code:
dmesg-Ausschnitt
usb 1-1: new full speed USB device using ahci and address 2
cdc_acm 1-1:1.10: ttyACM0: USB ACM device
mcfw: group 0.0.0.0: query cpmac:0 10sec
usb 1-1: USB disconnect, address 2
usb 1-1: new full speed USB device using ahci and address 3
cdc_acm 1-1:1.10: ttyACM0: USB ACM device

/var/mod/root/fritzextern/gsm_connections # ./init_sun_sbw350_e51.sh 
1...
2...
3...
4...
5...
6...
7...
8...
9...
AT&F
OK
ATE1
OKEinwahl....
AT+CGDCONT=1,"IP","minternet"
OK
ATD*99#
CONNECTconnect OK
chat:  Jan 01 08:37:42 CONNECT
Serial connection established.
using channel 1
Using interface ppp0
Connect: ppp0 <--> /dev/ttyACM0
rcvd [LCP ConfReq id=0x0 <auth pap> <mru 1500> <asyncmap 0xa0000>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x655ec430> <pcomp> <accomp>]
sent [LCP ConfAck id=0x0 <auth pap> <mru 1500> <asyncmap 0xa0000>]
rcvd [LCP ConfRej id=0x1 <magic 0x655ec430> <pcomp> <accomp>]
sent [LCP ConfReq id=0x2 <asyncmap 0x0>]
rcvd [LCP ConfAck id=0x2 <asyncmap 0x0>]
sent [PAP AuthReq id=0x1 user="guest" password=<hidden>]
rcvd [PAP AuthAck id=0x1 ""]
PAP authentication succeeded
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>]
rcvd [IPCP ConfReq id=0x0 <addr 10.6.6.6>]
sent [IPCP ConfAck id=0x0 <addr 10.6.6.6>]
rcvd [IPCP ConfNak id=0x1 <addr 10.172.3.1>]
sent [IPCP ConfReq id=0x2 <addr 10.172.3.1>]
rcvd [IPCP ConfAck id=0x2 <addr 10.172.3.1>]
replacing old default route to lan [192.168.xxx.x]
local  IP address 10.172.3.1
remote IP address 10.6.6.6

/var/mod/root/fritzextern/gsm_connections # ./init_pldt_e51.sh 
AT&F
OK
ATE1
OKEinwahl....
AT+CGDCONT=1,"IP","weroam"
OK
ATD*99#
CONNECTchat:  Jan 01 10:14:19 CONNECT
Serial connection established.
using channel 2
Using interface ppp0
Connect: ppp0 <--> /dev/ttyACM0
rcvd [LCP ConfReq id=0x0 <auth pap> <mru 1500> <asyncmap 0xa0000>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x6855950> <pcomp> <accomp>]
sent [LCP ConfAck id=0x0 <auth pap> <mru 1500> <asyncmap 0xa0000>]
rcvd [LCP ConfRej id=0x1 <magic 0x6855950> <pcomp> <accomp>]
sent [LCP ConfReq id=0x2 <asyncmap 0x0>]
rcvd [LCP ConfAck id=0x2 <asyncmap 0x0>]
sent [PAP AuthReq id=0x1 user="pldt@weroam" password=<hidden>]
rcvd [PAP AuthAck id=0x1 ""]
PAP authentication succeeded
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
rcvd [IPCP ConfReq id=0x0 <addr 10.6.6.6>]
sent [IPCP ConfAck id=0x0 <addr 10.6.6.6>]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
rcvd [IPCP ConfNak id=0x1 <addr 122.52.38.94> <ms-dns1 124.106.7.2> <ms-dns3 124.106.6.2>]
sent [IPCP ConfReq id=0x2 <addr 122.52.38.94> <ms-dns1 124.106.7.2> <ms-dns3 124.106.6.2>]
rcvd [IPCP ConfAck id=0x2 <addr 122.52.38.94> <ms-dns1 124.106.7.2> <ms-dns3 124.106.6.2>]
local  IP address 122.52.38.94
remote IP address 10.6.6.6
primary   DNS address 124.106.7.2
secondary DNS address 124.106.6.2

/var/mod/root/fritzextern/gsm_connections # ping 74.125.71.147
PING 74.125.71.147 (74.125.71.147): 56 data bytes
64 bytes from 74.125.71.147: seq=0 ttl=45 time=800.864 ms
64 bytes from 74.125.71.147: seq=1 ttl=45 time=698.241 ms
64 bytes from 74.125.71.147: seq=2 ttl=45 time=707.227 ms
64 bytes from 74.125.71.147: seq=3 ttl=45 time=676.157 ms
64 bytes from 74.125.71.147: seq=4 ttl=45 time=626.081 ms
64 bytes from 74.125.71.147: seq=5 ttl=45 time=714.003 ms
64 bytes from 74.125.71.147: seq=6 ttl=45 time=723.921 ms
64 bytes from 74.125.71.147: seq=7 ttl=45 time=654.854 ms
64 bytes from 74.125.71.147: seq=8 ttl=45 time=724.734 ms
64 bytes from 74.125.71.147: seq=9 ttl=45 time=734.695 ms

Im modifizierten Image sind alle Device-Nodes, bzw. Knotenpunkte schön eingerichtet, aber den ttyACM0 musste ich mit "mknod" selbst erstellen.
Zuerst hatte ich bedenken, dass das nicht geht.

Jetzt bleibt nur noch das DNS-Problem und das richtige Routing mit IP-Tables!
Das zaubern wir auch noch hin!

Gruß
Nik
 
Zuletzt bearbeitet:
Ich haaaab's!
Funct wie 'ne eins!

Sofern man die DNS-Server einmal gecaptured hat, kann man sie beim booten in die /etc/resolv.conf reinscripten:

cat meine_resolv.conf > /etc/resolv.conf
Erledigt!

Beim Erstellen der Iptables, wusste ich gar nicht was ich anwählen soll.
Erst hier sagt jemand deutlich was Sache ist.

Ich muss zu meiner Schande gestehen, dass die Firewallregeln (iptables) auf meiner NSLU2, nicht ganz richtig waren. Die hier
tuen es besser.
Leider behauptet @MaxMuster, dass sein VoIP so funktioniert, was bei mir nicht der Fall ist.
In der FritzGui lese ich unter DSL: "not connected", was ja logisch ist, weil es keins gibt (Deswegen blinkt auch die Power-LED so nervig) und unter Internet Telefonie steht lediglich "Number XXXXXXXX, no Internet connection", was für mich eigentlich bedeutet, dass da irgendwo eine Prüfung im System ist, die ich ausschalten muss, weil ja pingen, DNS-Auflösung und Internet geht.

Durch Umändern des TCP-Ports von Fritz WebGui in der ar7.cfg, konnte ich den Apache dort hinrücken, dadurch spare ich mir eine Forwarding-rule. Nicht ganz, Port 80 muss ich natürlich trotzdem öffnen :rolleyes:

Nachtrag:
Fritzbox in den Clientmode versetzen, als DNS Server, die von eurem UMTS verwenden und als Gateway die letzte Zahl auf einen Pseudorechner verlinken, Schwups -> Die Power-LED remains steady and the VoIP can flow! Ahhhhh!

Zwei Gateways im selben Subnet!!
Nicht so doof, wie der ICS in Microsoft, wo die IP am Schluss eine 1 haben muss!
Linux machts möglich!

Gruß
Nik
 
Zuletzt bearbeitet:
Hi Nik.
Schön, dass es endlich funktioniert. Magst du vielleicht mal deinen Weg beschreiben? Oder wo lagen bei dir die Stolperstellen. Ich würde dann im ersten Posting ein Verweis auf deinen Thread (oder so) machen.

Danke
Oliver
 
Sorry für die späte Antwort, musste noch das Handy repositionieren für einen besseren Empfang.

Weicht vielleicht etwas vom Thema ab, aber wenn's jemand wissen will, wie man die beste Position ermittelt:
Man baut eine Verbindung auf und pingt dann ohne limit z.B. google.com an. Man kanns auf verschiedenen Wegen probieren. Das mitgelieferte USB-Kabel eines Nokia ist meist lang genug, um das Handy hinzulegen und die Pingzeit beobachtend, im, oder gegen den Uhrzeigersinn milimeterweise zu drehen. Oder das Handy an einer Flaschenwand entlanglehnen und langsam daran herumführen, um am Ende dort stehen zu bleiben, wo man wahrnehmungsmässig die niedrigsten Pingzeiten erhält.
Was die Signal-Anzeige am Handy vorgibt, entscheidet nicht grundlegend über die Qualität der Verbindung! Niedrige Pingzeiten, am besten ohne Paketverluste sind hier anzustreben.
Die Position des Empfangsequipments als Ganzes ist da noch zu beachten. Es kann also schon passieren, dass man im Wohnzimmer einen schlechten Empfang hat, während am Klofenster der volle Pegel ausschlägt. Ist halt Glücksache. Ideal wäre es, wenn man das ganze auf dem Dach im Freien montieren könnte, aber da wird wohl kein Handy und keine Fritzbox mitmachen.

Und noch etwas wichtiges! Wenn ihr diese Zeilen beim pppd Verbindungsversuch mit mehreren Wiederholungen seht, dann ist eure Verbindung vermutlich grottenschlecht. Meist enden diese mit "script failed". Das Handy bettelt das Peer nach seiner zukünftigen IP an, aber das Peer kann nichts hören, weil der Client zu tief im Wald sitzt, mit vielen Bäumen dazwischen. Das Empfangssignal am Handy ist da nonsens, weil die Sendeleistung ebenso stimmen muss!
PAP authentication succeeded
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>]
rcvd [IPCP ConfReq id=0x0 <addr 10.6.6.6>]
sent [IPCP ConfAck id=0x0 <addr 10.6.6.6>]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>]
Ich hoffe, ihr macht dann nicht den Fehler am Script weiterzubasteln, bis es Nutzlos wird. Besser ist es dann wohl das Handy nur im GSM-Modus zu betreiben. Hat mich viel Zeit gekostet, um das rauszufinden.
Und wenn das Handy bereits im GSM-Only-Modus sein sollte, müsst ihr den Platz wechseln.
Am besten den Handy-Browser starten, dann seht ihr wie schnell, oder überhaupt die Verbindung zustande kommt.

Da ich nicht den ppp-cgi -Weg gegangen bin, musste ich natürlich die Scripte mit dem startup.sh in die zugehörigen Ordner reinpflanzen. Dabei sei jedoch anzumerken, dass es direkt nach dem booten erstmal kein /etc/ppp/peers gibt, sondern erst mit einer gewissen Verzögerung zum Vorschein kommt.
Daher muss euer Startup eine Prüfung enthalten, um erst dann die Kopiervorgänge zu veranlassen:
Code:
# copy data
cd /var/mod/root/meinexternesverzeichnis
directory="/etc/ppp/peers"
while [ ! -d $directory ]; do
	sleep 1
done
cp chat /var/mod/sbin/
cp vodafone_einwahl /etc/ppp/peers
cp o2_einwahl /etc/ppp/peers
cp ppp-off /var/mod/sbin
cp init_vodafone /var/mod/sbin
cp init_o2 /var/mod/sbin
cp ip-pre-up /etc/ppp/
[COLOR="red"]...und so weiter![/COLOR]
Im Fehlerfall ist diese While-Schleife endlos. Deshalb umändern, nach euren Bedürfnissen!

Und noch eine Kleinigkeit: Das option-Modul ist für den "Handy als Modem"-Betrieb nicht erforderlich!
Bitte nicht vergessen das Nokia im USB-Modus "PC Suite" zu stellen!
Im dmesg sollte folgendes zu finden sein:
Code:
usb 1-1: new full speed USB device using ahci and address 2
cdc_acm 1-1:1.1: ttyACM0: USB ACM device
Falls die zweite Zeile fehlt, dann habt ihr wahrscheinlich das "modprobe cdc_acm" verhunzt, bzw. nicht in die Freetz/modules eingetragen, oder ihr habt das Teil noch gar nicht im Image (Postings davor abchecken).
Und da ich ebenso erfolgreich ein Nokia Express Music 5800 in diesem Environment betrieben habe, habe ich den Verdacht, dass auch andere USB-Modelle genauso als usbserial-Device erkannt werden können. Demnach ist sogar ein 56k-USB-Modem an einer FritzBox 7170 möglich. Das muss man sich mal geben. Nicht jeder wohnt in einer Stadt, gell!?

Wer sich in die "man" von PPPD eingelesen hat, dem sind sicherlich auch die Scripte für ip-up, ip-down, sowie ip-pre-up aufgefallen. Ins ip-up gehört z.B. das starten eines Inadyn-MT (Nur bei public IP von Interesse). Ins ip-pre-up kann man die iptables starten, bevor das Interface steht. Und da der Inadyn ohne Verbindung nix bringt, kann man ihn im ip-down script stoppen. Man kann die Routen auch beim booten setzen. Ist halt Geschmacksache.

Wer das ip-pre-up benutzt, hat auch den Vorteil, dass er seine Firewall etwas einfacher verstellen kann.
Danach muss er die Verbindung nur kurz kappen und wiederherstellen. Dadurch tritt die neue Regel in Kraft.
Nachtrag: Das muss er nichtmal. Er führt einfach das veränderte ip-pre-up aus. Fertig!
Die Scripte (ist auch in der "man" so angegeben), außer das ppp-off (das gehört in die /var/mod/sbin), sollen beim Bootvorgang in die /etc/ppp/peers/* rein (Der pppd holt sich diese von dort automatisch).
Im ip-pre-up müssen die Tables dazu immer zuvor geflusht werden, also die Toilette runtergespült werden. Alles im selben Script.
Code:
iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain

iptables [COLOR="red"]<-Wie in meinem Post zuvor erwähnt[/COLOR]

Im Grunde genommen steht hier in den 14 Seiten bereits alles drin.
Es wird vorkommen, dass es bei der 1.1.4 Freetz nach einem "make dirclean" bei der Image-Erzeugung plötzlich Fehlermeldungen hagelt, aber kaum hat man ein neues Freetzarchiv entpackt und die .config mit dem Ordner "dl" von zuvor hineinkopiert, kann's weiter gehen. Nochmals Danke an alle!

@Olistudent: Ich benutze NFS-Freigaben in meinem Netzwerk. Den Weg mit dem ppp-cgi bin ich nicht gegangen, und statt eines UMTS-Sticks, klemmt ein Nokia WCDMA-Handy an der USB-Buchse. Wie viele da draussen die selbe Konstellation wie ich haben, wissen wir natürlich nicht, aber ich bin gerne bereit mit hilfreichen Informationen zu diesem Thema weiter zu helfen, so wie hier z.B. Viele Leute haben jetzt nach drei Jahren neue Boxen und befassen sich natürlich mit diesen.


Gruß
Nik
 
Zuletzt bearbeitet:
Hallo zusammen,
ich habe alles entsprechend Wiki "http://freetz.org/wiki/packages/ppp" eingerichtet. Das UMTS-Stick verbindet sich auch ordnungsgemäß mit dem Internet.
Aber leider funktioniert die Namensauflösung nicht. Ich habe schon alles probiert, -ich komme einfach nicht weiter 
Kann mir jemand Hilfestellung geben.

Otto
 
Hallo Otto,

ich hatte mit der Namensauflösung anfangs auch Probleme. Letztenendes habe ich die DNS-Server fest eingetragen, das funktioniert seitdem sehr gut.

Viele Grüße
Michael
 
Zuletzt bearbeitet:
Hallo Michael,
an welcher Stelle? Auf der Box? Auf dem PC?
Ich habe gestern abend mal den DNS-Server auf dem PC eingetragen und dann funktioniert es. Aber auf der Box bekomme ich es nicht hin.
Weißt Du noch wo der Eintrag hingehört?

Gruß
Otto
 
Moin Otto,

ich habe den DNS-Server-Eintrag irgendwo in den Skripten untergebracht. Ich komme gerade nicht an die Box ran und kann nicht nachsehen.

Viele Grüße
Michael
 
Hi Leute,

habe folgendes Problem:

Nach einem Stromausfall findet meine 7140@7170 mit der aktuellen freetz stable den UMTS-Stick (Vodafone/Huawei K3520) nicht mehr.
Reboote ich die Box dann über das Webif wird der Stick wieder erkannt und die UMTS Verbindung wird wie gewünscht aufgebaut.
Da ich die FB aber als ovpn-Client an einem entfernten Ort installieren möchte kann ich die Box ohne UMTS Verbingung nach einem Stromausfall ja nicht rebooten.
Notlösung wäre über cron einen täglichen Reboot ausführen zu lassen aber vielleicht kennt von Euch ja noch jemand eine bessere Lösung.

Gruß,
Benny

EDIT:

@ottohahn
im Fritzbox webif unter Internet > Zugangsdaten > Internetzugang über LAN1 auswählen, dort IP, Sub, eintragen und als Gateway irgendeine unbenutzte IP aus deinem Netz eintragen. Unter Pri. und Sec. DNS die Nameserver der Mobilfunkverbindung eintragen die Du in der Freetzoberfläche unter Status > ppp-cgi bei aktiver Verbindung angezeigt bekommst.
 
Zuletzt bearbeitet:
@handy-style
nimm einfach eine herkömmliche Zeitschaltuhr > 00.01 Uhr off / 00.02 Uhr on.
dies führt in jedem Fall einen sauberen reboot aus.
 

Hello Benny,
das gleiche Konstrukt habe ich auch gebaut. Bei mir bootet die Box sauber durch und erkennt den UMTS-Stick (Huawei E173) ordnungsgemäß. Ich hatte nur ein Problem mit dem OpenVPN start. Ich starte den Dienst jetzt 60s später und siehe da, -alles läuft.
Eine Woche arbeit, -viel lesen und Forum-Unterstützung. :D
 
Zuletzt bearbeitet von einem Moderator:
@infomerex

Zeitschaltuhr hat in meinem Fall den selben Effekt wie ein Stromausfall, daher unbrauchbar.
Hab die Lösung jedoch gefunden warum der UMTS-Stick nach einem Stromausfall nicht mehr erkannt wird.
Hab das Virtuelle CD-Rom auf dem Stick deaktiviert, nun klappt alles ;)
Vermutlich kam beim restart nach einem Stromausfall etwas mit der USB-Adresszuweisung durcheinander.

Gruß,

Benny
 
habs jetzt auch endlich bei meiner 7170 und E1550 hinbekommen.
Wichtig für die Namensauflösung und das routing ist auf alle Fälle iptaples (mit MASQUERADE) zum laufen zu bringen und die DNS einträge zu machen.

Iptables -> Regeln
Code:
# Generated by iptables-save v1.4.11.1 on Sat Jan  1 01:04:22 2000
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A POSTROUTING -o ppp0 -j MASQUERADE
-A POSTROUTING -o ppp0 -j MASQUERADE
-A POSTROUTING -o ppp0 -j MASQUERADE
COMMIT
# Completed on Sat Jan  1 01:04:22 2000
# Generated by iptables-save v1.4.11.1 on Sat Jan  1 01:04:22 2000
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i ppp0 -j DROP
-A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i ppp0 -j DROP
-A FORWARD -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i ppp0 -j DROP
-A FORWARD -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i ppp0 -j DROP
COMMIT
# Completed on Sat Jan  1 01:04:22 2000

DNSmasq aktivieren mit zusätzlichen optionen:
-r /etc/ppp/resolv.conf -S 208.67.220.220 -S 208.67.222.222
 
Hallo waldoo,

nach welcher Anleitung bist Du vorgegangen?
Wo fängt man aktuell am besten an?


MfG

Fritzix
 
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.