Forums

Ecos, LwIP, PPP and GPRS

Started by Stef January 18, 2006
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!!
In article <4fdd5$43ced14f$54f63171$12292@publishnet.news-service.com>,
Stef <stef33d@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@klos.com Klos Technologies, Inc. Web: http://www.klos.com/ ==================== http://www.loving-long-island.com/ ====================
In comp.arch.embedded,
Patrick Klos <pklos@osmium.mv.net> wrote:
>In article <4fdd5$43ced14f$54f63171$12292@publishnet.news-service.com>, >Stef <stef33d@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!
In article <e6643$43cfa4aa$54f63171$17770@publishnet.news-service.com>,
Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
>In comp.arch.embedded, >Patrick Klos <pklos@osmium.mv.net> wrote: >>In article <4fdd5$43ced14f$54f63171$12292@publishnet.news-service.com>, >>Stef <stef33d@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@klos.com Klos Technologies, Inc. Web: http://www.klos.com/ ==================== http://www.loving-long-island.com/ ====================
In comp.arch.embedded,
Patrick Klos <pklos@osmium.mv.net> wrote:
>In article <e6643$43cfa4aa$54f63171$17770@publishnet.news-service.com>, >Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote: >>In comp.arch.embedded, >>Patrick Klos <pklos@osmium.mv.net> wrote: >>>In article <4fdd5$43ced14f$54f63171$12292@publishnet.news-service.com>, >>>Stef <stef33d@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.
On Thursday, in article <dqofjn$1vvr$1@pyrite.mv.net>
     pklos@osmium.mv.net "Patrick Klos" wrote:

>In article <e6643$43cfa4aa$54f63171$17770@publishnet.news-service.com>, >Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote: >>In comp.arch.embedded, >>Patrick Klos <pklos@osmium.mv.net> wrote:
.......
>>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...
From the info I have not tried personally there is a username and password expected, I suggest you test it and check for capital letters. If you go to this page for a GPRS modem and get the zip file of all technical documents, it contains a web page listing of lots of known settings for user, password, APN, DNS for various operators and countries. <http://www.roundsolutions.com/GM862/index.htm> -- Paul Carpenter | paul@pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.gnuh8.org.uk/> GNU H8 & mailing list info <http://www.badweb.org.uk/> For those web sites you hate
In comp.arch.embedded,
Paul Carpenter <paul$@pcserviceselectronics.co.uk> wrote:
>On Thursday, in article <dqofjn$1vvr$1@pyrite.mv.net> > pklos@osmium.mv.net "Patrick Klos" wrote: >> >>Are you sure you have the correct user ID and password for the ISP?? It's >>a thought... > >From the info I have not tried personally there is a username and password >expected, I suggest you test it and check for capital letters. >
Always a posibility, but I have got the correct ones. For our vodafone network it's user:vodafone pass:vodafone. This works with modem in IP mode.
>If you go to this page for a GPRS modem and get the zip file of all >technical documents, it contains a web page listing of lots of known settings >for user, password, APN, DNS for various operators and countries. > > <http://www.roundsolutions.com/GM862/index.htm> >
Lots of datasheets there, downloading now, thanks. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) The little town that time forgot, Where all the women are strong, The men are good-looking, And the children above-average. -- Prairie Home Companion
> > <http://www.roundsolutions.com/GM862/index.htm> > > > Lots of datasheets there, downloading now, thanks.
To keep it simple: As a customer of Round Solutions you will enjoy a huge community based on the biggest GSM module user forum in the Internet with FAQ and a lot of postings. You will get factory support and you will see that users help users as well. You will stay in a community with more then 2100 members around the world. A big "technical family" that grows each day. Regards Meff www.gsm-modem.de P.S: I am the admin of the Round Solutions forum.

..is this thread too old to have a reply? :-)
It looks like it's quite hatd to figure out what's going on with my G600
GSM/GPRS module: I have SIMILAR data, but how to decode them?
MCU to modem:
7E 3F 7D 23 3F 21 7D 21 7D 21 7D 20 7D 34 7D 22 7D 26 7D 20 7D 20 7D 20 7D
20 7D 25 7D 26 65 67 6C 6A 7D 

Response:
7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 32 7D 22 7D 26 7D 20 7D 20 7D 20 7D
20 7D 23 7D 24 C0 23 7D 27 7D&nbsp;

Why these slight differences?

