[William Laing]

Thank you, Mike – we’ll check it out.

Best,
William

[William Laing]

Thank you very much, Carol and Jeff –

The gateway is back to normal now. New firmware was deployed, and log files are available again.

Have a great week!

Best,
William

[William Laing]

Thanks again, Jason – very helpful!

Best,
William

[William Laing]

Hi Jason –

We have related questions we’re hoping you can help us with:

(1) Do you know if folks have successfully installed VPN client software on the gateways? We’d really like to have web admin page access for Conduits out in the field.

(2) I haven’t looked around at where the cron job files are located yet. Do you know if customers are using cron jobs on their Conduits?

(3) Would the VPN client software and cron jobs survive a firmware upgrade?

Thanks,
William

[William Laing]

Thank you for the information, Jason – that’s very helpful.

Have a great day!

William

[William Laing]

Okay, Steve, thanks.

We’re now looking at having our application modify Wi-Fi parameters in the config file and upload/download using AEP API.

Can you point us to detailed documentation for the AEP API, especially for /api/command/download_config and /api/command/upload_config ?

When we do a POST for upload_config, we get a “200 Authorized Redirect” and a pointer to the file, <meta http-equiv=”REFRESH” content=”0;url=/tmp/config_MTCDT-LAT1-246A_1_6_2_02_21_19.tar.gz”>

But where is the file?

Thanks again!
William

[William Laing]

Thank you, Steve – very helpful to know.

We had a client meeting yesterday and walked through the use case in question. We believe we can mostly pre-configure the Conduit using one or more of your factory, our manufacturing partner and us. However, there’s one last piece to the puzzle.

After the Conduit is finally shipped to the end user, can you think of any way that Wi-Fi can be configured as WAN by us (remotely or through software) or by the end user? We do not want the end user to have Web Admin access. The SSIDs and other configuration items for WiFi as WAN will not be known until delivery to the end user.

+ we will be developing IoS and Android apps using Bluetooth; could we possibly use Bluetooth to configure Wi-Fi as WAN?

Any ideas appreciated!

Best,
William

[William Laing]

Great, Steve, thanks.

I have a couple more for you:

(1) if the Conduit is configured for Wi-Fi AP, can I use my browser and access the Web Admin over the Wi-Fi AP to enable Wi-Fi WAN?
(2) is it possible to purchase the Conduit as an OEM board with no enclosure?

Thanks again!
William

[William Laing]

Thanks again, Steve – all useful ideas, thanks!

Just a couple clarifications please:

(1) can a Conduit serve as both Wi-Fi WAN and Wi-Fi AP at the same time?
(2) Assume a Conduit is deployed with Eth0, Cellular and WiFi all enabled and prioritized for Failover. Assuming Wi-Fi is configured as access point, and user can access the Conduit’s WiFi network, can a user use any browser to access the embedded management pages using 192.168.2.1, say to to configure WiFi WAN settings?

Thanks,
William

[William Laing]

Good Morning, Steve –

Thank you for the response!

Great, so uploading the full configuration file is one option.

We are working with a client , a well-known company, who would like to commercialize systems we develop jointly. The systems combine their product with our technology to make a LoRa end-device and your Conduits.

What are the alternatives for configuring and deploying significant numbers of Conduits to the field? We wouldn’t want to manually configure each one. We would prefer to have them shipped directly to our partner or even to the end-user directly.

(1) Is DeviceHQ the way to go? But even with DeviceHQ, we would have to configure each Conduit with the necessary information to reach DeviceHQ: for example, Remote Management -> Remote Server, like the ds.devicehq.com server name, server port, checking the Enabled box, etc.

(2) Is some level of pre-configuring the Conduits something you guys could do before shipping? Like pre-configuring the Remote Management stuff?

(3) We use the AEP API, but that only works when we know the IP address and it’s the IP address is accessible. Do you know of any tricks here to make this work more broadly?

(4) the mts-io-sysfs commands are of some help but do not seem suitable for configuration.

(5) None of our Conduits and IP67s are configured for Wi-Fi. On Wi-Fi configured systems, could our customers access the Conduit web server and use the management pages to configure their gateway?

Thank you in advance for your help.

Best,
William

[William Laing]

Okay, Jeff –

We appreciate your efforts as always – thank you!

