We are trying to use our own UDP/IP stack on top of FCM/GPRS.
(We prefer to use our own IP stack instead of WaveCom’s for various reasons)
After activating a PDP context we
call the adl_fcmSendData() function to send out the UDP packet.
(We send it to our public IP address.)
adl_fcmSendData() returns OK indicating that it has successfully sent out data.
But at the receiving end we do not see the UDP packet coming through.
(Our router routes the UDP packets coming to our public IP to a specific static IP.
We run ethereal at this IP and check incoming packets.)
This has been working fine with our other non wavecom devices.
We tried it several times and obtained the same results.
Can somebody explain what is wrong.
Do we have to enable any specific setting for FCM to send IP packets from a non wavecom IP stack?
-Rad
This may be a complete red herring, but I have noticed a bug in the GSM Data Flow when sending blocks of over 270 bytes:
viewtopic.php?f=5&t=1040
Maybe the GPRS Flow under FCM is affected similarly…?
Interesting.
In my case I am just sending minimal test data over GPRS flow.(38 bytes including IP and UDP headers).
I guess I will run into the problem you are seeing after I get past this phase.
I see that the ADL User Guide mentions the GSM Data flow has no limit on the Maximum data packet size.
But your case proves there is an actual limit of 270 bytes.
Similarly the spec mentions a 1500 byte limit on GPRS flow.
May be the actual limit is different .(but should not be less than 38 bytes)
Hopefully you won’t - it could be that just the GSM Data flow is affected, and not the GPRS flow.
As I siad, it could be just a red herring for your case. Hopefully.
It’s not so much an actual limit on the packet size - more a bug that makes packets over that size unusable!
I have been running my own IP/UDP stack in Wavecom modems for almost 5 years. I just receently added a complete TCP client to my custome stack and it runs fine. I have not gone to OASIS yet due to project restraints. I am using OpenAT 422d, the current OS on the WaveCom website. I have been using the adl_fcmSendData() function until a few weeks ago. Under stress testing, sending 10 TCP HTTP packets in excess of 400 bytes back-to-back every 60 seconds, I found that the OS will cause a memory fault most times indicating a problem with a memcpy() or a memset(). Sometimes there were faults indicated in functions unrelated to any application code. The wierd part of the matter was that the reset would happen when only the 1 minute timer in the OBA was running and the rest of the application dormant including that the GPRS session with the network had been dropped (adl)gprsDeact()). After shasing this for several weeks I pinned it to the OS. It failed consistantly every 35-37 minutes in the test scenario. I then switched to the adl_fcmSendDataExt() function where you build a structure and pass it to the OS. The every 35 or so minute resets ceased. However after 5 hours of the same test running the OS reset with the same indications and happend while the application was in a ‘idle’ state . I might add that reset always happened about 10 -15 seconds after the application shut down the GPRS connection and entered a completely idle state waiting for the 1 minute timer to expire. This issue will be posted a a problem on this form.
So, anyway a custom IP stack will and does run successfully on the GPRS modem using ADL and fcm function calls