PPP problem with Cingular GPRS

PPP problem with Cingular GPRS

Post by Kyler Lair » Mon, 09 Dec 2002 02:24:38



I've been banging my head against Cingular GPRS for months.
I've exhausted my ideas for awhile so I'm about to take a
break from it unless someone can give me a clue.

I'm using a Cingular-provided T68i and a Pretec CompactBT
Bluetooth adapter in my laptop.  I'm running Debian unstable
on the laptop.  The Bluetooth connection works great.  I
expected it to be more of a problem, but I've been using it
with Earthlink dialup service.  (I have not gotten CSD
direct to Cingular to work.)

Here's a trace of the PPPd output:
================================================================================
Dec  7 11:24:13 remote pppd[8537]: pppd 2.4.1 started by root, uid 0
Dec  7 11:24:13 remote pppd[8537]: using channel 50
Dec  7 11:24:13 remote pppd[8537]: Using interface ppp0
Dec  7 11:24:13 remote pppd[8537]: Connect: ppp0 <--> /dev/rfcomm0
Dec  7 11:24:13 remote pppd[8537]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3178a56d> <pcomp> <accomp>]
Dec  7 11:24:13 remote pppd[8537]: rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <pcomp> <accomp> <auth pap>]
Dec  7 11:24:13 remote pppd[8537]: sent [LCP ConfAck id=0x1 <asyncmap 0x0> <pcomp> <accomp> <auth pap>]
Dec  7 11:24:13 remote pppd[8537]: rcvd [LCP ConfRej id=0x1 <magic 0x3178a56d>]
Dec  7 11:24:13 remote pppd[8537]: sent [LCP ConfReq id=0x2 <asyncmap 0x0> <pcomp> <accomp>]
Dec  7 11:24:13 remote pppd[8537]: rcvd [LCP ConfAck id=0x2 <asyncmap 0x0> <pcomp> <accomp>]

