Prev: USB CY7C67300 chip HPI
Next: Polling vs. Interrupts in counting pulses - what is better?
From: Stef on 18 Jan 2006 18:37
Hello,

I'm trying to get a GPRS PPP connection going in eCos using the LwIP
stack, but no luck so far.

It seems that my provider and the LwIP PPP code do not understand each
other. I', trying to find examples of correct communication but have
had no luck so far and RFC1661 is a bit hard to decode. Does anyone
know good links to information on this subject? Google has not come
up with many insightfull links for me.

For experts in debugging PPP communication, can you make any sense of the
following log data? I had to capture sending and receiving to the modem
separately, so the below parts should be intermixed.

There seems to be some communication and even user/pass sending and I get
a "Welcome!", but after that it dies somewhere.

If I turn on LWIP debugging, I see lots of "invalid" FCS messages. But
debugging uses diag_printf(), which turns off interrupts and therefore
might introduce character loss.


Sent to modem:

0000 41 54 5A 0A 41 54 20 53 30 3D 30 20 45 30 0A 41 ATZ.AT S0=0 E0.A
0010 54 2B 43 47 44 43 4F 4E 54 3D 31 2C 22 49 50 22 T+CGDCONT=1,"IP"
0020 2C 22 77 65 62 2E 76 6F 64 61 66 6F 6E 65 2E 6E ,"web.vodafone.n
0030 6C 22 0A 41 54 44 54 2A 39 39 23 0A 7E FF 7D 23 l".ATDT*99#.~.}#
0040 C0 21 7D 21 7D 21 7D 20 7D 34 7D 22 7D 26 7D 20 .!}!}!} }4}"}&}
0050 7D 20 7D 20 7D 20 7D 25 7D 26 52 7D 38 7D 30 44 } } } }%}&R}8}0D
0060 7D 27 7D 22 7D 28 7D 22 6E E1 7E FF 7D 23 C0 21 }'}"}(}"n.~.}#.!
0070 7D 21 7D 22 7D 20 7D 2E 7D 22 7D 26 7D 20 7D 20 }!}"} }.}"}&} }
0080 7D 20 7D 20 7D 27 7D 22 7D 28 7D 22 87 3A 7E 7E } } }'}"}(}".:~~
0090 FF 7D 23 C0 21 7D 22 7D 21 7D 20 7D 36 7D 21 7D .}#.!}"}!} }6}!}
00A0 24 7D 25 DC 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 $}%.}"}&} } } }
00B0 7D 27 7D 22 7D 28 7D 22 7D 23 7D 24 C0 23 D0 47 }'}"}(}"}#}$.#.G
00C0 7E FF 03 C0 23 01 01 00 16 08 76 6F 64 61 66 6F ~...#.....vodafo
00D0 6E 65 08 76 6F 64 61 66 6F 6E 65 9D D5 7E 7E FF ne.vodafone..~~.
00E0 03 80 21 01 01 00 16 03 06 00 00 00 00 81 06 00 ..!.............
00F0 00 00 00 83 06 00 00 00 00 6E DB 7E FF 03 80 21 .........n.~...!
0100 02 01 00 0A 03 06 C0 A8 6F 6F DA D3 7E FF 03 80 ........oo..~...
0110 21 01 02 00 10 03 06 00 00 00 00 83 06 00 00 00 !...............
0120 00 28 15 7E FF 03 80 21 01 03 00 0A 03 06 00 00 .(.~...!........
0130 00 00 E9 B3 7E FF 03 80 21 01 04 00 0A 03 06 C0 ....~...!.......
0140 A8 6F 70 DD 3D 7E FF 7D 23 C0 21 7D 26 7D 22 7D .op.=~.}#.!}&}"}
0150 20 7D 24 94 7D 2D 7E }$.}-~

Received from modem:

