[Ajay K]

Hi Jason,

Is this not a breaking change? It is very convenient to use to the online compiler as I have never been able to get the offline mbed-cli builds to work for me for the MDot target, even if I privately publish my program and build it using mbed cli using GCC-ARM as the tool chain.

I am trying to build it offline, but I am getting a lot of errors which I am not getting with the online compiler. Are there any instructions that I can use to build it offline? Also my colleague has logged a bug as an mbed-os issue and may be you can provide some insight so that they fix this issue on the online compiler?

Here is the GitHub issue that was logged: https://github.com/ARMmbed/mbed-os/issues/13121

Thanks,
Ajay

[Ajay K]

Any thoughts multitech team, this is blocking our production build.

[Ajay K]

Hi Jeff,

I was planning to open a ticket and that way I can attach the complete messages log file for Multitech to review. and also provide our .tar.gz file as well so it can be tested on the Multitech conduit. Since this is something new that is occurring on 5.2.1. We have not seen this particular hang prior to this version of the firmware and also like I mentioned, everything we need installed was successfully installed, however since the app-manager hangs, the custom app doesn’t show up on the admin site and requires a reboot to finish whatever is holding the app-manager from completing the install.

Thanks,
Ajay

[Ajay K]

Any ideas as to why the app-manager doesn’t exit once the installation is completed?

Thanks,
Ajay

[Ajay K]

Any thoughts?

[Ajay K]

Hi Jason,

Thanks for taking the time to respond and provide the examples of how to handle floating pins. In the example, as described a 4 step process.
1) Save the IO State.
2) Configure the pins to Analog Input and no pull
3) Sleep
4) Restore the IO State.

I am not sure I understand the save and restore IO State? Don’t we want to to permanently configure the unused external pins to analog input? Also I believe for the MDot there is no concept of deep sleep, even if we set that flag to true while going to sleep it has no effect correct and We use just RTC wakeup mode and no wake pins in our custom firmware.

Also below is a list of the external pins we are using on our custom hardware, do we need to configure those pins to analog input, no pull before going to sleep?

PA_9 (USBTX)
PA_10 (USBRX)
PA_4 (Digital In)
PA_8 (I2C_SCL)
PC_9 (I2C_SDA)
PA_1 (Digital Out)
PB_1 (Digital Out)

Thanks,
Ajay

[Ajay K]

Any thoughts on this?

Thanks,
Ajay

[Ajay K]

Thanks Jeff, that was it. I think I had at some point was testing with a POST request and it worked and somewhere down the line must have accidentally changed it to a GET request. Thanks as always for your help.

Thanks,
Ajay

[Ajay K]

Would disabling the dhcp6s and dhcps, prevent me from connecting to the conduit using the IP 192.168.2.1? I can no longer connect to my conduit after disabling the DHCP.

Thanks,
Ajay?

[Ajay K]

Thanks Jason, I got it working with the complete object.

[Ajay K]

Hey Jason,

Thanks a lot for your timely response. When you say to include the entire object, i.e.in addition to the enabled property I would need to include all the other properties as well in the request JSON object?

Thanks,
Ajay

[Ajay K]

Any thoughts, we can’t use the default MTU of 1500, as most VPN connection requires lower MTU. so it would be great if you can suggest a mechanism to update the PPP MTU.

Thanks,
Ajay

[Ajay K]

Just curious what was the https security protocol used in 1.7.4 version? Was it TLS 1.1 or SSL3?

Thanks,
Ajay

[Ajay K]

Hi Jason/Jeff,

Sorry for the false alarm, since the Https settings by default in the new conduit is configured to TLS 1.2, I had to ensure that the security protocol being used to communicate over https is TLS 1.2 and it works both using the Curl and using a .NET Http client as well.

Thanks,
Ajay

[Ajay K]

Any thoughts, its breaking a lot of our automation we have built setting up the conduit.

[Ajay K]

Hi Jeff/Steve,

Thanks for taking the time to help and clarify this feature. I can check with Verizon to see if they have any opinion on if they would end up having blacklisting or any other practice they may have if we turn on this feature and would potentially reconnect too often.

Thanks,
Ajay

[Ajay K]