We have half-a-dozen Conduits with cellular service but have never seen this issue before.

Best,
William

[William Laing]

Hi Jeff –

I used that AT&T webpage to enter the IMEI, and it says device is compatible.

I reinserted the SIM card. It appears that we’re no longer getting SIGHUPs.

But AT+CREG? returns +CREG: 0,2

We also see a failure in the chat script:

2019-02-07T17:03:23.387425-05:00 mtcdt chat[7496]: send (AT+CSQ^M)
2019-02-07T17:03:23.470118-05:00 mtcdt chat[7496]: expect (OK)
2019-02-07T17:03:23.470456-05:00 mtcdt chat[7496]: ^M
2019-02-07T17:03:23.475383-05:00 mtcdt chat[7496]: ^M
2019-02-07T17:03:23.475775-05:00 mtcdt chat[7496]: +CSQ: 23,99^M
2019-02-07T17:03:23.476136-05:00 mtcdt chat[7496]: ^M
2019-02-07T17:03:23.476425-05:00 mtcdt chat[7496]: OK
2019-02-07T17:03:23.476642-05:00 mtcdt chat[7496]: — got it
2019-02-07T17:03:23.477081-05:00 mtcdt chat[7496]: send (AT+CGDCONT=1,\”IP\”,\”m2m.com.attz\”^M)
2019-02-07T17:03:23.828354-05:00 mtcdt chat[7496]: expect (OK)
2019-02-07T17:03:23.828682-05:00 mtcdt chat[7496]: ^M
2019-02-07T17:03:23.833898-05:00 mtcdt chat[7496]: ^M
2019-02-07T17:03:23.834367-05:00 mtcdt chat[7496]: ERROR
2019-02-07T17:03:23.834594-05:00 mtcdt chat[7496]: — failed
2019-02-07T17:03:23.834887-05:00 mtcdt chat[7496]: Failed (ERROR)

[William Laing]

Jeff –

It looks like it’s connecting, but there are Hangups (SIGHUP). Here’s a snippet:

2019-02-06T16:21:09.493206-05:00 mtcdt pppd[2169]: Serial connection established.
2019-02-06T16:21:09.505894-05:00 mtcdt pppd[2169]: Using interface ppp0
2019-02-06T16:21:09.511016-05:00 mtcdt pppd[2169]: Connect: ppp0 <–> /dev/modem_at0
2019-02-06T16:21:10.545968-05:00 mtcdt pppd[2169]: CHAP authentication succeeded
2019-02-06T16:21:10.546194-05:00 mtcdt pppd[2169]: CHAP authentication succeeded
2019-02-06T16:21:10.592697-05:00 mtcdt pppd[2169]: Hangup (SIGHUP)
2019-02-06T16:21:10.592978-05:00 mtcdt pppd[2169]: Modem hangup
2019-02-06T16:21:10.593349-05:00 mtcdt pppd[2169]: Connection terminated.
2019-02-06T16:29:05.926188-05:00 mtcdt annexcd: [INFO] aep_interface.cc:getNetworkInterface:244: Gathering info for interface ppp0
2019-02-06T16:29:07.050238-05:00 mtcdt annexcd: [INFO] aep_interface.cc:getNetworkInterface:409: error reading /sys/class/net/ppp0/statistics/multicast
2019-02-06T16:29:07.055600-05:00 mtcdt annexcd: [ERR] delivery_agent.cc:FillNetworkInterface:228: network_interface(ppp0): invalid field ‘flags’
2019-02-06T16:29:07.057902-05:00 mtcdt annexcd: [INFO] delivery_agent.cc:SendNetworkInterfaceStats:526: failed to fill NetworkInterface message (ppp0) – sending empty interface
2019-02-06T16:36:08.777469-05:00 mtcdt pppd[2169]: Serial connection established.
2019-02-06T16:36:08.786231-05:00 mtcdt pppd[2169]: Using interface ppp0
2019-02-06T16:36:08.788172-05:00 mtcdt pppd[2169]: Connect: ppp0 <–> /dev/modem_at0
2019-02-06T16:36:09.843501-05:00 mtcdt pppd[2169]: CHAP authentication succeeded
2019-02-06T16:36:09.844607-05:00 mtcdt pppd[2169]: CHAP authentication succeeded
2019-02-06T16:36:09.888602-05:00 mtcdt pppd[2169]: Hangup (SIGHUP)
2019-02-06T16:36:09.888884-05:00 mtcdt pppd[2169]: Modem hangup
2019-02-06T16:36:09.889155-05:00 mtcdt pppd[2169]: Connection terminated.
2019-02-06T16:50:25.730084-05:00 mtcdt annexcd: [INFO] aep_interface.cc:getNetworkInterface:244: Gathering info for interface ppp0
2019-02-06T16:50:26.998180-05:00 mtcdt annexcd: [INFO] aep_interface.cc:getNetworkInterface:409: error reading /sys/class/net/ppp0/statistics/multicast
2019-02-06T16:50:27.001144-05:00 mtcdt annexcd: [ERR] delivery_agent.cc:FillNetworkInterface:228: network_interface(ppp0): invalid field ‘flags’
2019-02-06T16:50:27.002422-05:00 mtcdt annexcd: [INFO] delivery_agent.cc:SendNetworkInterfaceStats:526: failed to fill NetworkInterface message (ppp0) – sending empty interface