Dec  7 11:24:13 remote pppd[8537]: rcvd [PAP AuthAck id=0x1 ""]
Dec  7 11:24:13 remote pppd[8537]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Dec  7 11:24:13 remote pppd[8537]: sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Dec  7 11:24:13 remote pppd[8537]: rcvd [LCP ProtRej id=0x3 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
Dec  7 11:24:14 remote pppd[8537]: rcvd [IPCP ConfReq id=0x1]
Dec  7 11:24:14 remote pppd[8537]: sent [IPCP ConfNak id=0x1 <addr 0.0.0.0>]
Dec  7 11:24:14 remote pppd[8537]: rcvd [IPCP ConfRej id=0x1 <addr 0.0.0.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Dec  7 11:24:14 remote pppd[8537]: sent [IPCP ConfReq id=0x2 <addrs 0.0.0.0 0.0.0.0>]
Dec  7 11:24:14 remote pppd[8537]: rcvd [IPCP ConfReq id=0x2 <addr 0.0.0.0>]
Dec  7 11:24:14 remote pppd[8537]: sent [IPCP ConfRej id=0x2 <addr 0.0.0.0>]
Dec  7 11:24:14 remote pppd[8537]: rcvd [IPCP ConfRej id=0x2 <addrs 0.0.0.0 0.0.0.0>]
Dec  7 11:24:14 remote pppd[8537]: sent [IPCP ConfReq id=0x3]
Dec  7 11:24:14 remote pppd[8537]: rcvd [IPCP ConfReq id=0x3]
Dec  7 11:24:14 remote pppd[8537]: sent [IPCP ConfAck id=0x3]
Dec  7 11:24:14 remote pppd[8537]: rcvd [IPCP ConfAck id=0x3]
Dec  7 11:24:14 remote pppd[8537]: Could not determine local IP address
Dec  7 11:24:14 remote pppd[8537]: sent [IPCP TermReq id=0x4 "Could not determine local IP address"]
Dec  7 11:24:14 remote pppd[8537]: rcvd [IPCP TermAck id=0x4]
Dec  7 11:24:14 remote pppd[8537]: sent [LCP TermReq id=0x3 "No network protocols running"]
Dec  7 11:24:15 remote pppd[8537]: rcvd [LCP TermReq id=0x3 "No network protocols running"]
Dec  7 11:24:15 remote pppd[8537]: sent [LCP TermAck id=0x3]
Dec  7 11:24:15 remote pppd[8537]: rcvd [LCP TermAck id=0x3]
Dec  7 11:24:15 remote pppd[8537]: Connection terminated.
Dec  7 11:24:15 remote pppd[8537]: Connect time 0.1 minutes.
Dec  7 11:24:15 remote pppd[8537]: Sent 85 bytes, received 64 bytes.
Dec  7 11:24:15 remote pppd[8537]: Exit.        
================================================================================

I'm still not sure about the relationship between the
authentication data I enter on the phone vs. what I use via
PPP(/LCP/PAP/whatever).  It seems that what's in the phone
is what matters.

In this trace, it appears that the authentication is
accepted, but the negotiation for the connection breaks.  I
have twiddled the phone's compression settings with no luck.
The Linux PPP Howto mentions the "Could not determine local
IP address" issue, but it does not seem relevant here.

I tried adding
        ipcp-accept-local
        ipcp-accept-remote
per the recommendation in this thread.
        http://lists.debian.org/debian-user/2000/debian-user-200009/msg00049....
It didn't seem to make any difference.

The following PPP-related modules are loaded on my system.
        ppp_deflate             2904   0  (autoclean)
        zlib_inflate           18276   0  (autoclean) [ppp_deflate]
        zlib_deflate           17400   0  (autoclean) [ppp_deflate]
        bsd_comp                3928   0  (autoclean)
        ppp_async               6432   0  (autoclean)
        ppp_generic            16832   0  (autoclean) [ppp_deflate bsd_comp ppp_async]
        slhc                    4384   0  (autoclean) [ppp_generic]

So...any ideas?

Thank you.

--kyler

 
 
 

PPP problem with Cingular GPRS

Post by Clifford Kit » Mon, 09 Dec 2002 03:58:28



> Here's a trace of the PPPd output:
> ========================================================================
> Dec  7 11:24:13 remote pppd[8537]: pppd 2.4.1 started by root, uid 0
> Dec  7 11:24:13 remote pppd[8537]: using channel 50
> Dec  7 11:24:13 remote pppd[8537]: Using interface ppp0
> Dec  7 11:24:13 remote pppd[8537]: Connect: ppp0 <--> /dev/rfcomm0
> Dec  7 11:24:13 remote pppd[8537]: sent [LCP ConfReq id=0x1 <asyncmap 0x0>
> <magic 0x3178a56d> <pcomp> <accomp>]
> Dec  7 11:24:13 remote pppd[8537]: rcvd [LCP ConfReq id=0x1 <asyncmap 0x0>
> <pcomp> <accomp> <auth pap>]
> Dec  7 11:24:13 remote pppd[8537]: sent [LCP ConfAck id=0x1 <asyncmap 0x0>
> <pcomp> <accomp> <auth pap>]
> Dec  7 11:24:13 remote pppd[8537]: rcvd [LCP ConfRej id=0x1 <magic
> 0x3178a56d>]
> Dec  7 11:24:13 remote pppd[8537]: sent [LCP ConfReq id=0x2 <asyncmap 0x0>
> <pcomp> <accomp>]
> Dec  7 11:24:13 remote pppd[8537]: rcvd [LCP ConfAck id=0x2 <asyncmap 0x0>
> <pcomp> <accomp>]
> Dec  7 11:24:13 remote pppd[8537]: sent [PAP AuthReq id=0x1

> Dec  7 11:24:13 remote pppd[8537]: rcvd [PAP AuthAck id=0x1 ""]
> Dec  7 11:24:13 remote pppd[8537]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>
> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
> Dec  7 11:24:13 remote pppd[8537]: sent [CCP ConfReq id=0x1 <deflate 15>
> <deflate(old#) 15> <bsd v1 15>]
> Dec  7 11:24:13 remote pppd[8537]: rcvd [LCP ProtRej id=0x3 80 fd 01 01
> 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
> Dec  7 11:24:14 remote pppd[8537]: rcvd [IPCP ConfReq id=0x1]
> Dec  7 11:24:14 remote pppd[8537]: sent [IPCP ConfNak id=0x1 <addr
> 0.0.0.0>]

Pppd needs an IP address for the remote.  Try using the pppd option
":192.168.0.1" (you can use any convenient reserved IP address instead
of 192.168.0.1).

That should get rid of the immediate problem, which is that the remote
doesn't specify an IP address for itself.  Specifying a private address
for it as a pppd option should work; it will very likely be accepted
*provided* that the remote is not doing NAT and using the same subnet
to which the private IP address you supply belongs.

Quote:> Dec  7 11:24:14 remote pppd[8537]: rcvd [IPCP ConfRej id=0x1 <addr 0.0.0.0>
> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]

Not related to the problem, but I'd suggest you drop the pppd option
usepeerdns and add the options noccp, novj, and nomagic.  This will
eliminate the useless negotiations that take them out.

[Follow-ups sent to comp.os.linux.networking only]

--

PPP-Q&A links, downloads:    http://users3.ev1.net/~ckite/public_html/
/* In my book, the first poster to resort to personal abuse in a Usenet
   debate loses by default.  -  Rod Smith */

 
 
 

PPP problem with Cingular GPRS

Post by Kyler Lair » Mon, 09 Dec 2002 06:01:59



>Pppd needs an IP address for the remote.  Try using the pppd option
>":192.168.0.1" (you can use any convenient reserved IP address instead
>of 192.168.0.1).

That didn't do it, but it did change the response slightly.

===============================================================================
Dec  7 15:21:25 remote pppd[15550]: pppd 2.4.1 started by root, uid 0
Dec  7 15:21:25 remote pppd[15550]: using channel 55
Dec  7 15:21:25 remote pppd[15550]: Using interface ppp0
Dec  7 15:21:25 remote pppd[15550]: Connect: ppp0 <--> /dev/rfcomm0
Dec  7 15:21:25 remote pppd[15550]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <pcomp> <accomp>]
Dec  7 15:21:25 remote pppd[15550]: rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <pcomp> <accomp> <auth pap>]
Dec  7 15:21:25 remote pppd[15550]: sent [LCP ConfAck id=0x1 <asyncmap 0x0> <pcomp> <accomp> <auth pap>]
Dec  7 15:21:25 remote pppd[15550]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <pcomp> <accomp>]

Dec  7 15:21:25 remote pppd[15550]: rcvd [PAP AuthAck id=0x1 ""]
Dec  7 15:21:25 remote pppd[15550]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Dec  7 15:21:25 remote /etc/hotplug/net.agent: assuming ppp0 is already up
Dec  7 15:21:26 remote pppd[15550]: rcvd [IPCP ConfReq id=0x1]
Dec  7 15:21:26 remote pppd[15550]: sent [IPCP ConfNak id=0x1 <addr 192.168.0.1>]
Dec  7 15:21:26 remote pppd[15550]: rcvd [IPCP ConfRej id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Dec  7 15:21:26 remote pppd[15550]: sent [IPCP ConfReq id=0x2 <addrs 0.0.0.0 192.168.0.4>]
Dec  7 15:21:27 remote pppd[15550]: rcvd [IPCP ConfReq id=0x2 <addr 192.168.0.4>]
Dec  7 15:21:27 remote pppd[15550]: sent [IPCP ConfAck id=0x2 <addr 192.168.0.4>]
Dec  7 15:21:27 remote pppd[15550]: rcvd [IPCP ConfRej id=0x2 <addrs 0.0.0.0 192.168.0.4>]
Dec  7 15:21:27 remote pppd[15550]: sent [IPCP ConfReq id=0x3]
Dec  7 15:21:27 remote pppd[15550]: rcvd [IPCP ConfAck id=0x3]
Dec  7 15:21:27 remote pppd[15550]: Could not determine local IP address
Dec  7 15:21:27 remote pppd[15550]: sent [IPCP TermReq id=0x4 "Could not determine local IP address"]
Dec  7 15:21:27 remote pppd[15550]: rcvd [IPCP TermReq id=0x4 "Could not determine local IP address"]
Dec  7 15:21:27 remote pppd[15550]: sent [IPCP TermAck id=0x4]
===============================================================================

Quote:>Not related to the problem, but I'd suggest you drop the pppd option
>usepeerdns and add the options noccp, novj, and nomagic.  This will
>eliminate the useless negotiations that take them out.

Hmmmm...I don't see where usepeerdns was specified, but I've added the
others.  I would like to eliminate unecessary negotiation, so I'll
keep working on that.  Perhaps I need to specify ms-dns?

Thank you.

--kyler

 
 
 

PPP problem with Cingular GPRS

Post by Clifford Kit » Mon, 09 Dec 2002 11:13:11




>>Pppd needs an IP address for the remote.  Try using the pppd option
>>":192.168.0.1" (you can use any convenient reserved IP address instead
>>of 192.168.0.1).
> That didn't do it, but it did change the response slightly.
> =======================================================================
> Dec  7 15:21:25 remote pppd[15550]: pppd 2.4.1 started by root, uid 0
> Dec  7 15:21:25 remote pppd[15550]: using channel 55
> Dec  7 15:21:25 remote pppd[15550]: Using interface ppp0
> Dec  7 15:21:25 remote pppd[15550]: Connect: ppp0 <--> /dev/rfcomm0
> 0x0> <pcomp> <accomp>]
> Dec  7 15:21:25 remote pppd[15550]: rcvd [LCP ConfReq id=0x1 <asyncmap
> 0x0> <pcomp> <accomp> <auth pap>]
> Dec  7 15:21:25 remote pppd[15550]: sent [LCP ConfAck id=0x1 <asyncmap
> 0x0> <pcomp> <accomp> <auth pap>]
> Dec  7 15:21:25 remote pppd[15550]: rcvd [LCP ConfAck id=0x1 <asyncmap
> 0x0> <pcomp> <accomp>]
> Dec  7 15:21:25 remote pppd[15550]: sent [PAP AuthReq id=0x1

> Dec  7 15:21:25 remote pppd[15550]: rcvd [PAP AuthAck id=0x1 ""]
> Dec  7 15:21:25 remote pppd[15550]: sent [IPCP ConfReq id=0x1 <addr
> 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
> Dec  7 15:21:25 remote /etc/hotplug/net.agent: assuming ppp0 is already up

Whatever net.agent is, it is wrong.  The PPP interface doesn't come up
until after IPCP negotiations successfully complete.

Quote:> Dec  7 15:21:26 remote pppd[15550]: rcvd [IPCP ConfReq id=0x1]

The peer doesn't request an IP address in it's IPCP Configure-Request,
which is empty.

Quote:> Dec  7 15:21:26 remote pppd[15550]: sent [IPCP ConfNak id=0x1 <addr
> 192.168.0.1>]

So pppd suggests 192.168.0.1

Quote:> Dec  7 15:21:26 remote pppd[15550]: rcvd [IPCP ConfRej id=0x1 <addr
> 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]

The peer is broken, or very poorly configured; this Configure-Reject
means that the only configuration left is an empty IPCP request by pppd.
Try using the pppd option "192.168.0.1:192.168.0.4" and see what happens.

If that doesn't work then you may have to call the ISP and work your
way up the technical support ladder until you can find out what the ISP
PPP implementation wants done during IPCP negotiation.  If anyone there
knows at all.  Once upon a time someone modified a 2.3.x pppd to accept
0.0.0.0 to overcome a similar problem but that's an extreme measure with
no assurance that it will work.

Quote:> Dec  7 15:21:26 remote pppd[15550]: sent [IPCP ConfReq id=0x2 <addrs
> 0.0.0.0 192.168.0.4>]

This is an old IP address option, rarely seen these days, and is a last
ditch attempt by pppd to get the peer to send it an IP address to use
locally.

Quote:> Dec  7 15:21:27 remote pppd[15550]: rcvd [IPCP ConfReq id=0x2 <addr
> 192.168.0.4>]

The peer now wants 192.168.0.4, very strange.

Quote:> Dec  7 15:21:27 remote pppd[15550]: sent [IPCP ConfAck id=0x2 <addr
> 192.168.0.4>]

Pppd accepts that IP address for the remote.

Quote:> Dec  7 15:21:27 remote pppd[15550]: rcvd [IPCP ConfRej id=0x2 <addrs
> 0.0.0.0 192.168.0.4>]

The peer rejects the addrs option too.

Quote:> Dec  7 15:21:27 remote pppd[15550]: sent [IPCP ConfReq id=0x3]
> Dec  7 15:21:27 remote pppd[15550]: rcvd [IPCP ConfAck id=0x3]

Which is enough for pppd.  It sends an empty Configure-Request and
gets an Ack, setting things up for...

Quote:> Dec  7 15:21:27 remote pppd[15550]: Could not determine local IP address
> Dec  7 15:21:27 remote pppd[15550]: sent [IPCP TermReq id=0x4 "Could
> not determine local IP address"]

this IPCP Terminate-Request and then...

Quote:> Dec  7 15:21:27 remote pppd[15550]: rcvd [IPCP TermReq id=0x4 "Could
> not determine local IP address"]

the peer is likely gone away and pppd receives a bounce-back of it's
own Terminate-Request, but I can't be absolutely sure because of the
lack of magic numbers.

Quote:> Dec  7 15:21:27 remote pppd[15550]: sent [IPCP TermAck id=0x4]

Anyway pppd agrees with it's bounced message or one from the peer.
The end.

The posts about GPRS connections all seem to have *some* strange problem.

Quote:> ======================================================================
>>Not related to the problem, but I'd suggest you drop the pppd option
>>usepeerdns and add the options noccp, novj, and nomagic.  This will
>>eliminate the useless negotiations that take them out.
> Hmmmm...I don't see where usepeerdns was specified, but I've added the
> others.  I would like to eliminate unecessary negotiation, so I'll
> keep working on that.  Perhaps I need to specify ms-dns?

No, that's for pppd supplying the peer with a DNS nameserver IP address.
Do "grep usepeerdns /etc/ppp/*" and you should find the configuration
file with usepeerdns in it.


PPP-Q&A links, downloads:    http://users3.ev1.net/~ckite/public_html/
/* Slogan appropriate for a certain well-know software company:
   FAILURE IS NOT AN OPTION - it is built into the operating system
   and comes bundled with the software. */

 
 
 

PPP problem with Cingular GPRS

Post by Michael Buchenriede » Mon, 09 Dec 2002 20:44:31


[...]

Quote:>Dec  7 15:21:25 remote /etc/hotplug/net.agent: assuming ppp0 is already up

Broken, as pppd hasn't yet finished negotiations.

Quote:>Dec  7 15:21:26 remote pppd[15550]: rcvd [IPCP ConfReq id=0x1]
>Dec  7 15:21:26 remote pppd[15550]: sent [IPCP ConfNak id=0x1 <addr 192.168.0.1>]
>Dec  7 15:21:26 remote pppd[15550]: rcvd [IPCP ConfRej id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
>Dec  7 15:21:26 remote pppd[15550]: sent [IPCP ConfReq id=0x2 <addrs 0.0.0.0 192.168.0.4>]
>Dec  7 15:21:27 remote pppd[15550]: rcvd [IPCP ConfReq id=0x2 <addr 192.168.0.4>]
>Dec  7 15:21:27 remote pppd[15550]: sent [IPCP ConfAck id=0x2 <addr 192.168.0.4>]
>Dec  7 15:21:27 remote pppd[15550]: rcvd [IPCP ConfRej id=0x2 <addrs 0.0.0.0 192.168.0.4>]

[...]

The PPP implementation on the ISP's side is broken. You'll have to ring up
their tech department, asking them what their pppd version expects the client
to send/receive. Caveat: It is possible that the dialogue needed for the GPRS
connection needs a specifically adapted version of Linux' pppd as well, in case
the pppd version the ISP uses is some strange home-brewn thing with no
equivalent in the Linux world - in which case you're out of luck.

Michael
--

          Lumber Cartel Unit #456 (TINLC) & Official Netscum
    Note: If you want me to send you email, don't munge your address.

 
 
 

PPP problem with Cingular GPRS

Post by Kyler Lair » Wed, 11 Dec 2002 07:52:38


Thanks to all who tried to help me!  It's now working.
That's great, but I'm sorry to report that I don't know
what the problem was.

At work today, I borrowed an MS Windows computer and
dialed in using the built-in networking.  It worked
without any special setup.  I went back to my machine
and it worked there too.

I'm posting this using a Pretec CompactBT Bluetooth
adapter connected to a T68i using Cingular GPRS.

--kyler

 
 
 

1. GPRS with a Cingular SIM card

Hi. I've recently purchased a Cingular SIM card that I'm trying to use
to make a GPRS connection from Linux.

I've inserted the SIM into a Sierra Wireless AirCard 750 [1]. It's not
working.

Before I go into detail, I should mention that the config files I'm
using work perfectly with an AT&T SIM card when plugged into the same
AirCard, using the same version of the AirCard firmware (there are
different versions for different providers, though the same version of
the firmware should work for both AT&T and Cingular SIMs).

Consequently I doubt there is anything fundamentally wrong with the way
I'm trying to use GPRS, and that it's more likely something that I
don't know about how to use a Cingular SIM with GPRS. The obvious
question is whether or not the SIM is enabled for GPRS, but it was
purchased from a Cingular shop last Thursday and was only setup with a
$40 per month data plan.

Is there anything else you need to do? Do I need to specify a username
and password for example? The manual configuration guide on the
Cingular site [2] implies that there isn't.

Anyway, on to my diganostics.

My chatscript looks like this:

  ABORT ERROR
  '' AT
  OK AT+CSQ
  OK AT+CGDCONT=1,"IP","\T"
  OK ATD*99***1#
  CONNECT ''

When I cut and paste the key lines from the chat script into a terminal
connected to the wireless modem I get the following output. It all
looks fine to me, right up until part way through the initial hand
shake from the remote PPP server, when it says "NO CARRIER" and the
connection drops.

---cut---
Welcome to minicom 2.1

OPTIONS: History Buffer, F-key Macros, Search History Buffer, I18n
Compiled on Aug 13 2004, 08:34:08.

Press CTRL-A Z for help on special keys

AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0
OK
AT+CSQ
+CSQ: 15,0

OK
AT+CGDCONT=1,"IP","isp.cingular"
OK
ATD*99***1#
CONNECT

NO CARRIER
---cut---

Note that the AT+CSQ command is reporting the signal strength, a number
that can vary between 0 and 31; 15 is plenty.

What could cause the "NO CARRIER" message to appear even though data is
being transmitted? There is a 20 second pause between the last
character of the negotiation sent by the server and the "NO CARRIER"
message appearing.

I've also recorded the logs from an unsuccessful attempt to connect
with PPP and the chatscript. I uploaded them to pastebin:

http://pastebin.com/302278

This chatscript works every time with an AT&T SIM card.

Does anybody have any ideas? I'm getting really stuck for possibilities
to explore.

Thanks,

Graham.

2. 3Com 3c509 Networkcard + SuSE 6.1-AXP on Alpha PC164 (500Mhz)

3. linux, bluetooth and GPRS: PPP problem

4. PPP Problems

5. PPP over GPRS with Samsung S105

6. EtherAdapter-16

7. BSD4 to ppp GPRS

8. ppp +NT 4.0 RAS

9. gprs, ppp secrets and resolv.conf

10. PPP and GPRS: can send but not receive anything after line is up

11. Cingular or Verizon wirless service with Linux

12. Cingular EDGE on Linux

13. Serial port and gprs modem problem