E2 0A 0A 4F 4B 0A 0A 41 54 ...OK..AT
0160 20 53 30 3D 30 20 45 30 0A 0A 0A 4F 4B 0A 0A 0A S0=0 E0...OK...
0170 0A 4F 4B 0A 0A 0A 0A 43 4F 4E 4E 45 43 54 20 39 .OK....CONNECT 9
0180 36 30 30 0A 0A 7E FF 7D 23 C0 21 7D 21 7D 21 7D 600..~.}#.!}!}!}
0190 20 7D 36 7D 21 7D 24 7D 25 DC 7D 22 7D 26 7D 20 }6}!}$}%.}"}&}
01A0 7D 20 7D 20 7D 20 7D 27 7D 22 7D 28 7D 22 7D 23 } } } }'}"}(}"}#
01B0 7D 24 C0 23 26 B4 7E 7E FF 7D 23 C0 21 7D 24 7D }$.#&.~~.}#.!}$}
01C0 21 7D 20 7D 2A 7D 25 7D 26 52 7D 38 7D 30 44 B4 !} }*}%}&R}8}0D.
01D0 C5 7E 7E FF 7D 23 C0 21 7D 22 7D 22 7D 20 7D 2E .~~.}#.!}"}"} }.
01E0 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 27 7D 22 }"}&} } } } }'}"
01F0 7D 28 7D 22 B9 B9 7E 7E FF 7D 23 C0 21 7D 21 7D }(}"..~~.}#.!}!}
0200 21 7D 20 7D 36 7D 21 7D 24 7D 25 DC 7D 22 7D 26 !} }6}!}$}%.}"}&
0210 7D 20 7D 20 7D 20 7D 20 7D 27 7D 22 7D 28 7D 22 } } } } }'}"}(}"
0220 7D 23 7D 24 C0 23 26 B4 7E 7E C0 23 7D 22 7D 21 }#}$.#&.~~.#}"}!
0230 7D 20 7D 2D 7D 28 57 65 6C 63 6F 6D 65 21 4E BC } }-}(Welcome!N.
0240 7E 7E 80 21 7D 21 7D 21 7D 20 7D 2A 7D 23 7D 26 ~~.!}!}!} }*}#}&
0250 C0 A8 6F 6F CD 49 7E 7E 80 21 7D 24 7D 21 7D 20 ..oo.I~~.!}$}!}
0260 7D 2A 81 7D 26 7D 20 7D 20 7D 20 7D 20 22 57 7E }*.}&} } } } "W~
0270 7E 80 21 7D 24 7D 22 7D 20 7D 2A 83 7D 26 7D 20 ~.!}$}"} }*.}&}
0280 7D 20 7D 20 7D 20 73 89 7E 7E 80 21 7D 23 7D 23 } } } s.~~.!}#}#
0290 7D 20 7D 2A 7D 23 7D 26 C0 A8 6F 70 7D 2F 62 7E } }*}#}&..op}/b~
02A0 7E FF 7D 23 C0 21 7D 25 7D 22 7D 20 7D 24 59 28 ~.}#.!}%}"} }$Y(
02B0 7E 0A 0A 45 52 52 4F 52 0A 0A 0A 0A 4E 4F 20 43 ~..ERROR....NO C
02C0 41 52 52 49 45 52 0A 0A ARRIER..

--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

I think I'll KILL myself by leaping out of this 14th STORY WINDOW while
reading ERICA JONG'S poetry!!
From: Patrick Klos on 19 Jan 2006 08:10
In article <4fdd5$43ced14f$54f63171$12292(a)publishnet.news-service.com>,
Stef <stef33d(a)yahooI-N-V-A-L-I-D.com.invalid> wrote:
>Hello,
>
>I'm trying to get a GPRS PPP connection going in eCos using the LwIP
>stack, but no luck so far.
>
>It seems that my provider and the LwIP PPP code do not understand each
>other. I', trying to find examples of correct communication but have
>had no luck so far and RFC1661 is a bit hard to decode. Does anyone
>know good links to information on this subject? Google has not come
>up with many insightfull links for me.
>
>For experts in debugging PPP communication, can you make any sense of the
>following log data? I had to capture sending and receiving to the modem
>separately, so the below parts should be intermixed.

The information below looks like a normal basic negotiation. First LCP
is negotiated. Then the peer is authenticated with PAP. Then IPCP is
negotiated. Your client first asks for several options that the "server"
doesn't care for, but they finally swap IP addresses and should be ready
to send IP traffic. Then for some unknown reason, the "server" simply
sends a Terminate-Request to the "client". How long does the whole process
take??

>There seems to be some communication and even user/pass sending and I get
>a "Welcome!", but after that it dies somewhere.
>
>If I turn on LWIP debugging, I see lots of "invalid" FCS messages. But
>debugging uses diag_printf(), which turns off interrupts and therefore
>might introduce character loss.

