Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #191683 > unrolled thread

Embedded-Linux: Terminal vom GSM-Modem hängt

Back to article view | Back to de.sci.electronics

Contents

  Embedded-Linux: Terminal vom GSM-Modem hängt Manuel Reimer <Manuel.Nulldevice@nurfuerspam.de> - 2015-09-03 10:29 +0200
    Re: Embedded-Linux: Terminal vom GSM-Modem hängt Hanno Foest <hurga-news2@tigress.com> - 2015-09-03 11:30 +0200
      Re: Embedded-Linux: Terminal vom GSM-Modem hängt Manuel Reimer <Manuel.Nulldevice@nurfuerspam.de> - 2015-09-03 12:07 +0200
        Re: Embedded-Linux: Terminal vom GSM-Modem hängt "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2015-09-03 12:23 +0200
          Re: Embedded-Linux: Terminal vom GSM-Modem hängt Manuel Reimer <Manuel.Nulldevice@nurfuerspam.de> - 2015-09-03 12:35 +0200
            Re: Embedded-Linux: Terminal vom GSM-Modem hängt "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx> - 2015-09-03 13:51 +0200
              Re: Embedded-Linux: Terminal vom GSM-Modem hängt Michael Schwingen <news-1326478115@discworld.dascon.de> - 2015-09-03 21:30 +0000
            Re: Embedded-Linux: Terminal vom GSM-Modem hängt Michael Wieser <Mi_Wieser@web.de> - 2015-09-04 12:54 +0200
        Re: Embedded-Linux: Terminal vom GSM-Modem hängt Hanno Foest <hurga-news2@tigress.com> - 2015-09-03 12:28 +0200
          Re: Embedded-Linux: Terminal vom GSM-Modem hängt Manuel Reimer <Manuel.Nulldevice@nurfuerspam.de> - 2015-09-03 12:39 +0200
    Re: Embedded-Linux: Terminal vom GSM-Modem hc3a4ngt Paul Berger <3847106@owlpic.com> - 2015-09-03 13:13 +0200
      Re: Embedded-Linux: Terminal vom GSM-Modem hc3a4ngt Alexander Schreiber <als@usenet.thangorodrim.de> - 2015-09-04 10:11 +0200
    Re: Embedded-Linux: Terminal vom GSM-Modem hängt Manuel Reimer <Manuel.Nulldevice@nurfuerspam.de> - 2015-09-03 13:14 +0200
      Re: Re: Embedded-Linux: Terminal vom GSM-Modem hängt Matthias Weingart <mwnews@pentax.boerde.de> - 2015-09-04 06:44 +0000
    Re: Embedded-Linux: Terminal vom GSM-Modem hängt Bernd Nebendahl <Bernd_Nebendahl@web.de> - 2015-09-03 16:15 +0200
      Re: Embedded-Linux: Terminal vom GSM-Modem hängt Manuel Reimer <Manuel.Nulldevice@nurfuerspam.de> - 2015-09-03 16:33 +0200
        Re: Embedded-Linux: Terminal vom GSM-Modem hängt Martin Klaiber <usenet.martinkl@gmx.de> - 2015-09-04 11:36 +0200
    Re: Embedded-Linux: Terminal vom GSM-Modem hängt Andeas Wenzel <awspambucket@gmx.de> - 2015-09-04 01:56 +0200
    Re: Embedded-Linux: Terminal vom GSM-Modem hängt Manuel Reimer <Manuel.Nulldevice@nurfuerspam.de> - 2015-09-04 14:41 +0200
      Re: Embedded-Linux: Terminal vom GSM-Modem hängt Manuel Reimer <Manuel.Nulldevice@nurfuerspam.de> - 2015-09-04 22:33 +0200
        Re: Embedded-Linux: Terminal vom GSM-Modem hängt Marc Haber <mh+usenetspam1118@zugschl.us> - 2015-09-05 19:23 +0200
          Re: Embedded-Linux: Terminal vom GSM-Modem hängt Lutz Schulze <lschulze@netzwerkseite.de> - 2015-09-06 08:58 +0200
            Re: Embedded-Linux: Terminal vom GSM-Modem hängt Marc Haber <mh+usenetspam1118@zugschl.us> - 2015-09-06 09:39 +0200
              Re: Embedded-Linux: Terminal vom GSM-Modem hängt Marc Haber <mh+usenetspam1118@zugschl.us> - 2015-09-06 14:35 +0200
                Re: Embedded-Linux: Terminal vom GSM-Modem hängt Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2015-09-06 21:12 +0200
                  Re: Embedded-Linux: Terminal vom GSM-Modem hängt Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2015-09-07 12:55 +0200
                  Re: Embedded-Linux: Terminal vom GSM-Modem hängt Ewald Pfau <anderswo@gmx.net> - 2015-09-07 12:16 +0000
                    Re: Embedded-Linux: Terminal vom GSM-Modem hängt Hanno Foest <hurga-news2@tigress.com> - 2015-09-07 14:39 +0200
                  Re: Embedded-Linux: Terminal vom GSM-Modem hängt Marc Haber <mh+usenetspam1118@zugschl.us> - 2015-09-07 19:43 +0200
    Re: Embedded-Linux: Terminal vom GSM-Modem hängt Carla Schneider <carla_sch@yahoo.com> - 2015-09-08 00:18 +0200
      Re: Embedded-Linux: Terminal vom GSM-Modem hängt Manuel Reimer <Manuel.Nulldevice@nurfuerspam.de> - 2015-09-08 12:14 +0200
        Re: Embedded-Linux: Terminal vom GSM-Modem  hängt Carla Schneider <carla_sch@yahoo.com> - 2015-09-08 16:16 +0200
          Re: Embedded-Linux: Terminal vom GSM-Modem hängt Bernd Nebendahl <Bernd_Nebendahl@web.de> - 2015-09-08 17:09 +0200

