[William Laing]

Hello Bart –

Were you able to find a solution? I’m seeing the same error message.

Thank you.
William

[William Laing]

Update:

The client replaced an Ethernet cable, and connection was reestablished.

However, it’s still a mystery how the downloaded config for waninfo could report false for available, enabled and current on all network interfaces. They are correct when querying the Conduit directly.

[William Laing]

Hi Mike –

We’re seeing this problem again on an MTCDT-LVW2-247A (firmware 5.2.1).

+ I can ping 8.8.8.8
+ I cannot ping google.com: “ping: unknown host google.com”
+ Our MQTT endpoint to AWS no longer works; I’m guessing for the same reason we cannot ping http://www.google.com?
+ Conduit is only using the Ethernet interface as WAN
+ ETH0 is WAN with Mode=’DHCP Client’
+ I can access the Conduit on my subnet using HTTPS and SSH

Any thoughts?

Thank you.

William

[William Laing]

I’m not sure, Jeff. We see it intermittently, so we’ll take notes when we see it again.

We’re not using C++; we use MQTT extensively from Node-RED.

William

• This reply was modified 3 years, 9 months ago by William Laing.

[William Laing]

Hi Jeff,

We’re seeing this as well on an MTCDT-LVW2-247A Conduit running 5.1.2:

10 Jul 19:26:59 - [info] [lora in:2c1fb2ef.b2b7be] Connected to MQTT for LoRa in node.
10 Jul 19:27:00 - [info] [lora in:2c1fb2ef.b2b7be] LoRa-IN node reconnect
10 Jul 19:27:01 - [info] [lora in:2c1fb2ef.b2b7be] Connected to MQTT for LoRa in node.
10 Jul 19:27:06 - [info] [lora in:2c1fb2ef.b2b7be] LoRa-IN node reconnect
10 Jul 19:27:06 - [info] [lora in:2c1fb2ef.b2b7be] Connected to MQTT for LoRa in node.
10 Jul 19:27:08 - [info] [lora in:2c1fb2ef.b2b7be] LoRa-IN node reconnect
10 Jul 19:27:08 - [info] [lora in:2c1fb2ef.b2b7be] Connected to MQTT for LoRa in node.
10 Jul 19:27:09 - [info] [lora in:2c1fb2ef.b2b7be] LoRa-IN node

Rebooting the device clears it up. Has any solution/workaround been identified since the last post?

Thanks,
William

[William Laing]

Thanks, Jeff, no worries – I hadn’t begun designing/coding yet.

Yes, AT commands make a lot of sense.

Have a great day!

William

[William Laing]

That’s perfect, Jeff, thank you! Just what we need …

Have a great day!

William

[William Laing]

Thank you, Jeff – this is very helpful!

I will open a Portal ticket as you recommend.

Have a great day!
William

[William Laing]

Okay, Jeff – thanks, will do.

Best,
William

[William Laing]

Anyone?

[William Laing]

Thank you for the quick response, Jason.

It appears the problem was caused by environmental factors.

Much appreciated – have a great day!

• This reply was modified 4 years, 1 month ago by William Laing.

[William Laing]

Hi Kim –

Yes, we did get our Node-RED MQTT nodes working again with AWS. But, it’s been a while, and I don’t recall what change(s) we made.

Azure might be different from AWS, but, perhaps sharing some of our configuration will help you:

+ cert files located in var/config/ca-certificates directory
+ verify server certificate is not checked
+ use clean session is checked
+ blank Client ID
+ use legacy MQTT 3.1 support is checked
+ Port 8883

Once we got Node-RED logging working again on 5.x using guidance from the Multitech Support Portal, I believe we saw something in the logs that helped us with the MQTT connectivity issue.

Good luck.

Regards,
William

[William Laing]

Thank you, Jason, that was very helpful.

Have a great day!

[William Laing]

Can anyone help or point me in the right direction?

[William Laing]

We’re publishing from Node-RED to an MQTT endpoint at AWS using QoS=1 on the Node-RED mqtt-out node.

We like to buffer Node-RED to AWS messages during connections outages.

[William Laing]

Oops – I realized the mistake after I posted.

Thanks again!
William

[William Laing]

Thanks, Jeff – that’s very helpful!

That file and the collection endpoints are what we need.

For several of our customer use cases, we’ll need to configure values from software. For example, enabling services like cellular, WiFi client and Bluetooth, and prioritizing WANs for fail-over, etc.

Thanks again and have a great day!
William

[William Laing]

Steve –

One more thing: is there documentation or a configuration file download showing all the Conduit factory default settings?

Thanks,
William

[William Laing]

Okay, Steve, thanks!

[William Laing]

Thank you as always for your help, Jeff.

I had disabled signed firmware validation but hadn’t saved and restarted. That did the trick!

Thank you and have a great weekend,
William

[William Laing]

Thank you, Jeff – we appreciate the help.

Best,
William

[William Laing]

Hi Jeff –

Does the wifiscan script exist on firmware 1.7.4?

The only names I see are:

sudo find / -name ‘*wifiscan*’ -print

/var/lib/opkg/info/jswifiscan.control
/var/lib/opkg/info/jswifiscan.list
/usr/bin/jswifiscan

And jswifiscan appears to be a binary executable.

Using REST API, we have tried clearing the savedNetworks, disabling the wifi client, and then re-enabling the wifi client – to ensure no connections. But we still don’t see any networks. My phone sees about a dozen wifi networks here in the office next to the Conduit.

The client will enter their SSID. We’d like to parse the scanned networks to extract that network and get the rest of the information we need to add it into savedNetworks.

Any help appreciated.

Thanks,
William

[William Laing]

One more question, Jeff –

Do you know if there’s a way to initiate a scan of available Wi-Fi networks that the Wi-FI client (WAN) could use?

We are using the REST API and have tried various combinations of enabling/disabling the Wi-Fi client, resetting Wi-Fi, etc., but nothing seems to initiate a scan. We keep getting empty arrays for wifi/networks and wifi/client/savedNetworks.

Thanks,
William

[William Laing]

Thank you, Jeff – appreciate it!

Have a great day.

William

[William Laing]

Thank you, Jason – that works!

Best,
William

[William Laing]

Okay, Darrik, thank you for the reply.

That’s what I figured …

We’ll probably go with models that support both cellular providers in the future.

Best,
William

[William Laing]

Thank you for the help, Steve.

That explains it – I’ll call our cellular carrier.

I didn’t know we could order SIM cards with SMS capability. I don’t believe we ordered ours that way. At least it’s not obvious from looking at their attributes online on the carrier’s website.

Thank you!
William

[William Laing]

Good Morning –

The SMS capability is interesting. I’ve read through the help sections on AEP->SMS admin pages (Firmware 5.0.0.-AEP), but I cannot find information on how to actually send an SMS to the Conduit.

Any help appreciated!

[William Laing]

Thank you for the information, Brian.

We’ll install OpenVPN and experiment with use cases.

Best,
William

[William Laing]

Good Day –

Just reading this thread from several years ago now:

+ is OpenVPN still the preferred remote access method for AEP Conduits (besides DeviceHQ)
+ does a firmware upgrade still overwrite OpenVPN?

Thanks,
William

[Author]

Posts