logo

Could not compile stylesheet for simplistic. Using last compiled stylesheet.

Upgrading the Telit modem firmware

posted in IGEP BERLIN
Wednesday, September 25 2013, 04:54 PM
0
Hi all!

Is is possibile to upgrade the firmware of the Telit GE865 modem mounted on the Berlin board?

I've received a firmware image from Telit and there is a Windows tool to flash it (Xfp) but it obviously doesn't work on the board. I've been thinking about exposing the /dev/ttyO1 interface to the outside world via /dev/ttyO2 but so far my overall attempts have been unsuccesfull.

Did anyone succeed in upgrading the modem firmware?
Responses (25)
  • Accepted Answer

    Thursday, January 18 2018, 08:07 PM - #permalink
    0
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, January 18 2018, 07:55 PM - #permalink
    0
    You can improve your educational service into this zone. Like if you want to learn about the quantitative analysis and other technical questions, then get the help from essaytigers.com review and contact us for the best learning. You can connect to this site.
    The reply is currently minimized Show
  • Accepted Answer

    ciwili
    ciwili
    Offline
    Tuesday, January 16 2018, 10:09 AM - #permalink
    0
    That idea of technology is the best one so far
    Like
    The reply is currently minimized Show
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Monday, November 04 2013, 09:07 AM - #permalink
    0
    Hi Szymon,

    OK no problem, please contact sales@isee.biz for request a RMA (send this link http://www.isee.biz/support/upgrading-the-telit-modem-firmware)

    Manel
    The reply is currently minimized Show
  • Accepted Answer

    Stefanek
    Stefanek
    Offline
    Friday, November 01 2013, 01:31 AM - #permalink
    0
    Hi!

    OK. My results are the same with low (10-11) and very high (31) signal.
    Since you have tried with the same configuration and pppd scripts I guess
    that there are two possibilities:

    - both SIMs/operators I have tested are incompatible with the modem
    in some way

    - there is some kind of hardware problem. Maybe I have attached the antenna
    in a wrong way or something.

    If I send you back the board exactly as I have it now (with the antenna and
    OS image) will you test it for me?

    If you can connect with no problems then I'll blame the SIMs/operators/signal/myself,
    pay for the shipments and the testing service. If the hardware is determined to be
    faulty then you send me back a tested replacement board and everyone is happy.

    Let me know and thank you for the support!

    --

    Szymon
    The reply is currently minimized Show
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Thursday, October 31 2013, 12:18 PM - #permalink
    0
    We have done the test with the same firmware and IGEP Berlin, attached you've the logs.
    We call the pppd from the command line and the output is the file called debug_nodetach.txt, the debug output is in the file called log_messages.txt and at last we include our pppd scripts used in our test.

    About the results, we get the same result than you if the signal is not enough for establish the connection (below 18) after that we tested it with the right signal environment

    I hope it helps you ...

    Cheers
    Manel
    The reply is currently minimized Show
  • Accepted Answer

    Stefanek
    Stefanek
    Offline
    Wednesday, October 30 2013, 04:40 AM - #permalink
    0
    It's an image of the yocto firmware, the one you provide on your site.
    The version is "igep_firmware-yocto-1.2.2-3".

    I haven't customized the ip-up script at all so I think it's pretty standard:
    you can find it attached to this post (renamed to ip-up.txt)

    --

    Anyway, today I've made another puzzling discovery.

    I did another set of tests with a different SIM. This one has a poor signal
    here: around 11,0. It's not enough for the modem to attach to GSM network
    and it won't make calls or send sms messages (AT+CMGS fails with error 38
    which stands for "Network out of order" or something similar). But that's
    not really the point.

    Now, if I start pppd with exactly the same scripts (with the exception of the PIN
    and the APN) I get the same data dump! See dump6.txt file attached.

    I mean that I get the CONNECT message immediately after the ATD*99***1#,
    there is an LCP exchange, the PAP authentication and then the IPCP
    level messages that fail, like with the vodafone SIM.

    But the modem is not registered on GSM network and I think it can't even
    reach the cell tower: it shouldn't be communicating at all. Still, the pppd
    interaction happens.

    This is quite puzzling... it's like pppd is actually talking to the modem only
    and not to a remote peer reached wirelessly.

    Now in the Telit IP Easy Manual, page 21, I read:
    "The CONNECT result code is raised before complete connection establishment."
    ...

    Isn't that the initial part of the LCP/IPCP exchange is actually "fake" and
    the modem is using it only to gather the data to do its own exchange with
    the peer?
    Attachments:
    The reply is currently minimized Show
  • Accepted Answer

    Stefanek
    Stefanek
    Offline
    Tuesday, October 29 2013, 05:24 AM - #permalink
    0
    Tried it.

    dump4.txt is what I get by using exactly your pppd options.
    pppd asks for a non 0.0.0.0 IP address (no exact clue on how it got that, possibly via ethernet+dhcp)
    and the peer doesn't respond at all.

    If I readd the noipdefault option (and so pppd asks for 0.0.0.0) then
    the peer seems to send out some packets but doesn't listen to replies.
    In this case I get dump5.txt.
    Attachments:
    • mcaro
      more than a month ago
      [quote]Jun 12 15:01:08 igep00x0 daemon.info avahi-daemon[1326]: Withdrawing workstation service for ppp0.[/quote]
      What distribution are you using ?
      How you setup the if-up script for the pppd connection ?
    The reply is currently minimized Show
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Sunday, October 27 2013, 09:51 AM - #permalink
    0
    Stefanek wrote:

    Sorry, it looks I have trouble with attachments today.

    Well, here are the files:

    pppd options
    debug
    noauth
    show-password
    /dev/ttyO1
    115200
    nocrtscts
    defaultroute
    #noipdefault
    user 3454094XXX
    usepeerdns
    #nodeflate
    #novj
    #novjccomp
    #noaccomp
    #nopcomp
    name 3454094XXX
    #nobsdcomp
    #noccp
    #persist
    connect "/usr/sbin/chat -v -E -f /etc/ppp/chatscripts/gprs"
    ipcp-accept-local
    ipcp-accept-remote
    lcp-echo-failure 8
    lcp-echo-interval 3
    ipcp-max-configure 50
    ipcp-max-failure 50
    ipcp-max-terminate 10
    



    I modified your script, please could you try it ?
    The reply is currently minimized Show
  • Accepted Answer

    Stefanek
    Stefanek
    Offline
    Sunday, October 27 2013, 01:53 AM - #permalink
    0
    Well, this is the APN my Samsung Nexus S chooses automatically, both on 2G and 3G, and it works fine.
    And I've also connected succesfully with this APN (and almost the same pppd scripts) by using an Alcatel X220 modem connected via USB
    (that was 3G, though).

    Finally, it's listed as primary APN for vodafone italia here.

    I've also tried different APNs, though, with no result.
    The reply is currently minimized Show
  • Accepted Answer

    Stefanek
    Stefanek
    Offline
    Thursday, October 24 2013, 10:56 PM - #permalink
    0
    Sorry, it looks I have trouble with attachments today.

    Well, here are the files:

    pppd options
    debug
    noauth
    show-password
    /dev/ttyO1
    115200
    nocrtscts
    defaultroute
    noipdefault
    user 3454094XXX
    usepeerdns
    nodeflate
    novj
    novjccomp
    #noaccomp
    #nopcomp
    name 3454094XXX
    nobsdcomp
    noccp
    persist
    connect "/usr/sbin/chat -v -E -f /etc/ppp/chatscripts/gprs"
    ipcp-accept-local
    ipcp-accept-remote
    lcp-echo-failure 8
    lcp-echo-interval 3
    


    chatscript
    ABORT 'BUSY'
    ABORT 'NO CARRIER'
    ABORT 'VOICE'
    ABORT 'NO DIALTONE'
    ABORT 'NO DIAL TONE'
    ABORT 'NO ANSWER'
    ABORT 'DELAYED'
    REPORT CONNECT
    TIMEOUT 6
    '' 'ATQ0'
    'OK-AT-OK' 'ATZ'
    TIMEOUT 3
    'OK' 'AT+CPIN=2915'
    'OK\d-AT-OK' 'ATI'
    'OK' ATZ
    'OK' 'ATS0=0'
    'OK' 'AT+IFC=0,0'
    'OK' 'AT+FCLASS=0'
    'OK' 'AT+CSQ'
    'OK' 'AT+CREG?'
    'OK' 'AT+CGREG?'
    'OK' 'AT+CGDCONT=1,"IP","mobile.vodafone.it"'
    'OK' 'ATD*99***1#'
    TIMEOUT 30
    CONNECT ''
    
    • mcaro
      more than a month ago
      Are you sure that is the right APN: "mobile.vodafone.it"'?
    The reply is currently minimized Show
  • Accepted Answer

    Stefanek
    Stefanek
    Offline
    Wednesday, October 23 2013, 09:52 PM - #permalink
    0
    Sure!

    gprs.chatscript is actually /etc/ppp/chatscripts/gprs
    gprs.peers is actually /etc/ppp/peers/gprs

    I start it with "pppd call gprs"
    • mcaro
      more than a month ago
      The scripts be not there
    The reply is currently minimized Show
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Wednesday, October 23 2013, 05:07 PM - #permalink
    0
    Hi Szymon,

    Could you attach your gprs connection script ?

    Thanks
    Manel
    The reply is currently minimized Show
  • Accepted Answer

    Stefanek
    Stefanek
    Offline
    Wednesday, October 23 2013, 03:32 PM - #permalink
    0
    Sorry, in the post above the dump lines are filtered by the forum software
    and the contents of the < > parts are removed. Hovewer you can look it up
    in the dump.txt itself (and I see I have quoted the same part in your own post).
    The reply is currently minimized Show
  • Accepted Answer

    Stefanek
    Stefanek
    Offline
    Wednesday, October 23 2013, 03:28 PM - #permalink
    0
    Hi!

    Yes, right, in the last dump I forgot to include the AT+CGDCONT command.
    However its contents are preserved across sessions and were set properly
    also in that one. I'm quite sure as I did it like a hundred times :D

    AT+CGDCONT=1,"IP","mobile.vodafone.it".
    


    As for the pppd dump, I've analyzed the communication several times too.
    The peer stops responding, or the modem stops receiving responses, as
    soon as the protocol switches at IPCP negotiation level. dump2.txt shows it:

    # Local pppd asks for configuration: any IP address, and any DNS server will do
    sent [IPCP ConfReq id=0x1   ]
    
    # The remote party asks for configuration too, asking for this strange IP address
    rcvd [IPCP ConfReq id=0x1 ]
    
    # Local pppd says OK, I accept your IP address.
    sent [IPCP ConfAck id=0x1 ]
    
    # The remote party didn't hear the answer and asks again
    rcvd [IPCP ConfReq id=0x1 ]
    
    # Local pppd says OK, I accept your IP address
    sent [IPCP ConfAck id=0x1 ]
    
    # At LCP level communication works properly
    sent [LCP EchoReq id=0x1 magic=0xc016ae3c]
    rcvd [LCP EchoRep id=0x1 magic=0xe01d0700]
    
    # Local pppd got no answer for its own configuration request and repeats it
    sent [IPCP ConfReq id=0x1   ]
    
    # The remote party really doesn't listen: keeps repeating its own request
    rcvd [IPCP ConfReq id=0x1 ]
    ...
    



    I've also dissected the communication at byte level.by recording it via pppd.
    It's exactly what the log says: no proper answer from remote party after switching to IPCP.

    In fact I've also determined that the remote party DOES hear the requests and it's not
    responding selectively. That's because if I do not accept the remote IP address
    (by specifying a remote ip address in the pppd options) and reply with a ConfNak to
    the ConfReq then the remote party will change its ConfReq request accordingly.

    The pppd conversation problem was really the first symptom I noticed. Then, after
    investigation, I've pointed myself to the fact that AT+CGREG is never X,1 as it should
    be before attempting to communicate via GPRS...
    The reply is currently minimized Show
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Wednesday, October 23 2013, 11:21 AM - #permalink
    0
    Without defining the context you're not able to activate the connection, please define the context before try to attach to the GPRS network.
    So in fact looking your first dump, the issue not appears with the GPRS network appears a network configuration problem:

    Jun 11 08:29:26 igep00x0 local2.info chat[1443]: send (AT+CGDCONT=1,"IP","mobile.vodafone.it"^M)
    Jun 11 08:29:26 igep00x0 local2.info chat[1443]: expect (OK)
    Jun 11 08:29:26 igep00x0 local2.info chat[1443]: ^M
    Jun 11 08:29:26 igep00x0 local2.info chat[1443]: AT+CGDCONT=1,"IP","mobile.vodafone.it"^M^M
    Jun 11 08:29:26 igep00x0 local2.info chat[1443]: OK
    Jun 11 08:29:26 igep00x0 local2.info chat[1443]:  -- got it
    Jun 11 08:29:26 igep00x0 local2.info chat[1443]: send (ATDT*99#^M)
    Jun 11 08:29:26 igep00x0 local2.info chat[1443]: timeout set to 30 seconds
    Jun 11 08:29:26 igep00x0 local2.info chat[1443]: expect (CONNECT)
    Jun 11 08:29:26 igep00x0 local2.info chat[1443]: ^M
    Jun 11 08:29:26 igep00x0 local2.info chat[1443]: ATDT*99#^M^M
    Jun 11 08:29:26 igep00x0 local2.info chat[1443]: CONNECT
    Jun 11 08:29:26 igep00x0 local2.info chat[1443]:  -- got it
    Jun 11 08:29:26 igep00x0 local2.info chat[1443]: send (^M)
    Jun 11 08:29:26 igep00x0 daemon.debug pppd[1442]: Script /usr/sbin/chat -v -E -f /etc/ppp/chatscripts/gprs finished (pid 1443), status = 0x0
    Jun 11 08:29:26 igep00x0 daemon.info pppd[1442]: Serial connection established.
    Jun 11 08:29:26 igep00x0 daemon.debug pppd[1442]: using channel 1
    Jun 11 08:29:26 igep00x0 daemon.info connmand[1263]: ppp0 {newlink} index 7 operstate 2 
    Jun 11 08:29:26 igep00x0 daemon.info pppd[1442]: Using interface ppp0
    Jun 11 08:29:26 igep00x0 daemon.notice pppd[1442]: Connect: ppp0  /dev/ttyO1
    Jun 11 08:29:27 igep00x0 daemon.warn pppd[1442]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
    Jun 11 08:29:27 igep00x0 daemon.debug pppd[1442]: sent [LCP ConfReq id=0x1    ]
    Jun 11 08:29:27 igep00x0 daemon.debug pppd[1442]: rcvd [LCP ConfAck id=0x1    ]
    Jun 11 08:29:27 igep00x0 daemon.debug pppd[1442]: rcvd [LCP ConfReq id=0x1     ]
    Jun 11 08:29:27 igep00x0 daemon.debug pppd[1442]: sent [LCP ConfAck id=0x1     ]
    Jun 11 08:29:27 igep00x0 daemon.debug pppd[1442]: sent [LCP EchoReq id=0x0 magic=0xc016ae3c]
    Jun 11 08:29:27 igep00x0 daemon.warn pppd[1442]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
    Jun 11 08:29:27 igep00x0 daemon.debug pppd[1442]: sent [PAP AuthReq id=0x1 user="3454094XXX" password=""]
    Jun 11 08:29:27 igep00x0 daemon.debug pppd[1442]: rcvd [LCP EchoRep id=0x0 magic=0x36120700]
    Jun 11 08:29:27 igep00x0 daemon.debug pppd[1442]: rcvd [PAP AuthAck id=0x1 "Welcome!"]
    Jun 11 08:29:27 igep00x0 daemon.info pppd[1442]: Remote message: Welcome!
    Jun 11 08:29:27 igep00x0 daemon.notice pppd[1442]: PAP authentication succeeded
    Jun 11 08:29:27 igep00x0 daemon.debug pppd[1442]: sent [IPCP ConfReq id=0x1   ]
    Jun 11 08:29:27 igep00x0 daemon.debug pppd[1442]: rcvd [IPCP ConfReq id=0x1 ]
    Jun 11 08:29:27 igep00x0 daemon.debug pppd[1442]: sent [IPCP ConfAck id=0x1 ]
    Jun 11 08:29:30 igep00x0 daemon.debug pppd[1442]: rcvd [IPCP ConfReq id=0x1 ]
    Jun 11 08:29:30 igep00x0 daemon.debug pppd[1442]: sent [IPCP ConfAck id=0x1 ]
    Jun 11 08:29:30 igep00x0 daemon.debug pppd[1442]: sent [LCP EchoReq id=0x1 magic=0xc016ae3c]
    Jun 11 08:29:30 igep00x0 daemon.debug pppd[1442]: rcvd [LCP EchoRep id=0x1 magic=0xe01d0700]
    Jun 11 08:29:30 igep00x0 daemon.debug pppd[1442]: sent [IPCP ConfReq id=0x1   ]
    Jun 11 08:29:33 igep00x0 daemon.debug pppd[1442]: rcvd [IPCP ConfReq id=0x1 ]
    Jun 11 08:29:33 igep00x0 daemon.debug pppd[1442]: sent [IPCP ConfAck id=0x1 ]
    Jun 11 08:29:33 igep00x0 daemon.debug pppd[1442]: sent [LCP EchoReq id=0x2 magic=0xc016ae3c]
    Jun 11 08:29:33 igep00x0 daemon.debug pppd[1442]: rcvd [LCP EchoRep id=0x2 magic=0x8f290700]
    Jun 11 08:29:33 igep00x0 daemon.debug pppd[1442]: sent [IPCP ConfReq id=0x1   ]
    Jun 11 08:29:35 igep00x0 daemon.debug pppd[1442]: rcvd [IPCP ConfReq id=0x1 ]
    Jun 11 08:29:35 igep00x0 daemon.debug pppd[1442]: sent [IPCP ConfAck id=0x1 ]
    Jun 11 08:29:36 igep00x0 daemon.debug pppd[1442]: sent [LCP EchoReq id=0x3 magic=0xc016ae3c]
    Jun 11 08:29:36 igep00x0 daemon.debug pppd[1442]: rcvd [LCP EchoRep id=0x3 magic=0x43350700]
    Jun 11 08:29:36 igep00x0 daemon.debug pppd[1442]: sent [IPCP ConfReq id=0x1   ]
    Jun 11 08:29:38 igep00x0 daemon.debug pppd[1442]: rcvd [IPCP ConfReq id=0x1 ]
    Jun 11 08:29:38 igep00x0 daemon.debug pppd[1442]: sent [IPCP ConfAck id=0x1 ]
    Jun 11 08:29:39 igep00x0 daemon.debug pppd[1442]: sent [LCP EchoReq id=0x4 magic=0xc016ae3c]
    Jun 11 08:29:39 igep00x0 daemon.debug pppd[1442]: rcvd [LCP EchoRep id=0x4 magic=0xfb400700]
    Jun 11 08:29:39 igep00x0 daemon.debug pppd[1442]: sent [IPCP ConfReq id=0x1   ]
    Jun 11 08:29:42 igep00x0 daemon.debug pppd[1442]: sent [LCP EchoReq id=0x5 magic=0xc016ae3c]
    Jun 11 08:29:42 igep00x0 daemon.debug pppd[1442]: sent [IPCP ConfReq id=0x1   ]
    Jun 11 08:29:45 igep00x0 daemon.debug pppd[1442]: sent [LCP EchoReq id=0x6 magic=0xc016ae3c]
    Jun 11 08:29:45 igep00x0 daemon.debug pppd[1442]: sent [IPCP ConfReq id=0x1   ]
    Jun 11 08:29:48 igep00x0 daemon.debug pppd[1442]: sent [LCP EchoReq id=0x7 magic=0xc016ae3c]
    Jun 11 08:29:48 igep00x0 daemon.debug pppd[1442]: sent [IPCP ConfReq id=0x1   ]
    Jun 11 08:29:51 igep00x0 daemon.debug pppd[1442]: sent [LCP EchoReq id=0x8 magic=0xc016ae3c]
    Jun 11 08:29:51 igep00x0 daemon.debug pppd[1442]: sent [IPCP ConfReq id=0x1   ]
    Jun 11 08:29:54 igep00x0 daemon.debug pppd[1442]: sent [LCP EchoReq id=0x9 magic=0xc016ae3c]
    Jun 11 08:29:54 igep00x0 daemon.debug pppd[1442]: sent [IPCP ConfReq id=0x1   ]
    Jun 11 08:29:57 igep00x0 daemon.debug pppd[1442]: sent [LCP EchoReq id=0xa magic=0xc016ae3c]
    Jun 11 08:29:57 igep00x0 daemon.warn pppd[1442]: IPCP: timeout sending Config-Requests
    Jun 11 08:29:57 igep00x0 daemon.debug pppd[1442]: sent [LCP TermReq id=0x2 "No network protocols running"]
    Jun 11 08:30:00 igep00x0 daemon.debug pppd[1442]: sent [LCP TermReq id=0x3 "No network protocols running"]
    Jun 11 08:30:03 igep00x0 daemon.notice pppd[1442]: Connection terminated.
    Jun 11 08:30:03 igep00x0 daemon.info avahi-daemon[1317]: Withdrawing workstation service for ppp0.
    Jun 11 08:30:03 igep00x0 daemon.info connmand[1263]: ppp0 {dellink} index 7 operstate 2 
    Jun 11 08:30:04 igep00x0 daemon.notice pppd[1442]: Modem hangup
    
    


    These lines:

    Jun 11 08:29:26 igep00x0 local2.info chat[1443]: ATDT*99#^M^M
    Jun 11 08:29:26 igep00x0 local2.info chat[1443]: CONNECT


    Means that you're attached to the GPRS network and a ppp level the link is working:

    Jun 11 08:29:27 igep00x0 daemon.debug pppd[1442]: sent [LCP ConfReq id=0x1    ]
    Jun 11 08:29:27 igep00x0 daemon.debug pppd[1442]: rcvd [LCP ConfAck id=0x1    ]
    Jun 11 08:29:27 igep00x0 daemon.debug pppd[1442]: rcvd [LCP ConfReq id=0x1     ]
    Jun 11 08:29:27 igep00x0 daemon.debug pppd[1442]: sent [LCP ConfAck id=0x1     ]
    Jun 11 08:29:27 igep00x0 daemon.debug pppd[1442]: sent [LCP EchoReq id=0x0 magic=0xc016ae3c]
    Jun 11 08:29:27 igep00x0 daemon.warn pppd[1442]: Warning - secret file /etc/ppp/pap-secrets has world and/or group access
    Jun 11 08:29:27 igep00x0 daemon.debug pppd[1442]: sent [PAP AuthReq id=0x1 user="3454094XXX" password=""]
    Jun 11 08:29:27 igep00x0 daemon.debug pppd[1442]: rcvd [LCP EchoRep id=0x0 magic=0x36120700]
    Jun 11 08:29:27 igep00x0 daemon.debug pppd[1442]: rcvd [PAP AuthAck id=0x1 "Welcome!"]
    Jun 11 08:29:27 igep00x0 daemon.info pppd[1442]: Remote message: Welcome!
    Jun 11 08:29:27 igep00x0 daemon.notice pppd[1442]: PAP authentication succeeded
    


    Auth phase is complete and ok ...

    Now will start the configuration phase:

    Jun 11 08:29:39 igep00x0 daemon.debug pppd[1442]: sent [LCP EchoReq id=0x4 magic=0xc016ae3c]
    Jun 11 08:29:39 igep00x0 daemon.debug pppd[1442]: rcvd [LCP EchoRep id=0x4 magic=0xfb400700]
    Jun 11 08:29:39 igep00x0 daemon.debug pppd[1442]: sent [IPCP ConfReq id=0x1   ]
    Jun 11 08:29:42 igep00x0 daemon.debug pppd[1442]: sent [LCP EchoReq id=0x5 magic=0xc016ae3c]
    Jun 11 08:29:42 igep00x0 daemon.debug pppd[1442]: sent [IPCP ConfReq id=0x1   ]
    Jun 11 08:29:45 igep00x0 daemon.debug pppd[1442]: sent [LCP EchoReq id=0x6 magic=0xc016ae3c]
    Jun 11 08:29:45 igep00x0 daemon.debug pppd[1442]: sent [IPCP ConfReq id=0x1   ]
    Jun 11 08:29:48 igep00x0 daemon.debug pppd[1442]: sent [LCP EchoReq id=0x7 magic=0xc016ae3c]
    Jun 11 08:29:48 igep00x0 daemon.debug pppd[1442]: sent [IPCP ConfReq id=0x1   ]
    Jun 11 08:29:51 igep00x0 daemon.debug pppd[1442]: sent [LCP EchoReq id=0x8 magic=0xc016ae3c]
    Jun 11 08:29:51 igep00x0 daemon.debug pppd[1442]: sent [IPCP ConfReq id=0x1   ]
    Jun 11 08:29:54 igep00x0 daemon.debug pppd[1442]: sent [LCP EchoReq id=0x9 magic=0xc016ae3c]
    Jun 11 08:29:54 igep00x0 daemon.debug pppd[1442]: sent [IPCP ConfReq id=0x1   ]
    Jun 11 08:29:57 igep00x0 daemon.debug pppd[1442]: sent [LCP EchoReq id=0xa magic=0xc016ae3c]
    Jun 11 08:29:57 igep00x0 daemon.warn pppd[1442]: IPCP: timeout sending Config-Requests
    Jun 11 08:29:57 igep00x0 daemon.debug pppd[1442]: sent [LCP TermReq id=0x2 "No network protocols running"]
    Jun 11 08:30:00 igep00x0 daemon.debug pppd[1442]: sent [LCP TermReq id=0x3 "No network protocols running"]
    Jun 11 08:30:03 igep00x0 daemon.notice pppd[1442]: Connection terminated.
    Jun 11 08:30:03 igep00x0 daemon.info avahi-daemon[1317]: Withdrawing workstation service for ppp0.
    Jun 11 08:30:03 igep00x0 daemon.info connmand[1263]: ppp0 {dellink} index 7 operstate 2 
    Jun 11 08:30:04 igep00x0 daemon.notice pppd[1442]: Modem hangup
    


    Here appears the issue, are your script accepting the IP & DNS setup ??¿¿ due the PPP is sending the same request every time ... after try it 5 times your ISP left to response the messages and after that the IPCP close the connection ...

    Cheers
    Manel
    The reply is currently minimized Show
  • Accepted Answer

    Stefanek
    Stefanek
    Offline
    Wednesday, October 23 2013, 01:22 AM - #permalink
    0
    With AT+CMEE=2 I either get "operation not allowed" or "activation failed".

    I think that "operation not allowed" is a bit misleading since I get the same
    error code when the modem is switched in a band that is not used here
    (AT#BND=2) and the signal level is 0 (or better, 99,99). I think it didn't
    even communicate with the operator at all (so the operator couldn't
    allow or disallow the operation).

    Another dump in attachment.
    Attachments:
    The reply is currently minimized Show
  • Accepted Answer

    Stefanek
    Stefanek
    Offline
    Wednesday, October 23 2013, 12:42 AM - #permalink
    0
    Hm, you mean AT+CMEE=2 ?
    OK. Will do it now.
    The reply is currently minimized Show
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Tuesday, October 22 2013, 12:23 PM - #permalink
    0
    Please enable the Result Extended Messages for check the result code ...

    Manel
    The reply is currently minimized Show
  • Accepted Answer

    Stefanek
    Stefanek
    Offline
    Tuesday, October 22 2013, 05:11 AM - #permalink
    0
    Well, I'm sending AT+IFC=0,0 in my chatscript, as visible in the dump.txt attached in an earlier post.
    I've read about this in this forum thread.

    I've also tried AT+IFC=0,0 at the beginning of my manual tests with the same result.
    The dump of the microcom conversation is attached to this post.

    AT+CGREG? always reports 0,2 or 1,2 (depending on my settings), that is,
    it never registers on the GPRS network.

    I have checked again the SIM to verify it isn't limited on GPRS network.
    The Samsung Nexus S connects happily on 2G showing "G" in the signal indicator.
    It takes a couple of minutes though.

    Hm...what I might be doing wrong?
    I can provide other logs and do other tests if you wish.

    Thank You!

    Szymon
    Attachments:
    The reply is currently minimized Show
Your Reply

SUPPORT


This email address is being protected from spambots. You need JavaScript enabled to view it.
This email address is being protected from spambots. You need JavaScript enabled to view it.
IGEP Community Wiki
IGEP Community Forum
IGEP Community Online Chat