Where is the LWIP output log? I can't check the FCS by hand so I'll
have to trust the LWIP debug output.

>Sent to modem:
>
>0000 41 54 5A 0A 41 54 20 53 30 3D 30 20 45 30 0A 41 ATZ.AT S0=0 E0.A
>0010 54 2B 43 47 44 43 4F 4E 54 3D 31 2C 22 49 50 22 T+CGDCONT=1,"IP"
>0020 2C 22 77 65 62 2E 76 6F 64 61 66 6F 6E 65 2E 6E ,"web.vodafone.n
>0030 6C 22 0A 41 54 44 54 2A 39 39 23 0A 7E FF 7D 23 l".ATDT*99#.~.}#
>0040 C0 21 7D 21 7D 21 7D 20 7D 34 7D 22 7D 26 7D 20 .!}!}!} }4}"}&}
>0050 7D 20 7D 20 7D 20 7D 25 7D 26 52 7D 38 7D 30 44 } } } }%}&R}8}0D
>0060 7D 27 7D 22 7D 28 7D 22 6E E1 7E FF 7D 23 C0 21 }'}"}(}"n.~.}#.!
>0070 7D 21 7D 22 7D 20 7D 2E 7D 22 7D 26 7D 20 7D 20 }!}"} }.}"}&} }
>0080 7D 20 7D 20 7D 27 7D 22 7D 28 7D 22 87 3A 7E 7E } } }'}"}(}".:~~
>0090 FF 7D 23 C0 21 7D 22 7D 21 7D 20 7D 36 7D 21 7D .}#.!}"}!} }6}!}
>00A0 24 7D 25 DC 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 $}%.}"}&} } } }
>00B0 7D 27 7D 22 7D 28 7D 22 7D 23 7D 24 C0 23 D0 47 }'}"}(}"}#}$.#.G
>00C0 7E FF 03 C0 23 01 01 00 16 08 76 6F 64 61 66 6F ~...#.....vodafo
>00D0 6E 65 08 76 6F 64 61 66 6F 6E 65 9D D5 7E 7E FF ne.vodafone..~~.
>00E0 03 80 21 01 01 00 16 03 06 00 00 00 00 81 06 00 ..!.............
>00F0 00 00 00 83 06 00 00 00 00 6E DB 7E FF 03 80 21 .........n.~...!
>0100 02 01 00 0A 03 06 C0 A8 6F 6F DA D3 7E FF 03 80 ........oo..~...
>0110 21 01 02 00 10 03 06 00 00 00 00 83 06 00 00 00 !...............
>0120 00 28 15 7E FF 03 80 21 01 03 00 0A 03 06 00 00 .(.~...!........
>0130 00 00 E9 B3 7E FF 03 80 21 01 04 00 0A 03 06 C0 ....~...!.......
>0140 A8 6F 70 DD 3D 7E FF 7D 23 C0 21 7D 26 7D 22 7D .op.=~.}#.!}&}"}
>0150 20 7D 24 94 7D 2D 7E }$.}-~
>
>Received from modem:
>
> E2 0A 0A 4F 4B 0A 0A 41 54 ...OK..AT
>0160 20 53 30 3D 30 20 45 30 0A 0A 0A 4F 4B 0A 0A 0A S0=0 E0...OK...
>0170 0A 4F 4B 0A 0A 0A 0A 43 4F 4E 4E 45 43 54 20 39 .OK....CONNECT 9
>0180 36 30 30 0A 0A 7E FF 7D 23 C0 21 7D 21 7D 21 7D 600..~.}#.!}!}!}
>0190 20 7D 36 7D 21 7D 24 7D 25 DC 7D 22 7D 26 7D 20 }6}!}$}%.}"}&}
>01A0 7D 20 7D 20 7D 20 7D 27 7D 22 7D 28 7D 22 7D 23 } } } }'}"}(}"}#
>01B0 7D 24 C0 23 26 B4 7E 7E FF 7D 23 C0 21 7D 24 7D }$.#&.~~.}#.!}$}
>01C0 21 7D 20 7D 2A 7D 25 7D 26 52 7D 38 7D 30 44 B4 !} }*}%}&R}8}0D.
>01D0 C5 7E 7E FF 7D 23 C0 21 7D 22 7D 22 7D 20 7D 2E .~~.}#.!}"}"} }.
>01E0 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 27 7D 22 }"}&} } } } }'}"
>01F0 7D 28 7D 22 B9 B9 7E 7E FF 7D 23 C0 21 7D 21 7D }(}"..~~.}#.!}!}
>0200 21 7D 20 7D 36 7D 21 7D 24 7D 25 DC 7D 22 7D 26 !} }6}!}$}%.}"}&
>0210 7D 20 7D 20 7D 20 7D 20 7D 27 7D 22 7D 28 7D 22 } } } } }'}"}(}"
>0220 7D 23 7D 24 C0 23 26 B4 7E 7E C0 23 7D 22 7D 21 }#}$.#&.~~.#}"}!
>0230 7D 20 7D 2D 7D 28 57 65 6C 63 6F 6D 65 21 4E BC } }-}(Welcome!N.
>0240 7E 7E 80 21 7D 21 7D 21 7D 20 7D 2A 7D 23 7D 26 ~~.!}!}!} }*}#}&
>0250 C0 A8 6F 6F CD 49 7E 7E 80 21 7D 24 7D 21 7D 20 ..oo.I~~.!}$}!}
>0260 7D 2A 81 7D 26 7D 20 7D 20 7D 20 7D 20 22 57 7E }*.}&} } } } "W~
>0270 7E 80 21 7D 24 7D 22 7D 20 7D 2A 83 7D 26 7D 20 ~.!}$}"} }*.}&}
>0280 7D 20 7D 20 7D 20 73 89 7E 7E 80 21 7D 23 7D 23 } } } s.~~.!}#}#
>0290 7D 20 7D 2A 7D 23 7D 26 C0 A8 6F 70 7D 2F 62 7E } }*}#}&..op}/b~
>02A0 7E FF 7D 23 C0 21 7D 25 7D 22 7D 20 7D 24 59 28 ~.}#.!}%}"} }$Y(
>02B0 7E 0A 0A 45 52 52 4F 52 0A 0A 0A 0A 4E 4F 20 43 ~..ERROR....NO C
>02C0 41 52 52 49 45 52 0A 0A ARRIER..
>
>--
>Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)
>
>I think I'll KILL myself by leaping out of this 14th STORY WINDOW while
>reading ERICA JONG'S poetry!!

