Productizing 'dataConnectionServiceSample.c'

Legato Application Framework
1

Summary

I have gotten the wp to connect for short periods of time when there is a good signal and APN values are known. I need to be able to keep connectivity to the WP for years on end, with the exception of a user explicitly turning cell data off or small outages to update APN/Routing settings.

I am looking for documentation/code on how to achieve these design goals, specifically the questions below answered.

Questions

  • WP gets stuck in connected state, does not allow disconnect and/or APN updates. How do i fix this?
    • I am not 100% but this may occur when the program is killed before calling le_data_Release
    • Once in this state not even cm data can disconnect the modem or update the APN
  • If there is a loss of connectivity due to a Cell Network event (IE: Update Location) or loss of signal. Does my program need to detect the loss of the data handler or issue a re-connect or does the legato runtime reconnect for me?
  • Regarding advanced Cell Routing, do we attach the example function as a DCS handler like in the example code? Also what are the events that trigger this function?

References

  • Code is based primarily on dataConnectionServiceSample.c
  • Additional le_mdc hooks are added to adjust APN settings
  • cm code is used as a reference, but its use of globals and ConfigTree valaues makes it harder to follow. There is also a warning saying Customers should not use cm in production.
2

Can you reproduce the problem with cm command only?

I suspect your application makes the problem

3

@jyijyi you are correct, but that is because cm is performing under-documented actions from what i can tell. I think that cm avoids the system getting stuck in a connected state by using dataConnectionService:/sessionCleanup in the config tree explicitly. A single header file mentions it use, but it is unclear if the values are just used as a keystore or if it triggers any actions from the runtime.

At this point it looks you need to update dataConnectionSample.c with mechanisms you use in cm data (sessionCleanup and otherwise). I also need the other questions answered from my original post.

4

Does my program need to detect the loss of the data handler or issue a re-connect or does the legato runtime reconnect for me?

You can see here:

Once an application makes a data connection request, it should monitor the connection state reported to the registered connection state handler. The application should only try transmitting data when the state is connected, and should stop transmitting data when the state is not connected. If the state is not connected, the data connection service will try to establish or re-establish the connection endlessly until le_data_Release() is called. There’s no need for an application to issue a new connection request.

5

Thank you, let me update my original question list

Questions

  1. What needs to be added to dataConnectionSample.c to make it production ready?
  • dataConnectionService:/sessionCleanup needs to be explained/documented (it looks like this stems from le_dcs no longer using the Config Tree?)
  • Regarding Channel Monitoring, cm stored handlerRef into the config tree in reference to the dcs event handler. Does this handler persists after cm is done executing (IE: when the prompt returns after data connect)? If not why is it stored in the Config Tree?
  • Can the le_data_RequestObjRef_t value be stored in the Config tree the same way le_dcs_RequestObjRef_t is?
6

I never use your sample app, but do you see problem with modemdemo to establish data connection?

7

My app is essentially your/Legato’s sample app. It is not exactly the same as modemDemo as that also performs SMS actions. Both do not perform the dataConnectionService:/sessionCleanup step cm does so I imagine i am going to get the same stuck in connected result.

Please answer the questions in the prior comment

8

i can see both the dataConnectionSample.c and modemdemo are using le_data_request() to establish data connection.

What is the problem with this API?
Have you tried with modemdemo and see if there is problem?

9

It looks like the request reference value, whether from le_data or le_dcs, is needed to stop a connected state. This is why cm stores it in the Config Tree immediately after getting it as reqRef, as apps can crash for any reason so the only way to keep that value safe is to put it in outside program memory. As for the other stored value, handlerRef, it looks like a similar situation just involving the event monitoring handler (IE: a unique ID is needed to remove the old/unused handler).

This information is not included in modemDemo.c or dataConnectionSample.c. It is just me just trying to figure out why the cm tool does not get the system into these states. I need the Legato team to more explicitly confirm/detail/correct my theory about these stored values.