[William Laing]

Jeff –

I did a grep on /var/log/messages for ‘chat’, and here’s what I got:

=========================================================================
2019-02-06T16:11:06.985220-05:00 mtcdt chat[4069]: info: Attempting Basic Radio Communication
2019-02-06T16:11:06.986689-05:00 mtcdt chat[4069]: send (AT^M)
2019-02-06T16:11:07.019134-05:00 mtcdt chat[4069]: expect (OK)
2019-02-06T16:11:07.026722-05:00 mtcdt chat[4069]: ^M
2019-02-06T16:11:07.028274-05:00 mtcdt chat[4069]: OK
2019-02-06T16:11:07.029504-05:00 mtcdt chat[4069]: — got it
2019-02-06T16:11:07.030604-05:00 mtcdt chat[4069]: info: Checking if SIM is inserted
2019-02-06T16:11:07.031824-05:00 mtcdt chat[4069]: send (AT#SIMDET?^M)
2019-02-06T16:11:07.145253-05:00 mtcdt chat[4069]: expect (#SIMDET: 2,1)
2019-02-06T16:11:07.145693-05:00 mtcdt chat[4069]: ^M
2019-02-06T16:11:07.153013-05:00 mtcdt chat[4069]: ^M
2019-02-06T16:11:07.153390-05:00 mtcdt chat[4069]: #SIMDET: 2,1
2019-02-06T16:11:07.153727-05:00 mtcdt chat[4069]: — got it
2019-02-06T16:11:07.153973-05:00 mtcdt chat[4069]: info: Checking if SIM is locked
2019-02-06T16:11:07.154187-05:00 mtcdt chat[4069]: send (AT+CPIN?^M)
2019-02-06T16:11:07.246891-05:00 mtcdt chat[4069]: expect (READY)
2019-02-06T16:11:07.247286-05:00 mtcdt chat[4069]: ^M
2019-02-06T16:11:07.247661-05:00 mtcdt chat[4069]: ^M
2019-02-06T16:11:07.247954-05:00 mtcdt chat[4069]: OK^M
2019-02-06T16:11:07.254384-05:00 mtcdt chat[4069]: ^M
2019-02-06T16:11:07.254882-05:00 mtcdt chat[4069]: +CPIN: READY
2019-02-06T16:11:07.255093-05:00 mtcdt chat[4069]: — got it
2019-02-06T16:11:07.255328-05:00 mtcdt chat[4069]: info: SIM was unlocked
2019-02-06T16:11:07.255624-05:00 mtcdt chat[4069]: info: Waiting for minimum signal strength
2019-02-06T16:11:07.255845-05:00 mtcdt chat[4069]: send (AT+CSQ^M)
2019-02-06T16:11:07.328009-05:00 mtcdt chat[4069]: expect (+CSQ: )
2019-02-06T16:11:07.328341-05:00 mtcdt chat[4069]: ^M
2019-02-06T16:11:07.328708-05:00 mtcdt chat[4069]: ^M
2019-02-06T16:11:07.329063-05:00 mtcdt chat[4069]: OK^M
2019-02-06T16:11:07.335433-05:00 mtcdt chat[4069]: ^M
2019-02-06T16:11:07.335863-05:00 mtcdt chat[4069]: +CSQ:
2019-02-06T16:11:07.336070-05:00 mtcdt chat[4069]: — got it
2019-02-06T16:11:07.336312-05:00 mtcdt chat[4069]: expect (99,99)
2019-02-06T16:11:07.336724-05:00 mtcdt chat[4069]: 30,99^M
2019-02-06T16:11:07.336988-05:00 mtcdt chat[4069]: ^M
2019-02-06T16:11:07.337258-05:00 mtcdt chat[4069]: OK^M
2019-02-06T16:11:08.337102-05:00 mtcdt chat[4069]: alarm
2019-02-06T16:11:08.337984-05:00 mtcdt chat[4069]: send (AT^M)
2019-02-06T16:11:08.369840-05:00 mtcdt chat[4069]: expect (OK)
2019-02-06T16:11:08.376257-05:00 mtcdt chat[4069]: ^M
2019-02-06T16:11:08.376736-05:00 mtcdt chat[4069]: OK
2019-02-06T16:11:08.376956-05:00 mtcdt chat[4069]: — got it
2019-02-06T16:11:08.377212-05:00 mtcdt chat[4069]: send (AT^M)
2019-02-06T16:11:08.408573-05:00 mtcdt chat[4069]: abort on (NO CARRIER)
2019-02-06T16:11:08.408866-05:00 mtcdt chat[4069]: abort on (BUSY)
2019-02-06T16:11:08.409111-05:00 mtcdt chat[4069]: abort on (ERROR)
2019-02-06T16:11:08.409351-05:00 mtcdt chat[4069]: expect (OK)
2019-02-06T16:11:08.409750-05:00 mtcdt chat[4069]: ^M
2019-02-06T16:11:08.413375-05:00 mtcdt chat[4069]: ^M
2019-02-06T16:11:08.413794-05:00 mtcdt chat[4069]: OK
2019-02-06T16:11:08.414020-05:00 mtcdt chat[4069]: — got it
2019-02-06T16:11:08.414285-05:00 mtcdt chat[4069]: send (AT+CSQ^M)
2019-02-06T16:11:08.486822-05:00 mtcdt chat[4069]: expect (OK)
2019-02-06T16:11:08.487164-05:00 mtcdt chat[4069]: ^M
2019-02-06T16:11:08.494379-05:00 mtcdt chat[4069]: ^M
2019-02-06T16:11:08.494911-05:00 mtcdt chat[4069]: +CSQ: 30,99^M
2019-02-06T16:11:08.495186-05:00 mtcdt chat[4069]: ^M
2019-02-06T16:11:08.495524-05:00 mtcdt chat[4069]: OK
2019-02-06T16:11:08.495751-05:00 mtcdt chat[4069]: — got it
2019-02-06T16:11:08.496014-05:00 mtcdt chat[4069]: send (AT+CGDCONT=1,\”IP\”,\”m2m.com.attz\”^M)
2019-02-06T16:11:08.852902-05:00 mtcdt chat[4069]: expect (OK)
2019-02-06T16:11:08.853241-05:00 mtcdt chat[4069]: ^M
2019-02-06T16:11:08.887378-05:00 mtcdt chat[4069]: ^M
2019-02-06T16:11:08.887807-05:00 mtcdt chat[4069]: OK
2019-02-06T16:11:08.888022-05:00 mtcdt chat[4069]: — got it
2019-02-06T16:11:08.888270-05:00 mtcdt chat[4069]: send (ATDT*99***1#^M)
2019-02-06T16:11:09.021994-05:00 mtcdt chat[4069]: expect (CONNECT)
2019-02-06T16:11:09.022334-05:00 mtcdt chat[4069]: ^M
2019-02-06T16:11:09.061938-05:00 mtcdt chat[4069]: ^M
2019-02-06T16:11:09.062339-05:00 mtcdt chat[4069]: CONNECT
2019-02-06T16:11:09.062549-05:00 mtcdt chat[4069]: — got it
2019-02-06T16:11:09.062863-05:00 mtcdt chat[4069]: send (^M)
admin@mtcdt:/var/log#

[William Laing]

Jeff –

Cellular checkbox is enabled. There is no IP address. And DNS says ‘Not Acquired’.

As far as I can tell, Cellular Configuration is the same (APN, Authentication type, etc.) as the other Conduits.

William

[William Laing]

We just developed a similar issue with one of our IP67 gateways.

When I click on Administration->Remote Management->Check-In To DeviceHQ, I also receive Current Status: failed to open connection with the remote server.

It’s an IP67 running AEP 1.6.4.

It had been checking into DeviceHQ on a regular basis until we installed an AT&T Sim card and enabled cellular.

When we type “nslookup http://www.devicehq.com&#8221;, we get nslookup: can’t resolve ‘http://www.devicehq.com&#8217;

Any help appreciated – thanks!

[William Laing]

Okay, Jason – got it, thanks.

[William Laing]

Great, Jason, thank you as always for the help!

Now that you mentioned the mosquitto_sub commands, (1) I believe can use the AEP API commands as well.

In the meantime, I found a section titled “Setting Up the mDot Using Manual Join” at http://www.multitech.net/developer/software/lora/conduit-mlinux-convert-to-basic-packet-forwarder/ .

(2) Should I configure the xDot as suggested above?

(3) Network Servers can be configured to a range of frequency sub-bands. Packet Forwarders are at FSB=1. Will Packet Forwarders receive all Xdot uplinks, no matter how the xDot is configured (AT+NI, AT+NK, etc.)?

Thank you.

[William Laing]

Okay, Jeff, will do – thanks.

[William Laing]

Hi Jeff –

Five of our Conduits are reporting GPS; one is not. They are all configured the same way as best we can tell.

These same messages are found in /var/log/messages for both Conduits:

2019-01-07T18:28:50.699113+00:00 mtcdt admin: Is GPSD running?
2019-01-07T18:28:50.729038+00:00 mtcdt admin: FIX OK field should be single hex digit: gpsmon data: gpsmon:ERROR: TCP device open error can’t connect to host/port pair.
2019-01-07T18:28:50.758635+00:00 mtcdt admin: GPS does not have a fix yet. Try again later.

Yet one is reporting GPS, and the other is not.

[William Laing]

Okay, we have the debug port working and changed the debug to six, so we can see everything.

The debug messages are fairly self-explanatory, but are they documented somewhere?

Thank you.

[William Laing]

Okay, Jason, thanks.

Which file would contain that debug output?

[William Laing]

We are able to do PUTs using Postman.

A couple things to consider:

+ When I copied your JSON body and tried it, your double-quote characters did not work, so I needed to retype them on my machine
+ Authorization->Type: Basic Auth
+ Authorization->Username: value typed in
+ Authorization->Password: value typed in
+ The JSON body I used was of the form:
{
“deveui” : “00-80-00-00-04-00-99-99”,
“serial_number” : “1234”
}

Hope that helps.

[William Laing]

That procedure worked, Jeff, thanks!

I’m not a Linux admin guru, but it’s interesting that the changes to those two files are undone after a Conduit restart. In any case, we’re up and running.

Thanks, and have a great weekend!

William

[William Laing]

Thanks again for looking into this, Jeff.

I’m not getting an error when I do “sudo su root”. Nothing happens when I execute that command. I remain as user admin.

The third-party vendor’s installation script returns the error I mentioned previously.

We look forward to hearing what you discover.

Thanks,
William

[William Laing]

Hi Jeff,

I used visudo to make the change, but I’m still getting an error with the third-party vendor’s installation script even if I execute with sudo -s <install_script_name.sh>:

Error: Software must be installed as root.
Execute ‘sudo su root’ and retry the install

Is there any way to make ‘sudo su root’ work on the new version of firmware like it used to?

Thanks,
William

[William Laing]

Thanks for looking into this, Jeff.

I’m not a Linux admin expert. Is this something I can change with visudo?

Or should I roll our Conduits back to AEP 1.4.16?

Thanks,
William

[William Laing]

Thanks for the response, Jeff.

It’s a third-party software package, so I emailed them about it.

But we were able to install their software on a couple Conduits several times in the past with an earlier AEP firmware (1.4.16).

Did the ability to sudo go away with AEP 1.6.2?

Thanks,
William

[William Laing]

These look great, Jason, thank you very much!

[William Laing]

Okay, Steve, will do.

Thank you very much for the help.

[Author]

Posts