Page 1 of 2  [1] 2  Next page →

#191683 — Embedded-Linux: Terminal vom GSM-Modem hängt

Hallo,

hat hier jemand Erfahrung mit GSM-Modems?

Ich nutze ein Huawei E352s-5 am USB-Port von einem Raspberry Pi B+.

Bevor die Baugruppe außer Haus geht habe ich das ganze mal hier bei mir 
angeschlossen und einfach über die Nacht laufen lassen. Heute ist genau 
das passiert was nicht passieren soll.

Beim Versuch mit dem Modem zu sprechen geht garnichts mehr. Kein 
AT-Befehl wird angenommen. Auch das "Command-Echo" tut nicht. Scheint 
komplett tot zu sein...

Kurz USB getrennt und danach geht alles wieder. Das ist natürlich keine 
Option und eine Frickellösung der Form "USB über einen GPIO-Pin kurz 
trennen" sind nicht wirklich optimal.

Irgendwelche Tipps? Ich brauche das ganze möglichst zuverlässig. So 
langsam befürchte ich, dass die USB-Sticks diese Anforderung nicht 
erfüllen können.

Das Modem sendet permanent Infos in der Form:
^MODE: 3,3

^RSSI: 6

^RSSI: 5

^SRVST: 2

^RSSI: 7

Kann das das Problem sein? Diese Zeilen werden ja im "Leerlauf" von 
niemandem angenommen. Ein Entladen/Neuladen der Kernel-Module für die 
USB-Kommunikation hat das ganze aber nicht resetten können.

Ich reboote das Teil jetzt mal und lasse wieder bis morgen durchlaufen. 
Mal sehen ob das Modem dann wieder hängt...

Gruß

Manuel

[toc] | [next] | [standalone]

#191690

Am 03.09.2015 10:29 schrieb Manuel Reimer:

> Irgendwelche Tipps? Ich brauche das ganze möglichst zuverlässig. So
> langsam befürchte ich, dass wie USB-Sticks diese Anforderung nicht
> erfüllen können.

Für Zuverlässigkeit sind sie ja auch nicht gedacht. Was nicht heißt, daß 
sie das nicht sein können, aber das ist dann halt eher Zufall. Also: Mit 
anderen Modellen herumprobieren. Ein anderes Netzteil für den Raspi 
probieren ist auch oft eine gute Idee.

Restliche Probleme mit Watchdogskript und Reboot erschlagen. - Die 
USB-Anbindung vom Raspi entspricht nicht ganz dem, was man vom PC so 
kennt. Es ist unklar, ob man die wirklich jemals stabil bekommt. Das ist 
eher so eine "meistens gehts" Lösung.