I have compiled and run modemDemo but best I can tell the only way to interact with it is to send the device SMS commands. My sims do not allow SMS commands so this is a non-starter. Best I can tell, if the program was stopped mid IPv4/IPv6 test the WP would get stuck in the connect state just like dataConnectionSample.c.

10

you can use the following command to run the modemdemo:

app runProc modemDemo1 send --exe=send -- 1234567 "Online"
app runProc modemDemo1 send --exe=send -- 1234567 "Offline"

All result is in /legato/systems/current/appsWriteable/modemDemo1/smsChat.txt

I still don’t quite understand your question, what is the relationship or problem with the config tree and the connected state of the application?
Can you list out the full procedure to reproduce your issue with modemdemo application?

BTW, do you contact distributor to report this issue if you need official support from legato team?

11

My original issue was that the WP77xx was getting stuck in a ‘connected’ state (I could not disconnect or update the APN). My application was based on dataConnectionSample.c. I noticed that cm did not get into this state so I decided to compare it, mainly cm_data.c, to dataConnectionSample.c. Besides cm using le_dcs instead of le_data, the primary difference in cm_data.c was the use of the *SessionCleanup* functions located in it and dcs_util.c . These functions are tied directly to Config Tree values and great effort is spent configuring them prior to and after cm connect.

I am asking for the design reasoning and documentation for functions that interact with dataConnectionService:/sessionCleanup/ because of this.

Regarding modemDemo

The provided commands work, I will continue to see if it also gets stuck in the connected state; however, I am still requesting the sessionCleanup documentation.

BTW, do you contact distributor to report this issue if you need official support from legato team?

They pointed here.

12

I think you can first see if modemdemo has problem.
If no, then you can port your code to modemdemo app

Btw, did you check logread to see why your app cannot change apn?

13

Ok, I believe I have determined the issue/behavior that led to the creation of the ticket:

  1. Many application can call le_data_Request concurrently and they will all receive a valid request objects.
  2. As long as 1 of those applications are running and have not release the Request, the connection will be considered ‘in-use’

The confusing part is how cm, the primary cell test utility, changes the behavior of the system.

  1. If cm started the cell connection, and a request to disconnect is issued, then ‘cm’ will report a successful disconnect
  2. If there is a le_data_Request app running (started after cm data connect but before cm data disconnect), the lte connection will actually stay connected, making cm successful disconnect message confusing.
  3. cm will get connect and disconnect errors while the le_data applications are running going forward.

I am still unclear about le_dcs_Start requests differ in behavior compared to le_data_Request as well as how sessionCleanup: modifies the behavior even more (does it allow the connection to stay up after the app terminates or the config tree values are deleted?). Please clear this up and I’ll close the ticket.

14

Not quite sure how session cleanup is related to modifying apn or disconnecting data channel …

Have you tried to port the session cleanup code to modemdemo and see if it fixes anything if you think this is related?

Another test you can do is to test in wp77 firmware r14.1 instead of r15.1, i saw that the session cleanup code is added only in legato 21.5 which is in firmware r15.1.
Legato 19.11.5 in firmware r14.1 does not contain such cleanup code.
If there is no problem for cm tool in r14.1, that means the session cleanup code is not related to your problem:

Btw, did you check logread to see why your app cannot change apn?

Lastly, do you mean that modemdemo is working fine for you now?

15

I don’t either because it is undocumented. Please feel free to get us on the same page by fixing this.

I have not because session cleanup looks to be coupled with the le_dcs api with modemDemo does not use, just cm.

16

le_data_request() is also calling to dcs:

Another test you can do is to test in wp77 firmware r14.1 instead of r15.1, i saw that the session cleanup code is added only in legato 21.5 which is in firmware r15.1.
Legato 19.11.5 in firmware r14.1 does not contain such cleanup code.
If there is no problem for cm tool in r14.1, that means the session cleanup code is not related to your problem:

Btw, did you check logread to see why your app cannot change apn?

Lastly, do you mean that modemdemo is working fine for you now?