PPP hangs up before completing T-Mobile connection
Jim0000001
(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
Jorgen Grahn
> 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?
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 <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Jim0000001
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
Jorgen Grahn
> On Aug 26, 2:06 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
>> On Thu, 2011-08-25, Jim0000001 wrote:
>> > 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?
>>
>> 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.
> 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.
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.
Jim0000001
>
> - Show quoted text -
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 ''
=========================================
Jorgen Grahn
> On Aug 29, 3:41 am, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
>> On Sun, 2011-08-28, Jim0000001 wrote:
>> > On Aug 26, 2:06 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
>> >> On Thu, 2011-08-25, Jim0000001 wrote:
>> >> > 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?
>>
>> >> 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.
>> > 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.
>>
>> 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.
> 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).
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.
> 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.
But I'm unable to help further. Once again, can you somehow get
diagnostics from the device? Via that Sierra CNS software maybe?
Moe Trin
article <09b9f76f-44a3-426c...@w22g2000prj.googlegroups.com>,
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.
>Using pppd after that to dial to the APN comes after and is
>supposed to give me an IP.
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
Jim0000001
Trin) wrote:
> On Mon, 29 Aug 2011, in the Usenet newsgroup comp.os.linux.networking, in
> NOTE: Posting from groups.google.com (or some web-forums) dramatically
> reduces the chance of your post being seen. Find a real news server.
Thanks Moe. That explains a lot. I will keep that in mind next time.
> OK, I think - are you sure that is the username/password they want?
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.)
> ]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.
Hmm! So as I said above, there is no username/password to supply to
the apn.
> ]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.
>
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.
> ]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.
I tried adding "local" and the output is below.
> ]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?
>
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.
Moe Trin
article <fce225c8-e351-451d...@y8g2000prd.googlegroups.com>,
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.
>Thanks Moe. That explains a lot. I will keep that in mind next time.
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.
>> OK, I think - are you sure that is the username/password they want?
>I was assuming that the lines below that say "CHAP authentication
>succeed" indicated that my username/password was acceptable.
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).
>What I provide in the chap-secrets file is literally what I provided -
>three space separated asterisks.
How is tmobile authenticating - or does anyone dialing in automatically
get a connection, etc.?
>No trimming. This is literally from the pppd commandline.
OK - not used to seeing many people use the command line any more ;-)
>In my latest test I left out the asterisks so chap-secrets is empty.
OK let's look at the results
>syslog, with pppd additions: "local", "noccp", "noauth".
"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
>Aug 31 23:31:50 clfs pppd[15457]: sent [LCP ConfReq id=3D0x1
><asyncmap 0x0> <magic 0x2d54bf4e> <pcomp> <accomp>]
You say "hello" and propose normal options
>Aug 31 23:31:50 clfs pppd[15457]: rcvd [LCP ConfReq id=3D0x3
><asyncmap 0x0> <auth chap MD5> <magic 0x9230c7fc> <pcomp> <accomp>]
Peer says "hello" also proposes normal options, and requests you
authenticate via RFC1994 (CHAP using MD5 hashing).
>Aug 31 23:31:50 clfs pppd[15457]: No auth is possible
Your pppd sees it has no username/secret and panics
>Aug 31 23:31:50 clfs pppd[15457]: sent [LCP ConfRej id=3D0x3 <auth
>chap MD5>]
and tells the peer "I'm not going to authenticate"
>Aug 31 23:31:50 clfs pppd[15457]: rcvd [LCP ConfAck id=3D0x1
><asyncmap 0x0> <magic 0x2d54bf4e> <pcomp> <accomp>]
> Aug 31 23:31:50 clfs pppd[15457]: rcvd [LCP ConfReq id=3D0x4
><asyncmap 0x0> <magic 0x9230c7fc> <pcomp> <accomp>]
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.
>Aug 31 23:31:50 clfs pppd[15457]: sent [LCP ConfAck id=3D0x4
><asyncmap 0x0> <magic 0x9230c7fc> <pcomp> <accomp>]
You say "sounds good to me" and we go on to the next stage
>Aug 31 23:31:50 clfs pppd[15457]: sent [IPCP ConfReq id=3D0x1
><compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3
>0.0.0.0>]
You say "I wanna talk IP, I don't know my address, or the address
of the DNS.
>Aug 31 23:31:51 clfs pppd[15457]: rcvd [IPCP ConfNak id=3D0x1 <ms-
>dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
>Aug 31 23:31:51 clfs pppd[15457]: sent [IPCP ConfReq id=3D0x2
><compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3
>10.11.12.14>]
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
>Aug 31 23:31:55 clfs pppd[15457]: sent [IPCP ConfReq id=3D0x2
><compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3
>10.11.12.14>]
and again
>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
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,
>Aug 31 23:32:22 clfs pppd[15457]: sent [LCP TermReq id=3D0x2 "No
>network protocols running"]
>Aug 31 23:32:25 clfs pppd[15457]: sent [LCP TermReq id=3D0x3 "No
>network protocols running"]
>Aug 31 23:32:28 clfs pppd[15457]: Connection terminated.
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
Jorgen Grahn
...
>>Aug 31 23:32:28 clfs pppd[15457]: Connection terminated.
>
> 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. ;-)
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.
Jim0000001
> On Wed, 31 Aug 2011, in the Usenet newsgroup comp.os.linux.networking, in
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
Moe Trin
article <bfcd1c08-d656-4aea...@s2g2000prm.googlegroups.com>,
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.
>ibupro...@painkiller.example.tld.invalid (Moe Trin) wrote:
>> 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. ;-)
>Just to finally close on this....................................
>I got the problem solved.
Thank you - appreciate the feedback.
>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.
That's not fair!!! You're making it even more complicated ;-)
>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.
Got it!
>That was it. Everything else was fine.
>Thanks for all your help.
You're very welcome!
Old guy