Hello, I'm at my wits' end trying to get ofono working with the
sim5320 module. I'm using the plugins/sim900.c module as a starting
point. I think the issue has something to do with the difference
between the MUX functionality between the 900 and the 5320. The sim900
supports the elaborate parameters sent on the
AT+CMUX=0,x,x,x,x, etc.
but the SIM5320 only supports
AT+CMUX=0
There's that... but also the way the sim900 plugin creates a
SETUP_DLC, initiates muxing, then deletes the setup DLC and creates 4
new DLC's... it didn't work for the sim5320 until I remapped the DLC's
somewhat like this:
#define NUM_DLC 4
#define VOICE_DLC 2
#define NETREG_DLC 1
//#define SMS_DLC 2
#define GPRS_DLC 3
#define SETUP_DLC 0
static char *dlc_prefixes[NUM_DLC] = {
[VOICE_DLC]="Voice: ",
[NETREG_DLC]="Net: ",
// [SMS_DLC]= "SMS: ",
[GPRS_DLC]= "GPRS: " ,
[SETUP_DLC]= "Setup: ",
};
Note I have to eliminate the SMS_DLC usage later in sim5320_post_sim:
// ofono_sms_create(modem, OFONO_VENDOR_SIMCOM, "atmodem",
// data->dlcs[SMS_DLC]);
OK everything is *ALMOST* working. ofonod interacts fine with
connmand, connmand tells ofonod to activate the sim5320, which
actually establishes a ppp connection and sets up a ppp device:
ppp0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-0
inet addr:30.97.132.47 P-t-P:30.97.132.47 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 B) TX bytes:124 (124.0 B)
Here's the rub: No matter what I do, I never get any RX packets from
that ppp device, and even when it appears to TX packets (I'm trying to
ping out) the machine on the internet isn't actually receiving them.
I'm running on a beaglebone with a custom board with a sim5320 module on it.
I have no idea what to try... Any advice would be appreciated...
Thanks very much!!!!
-Dave

Hey folks,
I just tried Connman and oFono on a Debian stretch system for the first
time, hoping to get a more robust solution for keeping a cellular and/or
ethernet connection up. It seems the duo is quite capable of doing what
I need, but there were a few bumps in setting this up, where I think
things could be improved.
Some of these issues might be more connman issues, but they're mostly on
the cross-over area between the two, so I'll post them here for now.
In somewhat chronological order:
- I could not find any documentation on how to get a cellular
connection up. Plugging in a dongle made the "cellular" technology
appear in connman, but no services, with no indication of what needed
to happen next.
- When provisioning in oFono fails, a single gprs context is created
without an APN. Setting the APN manually made the profile show up in
connman and (eventually) work.
It might be better to cange connman to create a service for a context
without an APN, and show an error when trying to connect it, instead
of completely hiding the context.
- There does not seem to be any official commandline interface to ofono
to figure out what is happening. There are "test" python scripts in
the source repo, but these are not shipped in the Debian package
(reported here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868377)
- When mobile-broadband-provider-info provision finds multiple matches
for the operator (that is, multiple apns all with the same usage
type), provisioning fails, disregarding *all* apns found. I believe
this even happens when there is just one type duplicate (e.g. if
multiple mms profiles are available and just one internet profile,
the internet one is not used). Not entirely sure, though.
- When multiple profiles match, it would not make sense for oFono to
just pick an arbitrary one to use. Ideally, it would just create
a context for each, and let the user select the right context. For
this to actually work, the user must be able to distinguish them, and
see all the relevant details for profile/context to allow choosing
the right one.
I tried simply passing "allow_duplicates=TRUE" to ..., which does
indeed create all contexts, but seems to show only the first two as
aservices in connman (not sure why just these two), and there is no
way to really distinguish them (the service name is just the
currently connected network name).
- When actually connecting from connman (or activating a context using
the ofono test/activate-context script), the reported errors are very
unclear. I only got a "Not implemented" error, which is very
non-descriptive and, looking at the code, is returned in quite some
different places. There's also nothing in the log to indicate what
went wrong.
The activation error in my case was due to a missing tun kernel
module, I submitted a separate patch for that.
- I also ran into an issue where my modem was not properly detected at
startup, debug output showed it couldn't detect the USB vidpid for
some subdevices. I suspect there might be a race condition involved
there, but I'm still investigating.
Gr.
Matthijs

Hi,
I am trying to add AGPS functionality to Gemalto modems. I took a look
at interface AssistedSatelliteNavigation and implementation in
drivers/atmodem/gnss.c. Unfortunately, Gemalto does not support AT+CPOS
command but it uses a custom command: AT^SBNW. Moreover, the positioning
file expected is not XML but binary format.
The process of loading the binary is:
- Download binary file from Gemalto server to local memory
- Initiate binary write command: AT^SBNW="agps",<binary_file_length>
- Copy binary file from local memory to modem over its application (or
modem) interface
AT^SBNW immediately returns "CONNECT". Then "AGPS READY: SEND FILE..."
After the modem receives the exact amount of bytes specified in the
command, it verifies the data and returns one of the following: "AGPS
END OK", "TIME INFO ERROR", "BAD CRC" or "OK".
So I am facing several issues:
- How to send binary data from local memory to oFono? DBus message
with array of bytes?
- How to send binary data from oFono to modem interface? Does gatchat
only support strings?
- How to handle custom result codes? I already tried some hacks, and I
had to blacklist the response "CONNECT" for instance.
Or maybe it isn't worth the effort implementing it in oFono?
Regards,
Vincent