Good luck!

Patrick
========= For LAN/WAN Protocol Analysis, check out PacketView Pro! =========
Patrick Klos Email: patrick(a)klos.com
Klos Technologies, Inc. Web: http://www.klos.com/
==================== http://www.loving-long-island.com/ ====================
From: Stef on 19 Jan 2006 09:39
In comp.arch.embedded,
Patrick Klos <pklos(a)osmium.mv.net> wrote:
>In article <4fdd5$43ced14f$54f63171$12292(a)publishnet.news-service.com>,
>Stef <stef33d(a)yahooI-N-V-A-L-I-D.com.invalid> wrote:
>>
>>For experts in debugging PPP communication, can you make any sense of the
>>following log data? I had to capture sending and receiving to the modem
>>separately, so the below parts should be intermixed.
>
>The information below looks like a normal basic negotiation. First LCP
>is negotiated. Then the peer is authenticated with PAP. Then IPCP is
>negotiated. Your client first asks for several options that the "server"
>doesn't care for, but they finally swap IP addresses and should be ready
>to send IP traffic. Then for some unknown reason, the "server" simply
>sends a Terminate-Request to the "client". How long does the whole process
>take??
>
Thanks, but how can you tell? If I look at RFC1661 and my data, about the
only thing I can make sense of is the 'C021' and 'C023', but the data
following those does not look like what I expect from RFC1661. If you can
point me to a site that explains the data, I'd be very thankfull.

The whole process takes about 5 seconds.
This Terminate-request" is one of last data packets before I get "ERROR"?

>>There seems to be some communication and even user/pass sending and I get
>>a "Welcome!", but after that it dies somewhere.
>>
>>If I turn on LWIP debugging, I see lots of "invalid" FCS messages. But
>>debugging uses diag_printf(), which turns off interrupts and therefore
>>might introduce character loss.
>
>Where is the LWIP output log? I can't check the FCS by hand so I'll
>have to trust the LWIP debug output.
>
With the debug on, there is data loss because it turns off interrupts
while printing the messages over another serial port. But when turned
on, it mostly complains about invalid FCS for 'C023' and 'C021'
packets. But due to the data loss, I do not trust it that much.

