Suchergebnisse

Moin! Dann hast Du wohl beim Anpassen der 'profile' den Bootstrap zerscchossen - oder die Datei-Attribute für die profile vielleicht geändert!? (wenn ma einmal den bootstrap aktiv hat, braucht man die profile nicht mehr ändern - das macht man dann alles auf dem Stick) mfg, emkay

Moin! Vielleicht in dem Zusammenhang interessant (vielleicht auch nicht ) Hab' eben endlich eine (in meinen Augen) halbwegs zuverlässige Möglichkeit gefunden, recht einfach an die externen IPs zu kommen.. IPv4:Quellcode (1 Zeile) IPv6:Quellcode (1 Zeile) Akamai ist in meinen Augen zuverlässig und vertrauenswürdig genug als Service für sowas Wenn man wget eine 'binding-address' mitgibt, sollte man auch das jeweilige Interface vorgeben können. mfg, emkay

Man hat ja andererseits den Vorteil, daß man nach Anstecken der COM sofort eine Console hat - auch ohne Anpassung der Config. Das spart 'ne Menge Zeit. Mein SPH läuft zB. mit der Standard-Config - die 'innere Firewall' und Telnet passe ich in der /etc/profile an. -- automatisiert per sed-Befehl Ich brauch' also wohl länger zum Öffnen des SPHs, als für die eigentlichen Anpassungen... mfg, emkay