Hanno

[toc] | [prev] | [next] | [standalone]

#191692

On 09/03/2015 11:30 AM, Hanno Foest wrote:
> Für Zuverlässigkeit sind sie ja auch nicht gedacht. Was nicht heißt, daß
> sie das nicht sein können, aber das ist dann halt eher Zufall. Also: Mit
> anderen Modellen herumprobieren.

Ich schau morgen nochmal drauf. Wenn dann wieder das Modem hängt, dann 
bestelle ich das hier:

http://www.ebay.de/itm/141678983679

> Ein anderes Netzteil für den Raspi
> probieren ist auch oft eine gute Idee.

Der Raspi ist in einem Hutschienengehäuse und das nebendran hängende 
Hutschienen-Netzteil sollte hochwertig genug sein.

> Restliche Probleme mit Watchdogskript und Reboot erschlagen. - Die
> USB-Anbindung vom Raspi entspricht nicht ganz dem, was man vom PC so
> kennt. Es ist unklar, ob man die wirklich jemals stabil bekommt. Das ist
> eher so eine "meistens gehts" Lösung.

Da habe ich im Netz aber schon andere Meinungen gelesen. Mal sehen was 
die Erfahrungen hier zeigen...

Gruß

Manuel

[toc] | [prev] | [next] | [standalone]

#191694

Manuel Reimer <Manuel.Nulldevice@nurfuerspam.de> wrote:

>Da habe ich im Netz aber schon andere Meinungen gelesen. Mal sehen was 
>die Erfahrungen hier zeigen...

Es hängt von so vielen Parametern ab, Firmware, Netzbetreiber,
Systemtechnik des Netzbetreibers - generell sind all diese Dinger
nicht auf Zuverlässigkeit, sondern auf schnelles Design und billige
Fertigung getrimmt, es ist durchaus üblich, daß die ab und an
abschmieren. 

Will man da was Zuverlässiges, dann muß man was Teures kaufen, was für
den Industriemarkt gedacht ist, das Consumer-Zeugs kann taugen, muß
aber nicht. Nicht umsonst haben bessere Router mit USB-Port für solche
UMTS/LTE-Dinger eine Resetfunktion, die dem Ding kurz die 5V abklemmt,
wenn es abschmiert. Die wissen, warum das eine gute Idee ist :)


-ras

-- 
Ralph A. Schmid
http://www.schmid.xxx/ http://www.db0fue.de/
http://www.bclog.de/ http://www.kabuliyan.de/ 

[toc] | [prev] | [next] | [standalone]

#191696

On 09/03/2015 12:23 PM, Ralph A. Schmid, dk5ras wrote:
> Will man da was Zuverlässiges, dann muß man was Teures kaufen, was für
> den Industriemarkt gedacht ist, das Consumer-Zeugs kann taugen, muß
> aber nicht. Nicht umsonst haben bessere Router mit USB-Port für solche
> UMTS/LTE-Dinger eine Resetfunktion, die dem Ding kurz die 5V abklemmt,
> wenn es abschmiert. Die wissen, warum das eine gute Idee ist :)

Hast du da eine Quelle dazu? Konnte auf die Schnelle nichts finden.

Wenn sich das Modem morgen wieder totstellt, dann sende ich mal den 
Befehl, dass der Port in Standby gehen soll. Wenn die Firmware nicht 
ganz tot ist, dann geht der Stick in den Stromsparmodus. Könnte ich 
eigentlich jedes Mal machen wenn ich meinen Datentransfer durchhabe 
(spart ja auch Strom). Wenn er daraus wieder in funktionalem Zustand 
erwacht, dann wäre das eine Lösung...

Gruß

Manuel

[toc] | [prev] | [next] | [standalone]

#191701

Manuel Reimer <Manuel.Nulldevice@nurfuerspam.de> wrote:

>Hast du da eine Quelle dazu? Konnte auf die Schnelle nichts finden.