Is there a way to calculate the FCS manually (or programmatically in
my debuggging code)? A page discribing how it is calculated would be
very welcome.

We now also tried to get this modem (multitech MTSMC-G-F1) to work with
windows, but the results are a bit simular. Only thing is that there is
about twice as much data between "Welcome!" and "ERROR". But also hangs
up after a few seconds.

So maybe there is a problem with the mode settings? Looking for GPRS
settings on the net provides me with many different answers, but this
is what I'm using now:

ATZ
AT S0=0 E0
AT+CGDCONT=1,"IP","web.vodafone.nl"
ATDT*99#

But there are many more settings to GPRS.

--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

We just joined the civil hair patrol!
From: Patrick Klos on 19 Jan 2006 11:43
In article <e6643$43cfa4aa$54f63171$17770(a)publishnet.news-service.com>,
Stef <stef33d(a)yahooI-N-V-A-L-I-D.com.invalid> wrote:
>In comp.arch.embedded,
>Patrick Klos <pklos(a)osmium.mv.net> wrote:
>>In article <4fdd5$43ced14f$54f63171$12292(a)publishnet.news-service.com>,
>>Stef <stef33d(a)yahooI-N-V-A-L-I-D.com.invalid> wrote:
>>The information below looks like a normal basic negotiation. First LCP
>>is negotiated. Then the peer is authenticated with PAP. Then IPCP is
>>negotiated. Your client first asks for several options that the "server"
>>doesn't care for, but they finally swap IP addresses and should be ready
>>to send IP traffic. Then for some unknown reason, the "server" simply
>>sends a Terminate-Request to the "client". How long does the whole process
>>take??
>>
>Thanks, but how can you tell?

Years of experience looking at PPP packets! ;^)

>If I look at RFC1661 and my data, about the
>only thing I can make sense of is the 'C021' and 'C023', but the data
>following those does not look like what I expect from RFC1661. If you can
>point me to a site that explains the data, I'd be very thankfull.

The RFC is the primary source. The frames are pretty straightforward
once you get used to the FLAG and ESCAPE mechanisms.

>The whole process takes about 5 seconds.
>This Terminate-request" is one of last data packets before I get "ERROR"?

Are you aware of any system or device that works with this device and
ISP correctly? If so, can you get a trace of what it's doing?

>With the debug on, there is data loss because it turns off interrupts
>while printing the messages over another serial port. But when turned
>on, it mostly complains about invalid FCS for 'C023' and 'C021'
>packets. But due to the data loss, I do not trust it that much.

Can you modify the debug output to go to a memory buffer instead of the
serial port (or severely abbreviate the debug messages)??

>Is there a way to calculate the FCS manually (or programmatically in
>my debuggging code)? A page discribing how it is calculated would be
>very welcome.

This page looks reasonable, but I haven't tried it myself:

http://www.netfor2.com/fcs.htm

>We now also tried to get this modem (multitech MTSMC-G-F1) to work with
>windows, but the results are a bit simular. Only thing is that there is
>about twice as much data between "Welcome!" and "ERROR". But also hangs
>up after a few seconds.

As others know better than I, GPRS modems can act a little strange.
Maybe someone else will have some insight on that aspect of your problem?

>So maybe there is a problem with the mode settings? Looking for GPRS
>settings on the net provides me with many different answers, but this
>is what I'm using now:
>
>ATZ
>AT S0=0 E0
>AT+CGDCONT=1,"IP","web.vodafone.nl"
>ATDT*99#
>
>But there are many more settings to GPRS.

Are you sure you have the correct user ID and password for the ISP?? It's
a thought...

