Re: Ecos, LwIP, PPP and GPRS

In comp.arch.embedded,
Patrick Klos <pklos@xxxxxxxxxxxxx> wrote:
>In article <e6643$43cfa4aa$54f63171$17770@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
>Stef <stef33d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>>In comp.arch.embedded,
>>Patrick Klos <pklos@xxxxxxxxxxxxx> wrote:
>>>In article <4fdd5$43ced14f$54f63171$12292@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
>>>Stef <stef33d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> 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 data*** 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.
.