Stichwort M2M, machine to machine, da sollte man schon was googeln
könnnen. Ich lese immer wieder in den kostenlosen Käseblättchen, was
es da alles gibt, aber außer dem Namen Sierra Wireless blieb mir
mangels Bedarf nix im Gedächtnis, und an die erinnere ich mich auch
nur, weil ich von denen ein Modul im ThinkPad hatte.

>Wenn sich das Modem morgen wieder totstellt, dann sende ich mal den 
>Befehl, dass der Port in Standby gehen soll. Wenn die Firmware nicht 
>ganz tot ist, dann geht der Stick in den Stromsparmodus. Könnte ich 
>eigentlich jedes Mal machen wenn ich meinen Datentransfer durchhabe 
>(spart ja auch Strom). Wenn er daraus wieder in funktionalem Zustand 
>erwacht, dann wäre das eine Lösung...

Ausprobieren, ob's taugt, ich weiß nicht, was mit den 5V passiert,
wenn der Port in standby geht. 


-ras

-- 
Ralph A. Schmid
http://www.schmid.xxx/ http://www.db0fue.de/
http://www.bclog.de/ http://www.kabuliyan.de/ 

[toc] | [prev] | [next] | [standalone]

#191709

On 2015-09-03, Ralph A. Schmid, dk5ras <ralph@schmid.xxx> wrote:
> Stichwort M2M, machine to machine, da sollte man schon was googeln
> könnnen. Ich lese immer wieder in den kostenlosen Käseblättchen, was
> es da alles gibt, aber außer dem Namen Sierra Wireless blieb mir
> mangels Bedarf nix im Gedächtnis, und an die erinnere ich mich auch
> nur, weil ich von denen ein Modul im ThinkPad hatte.

u-blox und Quectel fallen mir noch ein - ich habe mit beiden keine
Erfahrungen.

Die Sierra UMTS/LTE-Module zeigen normalerweise keine der hier beschriebenen
Total-Hänger, aber die Kollegen, die die Software dafür machen, fluchen doch
öfters über Details.

cu
Michael

[toc] | [prev] | [next] | [standalone]

#191725

On Thu, 3 Sep 2015 12:35:50 +0200, Manuel Reimer
<Manuel.Nulldevice@nurfuerspam.de> wrote:

>On 09/03/2015 12:23 PM, Ralph A. Schmid, dk5ras wrote:
>> Will man da was Zuverlässiges, dann muß man was Teures kaufen, was für
>> den Industriemarkt gedacht ist, das Consumer-Zeugs kann taugen, muß
>> aber nicht. Nicht umsonst haben bessere Router mit USB-Port für solche
>> UMTS/LTE-Dinger eine Resetfunktion, die dem Ding kurz die 5V abklemmt,
>> wenn es abschmiert. Die wissen, warum das eine gute Idee ist :)
>
>Hast du da eine Quelle dazu? Konnte auf die Schnelle nichts finden.

wir hatten vor vielen Jahren mit Telit-Teilen ebesolche Probleme und
die einzige Lösung war dem die Versorgungsspannung abzudrehen und nach
einer kurzen Bedenkzeit wieder zu geben. Das Ding hat nichtmal mehr
auf den /Reset sauber reagiert....

Naja, seit dem funktioniert das

Grüße

-
Michael Wieser
-- 

[toc] | [prev] | [next] | [standalone]

#191695

Am 03.09.2015 12:07 schrieb Manuel Reimer:

>> Restliche Probleme mit Watchdogskript und Reboot erschlagen. - Die
>> USB-Anbindung vom Raspi entspricht nicht ganz dem, was man vom PC so
>> kennt. Es ist unklar, ob man die wirklich jemals stabil bekommt. Das ist
>> eher so eine "meistens gehts" Lösung.
>
> Da habe ich im Netz aber schon andere Meinungen gelesen. Mal sehen was
> die Erfahrungen hier zeigen...

Entscheide selber, wie vertrauenswürdig dir das Design erscheint:

https://www.raspberrypi.org/documentation/hardware/raspberrypi/usb/README.md

Straightforward ist das nicht. Wie gut das trotzdem funktioniert hängt 
nicht zuletzt vom Aufwand in den Treibern ab.

Hanno

[toc] | [prev] | [next] | [standalone]

#191697