Full sequence sent:
[code]
7E3F7D233F21
7D217D217D207D347D227D267D207D
207D207D207D257D2665676C6A7D277D
227D287D223F6D7E
7E3F
7D233F217D227D217D207D327D227D26
7D207D207D207D207D237D243F237D
277D227D287D223F3F7E
7E3F230102475052537E3F7D233F217D217D23
7D207D2E7D227D267D207D207D207D
207D277D227D287D222A3F7E
7E3F2301047E
7E3F2101057E3F2101062F7E
7E3F21010703067E3F2102017E3F2101083F3F7E
7E21453F04
5F6E3F16042D073F0102080928083F617E
7E2145
3F04
5F6E3F160478053F010104026C737E
7E2145303F160402203F3F7E
7E2145
7D5D
3F04
5F6E3F1604123456780204053F010104024A677E
7E21456E3F16047002203F3F7E
7E214506
7B
3F04
5F6E3F1604123456787E21
455F6E3F160404023F3F7E
7E21450B3F123456787E
214504
5F6E3F16040104023F3F7E
7E21453F717E21453F04
5F6E3F16043F01010402493A7E
7E2145047E
7E214574
3F04
5F6E3F160478053F010104026F2E7E
7E2145303F160402203F7E[/code]

Full response:
[code]
7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 32 7D 22 7D 26 7D 20 7D 20 7D 20 7D
20 7D 23 7D 24 C0 23 7D 27 7D 22 7D 28 7D 22 DD 94 7E 7E FF 7D 23 C0 21 7D
24 7D 21 7D 20 7D 2A 7D 25 7D 26 65 67 6C 6A 60 85 7E 7E FF 7D 23 C0 21 7D
22 7D 23 7D 20 7D 2E 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 27 7D 22 7D 28
7D 22 7D 34 BC 7E 7E C0 23 02 04 00 05 00 AA 5E 7E 7E 80 21 03 05
00030600000000C6A17E7E8021030600030600000000C1777E7E802101010004BB997E7E80210307000306B506E685837E7E80210208000306B506E68A397E
[/code]



---------------------------------------
Posted through http://www.EmbeddedRelated.com
They seem to be RFC 1662 encoded PPP frames.
I was too lazy to see if CRC's match.

A frame is delimited by 0x7e characters. I there are
back-to-back frames, only one delimiter is enough.

0x7d is an escape character, telling that the next byte
is to exclusive-or'ed witc 0x20.

-- 

-TV


On 19.3.19 22:09, jumpjack wrote:
> ..is this thread too old to have a reply? :-) > It looks like it's quite hatd to figure out what's going on with my G600 > GSM/GPRS module: I have SIMILAR data, but how to decode them? > MCU to modem: > 7E 3F 7D 23 3F 21 7D 21 7D 21 7D 20 7D 34 7D 22 7D 26 7D 20 7D 20 7D 20 7D > 20 7D 25 7D 26 65 67 6C 6A 7D > > Response: > 7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 32 7D 22 7D 26 7D 20 7D 20 7D 20 7D > 20 7D 23 7D 24 C0 23 7D 27 7D&Acirc; > > Why these slight differences? > > Full sequence sent: > [code] > 7E3F7D233F21 > 7D217D217D207D347D227D267D207D > 207D207D207D257D2665676C6A7D277D > 227D287D223F6D7E > 7E3F > 7D233F217D227D217D207D327D227D26 > 7D207D207D207D207D237D243F237D > 277D227D287D223F3F7E > 7E3F230102475052537E3F7D233F217D217D23 > 7D207D2E7D227D267D207D207D207D > 207D277D227D287D222A3F7E > 7E3F2301047E > 7E3F2101057E3F2101062F7E > 7E3F21010703067E3F2102017E3F2101083F3F7E > 7E21453F04 > 5F6E3F16042D073F0102080928083F617E > 7E2145 > 3F04 > 5F6E3F160478053F010104026C737E > 7E2145303F160402203F3F7E > 7E2145 > 7D5D > 3F04 > 5F6E3F1604123456780204053F010104024A677E > 7E21456E3F16047002203F3F7E > 7E214506 > 7B > 3F04 > 5F6E3F1604123456787E21 > 455F6E3F160404023F3F7E > 7E21450B3F123456787E > 214504 > 5F6E3F16040104023F3F7E > 7E21453F717E21453F04 > 5F6E3F16043F01010402493A7E > 7E2145047E > 7E214574 > 3F04 > 5F6E3F160478053F010104026F2E7E > 7E2145303F160402203F7E[/code] > > Full response: > [code] > 7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 32 7D 22 7D 26 7D 20 7D 20 7D 20 7D > 20 7D 23 7D 24 C0 23 7D 27 7D 22 7D 28 7D 22 DD 94 7E 7E FF 7D 23 C0 21 7D > 24 7D 21 7D 20 7D 2A 7D 25 7D 26 65 67 6C 6A 60 85 7E 7E FF 7D 23 C0 21 7D > 22 7D 23 7D 20 7D 2E 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 27 7D 22 7D 28 > 7D 22 7D 34 BC 7E 7E C0 23 02 04 00 05 00 AA 5E 7E 7E 80 21 03 05 > 00030600000000C6A17E7E8021030600030600000000C1777E7E802101010004BB997E7E80210307000306B506E685837E7E80210208000306B506E68A397E > [/code] > > > > --------------------------------------- > Posted through http://www.EmbeddedRelated.com >