Just wanted some clarification regarding this setting under cellular configuration in the conduit. Is this rebooting the PPP service or is it resetting the Radio modem? Also does it reset the modem or restart the PPP service after 2 hours as mentioned in the help section for this setting? I am little unclear by enabling this feature when/how does it decide to reboot the radio? Also I am unclear about the warning about potentially being blacklisted by the carrier?

Radio Reboot Enabled

Enable or disable radio reboot (default: disabled). Used in the rare case where a PPP connection has failed for two hours or more. When enabled, this feature restarts the radio. The pppcheck (ICMP/TCP Check) feature must also be enabled.
NOTE: Use this feature with discretion. While it attempts to wait for either the back-off timers to be fully exercised or ping failure for at least two hours, there is a possibility your radio could get black-listed by your network carrier if it attempts to reconnect too frequently.

Thanks,
Ajay

[Ajay K]

Thanks Jeff, I was using c# httpclient to send the put request and the extra header of Expect header was being sent and I removed it and it works fine now. Thanks for your help as always.

Thanks,
Ajay

[Ajay K]

awesome thanks for the quick turnaround!!

[Ajay K]

Hi Jeff,

We used the PPP stop and start and it helped us recover in these scenarios where the connection fails and the conduit doesn’t seem to recover once the connection is lost.

Thanks,
Ajay

[Ajay K]

Can I get some information regarding the PPP service? What is it specifically mean to stop, start and toggle the PPP Service? I see commands for all this under the command endpoint api, i.e. as mentioned below:

http://127.0.0.1/api/command/ppp_stop
http://127.0.0.1/api/command/ppp_start
http://127.0.0.1/api/command/ppp_toggle

Thanks,
Ajay

[Ajay K]

Hi Jason,

Needed some guidance on this issue we are facing. Currently as mentioned earlier in the thread. As of now we are having to take the extreme step of restarting the conduit for the conduit to successfully connect to the Verizon network. I was wondering if resetting the modem via the conduit API would have the same effect and prevent us from having to restart the conduit?

We are planning to call a post request of the above mentioned URL :

http://127.0.0.1/api/command/reset_modem

Thanks,
Ajay

[Ajay K]

Thanks Jeff for always taking the time to jump in and help. I have opened a ticket and hopefully we can resolve this issue ASAP.

Thanks,
Ajay

[Ajay K]

I will open a ticket as this is blocking us.

Thanks,
Ajay

[Ajay K]

Hi Jeff,

Thanks for your quick response and yes I see it in the web ui indicating it was successfully installed and I have the ability to start and stop the custom app from the web ui.

As far as the command o/p for “app-manager –command status” here is the o/p

admin@mtcdt:~$ sudo app-manager –command status
{
“Apps” :
[
{
“AppDescription” : “Orcell Application”,
“AppId” : “LOCAL”,
“AppInfo” : “”,
“AppName” : “OrcellApp”,
“AppType” : “CUSTOM”,
“AppVersion” : “4.0”,
“AppVersionNotes” : “App Version with the latest Gateway hardware”,
“Enabled” : true,
“status” : “STOPPED”
}
]
}

Orcell is just a name for our app and we use the conduit and the version of the conduit is at the beginning of this thread. Also like I mentioned earlier in the thread, if i just run the /var/bin/node and my applications app.js it runs fine without any issues.

Also based on increasing the log level, it clear that the start command is being called correctly. The command it would have called eventually to run our custom app would have been this.

/usr/sbin/start-stop-daemon –start –background –pidfile “/var/run/OrcellApp.pid” –make-pidfile –chdir “/var/config/app/OrcellApp” –startas /sbin/orsat-angel — /bin/bash -c “exec /usr/bin/node –max-old-space-size=40 — /var/config/app/OrcellApp/app.js > /var/log/OrcellApp.log 2>&1

However I see in the log entries that the above command is being called, but nothing seems to happen. Log files have the following entries now…let me know if there is anything else I can do to troubleshoot this further.

