MRU problem

Question1:

We tried to integrate EB2 to TINI (TBM390) , what happened is that :

- GM862 negotiates LCP options 2,3,5,7 and 8.
- TINI rejected 5,7, and 8 and acked 2"000a0000" and 3"c023"
- in PAP mode TINI recieved "PPP in progress"
- In IPCP IP was negotiated successfully

however:

- We couldn`t transfer any IP packets over GPRS !!

we are suspecting :
- MRU. as it hasn`t been negotiated in LCP mode.

our question is :
can we set/get this parameter in GM862 ?
Any suggestion/hint why we can not transfer data ?

Thanks

Sometimes I found that setting the wrong APN in the AT+CGDCONT parameter leads to a successful LCP/IP negotiation but then no packets can be exchanged over GPRS.

This may be the case. Check your APN.

Thanks Fabio,,

APN setting is correct, I could notice once I pinged TINI from network side, that IP packets could reach to GM862, but those packets are not handled to TINI for a reason or another. Hence ping command fails !!

the following is thE AT command set which I am using to initialize GM862 modem. Any help or suggestion is very appreciated.

Thanks
Jhn

AT
AT &F0&D0&C0 E0
AT V1 W1 S95=47
AT&K0
AT
AT &F0&D0&C0 E0
AT V1 W1 S95=47
AT&K0
AT&S0
AT+IPR=57600
AT+IFC=0,0
AT+ILRR=0
AT+ICF=3
AT+CGDCONT=1,"IP","internet","0.0.0.0",0,0
AT+CGQMIN=1,0,0,0,0,0
AT+CGQREQ=1,0,0,0,0,0
ATD*99***1#

How do you know that packets reach the GM862??

No response to the pinging is a quite common behavior of many bearers.
This is for the security of the modem, since you are going to pay for all the data exchanged through the air (up or download), all bearer filter many services daemons ports with a strict policy firewall.
Otherwise if you get attacked by some hacker you`ll lose the credit very fast...

One of the first thing that`s inhibit is of coarse the ping service (just to avoid anyone being sure you are there ready to receive/pay the data).
But usually the bearer firewall that protects the modem from the internet is far more clever, denying all incoming TCP/UDP connections and allowing only GPRS initiated socket to be opened.
Here in Italy I found the firewall being VERY restrictive, it closes the TCP connection pipe after a 30/60s silence timeout and allows only 2-3 UDP packet exchanges before closing the UDP pipe (the minimum required for DNS query).

This behavior results in a particular fact: Two GPRS devices are never going to connect each other... the receiver will never see any connection request.

Of coarse bearer firewall policy depends strictly from network operator, this was just to let you aware that the module accesses internet through a firewall that may (and probably WILL) severely limit your TCP/UDP connections freedom..

I do believe that the HTTP service port 80 is always free for use... Use that one for testing
(outcoming connection of coarse).

Just a further note on the init commands:

Why did you set the flow control to none (&K0) if both the GM862-GPRS and the TINI provide full RS232 port with HW flow control?

I`d rather use &K3.

It`s not a good idea having no flow control over the serial link, at least use the sw (&K4).

Thanks Fabio,

I am sorry, I forget to mention that, I am using a special APN dedicated for testing and debugging (all ports are open), The test SIM which I am using is successfully working on other Modems, I can ping, open TCP/IP sussions and UDP/IP sussions successfully, So it is not a network-side problem (Firewall),, I used TINI with other Modems and it works fine,, except for GM862-GPRS.

Regarding your question (How did I know that IP packets could reach GM862-GPRS once I ping it ?) Well, maybe it is not a proffessional way, but it is really simple,, I could guess that IP packets could reach GM862 by capturing RF interfernce using small speaker located beside GM862-GPRS antenna,, I can hear the interference level only when I ping GM862.

I chose to disable flow control in RS232 to eleminate any factor which might cause packets to stop flowwing. I will give it a try to enable flow-control on RS232, although I used to work in this mode freely without any problems using other Modmes.