Patrick
========= For LAN/WAN Protocol Analysis, check out PacketView Pro! =========
Patrick Klos Email: patrick(a)klos.com
Klos Technologies, Inc. Web: http://www.klos.com/
==================== http://www.loving-long-island.com/ ====================
From: Stef on 19 Jan 2006 12:40
In comp.arch.embedded,
Patrick Klos <pklos(a)osmium.mv.net> wrote:
>In article <e6643$43cfa4aa$54f63171$17770(a)publishnet.news-service.com>,
>Stef <stef33d(a)yahooI-N-V-A-L-I-D.com.invalid> wrote:
>>In comp.arch.embedded,
>>Patrick Klos <pklos(a)osmium.mv.net> wrote:
>>>In article <4fdd5$43ced14f$54f63171$12292(a)publishnet.news-service.com>,
>>>Stef <stef33d(a)yahooI-N-V-A-L-I-D.com.invalid> wrote:
>>>The information below looks like a normal basic negotiation. First LCP
>>>is negotiated. Then the peer is authenticated with PAP. Then IPCP is
>>>negotiated. Your client first asks for several options that the "server"
>>>doesn't care for, but they finally swap IP addresses and should be ready
>>>to send IP traffic. Then for some unknown reason, the "server" simply
>>>sends a Terminate-Request to the "client". How long does the whole process
>>>take??
>>>
>>Thanks, but how can you tell?
>
>Years of experience looking at PPP packets! ;^)
>
Ah, that explains it! My experience in this field is a few days. ;-)

>>If I look at RFC1661 and my data, about the
>>only thing I can make sense of is the 'C021' and 'C023', but the data
>>following those does not look like what I expect from RFC1661. If you can
>>point me to a site that explains the data, I'd be very thankfull.
>
>The RFC is the primary source. The frames are pretty straightforward
>once you get used to the FLAG and ESCAPE mechanisms.
>
OK, just keep going then.

>>The whole process takes about 5 seconds.
>>This Terminate-request" is one of last data packets before I get "ERROR"?
>
>Are you aware of any system or device that works with this device and
>ISP correctly? If so, can you get a trace of what it's doing?
>
Yes, and it is..... This modem!

I've had a talk with our local distributor today and it turns out that
there is another AT command set manual for this modem. The one for the
internal IP stack! The datasheet fails to mention the 'minor' fact that
the modem has an IP stack built in. So I can do FTP comms using AT
commands and serial data. No need for IP stack and PPP on the target.
I'm not sure I can do all I need with the internal IP stack, but the
FTP is the most important right now.

So just now I downloaded a file from an ftp server using only
hyperterminal to type a few AT commands.

For now I will continue with the internal stack, but I would like to
get the PPP stuff working at a later stage.

>>With the debug on, there is data loss because it turns off interrupts
>>while printing the messages over another serial port. But when turned
>>on, it mostly complains about invalid FCS for 'C023' and 'C021'
>>packets. But due to the data loss, I do not trust it that much.
>
>Can you modify the debug output to go to a memory buffer instead of the
>serial port (or severely abbreviate the debug messages)??
>
That is what I've already done to log the serial data you saw earlier.
I logged it to a buffer and spit it out in a hex-dump like format when
the connection dies. I've also redirected one debug function to use a
normal serial port that does not stop interrupts, but debug data keeps
coming on that blocking channel from other places in LWIP when debug
is turned on. So I would have to go through all the LWIP sources
to find out where it's coming from.


>>Is there a way to calculate the FCS manually (or programmatically in
>>my debuggging code)? A page discribing how it is calculated would be
>>very welcome.
>
>This page looks reasonable, but I haven't tried it myself:
>
> http://www.netfor2.com/fcs.htm
>
That looks very good indeed. And pressing 'previous' gets me to a page
that I've been looking for for the last few days: A detailed PPP packet
example. Thanks for that link.

>>We now also tried to get this modem (multitech MTSMC-G-F1) to work with
>>windows, but the results are a bit simular. Only thing is that there is
>>about twice as much data between "Welcome!" and "ERROR". But also hangs
>>up after a few seconds.
>
>As others know better than I, GPRS modems can act a little strange.
>Maybe someone else will have some insight on that aspect of your problem?
>
>
Yes, this one seems to need an AT+CGATT=1 to get on the network. And i've
found at least 4 AT commands/dial strings to start the actual connection,
but which is 'right'?

OK, I can do my FTP for now and come back to the PPP when that is done.

Thanks for your help.

--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

Cutler Webster's Law:
There are two sides to every argument, unless a person
is personally involved, in which case there is only one.
 |  Next  |  Last
Pages: 1 2
Prev: USB CY7C67300 chip HPI
Next: Polling vs. Interrupts in counting pulses - what is better?