On 09/03/2015 12:28 PM, Hanno Foest wrote:
> Entscheide selber, wie vertrauenswürdig dir das Design erscheint:
>
> https://www.raspberrypi.org/documentation/hardware/raspberrypi/usb/README.md

Das es USB-OTG ist, habe ich erwartet. Allerdings ist der SoC 
mittlerweile gut abgehangen. Einige fahren problemlos kleine 
Server-Dienste auf dem Raspberry und das LAN hängt ja auch am USB.

> Straightforward ist das nicht. Wie gut das trotzdem funktioniert hängt
> nicht zuletzt vom Aufwand in den Treibern ab.

Stimmt. Mehr wie "usbserial" brauche ich aber nicht. Ich erwarte einfach 
mal, dass dieser Treiber nach etlichen Jahren doch ziemlich stabil sein 
müsste.

Extra aus dem Grund habe ich den Stick ja bis auf "Modem" 
runterkonfiguriert. Den ganzen anderen Treiber-Murks will ich garnicht 
erst mitladen.

Gruß

Manuel

[toc] | [prev] | [next] | [standalone]

#191699 — Re: Embedded-Linux: Terminal vom GSM-Modem hc3a4ngt

Manuel Reimer wrote:

> hat hier jemand Erfahrung mit GSM-Modems?

Nö, habe ich nicht.
Aber wie Hanno schon schrieb, ist USB auf dem Raspi recht "eigenartig". Ich
habe kürzlich Tage damit verbracht, um rauszufinden daß 2 USB-Webcams
gleichzeitig am Raspi nicht funktionieren.
Zudem hängte sich der Pi beim Download auf, angeschlossen war nur 1 Webcam
sowie ein WLAN-Stick. 
Abhilfe brachte schließlich ein "max_usb_current = 1" in /boot/config.txt¹.
Offenbar ist selbst die Stromversorgung von USB-Geräten auf Kante
gestrickt.
Frage nicht wie lange ich rumdoktern mußte, bis mein Webserver mit WLAN²
endlich stabil lief.

Vielleicht hifts ja bei Dir auch.

Gruß,
Paul

¹Zufällig irgenwo in den Untiefen des Netzes gefunden. Offizielle Doku ist
das nicht.

²Auch DHCP ist im aktuellen raspbian kaputt, sogar wenn man's nicht benutzt.

[toc] | [prev] | [next] | [standalone]

#191720 — Re: Embedded-Linux: Terminal vom GSM-Modem hc3a4ngt

Paul Berger <3847106@owlpic.com> wrote:
> Manuel Reimer wrote:
>
>> hat hier jemand Erfahrung mit GSM-Modems?
>
> Nö, habe ich nicht.
> Aber wie Hanno schon schrieb, ist USB auf dem Raspi recht "eigenartig". Ich
> habe kürzlich Tage damit verbracht, um rauszufinden daß 2 USB-Webcams
> gleichzeitig am Raspi nicht funktionieren.
> Zudem hängte sich der Pi beim Download auf, angeschlossen war nur 1 Webcam
> sowie ein WLAN-Stick. 
> Abhilfe brachte schließlich ein "max_usb_current = 1" in /boot/config.txt¹.
> Offenbar ist selbst die Stromversorgung von USB-Geräten auf Kante
> gestrickt.

Ist sie. So kommen auch keine 5V am USB raus, sondern IIRC nur so um die
4.4V. Das ist zwar noch im Bereich der USB Spec, aber wenn man Hardware
erwischt, deren Entwickler die Specs nicht gelesen haben und froehlich 5V
erwarten dann kann es da schonmal eng werden.

> Frage nicht wie lange ich rumdoktern mußte, bis mein Webserver mit WLAN²
> endlich stabil lief.

Ha, ich hatte das irgendwann mal mit der Brechstange "gelöst": Script das
alle paar min prüft, ob das Gateway erreichbar ist und falls nicht einen
Reboot auslöst. Ging so halbwegs, aber brauchbar ist was anderes.

> ¹Zufällig irgenwo in den Untiefen des Netzes gefunden. Offizielle Doku ist
> das nicht.

An sowas hat man sich doch in dem Bereich der kleinen (embedded) Bastel-
boards doch schon lange gewöhnt, leider.