2020-03-23T19:42:57.755805+00:00 mtcdt Start: /var/config/app/OrcellApp
2020-03-23T19:42:57.838459+00:00 mtcdt Start: LOCAL
2020-03-23T19:42:57.938624+00:00 mtcdt Start: exec /usr/bin/node /var/config/app/OrcellApp/app.js > /var/log/OrcellApp.log 2>&1
2020-03-23T19:42:58.284646+00:00 mtcdt Start: Exec /usr/bin/node /var/config/app/OrcellApp/app.js > /var/log/OrcellApp.log 2>&1 completed!
2020-03-23T19:42:58.325324+00:00 mtcdt APPMANAGER: AppDataDB::SetAppData: updating app info in /var/config/AppManager.json with appId: LOCAL
2020-03-23T19:42:58.396101+00:00 mtcdt APPMANAGER: Released lock on fd
2020-03-23T19:42:58.397423+00:00 mtcdt APPMANAGER: Exiting with success status
2020-03-23T19:42:58.501236+00:00 mtcdt APPMANAGER: LockFile::GetLockNB: attempting to get file lock
2020-03-23T19:42:58.502640+00:00 mtcdt APPMANAGER: LockFile::GetLockNB: Got lock on fd 6
2020-03-23T19:42:58.505451+00:00 mtcdt APPMANAGER: AppCommand::executeStatus: Getting app statuses
2020-03-23T19:42:58.510282+00:00 mtcdt APPMANAGER: AppCommand::getBasePathFor: unknown app type. Defaulting to custom
2020-03-23T19:42:58.537456+00:00 mtcdt APPMANAGER: AppCommand::executeStatus: can’t read pid as a string, trying as number:#012 in Json::Value::asCString(): requires stringValue
2020-03-23T19:42:58.554107+00:00 mtcdt APPMANAGER: Released lock on fd
2020-03-23T19:42:58.555288+00:00 mtcdt APPMANAGER: Exiting with success status

Thanks,
Ajay

[Ajay K]

Hi Jeff,

Here is what I get when I run the app-manager from the command prompt.

admin@mtcdt:~$ sudo app-manager –command start –appid “LOCAL”
AppCommand::executeStartScript: executing: /var/config/app/OrcellApp/Start start
Success!

This is what is reported in the messages log file.

2020-03-23T17:38:50.141277+00:00 mtcdt APPMANAGER: AppCommand::executeStatus: Getting app statuses
2020-03-23T17:38:50.215028+00:00 mtcdt APPMANAGER: AppCommand::getBasePathFor: unknown app type. Defaulting to custom
2020-03-23T17:38:50.219330+00:00 mtcdt APPMANAGER: AppCommand::executeStatus: can’t read pid as a string, trying as number:#012

So bottom line there are not more details as to why the custom app is not getting launched.

Also I was looking the /var/config/db.json shouldn’t there be an entry for customapps in it? currently the customapp section in the file is as shown below.

“customApps” : {},

One other thing I noticed even node red logs used to be created in the previous version of the firmware, I don’t see node red logs being created either.

At this point we are completely blocked, I am not sure what this successfully runs in prior version of the conduit firmware, specifically 1.7.4 and not in this version of the conduit firmware 1.5.2.

Thanks,
Ajay

[Ajay K]

Hi Jason,

Thanks for taking the time to respond. That is the same link I called out on this thread. Wasn’t there a pdf file which had clear examples for each of the endpoints on what needs to be posted for the http post scenarios such as when executing the commands?

Meanwhile I will also open a ticket.

Thanks,
Ajay

[Ajay K]

Any thoughts as this is affecting our ability to connect to the conduits in these remote locations?

[Ajay K]

any thoughts?

[Ajay K]

Hi Jeff,

Not sure why you addressed me as William :). Anyway if the app-manager is executing the start script under the root privilege, not sure why the app is not running? There is no application logs for the application being created, the status.json is not getting updated with the current status of the application. This is why I was assuming the issues were related to the application accessing the specific files in the file system.

The application related log file is being created under /var/logs and the status.json file is right under the application install directory and the <application>.pid file /var/run/ folder. None of these files are either being updated or logs being generated. If look at the messages log file under the /var/logs folder all I see an entry that indicates the application was started successfully, but nothing beyond that. Is there a better way to troubleshoot what is happening once the app-manager starts the application?

If I just run the application from the command prompt using the sudo command the application runs fine without any issues. i.e. for ex:

sudo /usr/bin/node /var/config/apps/TestCustomApp/app.js

Thanks,
Ajay.

[Author]

Posts