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

    Friday, September 27 2013, 10:35 AM - #permalink
    0
    Hi, TXD_AUX and RXD_AUX lines of Telit modem are not available on IGEP BERLIN. These lines are serial programer port. So, It could not be upgraded the firmware. Best regards, Agusti
    The reply is currently minimized Show
  • Accepted Answer

    Stefanek
    Stefanek
    Offline
    Saturday, October 19 2013, 03:47 AM - #permalink
    1
    Hi!

    For the record, it is actually possibile to upgrade the firmware of the modem
    by using the internal serial port (/dev/ttyO1).
    You have to ask Telit support for the procedure and sign a NDA to obtain it.

    Unfortunately the upgrade doesn't solve my problem as the modem
    still won't attach to GPRS by any means. I'm starting to suspect that
    there is a hardware fault somewhere...

    --

    Szymon
    The reply is currently minimized Show
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Saturday, October 19 2013, 12:31 PM - #permalink
    0
    Hi Szymon

    Thanks for that point, We will ask them ...

    So Did you check it what is the signal level ? and I suppose that you verified the sim card is operative and it not have any restriction ...

    Thanks

    Manel
    The reply is currently minimized Show
  • Accepted Answer

    Stefanek
    Stefanek
    Offline
    Saturday, October 19 2013, 12:59 PM - #permalink
    0
    Well, the signal level reported by AT+CSQ is 31,0: basically out of scale. I'm100 m from a cell tower.

    The SIM seems to work nicely when inserted in a phone, both in 3G and 2G mode.
    I suppose that 2G-only mode of an android phone is GPRS so having it working implies
    that there are no limitations on the SIM.

    An external 3G modem connected via USB with the same SIM connects immediately
    (with the same chatscript and pppd options) so it's not the OS or pppd configuration.

    The point is that the response to the AT+CGREG command is always 0,2, no matter
    what I do.

    The interesting thing is that I can send SMS messages and I also can make an ATDT
    data call. The modem replies with a CONNECT message and pppd seems to run
    through the authentication phase. However, the IPCP negotiation fails with the other
    party not responding. I suppose it's because the modem isn't actually registered on
    the GPRS network...

    The attached dump.txt contains an example of pppd log (one of dozents of variants I've
    produced trying different options).
    Attachments:
    The reply is currently minimized Show
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Saturday, October 19 2013, 07:34 PM - #permalink
    0
    Ok, please check if the modem side has the hardware control lines activated ... and if it is then disable it ...

    check it with:

    at+ifc?


    if the result is different than 0,0 so change the value with:

    at+ifc=0,0


    Cheers
    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
  • 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
    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

    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

    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, 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

    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

    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, 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

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

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

    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

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