Moin @q6676790! Naja, man muß ja keine der fertigen Komplettlösungen nutzen... Einfach den Basis-Bootstrap - dann kann man 'bottom-up' einbauen, was man persönlich haben möchte (naja - Telnet oder SSH ist wohl fast immer sinnvoll ) Pins für den Kurzschluß nach außen zu führen ginge wohl - aber da braucht's 'ne echt ruhige Hand Aber es gibt normalerweise nur rund alle 18 Monate ein FW-Update, daß sollte nicht das Problem sein. (wenn man jetzt die 4er drauf macht, ist die Wahrscheinlichkeit eines …

Moin nochmal! Entweder das Telnet-Flag nur bei der Bastelkiste setzen (wahrscheinlich nicht praktikabel ) oder man liest auf 'nem Tablet (mach ich manchmal so...) Der einfachste Weg dürfte aber sein, den 2. SPH nicht in's normale LAN zu nehmen... entweder per 2. LAN-Kabel (kann USB sein) oder einfach per LAN an den normalen und per WLAN an die Bastelkiste. Dann kann man per Routing oder einfacher, per Mausklick (AN/AUS der jeweiligen Netzwerkverbindung) zwischen den beiden SPHs umschalten. Währe…

Moin @q6676790! Jupp Man macht sich da den Nebenffekt des Telnet-Flags zunutze --> wenn das gesetzt is, senkt der SPH die 'innere' Firewall und steht ungeschützt im LAN. (Zugriffe aus dem WAN / Internet werden aber weiter geblockt) Ohne die LAN-seitige Firewall ist deshalb dann das LTE-Modul über seine Konfigurations-IP nicht nur für den SPH selbst, sondern auch von jedem anderen Gerät im eigenen LAN erreichbar. Ab der FW-V03 ist zwar kein 'telnetd' mehr da, aber der Nebeneffekt des Flags bleibt…

Moin @Hendrik! Streng genommen war das aber gar keine Frage zu Telnet / Hardware-Serial, sondern zu @danXdes Komplettlösung mfg, emkay

Genau -- kann sein, daß Du erst mehrmals auf 'wiederholen' oder so klicken musst, bis Dir 'überspringen' angeboten wird. mfg, emkay

Moin @steinmax09! Wenn Du nur die Frequenz fixieren möchtest, ist sphfreq eventuell der kompliziertere Weg, gerade bei den neuen Firmware-Versionen... Einfacher: -- such Dir hier ein Tool aus --> tools zum ent-/verschlüsseln der config -- setze das Telnet-Flag (Passwort etc. brauchst Du nicht) --> Telnet aktivieren -- dann kannst Du hiermit die Frequenz fixieren --> version 1.0-pre13 mfg, emkay

Moin! Jupp, ich habe ein OpenVPN-Binary damals für die 2er-FW erstellt... (für die 4er müsste man wohl neu kompillieren) Aber selbst mit Tricks maxed der Durchsatz im Download bei etwa 5MBit/s aus. -- wenn man's schaffen würde, an die Crypto-Bibliotheken der originalen Firmware anzubinden, könnte man da vielleicht noch was rausholen.... (wegen Hardware unterstützung müssten dann zumindest manche Verschlüsselungen optimiert werden, ob das dann auch die sind, die der eigene Anbieter nutzt, ist abe…

Zitat von MXPrime: „das wäre dann in der Praxis (( /opt/bin/dsl-tunnel.sh down &) &)“nein... Nicht dsl-tunnel.sh muß von der Konsole gelöst werden, sondern killtunnel - dazu müsste man dann wohl dsl-tunel.sh anpassen, damit dieses killtunnel ohne Verbindung zur Konsole startet mfg, emkay

jetzt haste das Forum putt gemacht....

Die Grundidee dahinter, den Tunnel zu brechen, war ja eigentlich, daß alles außer Telefonie über LTE läuft... Dein Setup könnte trotzdem funktionieren, aber eventuell muß dann Deine QOS-Richtlinie anderst aussehen, als mit aktivem Tunnel. Keine Ahnung, ob das schonmal jemand gemacht hat. Mein erster Versuch wäre wohl, einfach einen der Telefonie-Marker zu 'mißbrauchen' -- also 48 oder 46 Und übrigens: ich habe gerade mal getestet --> ein Script über (( &) &) gestartet, läuft weiter auch ohne She…

nöpp... keine Path-Probleme... nohup und disown scheints bei busybox-ash nicht zu geben.... Deshalb wäre (( command &) &) auch der sinnvollste Weg Naja, mit busybox gäbe es eben noch den Weg über 'start-stop-daemon' -- das ist vorhanden.

Nee... wenn, dannQuellcode (1 Zeile) dsl-tunnel.sh kenn ich nicht - sollte aber funktionieren. Streng genommen müsste man aber wohl das Start-/Stop-Script, also 'dsl-tunnel.sh' übeerarbeiten, damit dieses die Aufgabe des Trennens der Shell übernimmt - dann wär's sauber.... mfg, emkay

Ich war da jetzt mal echt neugierig, weil es ja sowas wie'n Standard-Problem ist, daß man mit Telnet / SSH durchaus öfter mal bekommt... Der saubere Weg, sowas ohne zusätzliche Tools zu machen, scheint wohl folgendes zu sein:Quellcode (1 Zeile)--> also doppeltes 'Sub-Shelling' im Hintergrund, was dazu führt, daß das Script dem Init-Prozeß unterstellt wird, statt der aktuellen Shell. Da dann 'Init' der Parent-Prozeß vom Script ist, ist dieses dann auch kein 'Zombie' und Init räumt hinter ihm auf.…

Moin! Jupp.... da liegt das Problem Wenn man das Script manuell startet, wird es mit der Shell verbunden - endet die Shell, endet auch das Script... -- ich glaub' das hatten wir damals sogar mal erwähnt, daß die Shell da offen bleiben sollte -- (das Problem taucht sonst nicht so oft auf, weil die meisten die Scripts nicht manuell, sondern über ein Web-Interface starten) Hauptproblem ist also, daß die Shell beim trennen von Telnet ein SIGHUP-Signal bekommt, welches sie an ihre Jobs/Programme/Scri…

Joa... dann gibt's entweder 'ne Abweichung zu meinem killtunnel-Script, oder es könnt' sich natürlich auch was mit den neueren FW-Versionen verändert haben... (Name des Interfaces zB.) Eventuell hilft es bei sowas ja, mal die Fehlermeldungen zu lesen.... (die Erwähnung, daß da was 'muckte' allein, hat ja wenig Aussagekraft und hilft kaum ) Ich selbst kann da im Moment nur die für euch wohl kaum hilfreiche Aussage treffen, daß mein Script ohne zusätzliches 'Geschnörkel' problemlos lief - für Ände…

Tja - die Frage kannst eigentlich nur Du selbst beantworten Das Script beendet sich niemals selbst - muß also von irgendwem / irgendetwas auf Deinem Router gekillt werden. MitQuellcode (1 Zeile) solltest Du sehen können, ob das Script läuft (wenn ja, zeigt es dessen Process-Infos an, wenn nein zeigt es nix). Und mal ganz dumm: auch mal die Datei-Attribute der Scripts überprüfen - manchmal sind's die gaaanz kleinen Sachen mfg, emkay

Naja, wenn's eigentlich funktioniert, muß auch die Schleife funktionieren... Der Befehl zum Löschen des Tunnels ist ja innerhalb der while-Schleife Aber das killtunnel-Script darf natürlich nicht beendet werden, sonst endet logischerweise auch die Schleife. Eventuell wird bei Dir ungewollt das Script beendet... dann wird der Tunnel nach einer Weile wieder hergestellt. Also: -- Script 'killtunnel' läuft --> 1x pro Sekunde wird das Tunnelinterface, wenn vorhanden, entfernt -- Script wird beendet -…