> ²Auch DHCP ist im aktuellen raspbian kaputt, sogar wenn man's nicht benutzt.

Andere Firmen bauen auch nette kleine Boards, für gar nicht mal soviel Geld.

Man liest sich,
             Alex.
-- 
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison

[toc] | [prev] | [next] | [standalone]

#191700

Nachtrag: Eine sehr lange Laufzeit braucht es garnicht sondern schon 
nach kurzer Zeit scheint in irgendeinem "Buffer" so viel 
Status-Nachricht gespeichert zu sein, dass der serielle Port dauerhaft 
hängt.

Gerade hat knapp eine Stunde dafür gereicht.

Auch direkt nach dem Einstecken bekomme ich die Verbindung nicht geöffnet.

Ganz schöne Sch**** das....

Gruß

Manuel

[toc] | [prev] | [next] | [standalone]

#191718

Manuel Reimer <Manuel.Nulldevice@nurfuerspam.de>:

> Nachtrag: Eine sehr lange Laufzeit braucht es garnicht sondern schon 
> nach kurzer Zeit scheint in irgendeinem "Buffer" so viel 
> Status-Nachricht gespeichert zu sein, dass der serielle Port dauerhaft 
> hängt.
> 
> Gerade hat knapp eine Stunde dafür gereicht.
> 
> Auch direkt nach dem Einstecken bekomme ich die Verbindung nicht geöffnet.
> 
> Ganz schöne Sch**** das....

Klingt ja ähnlich wie ein Windowsproblem, wo eine noch geladene Treiberleiche 
für ein USB-Serial einen COM port blockiert bis man wieder rebootet. Aber bei 
dir läuft es ja wenigsten nach Replug wieder.
Könnte wirklich ein Buffer-Full Problem im Kernel sein. Probier doch mal 
"flush" Kommandos um die serial port buffer zu löschen. 

M.
-- 

[toc] | [prev] | [next] | [standalone]

#191703

Am 2015-09-03 um 10:29 schrieb Manuel Reimer:
> Hallo,
>
> hat hier jemand Erfahrung mit GSM-Modems?
>
> Ich nutze ein Huawei E352s-5 am USB-Port von einem Raspberry Pi B+.

Ich habe einen Huawei (genaues Modell muss ich zuhause nachschauen) an 
einem RP B+. Das ganze macht SMS forwarding an ein Iridium Satphone 
(deutsche Mobilfunkanbieten schicken keine SMS ans Iridium Netz), daher 
nutze ich die webseite von Iridium per curl um die empfangene SMS 
weiterzuleiten.

Am Anfang hatte ich auch Probleme (komisches Verhalten, kein kompleter 
Ausfall) bis ich den USB Surfstick per extern versorgtem USB Hub an den 
RP gehängt habe. Offenbar braucht der Stick mehr Strom als der RP 
liefern kann.

Vielleicht hilft das auch bei Dir.

Bernd

[toc] | [prev] | [next] | [standalone]

#191704

On 09/03/2015 04:15 PM, Bernd Nebendahl wrote:
> Am Anfang hatte ich auch Probleme (komisches Verhalten, kein kompleter
> Ausfall) bis ich den USB Surfstick per extern versorgtem USB Hub an den
> RP gehängt habe. Offenbar braucht der Stick mehr Strom als der RP
> liefern kann.
>
> Vielleicht hilft das auch bei Dir.

Habe ich gerade probiert. Hochwertiger Hub mit 2,5A externem Netzteil. 
Verhalten bleibt exakt gleich.

Der "Ausfall" resettet sich wenn man rebootet. Wenn die Hardware (der 
Stick) sich verschlucken würde, dann würde ich erwarten, dass er nach 
dem Reboot immer noch hängt, weil beim Booten ja der Strom nicht 
abgestellt wird.

Ich bin so langsam echt mit meinem Latein am Ende...

Konkret bekomme ich (bevor der Stick erst wieder nach Aus-/Einstecken 
oder Reboot reagiert) folgendes im Log:


