PPP hangs up before completing T-Mobile connection

Discussion in 'Linux Networking' started by Jim0000001, Aug 26, 2011.

  1. Jim0000001

    Jim0000001 Guest

    I'm trying to dial out on a GSM modem to a T-Mobile APN
    (epc.tmobile.com). However, pppd hangs-up before obtaining an IP
    address. Can anyone tell me why I'm not getting a connection with an
    IP address?
    The ppp session looks like this:
    -------------------------------
    -bash-4.0# pppd call tmobileGsm
    Starting Sierra Wireless GSM connect script...
    Setting the abort string
    Initializing modem
    Setting APN
    Dialing...
    Serial connection established.
    using channel 41
    Using interface ppp0
    Connect: ppp0 <--> /dev/ttySierraAT
    sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x31a77a57> <pcomp>
    <accomp>]
    rcvd [LCP ConfReq id=0x27 <asyncmap 0x0> <auth chap MD5> <magic
    0x730ab6a3> <pcomp> <accomp>]
    sent [LCP ConfAck id=0x27 <asyncmap 0x0> <auth chap MD5> <magic
    0x730ab6a3> <pcomp> <accomp>]
    rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x31a77a57> <pcomp>
    <accomp>]
    rcvd [LCP DiscReq id=0x28 magic=0x730ab6a3]
    rcvd [CHAP Challenge id=0x1 <4e8ec9fb06249e6d223e4fa904817891>, name =
    "UMTS_CHAP_SRVR"]
    sent [CHAP Response id=0x1 <54a5a4872d90fa1b7e2c85b8ce9debc7>, name =
    "scu1"]
    rcvd [CHAP Success id=0x1 ""]
    CHAP authentication succeeded
    CHAP authentication succeeded
    sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1
    0.0.0.0> <ms-dns3 0.0.0.0>]
    Modem hangup
    Connection terminated.
    -bash-4.0#
    ========================
    Here is tmobileGsm:
    ---------------------------------------
    -detach
    /dev/ttySierraAT
    460800
    debug
    defaultroute
    usepeerdns
    noccp
    crtscts
    lock
    connect '/usr/sbin/chat -v -t6 -f /etc/ppp/peers/
    tmobileGsm.connect.chat'
    ========================
    Here is the options file:
    ---------------------------------------
    lock
    noipdefault
    ========================
    Here is the chap-secrets file:
    -----------------
    # client server secret IP addresses
    * * *
    ========================

    Any help is very much appreciated.
    Jim
     
    Jim0000001, Aug 26, 2011
    #1
    1. Advertisements

  2. Jim0000001

    Jorgen Grahn Guest

    Can you get any more detailed information out of the "modem"? It gets
    fairly detailed information from the network about what went wrong; if
    you can make it give up that information instead of just hanging up,
    you may see the problem.

    /Jorgen
     
    Jorgen Grahn, Aug 26, 2011
    #2
    1. Advertisements

  3. Jim0000001

    Jim0000001 Guest

    The modem actually stays connected. I can run the "pppd call
    tmobileGsm" command multiple times and it always talks over the
    network, unless I specifically shutdown the modem. The "Modem hangup"
    log is coming from pppd.
    Jim
     
    Jim0000001, Aug 28, 2011
    #3
  4. Jim0000001

    Jorgen Grahn Guest

    What does "stay connected" mean here, and how do you detect it? To me
    "connected" means "has a PDP Context", which in turn it means
    everything on the far end went OK -- your credentials were accepted by
    the network, and the modem got a fully functional IPv4 address. All
    that remains to do is to tell your pppd.

    /Jorgen
     
    Jorgen Grahn, Aug 29, 2011
    #4
  5. Jim0000001

    Jim0000001 Guest

    Oh, I see your viewpoint now. Maybe "connected" is not be best term.
    I enable the GSM modem, and using the Sierra CNS interface, I tell it
    to connect to the GSM network. It returns with an "attached" status
    but an "inactive" session (terms relevant to GSM). At this point,
    pppd can "dial". The script I use to dial is shown below. So when I
    was saying "connected", I mean't the modem is connected to the GSM
    network. Using pppd after that to dial to the APN comes after and is
    supposed to give me an IP.

    So going forward I will say I am ATTACHED to the GSM network, and am
    unable to get CONNECTED to the APN with an IP address.

    Jim
    ========================================
    # Generic T-Mobile PPPD script
    SAY 'Starting Sierra Wireless GSM connect script...\n'
    SAY '\n'
    SAY 'Setting the abort string\n'
    SAY '\n'
    # Abort String ------------------------------
    ABORT 'NO DIAL TONE' ABORT 'NO ANSWER' ABORT 'NO CARRIER' ABORT
    DELAYED

    SAY 'Initializing modem\n'
    # Modem Initialization
    '' AT
    OK ATZ

    SAY '\n'
    SAY 'Setting APN\n'
    # Access Point Name (APN)
    # Incorrect APN or CGDCONT can often cause errors in connection.

    # T-Mobile Internet plan (all new plans)
    OK 'AT+CGDCONT=1,"IP","epc.tmobile.com"'

    SAY '\n'
    SAY 'Dialing...\n'
    # Dial the ISP, this is the common Cingular dial string
    OK ATD*99#
    CONNECT ''
    =========================================
     
    Jim0000001, Aug 29, 2011
    #5
  6. Jim0000001

    Jorgen Grahn Guest

    Yes, "attached" was the word I was looking for. You have radio contact
    and are known to the network, but none of the stuff that forms a
    working data tunnel is there yet.
    But I'm unable to help further. Once again, can you somehow get
    diagnostics from the device? Via that Sierra CNS software maybe?

    /Jorgen
     
    Jorgen Grahn, Aug 29, 2011
    #6
  7. Jim0000001

    Moe Trin Guest

    On Mon, 29 Aug 2011, in the Usenet newsgroup comp.os.linux.networking, in
    article <>,
    Jim0000001 wrote:

    NOTE: Posting from groups.google.com (or some web-forums) dramatically
    reduces the chance of your post being seen. Find a real news server.
    In your original post on Thursday, you show:

    ]Dialing...
    ]Serial connection established.
    ]using channel 41
    ]Using interface ppp0
    ]Connect: ppp0 <--> /dev/ttySierraAT

    and this means the "dialing" worked correctly. You then show

    ]sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x31a77a57> <pcomp>
    ]<accomp>]
    ]rcvd [LCP ConfReq id=0x27 <asyncmap 0x0> <auth chap MD5> <magic
    ]0x730ab6a3> <pcomp> <accomp>]
    ]sent [LCP ConfAck id=0x27 <asyncmap 0x0> <auth chap MD5> <magic
    ]0x730ab6a3> <pcomp> <accomp>]
    ]rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x31a77a57> <pcomp>
    ]<accomp>]

    and that means you are able to "talk" over the link. All this is
    normal.

    ]rcvd [LCP DiscReq id=0x28 magic=0x730ab6a3]

    That's a bit unusual (I don't think I've seen it more than six times
    in the last ten years), but it's correct by RFC1661 Section 5.9. Not
    a/the problem.

    ]rcvd [CHAP Challenge id=0x1 <4e8ec9fb06249e6d223e4fa904817891>, name =
    ]"UMTS_CHAP_SRVR"]
    ]sent [CHAP Response id=0x1 <54a5a4872d90fa1b7e2c85b8ce9debc7>, name =
    ]"scu1"]

    OK, I think - are you sure that is the username/password they want?

    ]rcvd [CHAP Success id=0x1 ""]
    ]CHAP authentication succeeded

    They're saying it's OK, but that may be just to get to the "OPEN"
    state so they can terminate things because they've mis-read RFC1661.

    ]sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1
    ]0.0.0.0> <ms-dns3 0.0.0.0>]
    ]Modem hangup
    ]Connection terminated.

    You've trimmed the logs excessively (date/time and daemon who provided
    the message are missing), but the "Modem hangup" is normal for pppd
    when it receives a modem hangup signal from the modem - for the old
    RS-232 serial protocol, this would be the "CD" (Carrier Detect") pin
    dropping - in other words, this is a signal _generated_ by the modem
    saying that the serial connection has been broken. Now what caused
    the modem device to say that is something you'll have to investigate.

    ]Here is tmobileGsm:
    ]---------------------------------------
    ]-detach
    ]/dev/ttySierraAT

    [compton ~]$ grep -i sierra /usr/src/linux/docs/devices-2.6+.txt
    [compton ~]$

    No idea. USB? If so, something in the USB driver is emulating the
    CD signal, because the actual wire only exists in RS-232.

    ]crtscts

    You are depending on that emulation to handle flow control. You
    might try using the "local" option to cause pppd to ignore the
    supposed modem hangup signal, but I don't think that is reliable
    either.

    ]connect '/usr/sbin/chat -v -t6 -f /etc/ppp/peers/

    Setting the timeout to 6 seconds (default is 45, but that was based on
    a POTS type of connection) may cause problems, though your log shows
    chat establishing a connection (the "Serial connection established"
    message) so this is unlikely to be "the" problem.

    ]Here is the chap-secrets file:

    and I assume it actually has "username * auth-code" in place of the
    stars you show. Are you sure the username and secret are what they
    are expecting you to use?

    Old guy
     
    Moe Trin, Aug 30, 2011
    #7
  8. Jim0000001

    Jim0000001 Guest

    Thanks Moe. That explains a lot. I will keep that in mind next time.
    I was assuming that the lines below that say "CHAP authentication
    succeed" indicated that my username/password was acceptable. What I
    provide in the chap-secrets file is literally what I provided - three
    space separated asterisks. The tmobile APN should not require any
    username or password. (I had to place some text in chap-secrets to
    quiet down pppd.)
    Hmm! So as I said above, there is no username/password to supply to
    the apn.
    No trimming. This is literally from the pppd commandline. I will do
    another run and post the syslog output so you can see my CNS logs
    intermixed.
    I tried adding "local" and the output is below.
    So as I said above, no username or password is required. In my latest
    test I left out the asterisks so chap-secrets is empty.

    Here is the latest output, this time from syslog, with pppd additions:
    "local", "noccp", "noauth".
    Aug 31 23:31:49 clfs pppd[15457]: pppd 2.4.4 started by root, uid
    0
    Aug 31 23:31:49 clfs chat[15459]: abort on (NO DIAL TONE)
    Aug 31 23:31:49 clfs chat[15459]: abort on (NO ANSWER)
    Aug 31 23:31:49 clfs chat[15459]: abort on (NO CARRIER)
    Aug 31 23:31:49 clfs chat[15459]: abort on (DELAYED)
    Aug 31 23:31:49 clfs chat[15459]: send (AT^M)
    Aug 31 23:31:49 clfs chat[15459]: expect (OK)
    Aug 31 23:31:49 clfs chat[15459]: AT^M^M
    Aug 31 23:31:49 clfs chat[15459]: OK
    Aug 31 23:31:49 clfs chat[15459]: -- got it
    Aug 31 23:31:49 clfs chat[15459]: send (ATZ^M)
    Aug 31 23:31:49 clfs chat[15459]: expect (OK)
    Aug 31 23:31:49 clfs chat[15459]: ^M
    Aug 31 23:31:49 clfs chat[15459]: ATZ^M^M
    Aug 31 23:31:49 clfs chat[15459]: OK
    Aug 31 23:31:49 clfs chat[15459]: -- got it
    Aug 31 23:31:49 clfs chat[15459]: send (AT
    +CGDCONT=1,"IP","epc.tmobile.com"^M)
    Aug 31 23:31:49 clfs chat[15459]: expect (OK)
    Aug 31 23:31:49 clfs chat[15459]: ^M
    Aug 31 23:31:49 clfs chat[15459]: AT
    +CGDCONT=1,"IP","epc.tmobile.com"^M^M
    Aug 31 23:31:49 clfs chat[15459]: OK
    Aug 31 23:31:49 clfs chat[15459]: -- got it
    Aug 31 23:31:49 clfs chat[15459]: send (ATD*99#^M)
    Aug 31 23:31:49 clfs chat[15459]: expect (CONNECT)
    Aug 31 23:31:49 clfs chat[15459]: ^M
    Aug 31 23:31:49 clfs chat[15459]: ATD*99#^M^M
    Aug 31 23:31:49 clfs chat[15459]: CONNECT
    Aug 31 23:31:49 clfs chat[15459]: -- got it
    Aug 31 23:31:49 clfs chat[15459]: send (^M)
    Aug 31 23:31:49 clfs pppd[15457]: Serial connection established.
    Aug 31 23:31:49 clfs pppd[15457]: using channel 13
    Aug 31 23:31:49 clfs pppd[15457]: Using interface ppp0
    Aug 31 23:31:49 clfs pppd[15457]: Connect: ppp0 <--> /dev/
    ttySierraAT
    Aug 31 23:31:50 clfs pppd[15457]: sent [LCP ConfReq id=0x1
    <asyncmap 0x0> <magic 0x2d54bf4e> <pcomp> <accomp>]
    Aug 31 23:31:50 clfs pppd[15457]: rcvd [LCP ConfReq id=0x3
    <asyncmap 0x0> <auth chap MD5> <magic 0x9230c7fc> <pcomp> <accomp>]
    Aug 31 23:31:50 clfs pppd[15457]: No auth is possible
    Aug 31 23:31:50 clfs pppd[15457]: sent [LCP ConfRej id=0x3 <auth
    chap MD5>]
    Aug 31 23:31:50 clfs pppd[15457]: rcvd [LCP ConfAck id=0x1
    <asyncmap 0x0> <magic 0x2d54bf4e> <pcomp> <accomp>]
    Aug 31 23:31:50 clfs pppd[15457]: rcvd [LCP ConfReq id=0x4
    <asyncmap 0x0> <magic 0x9230c7fc> <pcomp> <accomp>]
    Aug 31 23:31:50 clfs pppd[15457]: sent [LCP ConfAck id=0x4
    <asyncmap 0x0> <magic 0x9230c7fc> <pcomp> <accomp>]
    Aug 31 23:31:50 clfs pppd[15457]: sent [IPCP ConfReq id=0x1
    <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3
    0.0.0.0>]
    Aug 31 23:31:50 clfs pppd[15457]: rcvd [LCP DiscReq id=0x5
    magic=0x9230c7fc]
    Aug 31 23:31:51 clfs : sierratest: -> NetworkStatus: Normal,
    Roaming Active, country: USA, network: AT&T [3
    SierraCnsIf::HandleCnsNetworkStatus(832)]
    Aug 31 23:31:51 clfs : sierratest: mcc: 310, mnc:
    410, lac: 55523, cell: 30766
    Aug 31 23:31:51 clfs : sierratest: -> Service: HSDPA, Network:
    ATTACHED, Session: INACTIVE [3
    SierraCnsIf::HandleCnsAvailableServiceDetails(981)]
    Aug 31 23:31:51 clfs pppd[15457]: rcvd [IPCP ConfNak id=0x1 <ms-
    dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
    Aug 31 23:31:51 clfs pppd[15457]: sent [IPCP ConfReq id=0x2
    <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3
    10.11.12.14>]
    Aug 31 23:31:52 clfs : sierratest: -> NetworkStatus: Normal,
    Roaming Active, country: USA, network: AT&T [3
    SierraCnsIf::HandleCnsNetworkStatus(832)]
    Aug 31 23:31:52 clfs : sierratest: mcc: 310, mnc:
    410, lac: 55523, cell: 30766
    Aug 31 23:31:52 clfs : sierratest: -> Service: HSDPA, Network:
    ATTACHED, Session: INACTIVE [3
    SierraCnsIf::HandleCnsAvailableServiceDetails(981)]
    Aug 31 23:31:52 clfs : sierratest: -> NetworkStatus: Normal,
    Roaming Active, country: USA, network: AT&T [3
    SierraCnsIf::HandleCnsNetworkStatus(832)]
    Aug 31 23:31:52 clfs : sierratest: mcc: 310, mnc:
    410, lac: 55523, cell: 30766
    Aug 31 23:31:52 clfs : sierratest: -> Service: HSDPA, Network:
    ATTACHED, Session: INACTIVE [3
    SierraCnsIf::HandleCnsAvailableServiceDetails(981)]
    Aug 31 23:31:52 clfs : sierratest: -> Service: HSDPA, Network:
    ATTACHED, Session: INACTIVE [3
    SierraCnsIf::HandleCnsAvailableServiceDetails(981)]
    Aug 31 23:31:52 clfs : sierratest: -> NetworkStatus: Normal,
    Roaming Active, country: USA, network: AT&T [3
    SierraCnsIf::HandleCnsNetworkStatus(832)]
    Aug 31 23:31:52 clfs : sierratest: mcc: 310, mnc:
    410, lac: 55523, cell: 30766
    Aug 31 23:31:52 clfs : sierratest: -> Service: HSDPA, Network:
    ATTACHED, Session: INACTIVE [3
    SierraCnsIf::HandleCnsAvailableServiceDetails(981)]
    Aug 31 23:31:55 clfs pppd[15457]: sent [IPCP ConfReq id=0x2
    <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3
    10.11.12.14>]
    Aug 31 23:32:22 clfs pppd[15457]: last message repeated 8 times
    Aug 31 23:32:22 clfs pppd[15457]: IPCP: timeout sending Config-
    Requests
    Aug 31 23:32:22 clfs pppd[15457]: sent [LCP TermReq id=0x2 "No
    network protocols running"]
    Aug 31 23:32:25 clfs pppd[15457]: sent [LCP TermReq id=0x3 "No
    network protocols running"]
    Aug 31 23:32:28 clfs pppd[15457]: Connection terminated.
    Aug 31 23:32:28 clfs kernel: [190648.800189] netconsole: network
    logging stopped, interface ppp0 unegistee
    Aug 31 23:32:28 clfs kernel: rrd
    Aug 31 23:32:28 clfs pppd[15457]: Modem hangup
    Aug 31 23:32:28 clfs pppd[15457]: Exit.
     
    Jim0000001, Sep 1, 2011
    #8
  9. Jim0000001

    Moe Trin Guest

    On Wed, 31 Aug 2011, in the Usenet newsgroup comp.os.linux.networking, in
    article <>,
    Jim0000001 wrote:

    NOTE: Posting from groups.google.com (or some web-forums) dramatically
    reduces the chance of your post being seen. Find a real news server.
    My news reader is configured to add that note when I reply to posts
    from groups.google.com and some others. Google has a pretty bad
    reputation for spam tolerance, and some people (and some news servers)
    filter such posts. Search for "free news server" or "public news server"
    and you'll find a number of candidates.
    Looking at the original posting, you showed:

    ]sent [CHAP Response id=0x1 <54a5a4872d90fa1b7e2c85b8ce9debc7>, name =
    ]"scu1"]

    Somewhere, pppd has picked up the username "scu1" and was replying to
    the challenge with that name - I've no idea what "password" it was
    using. Mentioned, there are some pretty horrible implementations of
    ppp out there, and some authors assume that the LCP (Link Control
    Protocol) has to reach an "open" state before the connection can be
    terminated. The "Phase Diagram" section of RFC1661 says otherwise,
    but it's not uncommon to find logs showing the peer accepting
    authentication and then hanging up the phone as you show, INSTEAD OF
    responding with an authentication failure message (which is _required_
    by RFC1334 Section 2.2.2 for the PAP and 3.2.2 for the original specs
    for CHAP and RFC1994 Section 4.2 for current version of CHAP) and
    initiating a TermReq (termination requested).
    How is tmobile authenticating - or does anyone dialing in automatically
    get a connection, etc.?
    OK - not used to seeing many people use the command line any more ;-)
    OK let's look at the results
    "noauth" tells pppd not to ask the peer to authenticate TO YOU (which
    most ISPs won't do) because this pppd defaults to asking _if_ there is
    a preexisting default route in your system routing table. The more
    "correct" option if needed would be "refuse-chap" - but with the empty
    secrets file, your pppd is acting as if it had that option.

    [chat log data]

    Looks good
    You say "hello" and propose normal options
    Peer says "hello" also proposes normal options, and requests you
    authenticate via RFC1994 (CHAP using MD5 hashing).
    Your pppd sees it has no username/secret and panics
    and tells the peer "I'm not going to authenticate"
    Peer acknowledges your hello (agreeing to your options), and now
    says "hello" again, but isn't asking for authentication which is
    basically what RFC1661 specifies must happen. The other option the
    peer has would be to tell you to go away ("[LCP TermReq] id=xxxx")
    and terminate the attempt.
    You say "sounds good to me" and we go on to the next stage
    You say "I wanna talk IP, I don't know my address, or the address
    of the DNS.
    Good news, bad news - the peer says you can't use 0.0.0.0 as the
    DNS, use these other addresses - that's good. What is bad is that
    it doesn't suggest an IP address for you to use. You ask again
    and again
    but we never hear anything more from the peer. That first IPCP
    ConfNak should look something like

    Aug 31 23:31:51 clfs pppd[15457]: rcvd [IPCP ConfNak id=01 <addr
    192.0.2.22> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]

    or similar - suggesting you ask for those addresses

    Aug 31 23:31:51 clfs pppd[15457]: sent [IPCP ConfReq id=03 <compress
    VJ 0f 01> <addr 192.0.2.22> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]

    like that. Obviously, the address requested would be something else,
    but that's how things are supposed to work. Instead, we hear nothing
    further from the peer, and after a while,
    your pppd gives up and throws in the towel.

    I hate to tell you, but I really do expect that tmobile wants some
    form of username/authentication tokens - but I have no idea what.

    You have to understand that ppp over GSM is a bit of a bastard mix of
    protocols that weren't designed to work together. Normally, they do,
    but sometimes that's merely the Gods playing mind-games with us. ;-)

    Old guy
     
    Moe Trin, Sep 1, 2011
    #9
  10. Jim0000001

    Jorgen Grahn Guest

    .
    If it's the setup I'm familiar with, there is no PPP over GSM involved.
    PPP goes between the host and the "modem". The modem has a similar
    tunnel across the radio network, but it's not PPP. The /authentication/
    is typically PAP or CHAP though, and I understand that's copied from
    the PPP stuff.

    So, IIUC the "modem" works as a proxy/gateway which translates between
    PPP and the GSM protocols.

    /Jorgen
     
    Jorgen Grahn, Sep 2, 2011
    #10
  11. Jim0000001

    Jim0000001 Guest

    Just to finally close on this....................................
    I got the problem solved.

    The issue was the SIM card I have are from Deutche Telekom in
    Germany. I am trying to test communication in the US. The SIM card
    does have unlimited international access and roaming.

    The solution, as Moe pointed out, was to use the correct APN and
    username and password required for that particular account. I had to
    get the information from Deutche Telekom, even for my use in the US -
    because only they new the setup on the SIM card and the account.

    Here are the magic items that had to be correct:
    In chap-secrets I had to add:
    "t-mobile" * "tm" *
    In my tmobileGsm ppp options file I had to add:
    user "t-mobile"
    In my tmobileGsm.connect.chat file I had to set the APN to:
    "internet.t-mobile"

    That was it. Everything else was fine.
    Thanks for all your help.
    Jim
     
    Jim0000001, Sep 12, 2011
    #11
  12. Jim0000001

    Moe Trin Guest

    On Mon, 12 Sep 2011, in the Usenet newsgroup comp.os.linux.networking, in
    article <>,
    Jim0000001 wrote:

    NOTE: Posting from groups.google.com (or some web-forums) dramatically
    reduces the chance of your post being seen. Find a real news server.
    Thank you - appreciate the feedback.
    That's not fair!!! You're making it even more complicated ;-)
    Got it!
    You're very welcome!

    Old guy
     
    Moe Trin, Sep 13, 2011
    #12
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.