You know Fabio, the problem is that GM862-GPRS modem (as any other modem) is just a black box for me, I don`t know if there are known debugging commands to track what is going on exactly. Or I guess this is a higher level maintanence level which I don`t need to go through.

However, I am still in hope to find a solution for this problem through this Forum, what I need to know exactly :

- What are the scenarios which might cause IP packets to stuck after successful negotiation of PPP sussion ?
- Did any one interfaced succefully TINI (TBM390) to GM862-GPRS ?
- Back to the beginning, I am still suspecting the MRU compatibiilty issue between TINI and GM862, as it was not negotiated in PPP-LCP phase... hence , did any one know how to set/get MRU value in GM862 ?

Your feed back is really appreciated, I would like also to hear from guys in roundsolution of they are available on the forum ......

Many thanks

John

If you are worried about the MRU, then use the default 1500 octects.
This is the value used by the GM862-GPRS.

Can you specify the network operator/Country you are using for your tests?

Another test you can do is try to do the GPRS connection with a PC running Windows and see if the problem is still there...

Thanks Ben and Fabio,,

Now I understand

So 1500 octet is also the defualt setting for TINI. Fabio, I followed your recommendation, GM862 worked fine with WIN2000 , great. But I still need to integrate with TINI. TINI worked fine with other Modems. So what do you think !! What may cause IP packets to hang after successful negotiation of PPP ? Is it a flow control issue ? any Ideas how to debug ? Thanks for your support.

John,

Some users reported problems with the protocol field compression negotiation.

Remove the
nopcomp pppd option ( I believe you have linux on the TINI, right? )

This is my linux box pppd script (try it):

###################################
noauth
crtscts
connect "/usr/sbin/chat -v -f /etc/chatscripts/Gprs"
/dev/modem
115200
defaultroute
noipdefault
user USERNAME
usepeerdns
###################################

The chatscript GPRS is:
###################################
ABORT RING
ABORT BUSY
ABORT "NO CARRIER"
ABORT VOICE
ABORT "NO DIALTONE"
ABORT "NO ANSWER"
"" ATZ
OK AT+CGDCONT=1,"IP","uni.tim.it","0.0.0.0",0,0
OK AT+CGQREQ=1,0,0,0,0,0
OK AT+CGQMIN=1,0,0,0,0,0
OK ATD*99***1#
CONNECT \\d\\c
###################################

Change the +CGDCONT command to fit your Bearer GPRS APN settings.
- Edited by Fabio 19.05.2003, 11:11 -

Thanks Fabio,

Please correct me if I`m wrong. I understand that there is a problem in PPP connection once header compression is disabled ( right ?) ,, becasue the command which you provided should disable protocol header compression (nopcomp pppd option) (right ?)

Based on this I will :

- Enable protocol header compression on TINI.
- Enable protocol header compression on GM862-GPRS.

I will send the feed back as soon as I got back to the LAB as I m now in business trip.

By the way, TINI is running somthing close to Linux (but it is not really Linux) ,, this is special OS developed by Dallas Semi Conductor exclusivly for TINI, where applications are develpped using JAVA.

Thanks
Jhn

Exactly, the problem appears if the PPP protocol field compression negotiation phase is missing.

I`ve found that if you disable the protocol field compression negotiation in the ppp options, then the ppp will receive corrupted packets with header length 0.

So:
Enable protocol header compression negotiation on TINI.
On the GM862-GPRS the PHC is negotiated.

Hi Fabio,

Unfortunately TINI doesn`t support IP header compression, and Dalas guys are not intending to implement that feature . Hence, TINI wouldn`t negotiate PHC. I would be greateful if you can suggest a workaround, as this may stop development. I liked GM862-GPRS and I don`t want to go for other Modems.

Please help,,

Thanks
Jhn

Please Guys , any update ??
Jhn

Maybe I did not clarify enough,
you shall:
1- enable the PPP protocol compression (called also PPP header compression)
2- disable the IP header compression

Don`t confuse the two things. One is related to the PPP and the other to the IP.
You said that you don`t have IP header compression, that`s fine.
Just enable the ppp protocol header compression.

Fabio