Sep 03 16:30:45 alarmpi pppd[358]: pppd 2.4.7 started by root, uid 0
Sep 03 16:30:46 alarmpi chat[359]: timeout set to 5 seconds
Sep 03 16:30:46 alarmpi chat[359]: abort on (\nBUSY\r)
Sep 03 16:30:46 alarmpi chat[359]: abort on (\nERROR\r)
Sep 03 16:30:46 alarmpi chat[359]: abort on (\nNO ANSWER\r)
Sep 03 16:30:46 alarmpi chat[359]: abort on (\nNO CARRIER\r)
Sep 03 16:30:46 alarmpi chat[359]: abort on (\nNO DIALTONE\r)
Sep 03 16:30:46 alarmpi chat[359]: abort on (\nRINGING\r\n\r\nRINGING\r)
Sep 03 16:30:46 alarmpi chat[359]: send (^MAT^M)
Sep 03 16:30:46 alarmpi chat[359]: send (ATZ^M)
Sep 03 16:30:46 alarmpi chat[359]: timeout set to 12 seconds
Sep 03 16:30:46 alarmpi chat[359]: expect (OK)
Sep 03 16:30:46 alarmpi chat[359]: ^MAT^M^M
Sep 03 16:30:46 alarmpi chat[359]: OK
Sep 03 16:30:46 alarmpi chat[359]:  -- got it
Sep 03 16:30:46 alarmpi chat[359]: send (ATE1^M)
Sep 03 16:30:47 alarmpi chat[359]: expect (OK)
Sep 03 16:30:47 alarmpi chat[359]: ^M
Sep 03 16:30:47 alarmpi chat[359]: ATZ^M^M
Sep 03 16:30:47 alarmpi chat[359]: OK
Sep 03 16:30:47 alarmpi chat[359]:  -- got it
Sep 03 16:30:47 alarmpi chat[359]: send 
(AT+CGDCONT=1,"IP","data.access.de"^M)
Sep 03 16:30:47 alarmpi chat[359]: expect (OK)
Sep 03 16:30:47 alarmpi chat[359]: ^M
Sep 03 16:30:47 alarmpi chat[359]: ATE1^M^M
Sep 03 16:30:47 alarmpi chat[359]: OK
Sep 03 16:30:47 alarmpi chat[359]:  -- got it
Sep 03 16:30:47 alarmpi chat[359]: send (ATD*99#^M)
Sep 03 16:30:47 alarmpi chat[359]: expect (CONNECT)
Sep 03 16:30:47 alarmpi chat[359]: ^M
Sep 03 16:30:47 alarmpi chat[359]: AT+CGDCONT=1,"IP","data.access.de"^M^M
Sep 03 16:30:47 alarmpi chat[359]: OK^M
Sep 03 16:30:47 alarmpi chat[359]: ATD*99#^M^M
Sep 03 16:30:47 alarmpi chat[359]: CONNECT
Sep 03 16:30:47 alarmpi chat[359]:  -- got it
Sep 03 16:30:47 alarmpi chat[359]: send (^M)
Sep 03 16:30:47 alarmpi pppd[358]: Serial connection established.
Sep 03 16:30:47 alarmpi pppd[358]: Using interface ppp0
Sep 03 16:30:47 alarmpi pppd[358]: Connect: ppp0 <--> /dev/ttyUSB0
Sep 03 16:31:18 alarmpi pppd[358]: LCP: timeout sending Config-Requests
Sep 03 16:31:18 alarmpi pppd[358]: Connection terminated.
Sep 03 16:31:19 alarmpi pppd[358]: Modem hangup



Sieht so aus als würde der "Handshake" mit dem Stick funktionieren aber 
PPP kann dann die Verbindung nicht aktivieren.

Gruß

Manuel

[toc] | [prev] | [next] | [standalone]

#191723

Manuel Reimer <Manuel.Nulldevice@nurfuerspam.de> wrote:

> Sieht so aus als würde der "Handshake" mit dem Stick funktionieren aber 
> PPP kann dann die Verbindung nicht aktivieren.

Ack, so sehe ich das auch. Die Probleme beginnen IMHO ab:

| Sep 03 16:31:18 alarmpi pppd[358]: LCP: timeout sending Config-Requests

Ich verstehe das so, dass der pppd vergeblich auf LCP-Antworten der
Gegenstelle wartet. Woran das liegt, wird aus dem log leider nicht
deutlich, weil danach keine detaillierten Meldungen mehr kommen. Du
kannst entweder den syslogd empfindlicher einstellen, wie das genau
geht, hängt davon ab, welchen Du verwendest. Alternativ kennt der
pppd normalerweise auch "-d" oder eine ähnliche Debug-Option. Aber
Vorsicht, dabei können erhebliche Datenmengen anfallen.

Falls Du mit dem PPP-Protokoll nicht so vertraut bist, würde ich mir
auch mal anschauen, wie so eine PPP-Verbindung grundsätzlich abläuft,
also wer wann was sendet, bzw. erwartet. Dann wird klarer, wo es
hakt. Aber generell brauchst Du mehr Informationen, also das logging
erhöhen oder debugging einschalten. Und danach würde ich mit den
Fehlermeldungen im web auf die Suche gehen.

HTH und Gruß, Martin

[toc] | [prev] | [next] | [standalone]

#191715

Am 03.09.2015 um 10:29 schrieb Manuel Reimer:
> [...]
> Das Modem sendet permanent Infos in der Form:
> ^MODE: 3,3
>
> ^RSSI: 6
>
> ^RSSI: 5
>
> ^SRVST: 2
>
> ^RSSI: 7
>
> Kann das das Problem sein? [...]

Das sind "unsolicited result codes", Du kannst ja mal versuchen die mit

at^curc=0

abzustellen. Die AT-Kommandoreferenz zum E352s konnte ich nicht finden, 
aber hier...

http://download-c.huawei.com/download/downloadCenter?downloadId=14254

... gibt es die zu einem anderen Huawei-Modem das aber ähnlich sein 
dürfte. Kapitel 3.18 beschreibt das oben erwähnte AT-Kommando.

Viele Grüße,
Andreas

[toc] | [prev] | [next] | [standalone]

#191728

Hallo,

ich habe gestern nochmal einige Zeit rumprobiert und jetzt steht die 
Verbindung.

Ich habe den Stick komplett auf Werkseinstellungen zurückgesetzt und 
dann meine Konfigurationen neu reingespielt.

Ich kann jetzt ohne Probleme direkt via PPPD rauswählen und ein Ping auf 
einen Webserver kommt zurück.

Danke an alle für die Tipps.

Wie zuverlässig das letztlich ist, wird sich zeigen. Probleme kann ich 
erst lösen wenn sie auftreten.

Gruß

Manuel

[toc] | [prev] | [next] | [standalone]

#191736

On 09/04/2015 02:41 PM, Manuel Reimer wrote:
> Wie zuverlässig das letztlich ist, wird sich zeigen. Probleme kann ich
> erst lösen wenn sie auftreten.

Erste Auffälligkeit: Das ganze ist ein recht wackliges Konstrukt. Wenn 
man neben der stehenden Internetverbindung auf /dev/ttyUSB0 noch den 
Status auf /dev/ttyUSB2 mitliest, dann hängt das Modem irgendwann auf. 
Warum das so ist weiß der Geier...

Weiterhin hängt sich der Kernel komplett weg wenn man blockierend von 
/dev/ttyUSB2 liest (habe ich mit Perl versucht. Wollte die Daten 
eigentlich auswerten und nutzbar machen). Das ist zu 100% 
reproduzierbar. Passiert nur auf dem Raspberry. Das gleiche Perl-Script 
läuft auf meinem Desktop-PC (auch Linux) bestens. Kernel-Version ist bei 
mir auf dem Desktop die gleiche wie auf dem Raspberry.
Das habe ich auf der seriellen Konsole vom Raspberry wenn er hängt:
pastebin.com/Eacp7TP4

Wenn das Modem hängt, dann geht keine weitere Einwahl. Was aber geht ist:
http://www.roman10.net/how-to-reset-usb-device-in-linux/
Danach geht wieder eine Einwahl.

Ich gehe jetzt mal auf Nummer sicher. Nach dem Übertragen der Daten 
entlade ich alle Kernel-Module die mit dem Surfstick zu tun haben. Vor 
dem Transfer resette ich einmal den Port was dann effektiv die Module 
wieder lädt. Und auf den Status verzichte ich.

Gruß

Manuel

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | de.sci.electronics

csiph-web